Welcome

Hello. I’m Richard Allan Lee.
If you’d like to connect, I may have time to talk

I’ve spent 25 years getting closer to the intersection of people, technology, and outcomes — moving along a through-line that started with making things look right, extended to making them work right, and now hovers in the space of making entire organizations work well.

At a more granular level, so far I’ve been an artist, designer, design manager, software developer, revenue ops manager, software engineering manager, ux designer, program management director, commerical drone pilot, podcast host, voiceover actor and musician.   

“That’s nuts!” you might be thinking… Nope. I’m just a life-long learner, a bottom-up thinker, and a systems-builder who’s endlessly curious and utterly unafraid to admit he knows nothing about a topic – and then sets about to fix that!   

The through-line across my life is creativity and problem solving – and always looking for the win-win… for organizations and humans alike. Want to learn more?

The Long Way Around

On a recent cross country road trip with my daughter to see family in the Midwest US, we had a lot of ‘captive audience’ time to chat.

Lots of breaks too, as we took my EV — and while that’s incidental, I can confirm that experience was very manageable, and less fatiguing by far than similar trips in an ICE vehicle.

In discussing our generational perspectives (dad @ 52, kiddo @ nearly 16) topics came up that included music taste, plans and hopes around driving & cars, having kids of their own, how they’re thinking about college and the career path following… and AI.

I want to zero in on a moment when we had moved to discussing AI in her educational experience — from 3rd grade to being a rising sophomore in high school.

We’d talked a bit about her concerns for her classmates tempted to cheat and take the easy road. About their failure to learn how to think for themselves and learn how to learn well. About whether college will pay off for those that take that path. About whether her parents will find good jobs once more.

She’d gotten quiet after I’d asked how much she knew about the positives, the potential upsides that come up in global AI discussions… and I let the silence continue, giving us both some space. Then she said something that simply floored me with her reflection and wisdom:

“Dad, you had your whole life to learn things the old fashioned way, manually. You got to make mistakes and learn from them. You learned from books and from people and from experience. I want that for myself.”

I felt the earth shake. I may have teared up a little — but that was probably just dust in the air. We were driving through an area with nothing but fields of corn and beans, after all.

“That… makes a lot of sense, kid.”

The 30-Point Sprint: How Leaders Hoard Capability Instead of Building It

A staff engineer at a scaling tech company told me about their managing director — someone with organizational authority, access to the best AI tools, and apparently a lot of enthusiasm for using them. The director had assigned themselves 30 development story points in a single sprint. The rest of the team was carrying 6 to 16 each.

“They vibe code everything,” the engineer said, shaking their head. Their team was left babysitting that output.

I’m not here to cast shade, and I’ve seen enough versions of this pattern to know it’s rarely malice — it’s excitement without governance. Glee without the long view. AI makes execution feel effortless, and when that feeling hits someone with organizational authority, the natural instinct is to run with it and stay in motion.

But I keep thinking about what a different story that could have been.

Imagine the same director, the same tools, and the same gap in formal coding skill. Instead of assigning themselves 30 points, they walk into a team standup and say:

“Here’s the problem I was trying to solve, and this is how I approached it with AI. Show me how you would do it the traditional way — and then show me how you would do it with the AI tooling we’ve implemented. Let’s talk through the strengths, drawbacks, and leverage opportunities for all three approaches.”

How different would that be for the team? For that leader? For the org’s health as a whole?

That’s not a weak play. That’s one of the highest-leverage moves a leader can make — using their own ignorance as an opportunity to build a structured learning platform. The team gets to teach. The leader gets to learn. The org gets a three-way comparison that surfaces assumptions, tradeoffs, and best practices that would otherwise stay locked in individual heads — or leave entirely when those people move on.

It becomes a running growth exercise. It compounds, to the good, for a change.

Instead, the reality

30 story points for someone who should be focused on meta-level engineering concerns. A team stuck babysitting their leader’s output. And an opportunity for something genuinely great quietly wasted.

