How I lead

The leap

The senior-designer years were about controlling every output. I would immerse myself in one, two, maybe three projects at once. It was demanding but manageable, and my success was legible: did the design ship, was it right, did it solve the problem.

Then I became a product design lead and none of that held. I went from three projects to a team of 8 people with 8 to 10 projects running in parallel. My old assumption, that I could hold all of it myself, fell apart in about a month. I tried to attend every project meeting. That path leads to burnout, and I got far enough down it to see the end.

Letting go of control

The change was structural. I stopped trying to oversee everything and delegated supervision of the secondary projects to senior designers I trusted. I checked in periodically; my own focus narrowed to 1 to 3 key projects at a time. I made it explicit that seniors were expected to flag when a project was drifting or when they needed my direct input.

That last part is the piece people skip. Delegation without an escalation path is abdication, and the seniors knew it, because if something went wrong the accountability was still mine. Naming the signal made it safe to raise, and it meant I heard about drift from the person closest to it rather than from a stakeholder two weeks later.

It was not comfortable. I had spent years with a hand in every detail, and when designs came back from the designers, they were not the versions I would have made. Some of those versions turned out better than mine.

The identity problem

With the fires under control, a worse problem showed up: I could not tell whether I was doing anything.

In my first four months I felt like I had accomplished nothing. I was not designing screens. My actual contributions were setting direction, aligning stakeholders, unblocking someone, and being the person a designer talks to before they commit to an approach. None of that was visible in the ways I had previously measured myself. I kept concluding it was not enough.

I went looking for how other leads handled it, and found that they struggled with the same thing. The only quantifiable answer anyone offered was OKRs. That did not work for design. Design is a support function, so its OKRs depend on other departments succeeding, which makes them slippery: you can hit yours and still have shipped something nobody used, or miss yours while the product does well.

The finite metrics of a designer, screens shipped and files delivered, do not translate to the work of a lead, which is genuinely open-ended. There is always more that should be done than can be done.

The helicopter view

What settled it was reframing the question. If my job is to help the team meet the business and product goals, then the answer to “how am I doing” cannot be found in my own output. It is in whether the portfolio is pointed at the right things.

That means a helicopter view: rising above the daily noise to check that the whole set of projects is aligned with where the company needs to go, and protecting the team from attractive detours. My job is to make sure we are climbing the right mountain, not to climb it faster than everyone else.

It also changes what the first four months meant. What looked like doing nothing was mostly the cost of finding out which problems were worth the team’s time, and that work does not show up in a file.

What it looks like under pressure

The clearest test of this was Moladin, where the design team went 15 → 10 → 4 through a company-wide pivot. Scope did not shrink with the team: dealer financing, Tuwaga, the web transformation and an SME financing platform all kept running.

The temptation in that situation is to go back to being an individual contributor and pick up the slack personally. I did some of that, and it was the wrong instinct at scale. What actually carried the team was making context cheap to share and decisions easy to find: writing down what had been decided and why, keeping the design library maintainable by four people rather than fifteen, and using AI where it genuinely saved exploration and prototyping time.

The failure I had to design around was not the shrinking team. It was what a departure cost: when a designer left, the reasons behind decisions left with them, and whoever stayed had to work out from scratch why things were the way they were. That is a leadership problem, not a staffing one, and it is the part of the pivot I would do early next time instead of in response to it.

The other half of the pressure was the silo problem. Designers and PMs had drifted into questioning each other without shared context, because designers could not see how commercial decisions were being made. The fix was proximity, not process: designers in the conversations where the decisions happened, close enough to the ops and agent teams that they understood what those teams were dealing with. For internal tools the users are the other teams, which makes that empathy a design input rather than a soft skill.

What I believe about the job

Moving from senior designer to design lead is a change of trade more than a promotion. You give up the satisfaction of a finished screen for work that is messier and more abstract: building a team that can get to answers you would not have reached alone, and making sure it is aimed at the right problem.

That is still the metric I trust: whether the team is clear on the direction and equipped to move in it. Not my output, and not the team’s velocity on its own. Everything else in this essay is how I got to that, and most of it was learned by getting it wrong first.