The thousand-person design team

A thousand sounds like an ambition to build something large. It is not.

A thousand is what a design function can produce when its permanent team, the specialists it brings in, and the agents it trains are organised as one system. Most of that thousand will never appear on an org chart.

Underneath it is a question most design leaders are sitting with right now. When agents can produce screens, what is a design organisation actually for? And how do you structure one so that the answer is still people?

I built Monotype’s India design team from scratch, and today I lead ten designers across three global platforms. That is small for the scope, and it is deliberate. Growth should follow what the organisation needs, not what a design function is expected to look like.

That restraint taught me more than scale would have. A small team cannot afford to spend its judgement on work a system could carry, so we put the standard into Antiqua, our design system, and spent our time on journeys and on the decisions nobody else could make.

I have not run a thousand-person version of this. What follows is an argument, built from what a small team showed me, about how I would set up a design function from here.

The execution layer, the screens, the alignment, the variants, the edge-case states, is increasingly work a trained agent can produce. That does not make designers less necessary. It changes what they are necessary for.

Even at a junior level, the role becomes problem solving. Imagination, quality, the ability to see how a journey connects across a product: that control stays with people. If anything, it makes the right talent more valuable, because the work that remains is the work that was always hardest to hire for.

So the structure has to be built around ownership of problems, not production of screens. It has three parts: a permanent team that owns the problems, a variable force of specialists, and a bench of agents.

At the top are persona owners, each responsible for one of the people we design for. In a large function that is a director. In a smaller one, like mine today, it is a lead. In a marketplace, that might mean one owner for the merchant experience and another for the consumer. Their job is to understand that customer well enough that the rest of the team never has to guess.

Under them, lifecycle leads own stages of the journey: onboarding, purchase, the everyday product experience. They are accountable for how each journey holds together.

Under the lifecycle leads sit a small number of junior designers. They own parts of those journeys, build out the happy flows, and set the direction a journey needs to take.

At no level does this become a structure where people are optional. That is the point of it.

You do not get to a thousand by adding floors to the building. You get there with two layers that sit around the permanent team rather than beneath it. The first is people.

The variable force is the talent you bring in rather than carry. Some of it is depth: illustrators, animators, motion designers, craft a product needs intensely but not permanently. Some of it is elasticity: additional UX designers when complexity spikes, when speed matters, or when work arrives that was never on the roadmap.

I think specialists matter more in this model, not less. When agents make everyone faster at average work, the person who has solved this exact problem before is what lifts the work above average.

So I hire them differently from a permanent designer. If I need a great onboarding flow, I want someone who has built great onboarding flows, with case studies that prove it. When we brought in an iconography specialist who had worked with some of the best-known consumer brands, what he gave us was simple, grounded in the brand, and set the direction our iconography still follows.

The second layer is agents. They do not sit under anyone. They sit across every layer, and they are spawned for the work rather than assigned to a team.

Each agent is trained for a capability and grounded in what the organisation already knows: its product knowledge, its past work, and the principles of its design system. Some pick up happy flows, some the edge-case screens nobody wants to draw. Several can work together on a high-fidelity prototype, then help test it with unmoderated usability studies.

As prototyping moves closer to code, the bench reaches further. Agents can build part of the handoff layer before work reaches engineering. Even if that is thirty percent of the code, it is thirty percent more than engineering started with before.

The agents are owned by design leadership, collectively. Training them, encoding what the organisation knows, and keeping them honest is leadership work, not an operations function. Shared ownership can easily become nobody’s job, so it has to sit in what leaders are measured on.

This is where the model changes how a function scales. Each layer grows for a different reason.

The real risk in this model is not bad output. It is plausible output that nobody questions, produced by a team that has quietly stopped framing problems.

It hits juniors hardest. For most of us, judgement came from the execution work: drawing the screens, finding the edge cases, getting it wrong in front of a lead. If agents take that work, where do the next leads come from? The model has to answer that by design, and my answer has two parts.

The first is borders. Every designer, junior included, has a defined territory of journeys they own and a level of craft they are held to. Agents can carry the execution, but they do not get the journey. Juniors still need the fundamentals, even when a machine can do much of the work for them.

The second is the system itself. It cannot be a library designers draw from and leave alone. It has to keep evolving, and I challenge my designers to propose new interaction patterns, test them with users, and move the whole system forward. Judgement now gets built by being responsible for evolving a standard, not by executing against one.

An org design is a bet, so it is worth playing both outcomes forward. Neither has happened. They are the scenarios I would plan against.

Design reviews sound different. Nobody presents screens. Persona owners bring evidence about their customer: where merchants lose patience, when consumers come back, what changes with the season. Lifecycle leads walk a journey end to end, including the parts that happen offline.

The bench has done most of the drawing. Prototypes reach users in days, and engineering picks up work that is partly written. Specialists come in, leave a sharper direction behind, and the system absorbs it.

The real signal is the juniors. They are proposing interaction patterns, testing them, and arguing for them in system reviews. Some are ready to lead a lifecycle stage.

The risk in this version is complacency. When everything ships smoothly, nobody asks whether the smooth thing is the right thing.

The output is enormous and nobody can say why the product exists. Every screen is consistent. Activity metrics look excellent. Outcome metrics have not moved.

The juniors have become operators, fast at briefing agents and slow at framing problems. Lifecycle leads review volume instead of shaping direction. The agents were trained once and never corrected, so they reproduce a two-year-old understanding of the product at scale.

The problem is structural, not individual. The system rewarded output, so it got output.

This is the structure I would build toward from a senior director seat or a VP one, and parts of it are already running at a small scale.

I would start with ownership, not agents. Name the customers, give each one an owner, and give every designer a territory. Then make the design system explicit enough for an agent to execute against, because a bench is only as good as the standard it is grounded in. Put one journey on the bench first, judge it by what reaches customers rather than what ships, and widen it from there.

The common instinct is to count: fewer designers, more agents, a cost line that goes down. I think that is the wrong unit. The right question is where judgement lives.

Get that right, and a small team does the work of a thousand. Get it wrong, and a thousand agents do the work of nobody.