AI gives leaders without deep technical chops a real reason to lean in — not for the first time, but never has it been so readily accessible. The question is whether they use that access to hoard capability or to build it.

The answer is what separates a manager from a leader.

Originally shared on LinkedIn.

A New Job Is Lurking Inside Your Design/Product Org

AI capability inside a design org doesn’t distribute itself.

Enthusiasts will adopt it, of course. They build their own local workflows and see some gains. They may hoard the knowledge — not out of malice, but because nobody’s asked them to share it around. Everyone else keeps working in more traditional fashion, often quietly ashamed of their (self-diagnosed) ignorance.

This is AI Adoption Debt. And it’s not a training problem. Training can build knowledge, but it doesn’t build systems.

The role that builds those systems is forming right now inside mature design and product organizations. It doesn’t have a consensus title yet, and in most orgs, it doesn’t exist at all. Many don’t even know they need it.

What the role is not

It’s not a prompt engineer. It’s not an AI evangelist. It’s not a design technologist in the traditional sense, and it’s not a product manager for your AI tooling budget. Those roles exist and they matter — but they’re not this.

What the role actually is

The role’s primary responsibility is managing organizational AI adoption infrastructure — ensuring that knowledge compounds across teams rather than concentrating among early adopters. It sits at the intersection of DesignOps, systems-level organizational thinking, change management, and technical depth (without requiring engineering-level skills).

AI doesn’t speed up decision-making. Decision-making is still the bottleneck. This role builds the systems that distribute AI leverage equitably across the org so that the bottleneck doesn’t also become a single point of failure.

Building that infrastructure calls for a specific mix of skills

    • Deep familiarity with design practice
    • Systems-level organizational thinking
    • Change management expertise
    • Technical depth (not engineering-level, but fluent)
    • Accumulated judgment and pattern recognition

The 5th dimension: A foundation of judgment

The first four are table stakes. The fifth — judgment — is what separates someone who can describe this role from someone who can actually do it. It’s the ability to read an organization’s readiness, sequence interventions correctly, and know when to push and when to wait. It accrues slowly, can’t be hired in from scratch, and is what makes this role genuinely hard to fill.

Where the role is “beaming in” right now

It’s appearing most visibly inside organizations that have already built mature DesignOps functions. Those teams have the operational muscle memory. They know how to run programs, own shared infrastructure, and manage change at scale. The AI layer is new; the organizational pattern is not.

It’s also showing up in product orgs — particularly in companies where product operations has developed enough structural maturity to absorb a new domain.

Why it doesn’t yet exist

Because most organizations are still in the tool-buying phase. Leadership approves the budget. Individuals experiment. Ninety days later there are a dozen parallel workflows that don’t talk to each other, and one or two enthusiasts burning out trying to carry everyone else toward the goal post.

Nobody paused to ask: who owns the system?

What to do if you’re building a design or product org right now

    1. Audit honestly. Map who’s using AI tools, how, and what’s been shared beyond their immediate team. The gaps will be obvious.
    2. Assign ownership. Not enthusiast ownership — organizational ownership. Someone with design knowledge, organizational authority, and an operational orientation.
    3. Start with vocabulary. Shared vocabulary is what makes it possible for a new hire to be productive in weeks instead of months. It’s the cheapest, highest-leverage infrastructure investment you can make before building anything else.

The organizations that recognize this structural gap early will have a compounding advantage over those waiting for the formal job title to arrive before they act.

The role is forming. The question is whether it forms intentionally inside your org, or by accident.


Originally published on LinkedIn on June 2, 2026.

You Can’t Skip Steps. You Can Only See the Next One.

I was sixteen, maybe seventeen, working the shipping operation for a small publishing house. My job was simple: box the books, run the postage, get the orders out. The books were about process improvement and quality control — dense, technical stuff aimed at engineers and operations managers I’d never met and couldn’t have imagined.

