The designer as manager

For most of my career, designing meant working through a problem one iteration at a time. You could see the result instantly, but only as a static artifact. The thing you were designing was interactive; the tool you were designing in wasn't. Every generation of tooling improved that loop without ever closing the gap. AI is closing it, and the work looks fundamentally different on the other side.

Now I spend most of my time directing, evaluating, and refining. I write a brief, kick off three explorations in parallel, review what comes back, and give feedback that sharpens the next round. The work is still design. But the shape of the day has changed. It looks a lot more like management.

The multiplier framework

I've revisited Julie Zhuo's The Making of a Manager occasionally over the years, and one distinction has stuck with me: additive versus multiplicative work. She uses a lemonade stand to make the point, which undersells how hard the shift actually is. The point Zhuo was making was that if you spend all of your time doing the work yourself, your contribution is additive. If you build systems and enable others to execute, it's multiplicative. Her rule of thumb: "Anything your report can do just as well or better than you, you should delegate."

The designer who iterates on every screen themselves is doing additive work. The designer who encodes their judgment into a system and directs agents across parallel explorations is doing multiplicative work.

This isn't a new idea in management theory. It's a jarring one for designers, and equally jarring for engineers who built their identity around the craft of writing code. People who stayed on the IC track did so deliberately, sometimes against institutional pressure to move into management. It was a career bet on depth over leverage. Zhuo herself acknowledges that management "is not a promotion but rather a transition." Making that transition by choice is one thing. Watching AI dissolve the assumptions the IC track was built on is another.

That dissolution is already visible. Figma just opened the canvas to agents. Claude can screenshot its own work and iterate before you look at it. Apple just built the same loop into Xcode. But directing an agent on the canvas is nothing like designing on it. It optimizes for the literal goal you gave it, not the implicit standards in your head. That's management, not craft.

Critique as the actual job

Zhuo writes that working with AI is like managing an intern. That's the right shape. For a designer, the more specific shape is critique.

The work isn't design critique, exactly. But if I'm being honest, critique is probably the closest thing a designer can compare this style of iteration to. It has all the familiar moves of critique, like evaluating explorations and articulating the strength of each direction. You also need to continuously provide feedback that sharpens future rounds. Critique isn't something you do in a meeting anymore. It's the job itself.

Critique in its purest distillation was always some version of presenting your raw work in an honest and articulate manner, and using the trust you placed in your team and peers to sharpen and strengthen that work in a way you never could have individually. I've watched that version of critique erode over the course of my career. At Facebook, there was genuine investment in critique, with trained facilitators and explicit norms around showing early work. None of it survived contact with stack rankings and rolling layoffs. When your performance review is a biannual peer ranking, showing rough work is a reputational risk. People stopped doing it. Critique became a showcase.

The next iteration will be worse. People in a room reviewing each other's agent output. That's further from the original spirit of critique than even the performative version was. Nobody's rough thinking is exposed. Nobody's taste is vulnerable.

This matters for the management metaphor because it reframes what working with Claude actually gives you. What it gives you, beyond the speed and scale that get the most attention, is an honest feedback loop. Claude doesn't have a stake in your performance review. It won't remember that you showed a bad idea last Tuesday. The psychological safety that critique is supposed to provide but rarely does in practice? Claude provides it by default. You can throw a half-formed direction at it, get a real exploration back, and make a judgment call without anyone watching. What it can't do is make that judgment for you. That part is still yours.

What's actually changing

Paul Graham described the tension between maker and manager schedules almost two decades ago. Designers have been on one side of that line for their entire careers. Now the line is moving beneath you. Shorter cycles, more context-switching, more time spent evaluating than producing. The meditative quality of solving a problem with your hands is being lost in that. That loss is real.

But Zhuo's point about what managers actually do is worth sitting with: "Your job as a manager isn't to dole out advice or 'save the day'; it's to empower your report to find the answer themself." The designer's taste doesn't disappear in this model. It becomes the thing that makes the whole system work. Without it, you're just generating options. With it, you're selecting, refining, and directing toward something that couldn't have emerged from the tool alone.

In Taste will not save you, I argued that taste alone isn't a moat. I still believe that. But there's a difference between having taste and being able to deploy it. Design teams and the organizations around them have been shrinking, and the designers who remain are doing more of their work through systems. The shape of the work is changing whether any of us are ready for it or not.