Merging two design teams is a leveling problem

August 31, 2026 · Alex Zapadenko

After TheoremOne was acquired, I co-led the integration of its design team with Zemoga's into a single 200-person global practice at Monks. It closed in under nine months — faster than any other function in the company, and not because design is better at mergers. It was that leveling and career paths already existed on one side, so there was something to map onto instead of something to invent under deadline.

Almost none of the work was the org chart.

Two ladders, one word

Both companies had senior designers. Neither meant the same thing by it.

That sounds like a naming problem and it is not. Every consequential decision in a merged org runs through the level: who gets staffed on which client, who reviews whose work, what someone is paid, who is considered for the lead role that just opened. Until the two ladders are reconciled, none of those can be made — or rather, they get made anyway, by whoever is in the room, using whichever company's definition they grew up with. That's how a merger quietly becomes an annexation.

So the first real deliverable isn't a structure. It's a single definition of each level, specific enough that two managers from different companies reading the same portfolio land in roughly the same place. Then everybody gets mapped onto it, which is slow, uncomfortable, and the thing everything else waits on.

Speed is a retention strategy

The reason to do it fast is not efficiency. It's that the ambiguity is what costs you people.

In my experience the ones who leave during an integration don't leave because the answer went against them. They leave during the months when there is no answer — when nobody can say what their title will be, who they'll report to, or whether the ladder they've been climbing still exists. A person told "you're mapped to this level, here's the reasoning, here's what the next one requires" can decide whether to stay. A person told "we're still working through it" is being asked to wait on someone else's timetable with their career as the stake, and the good ones don't have to.

That reframes what you're optimising for. A leveling system that is 80% right in four months does more good than one that is 95% right in a year, because the second one loses people during the eleven months it takes to be careful.

What doesn't merge on that schedule

Ladders, career paths and hiring operations are tractable — they're artefacts, and artefacts can be written down and argued about. Craft culture is not.

How each team decided things — what got escalated, how much divergence was tolerated in a critique, whether a lead's opinion settled a question or opened one — those are habits, and they don't respond to a document. They take much longer, and pretending otherwise by declaring a merged "way of working" in month three produces a document everyone nods at and nobody uses.

The honest sequencing is: reconcile the ladder fast because it unblocks decisions and stops the bleeding, then let the working culture converge slowly through people actually working together on real engagements. Trying to do both at merger speed gets you a worse version of each.

Why one side already had a ladder

The thing that made the merger fast was built years earlier, slowly, and looked like nothing at the time.

Taking that team from ten people to fifty took just under five years. Ten to twenty took forty-one months; twenty to fifty took eighteen. Same company, same market, same person doing the hiring — nearly seven times the rate. The dates are on my about page if you want to check them: I was a design manager at TheoremOne from June 2017, and the second stretch ran from November 2020 to May 2022, roughly one net hire every eighteen days.

What changed was not effort or budget. It was that by 2020 there was somewhere to put people. The slow years bought four things, none of which look like growth on a headcount chart:

Lead roles, so there was a layer between me and everyone else.
Career frameworks, so a promotion was a decision about evidence rather than a negotiation.
Design operations, so staffing a project wasn't a conversation I personally had to be in.
Engagement models, so a new client didn't require inventing a way of working.

That's it. Four pieces of unglamorous scaffolding, and they took three and a half years mostly because I was building them while also doing the work. The second of them is the one the merger ran on.

The failure mode on the other side is worth naming, because it is the common one. A team that hires ahead of its structure doesn't grow to fifty — it grows to about twenty-five and then starts leaking. Everyone reports to one person who is now a full-time bottleneck; nobody can tell whether they're progressing; every new project relitigates process from scratch. The hires keep landing and the capacity doesn't move, which reads as a hiring-quality problem and is actually a structural one.

So when someone asks how fast a design team can double, the useful answer is a question: what happens to the twenty-first person when they arrive? If that can't be answered in specifics, hiring isn't the constraint yet.

What I'm not claiming

Structure doesn't cause growth. The company was growing hard toward five hundred people and was eventually acquired; the demand for designers was pulled by that, not manufactured by me. Plenty of teams build all four pieces and never get the second phase, because the business never asks for it. What structure determines is whether you can absorb growth when it comes — and, as it turned out, whether you can absorb a merger.

I co-led the integration, not led it, and the nine-month figure is the merger closing rather than everything being finished. I ran a 100-person product design org inside the 200-person practice, so parts of this are observed rather than mine. And I have no retention numbers to offer — what I have is the pattern of who left and when, which is evidence of a weaker kind and worth labelling as such.