In the downtime between orders, I taught myself to juggle, and I started reading the books almost immediately. Out of curiosity, and a restlessness I didn’t yet have a name for.

But somewhere between the shipping manifests and the packing tape, I absorbed a way of thinking about systems, variation, and process that I had no professional vocabulary for yet — and wouldn’t for years.

I wasn’t actively learning about process control. I was just in the room with books about stuff, right? That distinction turns out to matter more than I understood at the time.


There’s a concept in complexity theory called the adjacent possible. Stuart Kauffman introduced it to describe the boundary of what can come next in biological evolution — not all futures are accessible from a given state, only the ones one step away. Steven Johnson later applied it to innovation: you can’t leap to arbitrary ideas; you can only reach ideas that neighbor your current knowledge and experience.

I didn’t encounter this framework until long after I’d already lived it several times over. When I did, it named something I’d been carrying without language.

That’s the thing about the adjacent possible. From my experience and in the patterns I’ve observed across organizations, you rarely recognize you’re moving into it in real time. You’re just following the problem, the curiosity, the need. The new territory only becomes visible in retrospect.

Most Organizations Try To Leap

Most organizations approach AI adoption the way people approach career planning before they’ve lived enough to know better: they try to leap.

The pattern is familiar enough to be a cliché, but familiarity hasn’t made it less common. Leadership identifies the destination — “we’re getting AI” — and announces it org-wide, often with namedropped companies and models, and almost always paired with vague assurances that this won’t result in layoffs. Then comes the silence. Eventually, links appear, and maybe some basic instructions. Rarely anything that draws a clear line between existing strategy, the gaps AI is meant to address, and how the workforce is actually supposed to use the tools toward that end.

What happens next is predictable. The futurists and early adopters — the people who are curious and adaptive by nature — will engage. They’ll explore, experiment, build local workflows. But their work won’t be aligned or focused, because no one told them what problem they’re solving for the organization. Everyone else pokes at the tool with a stick, gets nothing useful back, and walks away. Adoption flatlines. Leadership concludes the tools weren’t as useful as advertised.

The tools were fine. It’s that steps were skipped.


Don’t Skip Steps

You can’t adopt an AI-native workflow if your team doesn’t share a vocabulary for how AI systems work. You can’t build that vocabulary if people don’t feel safe admitting what they don’t know. You can’t build that safety if leadership is signaling — through rushed timelines, vague reassurances, and the absence of any real curriculum — that uncertainty is a problem to be hidden rather than a condition to be managed.

Each step is only accessible from the one before it. Skipping them doesn’t accelerate the journey. It just means you’ll retrace them later, at higher cost, after something has already broken.

The organizations that move differently do something structurally simple but operationally demanding: they communicate a phased plan that connects strategy to tooling, provides a curriculum that serves every level of expertise and every function, and gives people immediate next steps they can take today. The longer arc includes touchpoints — moments to come together, review what’s been learned, and focus further with more clarity on goals. The plan evolves as the org learns.

The result isn’t that everyone becomes an AI power user overnight. It’s that everyone understands where this is going, how it connects to their work, and what their next step is. Everyone comes along for the ride — or at minimum, knows enough to make an informed decision about how they engage with it.

That’s not a technology problem. That’s an instructional design problem. And it’s solvable.


Closing The Gap Deliberately

Knowing the adjacent possible exists is half the work. The other half is building the bridge to it.

This is where instructional design enters — not as a corporate training concept, but as a discipline for closing the gap between where people are and where they need to be. The best practitioners of it start not with curriculum but with analysis: what does current capability actually look like, what does the next state require, and what specifically stands between the two?

That gap is the unit of work. Not “we need to learn AI” but “our teams can’t evaluate model output because they have no shared criteria for what good looks like.” Instead of the old trope “designers need to code,” the better lens is “designers need enough systems literacy to have a productive conversation with an engineer about tradeoffs.”

