Leadership Garden
The product vision landed with three strategic streams in it, each on a multi-year horizon. I had six engineers, two open reqs, and one lead I would trust with a team on a bad week. The team design workshop was already on the calendar for the following week.
Covering three streams with eight people was the obvious agenda. I threw it out. Two hours on that question produces an org chart nobody can staff, and everybody leaves the room feeling productive.
What follows is the sanitized version of what I ran instead. Four scenarios, one number that decided all of them, and a shape you can reuse next week if somebody has just handed you a strategy with more bets in it than you have people.
The published advice answers a different question
Almost everything written about splitting teams answers one question. Is this team too big?
Chase Seibert states the default position most cleanly, in a post whose title is the whole argument: don’t split the team until you have to. If communication is straining, a split adds cross-team meetings rather than removing them. If the team is thrashing between products, cut the number of products or funnel the backlog through one owner. If it is simply too large, move an engineer somewhere else. He is right, and I have used his argument on myself twice to talk myself out of a split I would have regretted.
Will Larson supplies the numbers everyone quotes. Six to eight in steady state. Grow a team to eight or ten, then bud it into two teams of four or five. Never create empty teams. His sharpest line is the one people skip past: teams under four are a leaky enough abstraction that they behave like individuals, and he says he has regretted sponsoring one every time.
Both of them are describing a split that happens backwards. Something hurts, and you relieve it.
Nothing hurt yet in my case. A strategy had arrived with three multi-year bets in it, and the workshop existed to decide which of them I could resource. Size heuristics have nothing to say about that, because size was not the symptom.
Larson does have an answer for my situation, and it is the strongest objection to everything below. In How to evolve an engineering organization he takes my exact case: you need to focus on more projects than you have properly sized teams. He notes that this pulls people toward creating small teams. His answer is to add workstreams to a proper team instead. Two streams, one team of eight, one manager.
That is correct more often than anyone in my workshop wanted it to be, and it is why Scenario 0 below gets a real seat rather than a courtesy mention. Where it stops short is accountability. A workstream has an owner in the planning sense and nobody in the “this is your mandate for the next three years” sense. When the quarter gets tight, a workstream loses to the team’s headline roadmap every time, because it sits inside that roadmap and losing to it is a Tuesday. A multi-year bet parked as somebody’s second workstream is not being run. Deferring it quietly is worse than deferring it out loud, because nobody ever has to say the sentence.
The constraint is leads
My arithmetic fit on one slide. Eight people. A stream needs roughly four engineers to survive on-call, vacation, illness, the person who eventually resigns, and the basic requirement that more than one human understands the code. Eight buys two solid streams, or one solid and one thin. It does not buy three. Three real teams is a twelve to fourteen person destination, twelve to twenty-four months out.
That was uncomfortable, and it was not the interesting number. The interesting number was one, which was how many proven leads I had (product and engineering).
Every new team is a lead decision before it is a headcount decision. You can hire an engineer in a quarter. You cannot hire a lead who already knows the domain, the codebase, and which of your engineers goes quiet when they are overloaded. Growing one internally takes two or three quarters of deliberate work.
So the earliest honest split date is set by lead readiness. Everything after that is scheduling.
Once I said that out loud, the workshop question changed. Instead of covering three streams, the room had to answer which two start now, who leads the second team, and what gets us to three. Same people, same two hours, and a question they could actually finish.
What lead-ready actually means
I have promoted people into first-team roles on the strength of their technical judgement and watched it go badly. Technical judgement is table stakes. It predicts almost nothing about the first six months.
What I watch for now is narrower.
Can they hold a plan they did not write? A lead who can only execute their own design will quietly rewrite the roadmap into something they find more interesting, and you will not notice for a quarter.
Do they deliver bad news early? Someone who tells me in week two that the estimate is wrong is ready. Someone who tells me in week nine with a recovery plan attached is not, and the recovery plan is the tell. It means they spent seven weeks managing my perception instead of the problem.
Conflict is the one I get wrong most often. When two of their engineers disagree in front of everybody, watch for the lead who defers to seniority, or to whoever pushed hardest, and calls that consensus.
None of this shows up in a normal quarter, which is the awkward part of the whole exercise. The evidence you need arrives during the weeks you would rather nobody was having. So I stop waiting for those weeks and manufacture a smaller version. Hand the candidate a workstream with a real deadline and a genuine dependency on another team. Let them run planning, and stay out of the room. Let them own the escalation when the dependency slips. It will.
Two quarters of that tells me more than two years of strong code review.
You can also hire the lead, and sometimes you should. Just cost it honestly. An external lead needs two quarters to build the trust an internal candidate already has, and you are asking them to spend that ramp on a brand new team carrying a multi-year mandate. That is two unknowns multiplied together, and the multiplication is the part that hurts.
The rules I do not negotiate
Before any scenarios, the constraints I bring into every one of these rooms:
- One team, one area. A team can carry two workstreams if each is staffed to survive on its own. Never three.
- Only form a team for work that will still exist in a year. Anything shorter is a project, and projects do not need an org chart.
- Every team has a named lead on day one. Acting leads by accident are how you burn a good engineer while congratulating yourself on their growth.
- Every new team gets at least one established engineer, ideally two. A team of new hires and good intentions ships nothing for six months.
Those four did most of the filtering before I drew a single box.
Find the fault line before you write scenarios
Two of my three streams were the same kind of work. Operator-facing platform, shared substrate, overlapping users. The product doc had already proposed one designer across both, which told me the product side had reached the same conclusion without writing it down. The third was a specialised data play with different skills and a different failure mode.
If any team was ever going to carry two streams, it had to be those two, and never one of them paired with the data work. That single observation deleted about half the possible org charts before anybody started arguing.
Do this part before the workshop. Otherwise you spend two hours debating combinations that were never viable, and the debate feels rigorous while producing nothing.
Scenario 0: stay one team, sequence the streams
One team of six growing to eight, under the existing lead, working one stream at a time in priority order.
Maximum resilience, no lead gap, lowest risk. Two multi-year bets also sit untouched for years, which breaks focus at the strategy level instead of the team level. Nobody on the team feels that pain, which is exactly what makes it dangerous.
I put it on the table as a real option with a review date attached, and I would do that again. Most workshops treat “not yet” as a failure to decide, so it never gets named. The room then drifts toward a split it cannot staff, because the alternative was never given a seat. Naming it, with an expiry, turns avoidance into a choice.
Scenario 1: three teams now
The org chart the vision implies. One team per stream, everything funded, everybody happy for about ten days.
This is the option everyone wants and nobody can staff. Three teams out of eight people means teams of two and three, which Larson would tell you behave like individuals, and which I would tell you are one resignation away from a stalled stream. Three teams also need three leads. I had one, and two of the three would have been running their first team on their first day of a multi-year mandate.
I put it on the slide anyway. Killing the seductive option with arithmetic in front of the room beats killing it privately and spending the next six months being told you never considered it.
Scenario 2: data plus platform, defer the third stream
Two teams of roughly four. The specialised stream and the foundation stream both start now. The most operations-facing stream waits.
This was my recommendation. It funds the visible part of the strategy and the platform work at the same time, and the deferred stream should genuinely be built on top of that platform rather than beside it. The skill split was clean too: backend-heavy on one side, full-stack on the other, nobody cut in half.
Both costs are real and I named them in the room rather than letting them surface later as surprises. I would be holding two quite different domains in my head, which degrades both. The deferred stream keeps hurting operations in the meantime, and the people living with that pain were sitting at the table while I said it.
Scenario 3: platform plus the third stream, defer data
Same two-team shape, different pairing. Both teams sit on the same substrate and share infrastructure, design and vocabulary.
Lowest context-switching cost of anything on the list, and it removes a technical dependency on another team’s roadmap. What it delays is the most visible part of the strategy, which is a sponsor problem rather than an engineering one. (Sponsor problems have a way of becoming engineering problems about two quarters later.)
I ranked it second and said exactly what would move it to first. If the platform dependency the data stream needed had not been ready, this one flips instantly, because the alternative is a new team spending its first months blocked on somebody else’s delivery date.
The menu is not there so the room can vote
Scenarios exist to force one sentence into the open. Here is the bet we are parking, and here is roughly when we come back to it.
If a team design session ends without that sentence, nothing was decided. You rearranged boxes, everybody kept believing their favourite stream is funded, and three months later a PM asks why nobody has started on their thing. Consensus, it turns out, is what a room produces when it is avoiding a decision.
Two questions could have flipped my recommendation, and I said so in the room rather than presenting the analysis as finished.
Who is actually lead-ready. That call is mine, it is the one I am most likely to get wrong, and it decides whether the split happens in three months or nine.
Which stream is genuinely funded as the priority. That one belongs to me and the product sponsor jointly. It is an argument about revenue narrative versus foundation, and engineering does not get to settle it alone.
Watch where the bottleneck lands
One thing I nearly missed, and Seibert had already written it down years ago. The product side had a single PM across the whole area.
Split engineering into two teams under one PM and the coordination cost relocates to that person’s calendar. You have recreated the focus problem on the product side, where you have no headcount lever at all. Design has the same failure mode and usually gets noticed even later.
Seibert lists exactly this as a reason not to split. You would need another product owner and another designer, going without either is not ideal, and neither is splitting one person across two teams. Reading it back after the workshop, I think he treats that as a cost weighing against the split. I treat it as a precondition. The difference matters, because his version leaves the decision inside engineering, and mine forces a conversation with whoever owns product headcount before anything gets announced.
So I made team formation conditional on the product side matching it one to one, and I said that with the PM in the room rather than in a polite follow-up message afterwards. (Say it in writing later and you have not raised it. You have created a paper trail for the argument you are going to lose in November.) A split that only exists in the engineering org chart is a rename with extra meetings.
Before you draw the boxes
Count your leads before you count your engineers. Find the fault line before you write scenarios, because half the debate you are dreading is about combinations that were never viable anyway.
And if the honest answer turns out to be Scenario 0, take Scenario 0 and set the review date. A holding pattern you chose on purpose beats a split you cannot staff, and your engineers can tell the difference long before you admit it to yourself.