We are hiring a design technologist. But we are not hiring the version of the role we eventually want. We are hiring the version the team is ready for, in a deliberate first phase, with a second phase already scoped.
Design technologist is one of the most discussed roles in our field right now. It is the designer who can actually ship production code, the one who closes the gap between Figma and the deployed interface, the unicorn. Every design leader I talk to wants one. Most of the ones who have tried to hire one have been disappointed, and almost always for the same reason: they hired for the endgame. They pictured the senior person who would single-handedly automate the design system, write production code, and partner with engineering as an equal and they wrote a job description to match. The market responded, either by returning too few candidates or by surfacing people who could hit two of the three bars but not the third.
We decided to take a different approach.
What the team is actually ready for
Our starting point is that our mobile design coverage has a gap. My senior designer is SWAMPED. The mobile backlog has been building. I’m serving as a design director on mobile and can’t stay as close to the pixels as is needed over the next 6 months. Whatever we hire, it has to solve this problem in the first quarter of ramp, or we will have hired the wrong thing.
At the same time, we have real ambitions for automating our design system. We want to use AI-assisted tooling — Claude Code, Devon-like agents, and whatever else lands in the next six months — to codify components, auto-generate documentation, and reduce the tax the design system team is carrying manually. This is not the work of the first ninety days. It is the work of the next six months. And it will not happen in a role whose first months were spent in mobile feature execution.
Those two realities, held together, gave us the decision.
The two-phase scope
The first phase is ninety days of senior product design work, paired with our mobile design director, cutting into the backlog. During that window, the hire is a senior product designer in every functional sense: contributing to features, partnering with engineers, shipping. The design technologist title is maintained because we want the person’s title to reflect where the role is going, but the scope is deliberately narrower than the title implies.
After ninety days, the scope shifts. Mobile coverage is no longer the crisis. The hire partners with our design system lead on automation building AI-assisted workflows for component codification, documentation, and the systems work that has historically been manual, slow, and under-resourced. This is the phase the title is actually designed for.
The hire gets one role and one manager. But they get two distinct bodies of work, in sequence, with the handoff planned from day one.
Why we scoped it this way
There are three reasons this structure beats the usual approach.
First, it matches the team’s absorptive capacity. The design technologist role only works if the team around it can productively use what the hire produces. Right now, our design system team is still building the foundations that an automation layer would accelerate. In ninety days, those foundations will be further along, and the team will have actual capacity to collaborate on automation. Hiring the endgame role today would mean hiring someone to build on sand.
Second, it gives the hire a credible first win. Nothing de-risks a complicated role faster than shipping something real in the first quarter. Mobile backlog work is legible, scoped, and high-leverage. The hire will have real wins to point to before they start the harder, more ambiguous work of automation.
Third, it teaches the organization what the role actually is. Half the friction around design technologist roles is that nobody on the cross-functional side knows what one does. By running phase one as “senior product designer on mobile,” we give engineering, product, and the rest of design a shared understanding of how the person works, how they communicate, how they scope. By the time phase two starts, the political and trust capital needed for systems work already exists.
What this decision is really about
Role design is a design problem. It has scope, constraints, users (the hire, their manager, and the team around them), and a set of outcomes to optimize for. Most role design fails for the same reason most product design fails: it optimizes for the ideal case and ignores the onboarding case. We wrote a role that works on day one and grows into its title over the first year. The alternative was writing a role that was right on paper and wrong in practice.
If you are hiring a design technologist this year, my recommendation is to resist the temptation to write the role you eventually want. Write the role your team is ready for today, with a clear second phase. Hire into the first phase. Budget for the second. And be honest about where the handoff sits.