In a healthcare UX org, that analysis might produce a capability map showing that clinical researchers can evaluate AI-generated synthesis but lack the vocabulary to specify what they need from a model — which points to the first curriculum artifact being not an AI tools tutorial, but a shared glossary.

The adjacent possible tells you where you’re going. Instructional design tells you how to get there without skipping the steps that make arrival possible.

Organizations that combine both — that map the next achievable state and build deliberate learning infrastructure to reach it — don’t just identify the gap. They close it on purpose, with a plan the whole org can see and follow.


How I Know This Is True

I was trained as a designer — classically, at art school — and somewhere in my first decade of professional work I drifted into engineering. Not because I planned to. Because the problems I was solving kept pulling me one step further into territory I didn’t have a name for yet.

Design gave me the vocabulary for how things should feel and function from a human perspective. Engineering gave me the vocabulary for why things behave the way they do at a system level. Neither one was a leap. Each one was adjacent to where I already stood.

In college, for gas and grocery money, I took a job caring for three disabled adults in their home. Long shifts — sometimes a full weekend, 24 to 48 hours at a stretch. It was unglamorous work in the way that most essential work is unglamorous.

Caring for someone who is wholly dependent on you — for meals, mobility, dignity — compresses your awareness in a specific way. You stop taking your own capability for granted. You develop a constant low-level inventory of what you have, what they need, and what the gap is. Not as a burden, but as a discipline. A practice of noticing.

The adjacent possible of that work wasn’t a job skill. It was an orientation — a habit of accounting for the advantages you’re operating with instead of moving through the world blind to them. Gratitude, yes, but the kind that makes you more capable: functional, not decorative.

Neither transition was planned. Both were adjacent to where I already stood.


What This Has To Do With You

If you’re navigating a career transition, a role change, or an org-wide transformation right now — and in 2026, most people in design and technology are doing at least one of those things — the adjacent possible is a more useful frame than almost anything else I know.

The question isn’t: where do I want to end up? The question is: what is genuinely one step away from where I am right now? What capability, relationship, or context sits just at the edge of my current reach?

That’s the step worth taking. Not because ambition is wrong, but because the steps you skip have a way of showing up later as gaps you can’t explain.

I spent time as a teenager running the shipping operation for a small publishing house — boxing and sending out books about process improvement and quality control before I had any professional context for what those books contained. I spent weekends in college learning what it means to be responsible for someone else’s wellbeing, happiness, and safety. I moved from design into engineering without a plan to do so.

None of it was linear. All of it was adjacent.


Originally published on LinkedIn on May 11, 2026.

Design Operations & Shiny New Tools

Your AI tools are ready. Your design org isn’t.

Design organizations have adopted a remarkable number of tools in a short window — Figma, FigJam, DevMode, and now AI layers on top of all of it. The tools work. That’s not the problem.

The problem is that nobody owns what happens next.

AI adoption isn’t a tools problem. It’s an ops problem.

There’s a pattern I keep seeing: leadership approves the budget, individuals start experimenting, and within 90 days the org has fragmented into a dozen parallel workflows that don’t talk to each other. One or two enthusiasts are burning out trying to carry everyone else toward the goal post. Everyone else is either quietly falling behind or quietly waiting to be shown the way.

This isn’t an AI-specific failure. It’s the same challenge DesignOps has always addressed — just with a new surface area and a much shorter adoption curve compressing the timeline.

What “ready” actually requires

Sustainable AI adoption happens across three layers:

    • Layer 1: The Tool — where nearly all budget concentrates. The licenses, the subscriptions, the pilots.
    • Layer 2: The Workflow — how the tools actually integrate with how people work day to day.
    • Layer 3: The System — the infrastructure for capturing what works, sharing it, governing it, and iterating on it over time.

Most organizations invest heavily in Layer 1, lightly in Layer 2, and do nothing about Layer 3. Then they wonder why adoption stalls six months after launch.

The shared vocabulary problem

