Why great teams can’t be copied

Most managers try to recreate a great team by copying its practices. Here is why that fails, and what to focus on instead.

Apr 14, 2026

👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.

To accelerate your growth see:

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

Most engineering managers carry around a ghost team. It is the team they worked on five or ten years ago where everything clicked: no ego, blameless retros, decisions made in ten minutes that would now take three meetings. They have spent every job since trying to get back there. And every time, it does not quite work.

The reason has nothing to do with the new people being worse, or the company being too big. It is that the kanban board, the lack of standups, the open Slack channels were outputs of trust, not inputs. Copy the outputs onto a team that has not earned the trust yet and you get the cargo cult version. It looks the same from the outside and feels nothing like it from the inside.

Process is scaffolding for trust you do not have yet. When the trust is there, you can take the scaffolding down and the building still stands. When it is not, you cannot.

What great teams actually had in common

The practices on great engineering teams vary wildly. Some pair-programmed all day. Some never paired. Some had a strict standup, some had no meetings at all. What was consistent across every version was three things, and none of them were practices.

People could be wrong without it costing them

When an engineer pushed back on a decision and turned out to be wrong, nothing happened to their standing. When something broke at 2am, the postmortem looked at the system, not the human.

This is the thing every “blameless culture” essay tries to describe. The actual mechanism is boring: leadership absorbed the political cost of mistakes instead of redistributing it down.

Decisions were cheap to make and cheap to revisit

The ghost team you remember probably did not have a great decision-making framework. It had people who could disagree in a meeting, commit afterwards, and bring it up again two weeks later if it was not working.

Nobody treated that as a loss of face. I have written before about the structural reasons engineers stop pushing back, and the through-line is the same: silence is almost always a sign that the cost of speaking up is higher than the cost of being wrong in private.

The manager was a shock absorber

Bad news from above got translated, contextualised, sometimes pushed back on before it reached the team. When something was non-negotiable, it was framed as such with the actual reason behind it.

Nobody had to pretend an executive whim was a brilliant strategic insight. This is harder than it sounds, because the path of least resistance for any manager is to pass pressure straight through. I have covered this in the piece on rants and transparency.

None of those three are practices. They are properties of a relationship, which is exactly why you cannot write them into a team charter on day one.

Building the foundation, not the rituals

If you cannot install the culture, what can you do? You create the foundation, deliberately, through small decisions that compound. None of these will feel transformative on day one. By month four, the team will feel different and you will not be able to point at the exact thing that changed.

Make one cheap, visible bet on trust per week

When an engineer says “I think we should do X” and you would normally say “let me think about it”, try saying yes instead, assuming the cost of being wrong is recoverable. Then make it obvious you are doing it.

“You said this would work better. Let’s try it for two sprints, I’ll back you either way”. The point is not the decision. The point is the precedent. After eight or ten of these, people start bringing you half-formed ideas instead of waiting until they are bulletproof.

Eat the first incident yourself

The first time something breaks in production after you join, your behaviour in the next two hours sets the tone for the next two years. Ask “who deployed this” and you have taught the team to hide. Ask “what did the system let us do that it shouldn’t have” and you have taught them the opposite.

Be obvious about it. Say it out loud, in the room. I have written more about how shallow understanding compounds into incidents, and the postmortem is where that compounding either gets caught or does not.

Translate, do not transmit

When news comes from above that you do not fully agree with, resist the urge to either hide it or repeat it verbatim. Work out what is actually being asked, what the constraint behind it is, and what you genuinely think about it. Then bring all three to the team.

The team does not need you to pretend everything from leadership is wise. They need you to show your work so they can do the same.

Run great 1:1s

Most 1:1s drift into status updates because status is the easiest thing to talk about. Resist that. If you are stuck for a starting point, I keep a generator with a few hundred questions that pulls a fresh set whenever I feel blocked. The questions matter less than the fact that you are signalling that the thirty minutes is for them, not for your status report.

Defend focused hours

One of the most under-appreciated things about the great teams in your past is that people had time to think. Not in theory between meetings, but actual blocks of three or four uninterrupted hours.

If calendars are getting shredded, you can model what good looks like with a focus time calculator and bring the numbers to your skip-level. “My team has 4.2 hours of focus time per week” is a more productive conversation than “we have too many meetings”.

A different way to think about the goal

If you do those things consistently for a quarter, you will start to notice something. Standups get shorter and more honest. Engineers tell you bad news earlier. Disagreements surface in the room instead of in the DMs afterwards.

None of that will be because you installed kanban or banned status meetings. It will be because you spent ninety days making it cheaper to be honest.

The team you are trying to recreate was not the way it was because of the practices. It was that way because someone, probably a manager you did not fully appreciate at the time, was doing the unglamorous work of absorbing pressure, eating mistakes, and making small bets on trust week after week. I put a lot of what I learned into the EM Field Guide, which is the closest thing I have to a single document on this kind of work.

The ghost team in your memory was not perfect either. You are remembering the feeling, not the receipts. What you actually want is not to recreate it, but to build a new team where the same conditions can take hold. That takes longer than you want it to, and the early days will look like nothing is happening. That is what compounding looks like before it starts to compound.

If you enjoyed this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide