Your Org Chart Decides Your Speed
The design technologist isn't a niche hire. It's what design looks like when you stop drawing lines between roles.
A few years ago, I put in a request to hire a remote Design Engineer at a public MarTech company. The request turned into a debate with the CEO about the role itself. For the design systems team, we needed people who could design and ship, not just design and hand off. The CEO agreed with the function. He just didn’t want the title.
“Call them Product Designers,” he said. “I don’t want the engineering team to think we’re hiring engineers under a different banner.”
And many all-hands at that company included this mantra:
We need to act more like a startup.
Startups hire people that are flexible, stretch outside their role, and do everything they can to ship fast. You cannot act like a startup. Not when your org chart is actively preventing it.
The canvas is a lie
There is a story design tells about itself that goes like this: great design comes from exploring options, the more options the better, on a canvas wide enough to hold them all. Figma is the canvas. The job is to fill it with possibilities and converge on the best one.
The story is mostly fiction. True 0 to 1 work, where you are inventing a category or a new interaction model, is rare. Almost all real product work is iteration inside heavy constraints: existing components, existing patterns, existing user expectations, existing data shapes, existing performance budgets. Pretend every feature is a 0 to 1 exploration and you will produce UI churn your users will revolt against. People do not want a new mental model every release. They want their software to feel consistent.
So if “explore widely on a canvas” is not the job, what is?
Design was never about the deliverable. The mockup, the spec, the prototype, none of those are the point. The point is reducing the cost of being wrong before being wrong gets expensive. That is the whole discipline, stated honestly. Everything else is choice of medium.
The medium that makes that cheapest right now is code. The job is to design inside the real product, against real data, with real components, and confront the edge cases the canvas lets you skip. Empty states, error boundaries, loading patterns, slow networks. The mockup makes them optional. The code does not. That is what Design Technologists do. Some companies call them Design Engineers. Some call them UX Engineers. The titles change. The practice does not.
This is not a niche role anymore
Atlassian published a piece naming the role formally. They report 35% month-over-month growth in AI prototyping inside the company and over 12,000 AI-powered prototypes running across teams since they invested in Design Technologists. Their framing is the one I have used for years: people who think like designers and code like engineers, sitting on the seam where most product work actually happens.
Vercel runs a full Design Engineering team that, in their words, skips the traditional handoff process. A designer sketches the start, a Design Engineer iterates in code, the result ships. Linear has built much of its reputation on the polish that Design Engineers like Paco Coursey and Emil Kowalski drive into the product. Stripe and Cursor are hiring for the role at premium compensation. The Browser Company hires Prototypers. Airbnb has UX Engineers.
I have been writing about this practice since 2024, and the part I keep coming back to is not that I saw it early. It is that the people who designed before AI made output cheap have a structural advantage now, not in spite of the change but because of it. Years of doing the work the slow way is what trains the judgment AI can’t replace. The taste, the edge-case instincts, the sense of what not to ship. When execution stops being the bottleneck, that judgment is the entire game. The companies that ship the best software treat this as core, not specialty, and they staff it with people whose taste was forged before the tools got generous.
Why most companies can’t do it
Because the org chart won’t let them.
The MarTech story I opened with is not unusual. It is the median experience. Companies build divisions between roles to manage scale, and the divisions calcify into politics.
Who reports to whom
Whose code can touch the main branch
Whose title implies seniority
Who owns this area and can approve my work
Once those lines are drawn, asking a designer to ship code becomes a territorial dispute, not a craft decision.
The cost is not in any single project. It is in the compound interest. Every handoff is a tax. Every gatekeeping policy is a tax. Every title compromise made to protect someone’s feelings is a tax. Pay them long enough and your billion-dollar company moves at the speed of a 5,000-person bureaucracy, no matter how many times the CEO uses the word “startup” on the all-hands.
Spiegel didn’t hire a PM until employee 201
On Lenny Rachitsky’s podcast recently, Evan Spiegel walked through a decision Snap made early that has stuck with me. Snap had 200 employees before they hired their first product manager. This was not an oversight. It was deliberate.
Spiegel’s concern was that the standard tech org reduces designers to producing visuals in response to a PM’s direction. He did not want that culture to take root. So when designers asked who would write the spec, or coordinate the cross-functional pieces, or run the working group, his answer was: why don’t you just do it yourself?
That single decision shaped Snap’s entire design culture. Designers did not become PM-adjacent assets. They became the engine of product direction. By the time Snap added PMs, the org was load-bearing on design, and PMs slotted into a coordination role rather than a directing role. The product teams I respect most operate the same way regardless of label: design carries the vision, engineering carries the execution, and the people who do both carry the work that crosses the seam.
Most companies do this in reverse. They hire PMs first because PMs are legible to investors and to other PMs. Design gets stacked underneath as a service function. Engineering builds its own walls. By the time anyone asks “why are we so slow,” the answer is in the org chart, and the org chart cannot be edited without bruising every ego it currently protects.
What I’m building, and why it’s hard
I am building a design practice made of Design Technologists. Not designers who could learn to code. Designers who already ship code. People who obsess over implementation details, who think in components and tokens, who care about how a piece of UI fits inside the larger system rather than inside its own frame.
The talent market for this profile is rough. The number of people with even one year of relevant experience is small. The number with two to five years is smaller. Most of them spent the early part of their careers inside design orgs that treated their instincts as a quirk. They were the ones who kept opening dev tools to fix the spacing themselves, the ones who got told, “you’re a designer who codes, that’s interesting, can you go back to making mockups.” Outcasts in the practice they were trying to elevate.
Now those same instincts are the most valuable thing on the team, and most of those people are not looking. The companies that figured this out early have already locked them in. That makes building this practice the hardest part of the entire project, and it is part of why I am writing this. The pool has to grow.
If you are a designer looking for your next role, the work to do right now is not to polish another case study. The case study format belongs to a workflow where the deliverable was the proof. The proof is now the thing, running. Build something. Use AI to learn to prototype outside Figma. Pick a real product, a real flow, and ship a working version of how you would change it. Put it on a URL. Let people click on it.
Show initiative, not credentials. The companies that need this skillset cannot find it through a portfolio of screenshots. They find it through people who already shipped.
Building the practice means building the org
You do not get a Design Technologist practice by hiring Design Technologists. You get it by refusing to draw the lines that make the role impossible.
That means a few things, none of which are radical. Designers can ship code. Engineers can shape interaction. Titles describe the work, not the political concession. Reviews focus on the artifact, not who is allowed to touch which file. The codebase is a shared instrument, not a guarded chamber. The design system is owned in code, not curated in a separate file format that has to be translated by a different team.
If you are a founder or a CEO reading this and thinking about your own team’s velocity, the question to sit with is not whether you should hire a Design Engineer. The question is whether the org you have built leaves room for one to actually do the job.
Most don’t. The ones that do compound.