One of the earliest symptoms of missing infrastructure is vocabulary fragmentation. Teams develop local language for the same concepts. New hires have no map. Knowledge stays locked in individual heads — and leaves the org entirely when those people move on.

Shared vocabulary is what makes it possible for a new hire to be productive in 15–30 days instead of six months. It’s not glamorous work. It doesn’t make the demo reel. But it’s the foundation everything else is built on, and it’s the cheapest, highest-leverage investment you can make before building any other system.

The governance gap nobody wants to talk about

AI tools introduce new questions that most design orgs haven’t formally answered yet: What’s confidential? What’s a quality standard for AI-assisted work? Who gets attribution? What are we not using these tools for, and why?

Without explicit answers — in writing, owned by someone — teams will answer these questions differently. And inconsistency at that level compounds fast.

DesignOps is the function that builds the guardrails

I’ve started calling the accumulated risk of inadequate adoption practice AI Adoption Debt. Like technical debt, it’s not visible until it’s expensive. Unlike technical debt, most orgs don’t even have a name for it yet — which means they’re not tracking it, not measuring it, and not paying it down.

DesignOps is the function positioned to own this work. Not because it’s glamorous — it isn’t — but because DesignOps already owns the operational infrastructure of the design org. AI adoption is just the newest domain in that scope.

Who owns this?

Right now, in most organizations: nobody. The enthusiasts do their best. The stragglers fall further behind. Leadership looks at tool adoption metrics and sees green.

What’s needed is an explicit owner — someone with design knowledge, organizational authority, and an operational orientation. Not the most excited person. The most equipped person.

Three concrete starting points for org and design leaders

    1. Audit your current AI adoption honestly. Where is it happening? By whom? What’s been shared beyond the team that built it? The gaps will be obvious once you look.
    2. Assign ownership thoughtfully and explicitly. Enthusiast ownership is not organizational ownership. This work needs someone with the authority to set standards and the skill to build systems.
    3. Start with vocabulary before building systems. A shared glossary is not a small thing. It’s the connective tissue that makes everything else transferable.

The tools are ready

They’ve been ready. The question was never whether the tools would work. The question is whether your organization is built to absorb what they make possible — and whether you’re willing to do the unglamorous ops work that separates sustainable adoption from AI Adoption Debt.


Originally published on LinkedIn on May 5, 2026.

Gumbo, Cast Iron Cornbread, and the Best Kind of Christmas Gift

For Christmas last year I asked my wife for an experience instead of a thing.

She turned it into a choose-your-own-adventure. I could pick almost anything — a class, a trip, an outing, something I’d been curious about but hadn’t made time for. The only rule was that it had to be something I’d actually do, not something I’d intend to do and reschedule into oblivion.

I chose a cooking class. Specifically: New Orleans. Cajun. Creole.

The class ran three hours, and it was excellent — hands-on from the start, no standing around watching someone else cook. We moved through several dishes, learning technique and building flavor as we went. The instructor knew the cuisine deeply, not just the recipes.

A couple weeks later I locked in two of the recipes at home: a proper gumbo (chicken, andouille, shrimp — the roux done right, low and slow until it’s the color of dark chocolate) and honey butter cornbread baked in a cast iron skillet. Both turned out well. The gumbo especially — there’s something satisfying about a dish that rewards patience and can’t really be rushed.

I’ve got a few more dishes from that night I haven’t tackled yet. I’m looking forward to them.

We capped the weekend with a family walk at a local park — one of those early spring days where the trees are still bare but you can see the Smokies clearly from the ridge, and the lake catches the light just right. A good reminder that this area has a lot going for it.

This young-at-heart GenX hubby and dad had a pretty good weekend.

If you’re in a gift-giving rut with someone who doesn’t need more stuff: ask them what they’ve been meaning to try. Then make it easy for them to actually do it. That’s the whole trick.

Originally shared on LinkedIn.

I Made a Nail

Last night after work, I headed down to our local Maker Space here in Knoxville and learned some very basic blacksmithing skills in a pretty nifty little smithy that’s a short walk from the rest of the Knox Makers facilities.

