If you are about to hire or promote a head of design, one question under the resume decides how the next year goes: will this person still make things? Not sketch over someone else’s file. Make. Own a real slice of the product end to end and put their name on it. After seven years of managing design teams I will give you my answer flat out. A design leader who stops touching the work forfeits the authority to judge it, and they lose that authority faster than anyone expects. The best ones keep shipping real craft next to the team, and you should hire for that on purpose.
Let me be precise about what shipping means for a leader, because the word gets used to cover a lot of theater. It is not pulling tickets out of a designer’s queue. It is not a Friday redline pass. It is one slice of real product per cycle, built in the same tools your team uses, under the same constraints, through the same review, landing in front of actual users. Small is fine. Unglamorous is better. The test is whether your name is on something a customer touched this month.
I hold myself to that. I lead design, and I am still in Figma and still in the front-end code. Inside a multi-billion-dollar apparel platform, I designed the feature that won our company hackathon and built it in a day with our lead engineer. Then I founded Story Genie and built the thing end to end, flow and copy and front-end, agents handing off to human review. I am not arguing from a theory of leadership. I am arguing from what happens to my own judgment in the weeks I do not build.
Judgment is perishable
Here is the decay, in order. In month one off the tools you are fine, running on cached knowledge of what things cost. By month three your feedback starts drifting toward the artifact and away from the constraints, because the constraints are the part you no longer feel. By month six your notes are unfalsifiable. Make it feel more premium. Tighten the hierarchy. Those are not calls, they are moods, and a designer cannot act on them without inventing the missing half of the decision themselves.
The expensive version shows up in planning. A leader who has not built in a year prices work in last year’s currency. They insist on a two-week estimate for something that is now an afternoon, and they wave through a one-line request that quietly means rebuilding the data layer. Both errors are invisible to them and obvious to everyone on the team, which is exactly how a room stops bringing its real problems to the person in charge.
AI turned that slow decay into a fast one. The price list for design and front-end work now resets every few months, so the gap between a leader who rebuilt something last week and one who last built in 2024 is no longer a matter of taste. It is a matter of being wrong about numbers. And the feeling of being current is not a substitute for being current. METR ran a randomized controlled trial with experienced open-source developers working in their own repositories, and the developers took 19% longer to finish issues when they were allowed to use AI tools (opens in new tab), after forecasting a 24% speedup and while still believing afterward that they had been sped up by 20%. Daily users of these tools, misreading their own speed by forty points. If people with their hands on the keys can be that wrong, a leader estimating from memory has no chance.
Taste that does not know the price of anything is a preference with a title behind it.
The room grants authority. The org chart only assigns it
This is the part founders underrate. Your title makes you the decider. It does not make you the person whose design opinion the team actually weights. Designers extend that quietly, to whoever can do the thing, and you can watch it move in a critique. The research on bosses points the same way. In a study of U.S. and British workers published in the Industrial and Labor Relations Review, Artz, Goodall and Oswald found that a boss’s technical competence is the single strongest predictor of a worker’s job satisfaction (opens in new tab), stronger than every other factor they measured, and that a worker who stays in the same job sees their well-being rise when their supervisor’s competence rises.
There is a longer thread of work on what those authors call expert leaders. In one study in the Journal of Economic Behavior and Organization, the same group looked at US professional basketball and found that a strong predictor of a leader’s success in year T is that person’s level of technical attainment in the underlying activity around year T-20 (opens in new tab), with the effect on team performance visible inside the first twelve months of a coach being hired. Being brilliant at the craft two decades earlier still showed up in the win column.
I want to name the honest limit in that finding, because it cuts at me too. It says past attainment travels. That is true in basketball, where the game in 2005 is close enough to the game today that an old jump shot still teaches you something. Design does not work that way right now. The substrate under our craft is being replaced every few quarters, so attainment from 2019 ages much faster than attainment from a sport with stable rules. Which means the bar is not was this person once great. It is has this person made something real recently.
What still shipping looks like on a leadership calendar
The objection I hear is that there is no room for this in a real leadership week, and the objection is fair, because most people try to do it wrong. They take interesting, critical-path work, then their calendar detonates and a designer is blocked for four days waiting on them. Do that twice and the team correctly decides your building is a vanity project.
So here are the rules I run. One slice per cycle, no more. Never on the critical path, so it can slip a week without hurting anyone. Prefer the work nobody wants: the empty states, the error copy, the internal tool, the migration. Ship it through the same review your designers sit in, and let someone else be the decider on it, which is the part that keeps the whole thing from being theater. One protected day a week, treated like a customer meeting, because it will lose to anything you let it lose to.
The payoff is not the artifact. It is that every build is a cost audit of your own organization. When I build a slice, I find out that our design system is missing the one component everybody hand-rolls, that a local environment takes two hours to stand up, that the handoff to engineering loses a third of the spec. Nobody reports that to you in a one-on-one, and no survey surfaces it with that resolution. You feel it, and then you can fix it as a leader instead of guessing at it.
The failure mode on the other side
The mirror image of this argument is a real problem and I have watched good people fall into it. The leader who ships instead of leading. Gallup puts 70% of the variance in team-level engagement (opens in new tab) on the manager, and that is a full job on its own. Hiring, feedback, protecting focus, making the case for design in rooms your designers never enter. If your building starts eating those hours, you have traded a job only you can do for a job several other people could do.
The tells are easy to check. The interesting work all has your name on it. Reviews sit for three days because you are heads-down. Nobody on the team grew this quarter. Team throughput went down the quarter you started building. If any of those are true, you took the wrong slice, and the answer is to take a smaller and duller one, not to stop.
The rule that keeps it honest: your shipping has to be additive to the team’s output, never a substitute for it. You are not there to be the best designer in the room. You are there to be a leader whose judgment the room can verify.
When a hands-off leader is the right call
There are situations where I would hire the leader who no longer builds, and I would rather tell you than pretend the stance is universal.
The first is scale. A VP of design over forty people and four product orgs has a job that is mostly org design, hiring, budget, and negotiation with peers who control the roadmap. Asking that person to hold a weekly build slot is asking them to do their job badly. What I would still require is recency instead of continuity: they made something real in the last eighteen months, and they can sit in a critique and say what they would do differently at the pixel and why, without hiding behind process language.
The second is a turnaround where the problem is not craft. If your design work is decent and your company cannot decide anything, ship anything, or agree on what it sells, the binding constraint is organizational and the leader you want is the one who can fix operating rhythm and stakeholder trust. Craft will not unblock that. Neither will a leader who retreats into the file because the meetings are unpleasant.
The third is domain. In long-cycle, heavily regulated, or hardware-adjacent work, the cost of a decision moves slowly, so judgment stays fresh much longer off the tools. A leader who last built two years ago in medical devices is far less out of date than one who last built two years ago in consumer AI.
Outside those cases, in the three to fifteen person design teams where most of this decision gets made, I think a full-time manager who does not make anything is a bad trade. You are paying senior money for opinions that get less reliable every quarter.
Three questions that test for it in a hire
Ask to see something they personally made in the last ninety days, and open the file. Not a case study. The file, or the repo, or the live URL. Then ask what it cost and what they cut, which separates people who made decisions from people who narrated them. Then ask who on their team shipped something better than theirs last quarter, because a hands-on leader who cannot name that person is a bottleneck wearing a craft argument as a disguise. I run a longer version of this for individual designers in the interview I use instead of a portfolio walkthrough.
The deflection to listen for is "I enable my team now." From a VP of sixty, that is the correct answer and I move on to their hiring record. From a candidate who will lead four designers at a Series A, it means you are about to add a layer of translation between your product and the people making it, at the exact stage when speed is the only advantage you have.
If you are making this call this quarter
Three paths, and they are for different companies. If you have three to six designers, a healthy product, and one person on the team with real craft and real judgment, promote them and buy them management coaching. You will get a leader who never loses the room, and the management skills are the easier half to teach. If you have eight or more designers and the hiring and roadmap load has become a full job, hire a full-time head of design, and hold the recency bar anyway. If you need craft on the floor and direction in the room right now but a permanent exec is not the right commitment yet, bring in a player-coach who leads and builds, which is what I do and how I would want to be judged. The traits worth screening for either way are laid out in what to look for in a design leader who still builds.
What you are buying with any of these is not slides. It is the hundreds of small calls this person will make in threads you never read, most of which decide whether the product is any good. Those calls are only as good as their sense of what things cost, and that sense is refreshed one way. By making something.
The leader I trust with design is the one who can still be wrong in the actual file, in front of the team, and fix it before the meeting is over. That is not a step down from leadership. It is the part that makes the leadership worth following.