I made a nail from mild steel.

One single solitary nail. And it took me a while. There was plenty of sweat — but no blood or tears.

Part of the joy was in slowing down. Being right there in the moment, focused on one thing. The forge, the hammer, the steel, the anvil.

 

The feedback is immediate and physical in a way almost nothing in my professional life is. You hit it wrong, you can see it. You hit it right, you can feel it.

It also gave me real appreciation for the hundreds of years of practice, innovation, and accumulated skill that humans have poured into that trade — and for the effort modern-day folks put into keeping it alive. The people at Knox Makers who run those sessions know their craft. They teach it generously.

And honestly? It made me deeply appreciate our local hardware stores. I’ll never look at a box of nails the same way.

Knox Makers, if you’re not familiar, is a welcoming, weird, wild bunch of subject matter experts in just about any domain you could name — kind, helpful, and cool without any hidden agendas. I’m lucky to have them nearby, and lucky to be a member.

Get out from behind your desk and go learn how to make something new — or old. Work to live.

Originally shared on LinkedIn.

Review: How To Start A New Country

My thoughts on “How To Start A New Country” by Balaji S. Srinivasan

Balaji S. Srinivasan is a prolific writer, founder and entrepreneur. His article from April 9, 2021 proposes starting new countries as digital communities:

The network state is built cloud first, land last. Rather than starting with the physical territory, we begin with a digital community.

Generally he can be depended on to expound at length on widespread topics in what some might call informed forward thinking, and others derisively label as science fiction, wishful thinking or technopositive propaganda. What is propaganda though?

“communication that is primarily used to influence an audience and further an agenda, which may not be objective and may be selectively presenting facts in order to encourage a particular synthesis or perception, or using loaded language in order to produce an emotional rather than a rational response.”

https://en.wikipedia.org/wiki/Propaganda

I would argue that this piece on a rather bold topic IS in fact communication being used to influence an audience, and to FURTHER AN AGENDA. I would not agree that it fits the definition beyond that, as it takes great pains to present facts clearly, perhaps anticipating such accusations and heading them off at the pass.

The article encourages both an emotional AND rational response, and in fact encourages rational thinking as it lays out the thinking behind the initially eyebrow-raising premise – starting a new country.

What case is it trying to make?

The author works to point out and get consensus on the concept of ‘a fresh start’. Why “new” is attractive, beneficial and feasible, comparing the rationale of a new country to that of a new company, new canvas or an empty page. This comparison escalates quickly, to buying vacant land with the idea of development, to new cryptocurrencies being created despite hundreds of perfectly sound ones already being in use.

Why Start a New Country?

Spanning ancient history and modern day events, Balaji quickly and compellingly lays out the “Why”, and moves on to “How”, detailing the specific ways new countries have come into being historically: Elections, revolutions and war. Next up are several modern additions to that toolbox: Micronations, Seasteading and Space. While these are interesting and worth keeping an eye on, his focus is on the concept of Cloud Countries.

Our idea is to proceed cloud first, land last… we start with the digital community… people interested in founding a new virtual social network, a new city, and eventually a new country… we organize our internal economy around remote work, we cultivate in-person levels of civility, we simulate architecture in VR, and we create art and literature that reflects our values.

https://1729.com/how-to-start-a-new-country/

Again, the language implies that every objection to this premise has been captured and countered, including “but, but countries have physical land, and measurable imports and exports, and quantifiable populations!”

Physical land need not be contiguous, and country-scale leaderboards already exist that track the population, solvency and outputs/inputs of countries across the world – so what’s the big obstacle again? Balaji feels path towards building a country lies in a reverse diaspora: a voice into a trickle into a chat room, then a recognized few enclaves in the physical world that correlate to digital communities – call them neighborhoods or call them what you will, the progression seems feasible.

Shared belief as a concept is identified as the fundamental mechanism in how currency works in general, with cryptocurrency specifically as an example of consensus belief, and that other measures of belief include voting with one’s feet, wallet, or even one’s mind via editorial content creation. Beyond simple belief though, the case is made that all the ingredients for this shift are already in place.

… the cloud country concept takes the most robust existing tech stack we have – namely the suite of technologies built around the internet – to route around political roadblocks, without waiting for future physical innovation.

Defining what a country truly is boils down to both quantifiable and societal elements. A country must have numbers, from how many citizens live there and contribute/benefit from statehood, and what it consumes and produces – these things define the impact it has on the global stage. A country must have recognition and representation on that stage, and be able to govern itself effectively.

Comparisons are made between Bitcoin and a new cloud country’s formation – the slow onramp, the gradual building of legitimacy and stored value, and the eventual societal acceptance and financial institution buy-in of Bitcoin we’re seeing in recent times. Another comparison case is made between digital networks like Facebook and Twitter, their longevity and robustness, and the size and robustness of actual nation states:

20% of existing countries have a population of less than 1M and ~55% have a population of less than 10M. This includes many countries people typically think of as “real”, like Luxembourg (615k), Cyprus (1.18M), Estonia (1.3M), New Zealand (4.7M), Ireland (4.8M), Singapore (5.8M)…

https://1729.com/how-to-start-a-new-country/

Wrapping Up

Everything that has been laid out here makes sense, on the surface, but the question of scale and timeframe seem the most pertinent. How large will these cloud nations be, and how long will they take to manifest effectively in the world we’re living in now?

If you don’t believe they’ll manifest at all, the question is really of no concern. However if you see the promise, the potential in this concept – the question is vital, as are the implications.

What can you do to prepare for this? How can you contribute to its inception and guide its evolution? I believe it’s by learning everything you can, keeping an open mind, sharing your insights, hopes, and doubts. Participating rather than standing by, pointing out flaws and looking for solutions, and choosing to have hope for the future rather than assuming things will only get worse.

Read the article, and post your thoughts online. Let’s talk.

This Isn’t Even a Unicorn Role. It’s Just Gibberish.

As a usability professional, the struggle with recruitment communications is real. I want to share some requirements from a recent UX job “description” — in quotes because it’s more of a laundry list of hopes and dreams than a coherent role definition.

Preface

Before I get into it – many items here are better suited for dedicated roles, or too broad for any single UX hire regardless of seniority. Some items are just… odd.

Here’s what this posting actually asked for

    • Establish the company’s technical vision — lead all aspects of the company’s technological development
    • Direct the company’s strategic direction, development and future growth
    • Do workshops internally and with customers
    • Conduct technological analyses and research
    • Open up new whitespaces for us
    • Help in pivoting our image from being an “executor” of designs to a “design & strategic” partner
    • Management of sales process and product delivery
    • Experience in overall transformation of Front/Back end systems for digitization
    • Experience in Mobile First Methodology to ensure internal systems are supported on all devices
    • Expert skills on Project management
    • QA/Test experience
    • PR/marketing experience

Breaking it down

CTO/VP Engineering territory: establish tech vision, lead technological development, direct strategic direction and future growth.

Niche or dedicated role territory: PR/marketing, sales process management, product delivery, project management, QA/Test.

Genuinely odd: “Open up new whitespaces for us.” I’ve been in this field a long time. I still don’t know what action I’m supposed to take on day one to accomplish that.

My Analysis

This isn’t a unicorn role. A unicorn role is a real job that asks for a rare combination of skills. This is a job description written by a committee that never stopped to ask: what does this person actually do on Tuesday morning?

Every touchpoint in your recruitment process is a signal about your organization. A job description this incoherent tells strong candidates — the ones with options — exactly what working there might feel like. They read it and move on.

If you’re writing a job description right now: start with what the person will own. Then what they’ll influence. Then what experience makes someone good at those specific things. That’s a job description. Everything else is a wishlist.

Originally shared on LinkedIn.