This is about what happens after you hire them.

Every manager who says they believe in autonomy still hovers the moment a deadline tightens, then tells themselves it’s a trust problem they need to work on.

You don’t have a trust problem. You have an unfinished-casting problem: you’re trying to feel calm about autonomy you never actually earned the right to give.

Danny doesn’t watch Linus climb through the vents

In the vault sequence, Danny is nowhere near Linus. He’s at a blackjack table, calm, not checking his watch every ninety seconds. He’s calm because checking would be pointless: he already answered the only question that mattered, back when he decided Linus was the one person on the crew who could do this specific job.

When casting is done properly, checking in stops doing anything useful. It doesn’t catch problems earlier. It doesn’t make the work better. It just interrupts someone who was already the right choice, on a schedule set by the checker’s nerves rather than anything happening in the work itself.

I watched a lead do this to someone hired for exactly the right reason. It was a good hire: correct casting, the right person for the job. Then the first real incident hit, and the lead pinged them every twenty minutes “just to check in”. They didn’t have anything to add, but checking felt like doing something. By the third ping, the engineer had spent more time writing status updates than fixing anything.

The fix: before you check in, ask yourself honestly whether you’re about to add something only you can add, or whether you’re anxious and calling it diligence. If you hired right, you don’t need to be doing the second one. The check-in is redundant by definition.

Autonomy is a receipt

Somewhere along the way, autonomy got filed under leadership style.

A trait. Something warm, permissive leaders have and controlling ones don’t.

It’s a comforting way to think about it, because it makes the fix sound easy:

• “just be more trusting,”

• “loosen your grip,”

• “believe in your people.”

None of that requires you to look back at who you actually hired. That’s backwards. Autonomy isn’t a mood you cultivate. It’s a receipt, proof the casting work happened, or proof that it didn’t.

Two leads, same line in the all-hands deck: “we trust our engineers.”

One of them actually staffed for the gap, hired the person who could own the ambiguous, cross-team parts of the system without hand-holding, and delegation is genuinely clean, because there was never anything to hand-hold.

The other one didn’t do that work, hired for a slightly different shape of role, and now quietly rewrites half of what gets delegated before it ships.

The fix: stop trying to generate more trust through willpower or generosity. If delegation keeps failing, the fix isn’t “trust more.” It’s going back and checking whether the casting actually supports the autonomy you’re trying to hand out.

When the plan breaks, the crew doesn’t call Danny

Autonomy that only exists when things are calm isn’t autonomy. The real test is the moment the plan breaks. In “Ocean’s Eleven”, Basher’s charges don’t go exactly to script, the getaway route changes, something nobody predicted happens. That’s when you find out whether you built a crew that adapts in its own lane, or a crew that immediately needs a supervisor.

Compare two incidents.

On one team, the specialist hired for exactly this scenario handles it inside their own lane. No drama, no escalation, resolved before most people notice anything happened.

On another team, the same category of incident turns into a twelve-person Slack thread of people “helping,” none of whom were actually the right person for it, all of whom now feel involved.

The fix: after your next incident, count how many people got pulled in who didn’t need to be there. That number is your actual autonomy score.

Autonomy in execution isn’t the same as alone in the dark

None of this means disappearing. Danny Ocean doesn’t run the vault himself, but he’s not off the grid either. He still holds the entire plan in his head, still knows exactly what every piece is supposed to add up to. Autonomy in execution means the interfaces between people are clear. It doesn’t mean nobody talks to each other, and it definitely doesn’t mean nobody knows the goal.

There’s a real difference between a team executing silently against a plan everyone can actually see, and a team that looks autonomous purely because nobody ever explained the goal, so each person is improvising in the dark and calling the resulting chaos independence.

The fix: what you’re actually reviewing, once casting is done, isn’t people’s work anymore. It’s whether the plan is still legible to everyone on it. That’s the job that’s left once you’ve stopped checking in.

Ocean’s crew didn’t need a supervisor watching every vault. It needed someone who already knew, months earlier, exactly who he’d cast for which job.

I noticed my own hovering the same way most people probably do: I caught myself mid-message, typing a status check into a channel where the answer had never once been late. Nothing had gone wrong. I just hadn’t sat with not-checking yet.

Stop trying to feel differently about your team. Go check whether you actually cast them for the gap in the first place. The trust was never the thing you were missing.

I’ve spent the last few weeks doing something most engineering managers dread: hiring.

Not just one role, but a crew.

And somewhere around candidate eleven, I realised I was doing it exactly backwards.

Every manager assumes their hiring problem is a talent problem: not enough strong candidates, not enough budget, not enough time to look properly. It isn’t any of those things.

You don’t have a talent gap. You have a casting gap: you keep hiring for a role you can already cover, instead of the one job on the crew that nobody else can do.

Danny Ocean never once asked if the pickpocket also knew demolitions

Watch the recruiting montage in Ocean’s Eleven again. Danny doesn’t run one process and rank the applicants against each other. He makes eleven separate trips, for eleven separate jobs, and he never once asks Linus if he can also handle explosives. Asking that would defeat the entire point of hiring Linus.

Most engineering teams do the opposite.

There’s one process, one rubric, one idea of what “strong” looks like, usually shaped by whoever’s already succeeding on the team or whoever happens to be running the interview.

Resemblance is easy to defend in a debrief. “They remind me of our best engineer” sounds like a compliment instead of what it actually is: a description of someone you didn’t need. So round after round selects for resemblance. You end up with a bench of people who are all good at the same thing, in slightly different amounts, and nobody who’s good at the thing that you actually need.

The fix: before you open a req, write down what happens the next time something breaks that only a specialist can fix. Hire for that scenario. Not for the average of the team you already have.

The job description is the wrong document. Write the job first.

Most job descriptions come from the same template.

• five years’ experience,

• strong communicator,

• comfortable with ambiguity,

• works well cross-functionally.

Every one of those lines is already true of half your current team, which makes it useless for deciding who to hire next.

I posted a “Senior Backend Engineer” role three times before admitting the actual gap wasn’t backend depth at all. What I needed was someone who could sit between an angry support ticket and the actual root cause: read a stack trace, talk to a customer, and not need a translator in between.

That’s not a title you’ll find on LinkedIn.

It’s barely a skill most JDs know how to ask for. But it was the only job that mattered, and I’d spent time screening for the wrong one because the template told me what a “senior engineer” should look like instead of asking what this specific team was missing.

The fix: before you write the JD, figure out what you need in one sentence. “This person does X, which nobody currently on this team does.” If you can’t finish that sentence, you’re not ready to post the role. You’re ready to write a JD, which is a different and much less useful thing.

Redundant strength is waste. Covered gaps change what a team can attempt.

Here’s the maths nobody runs.

Two people who are both an 8 out of 10 at the same skill don’t combine into a 16. They combine into maybe a 9, because most of what they’re good at now overlaps. One of them is functionally spare capacity, dressed up as a strong hire.

Compare that to a person who’s a 4 out of 10 at your team’s core skill but the only one who’s ever debugged a vendor’s hardware integration under real pressure. Weaker hire on paper. In practice, the only one who moves what your team can actually attempt.

You can run this comparison on the candidates that you actually like. Maybe one is marginally sharper on the core skill everyone already had covered twice over, while the other had spent two years wrangling the exact kind of flaky third-party integration that had been quietly killing your team. On the scorecard, the stronger candidate looks like the better hire. In the job you actually need done, they were the worse one. Consider picking for the gap.

Most managers won’t make that call, because it’s harder to defend upward. “We hired the person who scored lower” sounds like a mistake in a debrief, even when it’s the right decision.

The fix: when two candidates are close, stop asking who scores higher on the rubric you already wrote. Ask which one closes a gap the other one can’t. That’s the actual question. The rubric was only ever a rough proxy for it.

Danny Ocean’s crew didn’t work because every member was the best in the world at their thing (though they were very very competent). It worked because no two of them were doing the same job, so the whole took a shape none of them could have produced alone.

I didn’t have this framing when I started hiring this round. I had a headcount and a template, like most people do. It only clicked somewhere around the fifth or sixth interview, once I noticed I kept asking every candidate a version of the same question, as if I was trying to fill the same one role eleven times over.

So look at your team’s roster right now. If you can’t say what makes each person the only one for their job, ask yourself what job is actually missing.

Cast the gap. Not the resume.

I built a two-part worksheet for you to use for your next hiring — a skills matrix to find your team’s actual gap, and a rubric to hire for it instead of a resume.

Subscribe to ScrambleIT to unlock access.

Subscribe now

This episode puts second chances under a microscope and asks a harder question than most shows bother with: what actually earns one.

Nate is wanted back on the team and has the votes to prove it. Jamie wants his old game back and doesn’t know where it went. Ted wants an ordinary visit from his mother and gets a complicated one instead. Wanting something back doesn’t get any of them there.

What does get them there is way smaller: someone shows up, someone tells the truth, someone remembers what they were once forgiven for. That’s the episode, really.

Colin, Isaac, and Will show up at the Taste of Athens to ask Nate to come back. It’s not a small ask. The whole locker room signed off on it. But Nate hesitates, because nobody asked Beard, or any of the coaching staff, whether they wanted him back too.

He’s right to hesitate.

A decision the team loves can still be the wrong decision if the people who have to live with it every day weren’t in the room. Popularity isn’t buy-in. The players who’ll shake Nate’s hand at kickoff aren’t the ones who’ll sit next to him in tactics meetings for the next six months. Reinstating someone by majority vote skips the slower work of getting agreement from whoever actually has to rebuild the working relationship, and that’s a smaller, less enthusiastic room than the one that voted yes.

Keeley tries to help Jamie the way you’d help most players in a slump: she names the stakes. It’s Man City, his old club. His dad will be in the crowd, booing. Richmond is closing in on the title. Big game, big moment, rise to it.

It doesn’t land.

Pressure doesn’t fix a player who’s lost his sense of self. It only makes the weight heavier. Jamie isn’t undercooked on motivation. “I feel like I’ve lost me wings, Roy” isn’t the sentence of someone who needs a reason to care more. It’s the sentence of someone who doesn’t know who he is on the pitch anymore. Treat an identity problem like a performance problem and you get the opposite of what you wanted, which is exactly what happens here.

So Roy and Keeley try something less clever. After the team’s movie night, they follow Jamie through Manchester and end up, without much of a plan, at his mum’s front door.

She’s the one who gets through.

“You’re not lost. You’re just not sure which direction you’re going. Yet.”

That word “yet” is doing most of the work. Being unsure of your direction is not the same as being lost. One is a place you can’t find your way out of. The other is just where you happen to be standing right now. It’s a small reframe with a large effect: it turns a crisis into a phase, and a phase is something you can coach a person through.

Beard wants nothing to do with Nate’s return. He’s not being petty. He watched Nate torch the thing they built together, and he doesn’t trust that it won’t happen again.

Ted doesn’t argue with him. He shows him something instead: old footage of Nate hiding under the table the night they clinched promotion, tearing up the “Believe” sign after everyone else left the locker room.

“I hope that either all of us or none of us are judged by the actions of our weakest moments, but rather by the strength we show when and if we’re ever given a second chance.”

It’s the line the episode is built around, and it cuts both ways. It’s not just permission for Nate. It’s a standard Ted is asking to be held to himself, and one he’s asking Beard to extend at the exact moment Beard has every reason not to.

Beard goes to see Nate anyway. He tells him a story instead of handing him a decision: the version of himself Ted took a chance on after prison, no conditions attached. It sits close enough to Valjean and the bishop’s candlesticks that the resemblance seems deliberate.

Then he forgives him and invites him back.

The forgiveness you’re slowest to extend is usually the one you’ve forgotten you already received. Beard’s resistance doesn’t crack because Nate makes a good enough case. It cracks because Beard remembers being Nate: standing exactly where second chances get handed out, and someone handing him one anyway. Most of us carry at least one debt like that. Forgetting it is what makes us stingy with the same thing later.

Mae gives Ted a rhyme earlier in the episode about how parents mess up their kids, close enough to Philip Larkin’s poem “This Be the Verse” (”They fuck you up, your mum and dad”). It sets up the real conversation: Ted finally tells his mother the complicated thing instead of the polite thing.

She doesn’t defend herself. She just says: “Your son misses you.” This is why she came to visit. And it absolutely wrecks Ted.

The most useful thing you can say to someone who shaped you badly is what you actually feel. Politeness protects a relationship in the short run and starves it in the long one. Ted gets further with his mother in one honest exchange than he would in years of a comfortable, careful distance.

None of it happens because someone gave a speech. Nate gets back on the team because a teammate remembered what it felt like to need forgiveness himself. Jamie finds his game again because his mother named what he actually felt instead of what would motivate him. Ted gets closer to his mother because he stops being careful with her.

Second chances aren’t a mood that shows up once someone’s earned enough sympathy. They’re closer to a practice, something you choose to extend again and again, especially toward the people who are least convenient to forgive.

Anyone can forgive someone they already like. That’s the easy version of the lesson. The harder version is the more useful one.

Extending grace on the good days doesn’t take much. The practice is doing it on the days you’d rather not.

Subscribe to make sure you don’t miss the season finale next week!

Subscribe now

“I helped five people. Merged nothing. What did I even do?”

I asked him to walk me through the week anyway. Here’s what came out:

• he unblocked three engineers who were each about to spend a day on the wrong thing,

• he connected two efforts that were duplicating each other,

• he caught a dependency nobody else had flagged, the kind that surfaces four days before a release and turns a launch into a scramble.

Zero PRs. Zero lines of code authored. By every measure the team had available, he’d had an empty week.

He was, by a wide margin, the most valuable person on that team for those five days. And he was apologising for it.

The problem is that he had internalised the metric as a value judgment.

That’s how this work dies -by someone deciding that it doesn’t count.

1. If the only thing you can see is what got merged, you will systematically undervalue the people holding your team together

Code output is trivially easy to measure. Commits, PRs, review comments, story points — all of it is already instrumented, already aggregated, already sitting in a dashboard somewhere. Nobody has to advocate for it. It shows up whether you want it to or not.

The work that holds a team together has no instrumentation at all. There is no field for “prevented the wrong thing from being built.” There’s no counter for “noticed the two teams were solving the same problem.” The unblock that saved a day doesn’t appear anywhere, because the day it saved never happened. You can’t measure an averted disaster, only the one that you failed to prevent.

So you end up with a system where one category of contribution is visible, and the other is invisible by default. Not even undervalued but unvalued, in the literal sense that no value is ever assigned.

Then performance review season arrives and you’re asked to compare them.

I’ve watched managers do this with complete good faith and get it so, so wrong. They’re working with the evidence in front of them, and the evidence is structurally incomplete in a way that always favours the same kind of engineer. The person who spent the quarter heads-down on a well-scoped initative has a paper trail. The person who spent the quarter making sure six other people’s work fit together has a Slack history nobody’s going to read.

The fix: before you look at any output data, write down the names of the people whose absence would hurt most. Who you’d panic about losing. These may turn out to be different then the ones who ship the most. Every gap between the two lists is a place your measurement is lying to you, and it’s usually the same two or three names, quarter after quarter.

2. Glue work is the first thing to vanish when people feel measured only by output

Connecting work is genuinely expensive. Walking over to someone’s desk (or reaching out on slack for a quick huddle), understanding a problem that isn’t yours, holding two efforts in your head at once so you can spot the collision is real cognitive load. It comes out of the same budget as your own deliverables, and it comes out first, because interruptions land when they land.

Now add one piece of information: none of it counts.

Nobody has to say this out loud. It’s transmitted through what gets praised, what gets asked about in 1:1s, what shows up on the promotion packet. The engineer runs the calculation and adjusts.

They don’t announce that they’re stopping.
They just start being slightly less available.
The Slack reply comes an hour later.
They notice the duplicated effort and decide it’s not their call to raise.
The dependency question forms in their head and they let it go, because they’ve got their own thing to finish and their own thing is what gets looked at.

And for a few weeks, everything looks better. Their output goes up. They finally have contiguous focus time. Their metrics improve, which confirms to everyone including them that the trade was correct.

Then the seams start failing. Two teams ship incompatible interpretations of the same requirement. A dependency surfaces late and eats a release. The new hire takes eleven weeks to get productive instead of four. None of these failures point back to the cause, because the cause is an absence — a conversation that didn’t happen, a question nobody asked.

The fix: treat responsiveness to other people as a first-class line item in the work, with time protected for it. If someone’s job includes holding the team together, that has to appear in their goals, be defended when their delivery numbers dip, and be the reason they get promoted rather than a charming detail about how they operate.

3. Gratitude you never express is invisible

Most managers I work with genuinely appreciate their glue people. They’ll tell me about them at length.

Then I ask whether they’ve said any of it to the person.

The appreciation is real. It just lives entirely in the manager’s head, where it does nobody any good. And there’s a reason it stays there: appreciation for invisible work feels awkward to voice, because it’s hard to point at.

“Great work on that migration” is easy — there’s a migration.

“Thank you for the way you keep everyone aligned” sounds vague even when you mean it, so it doesn’t get said.

Meanwhile the person is drawing conclusions from silence. They shipped nothing visible, nobody mentioned anything, so the reasonable inference is that the week didn’t count. You didn’t tell them their work was invisible. But you didn’t tell them it wasn’t either.

The fix: name the achievement specifically. “The release shipped because you caught that dependency” does something that “you’re such a great team player” cannot. Say it in front of other people, because that’s how the team learns what actually counts here, and say it when it’s actually happening, while it’s still concrete enough to mean something.

4. Make the invisible work legible instead

You can’t fix this purely by asking managers to look harder. You need the work to leave a trace.

The instinct is to build a metric. But there is a trap here: the moment you count something like this, people optimise for the count, and you get performative helping instead of actual helping.

A few things that work:

Ask a different question in 1:1s. Not “what did you ship” — “what did you stop from going wrong, and who did you help?” People will underreport at first, because they’ve learned this isn’t the kind of thing you bring to a 1:1. Ask it every week and they stop underreporting, and you start accumulating the evidence you’ll need in six months.

Give retro a slot for it. One question: what nearly went wrong and didn’t, and why didn’t it? The answer is almost always a person who noticed something. That’s the record, generated by the team, in front of the team.

Write it down when it happens. Keep a running note per person of the specific unblocks, catches and connections. This is the difference between a promotion case built on evidence and one built on the phrase “everyone knows how important she is”, which, in a calibration meeting against someone with a commit graph, loses every single time.

Check the shape of who does it. Glue work distributes unevenly and the pattern is rarely random. It tends to accumulate on the most senior person on the team, the person who’s been there longest, and on women. If the same people are absorbing all of it while a different set of people get credit for shipping, you have a problem.

5. The teams that get this right don’t have better people

They have a shared answer to a specific question: what does a good week look like here?

On most teams, the answer is “a week where you shipped something.”

On teams that hold together, a good week can also mean the week where you noticed the thing. Where you made the connection. Where you spent Tuesday on someone else’s problem because their problem was going to become the team’s problem by Thursday. It’s visible in what gets asked about, what gets praised, and who gets promoted.

That’s the whole intervention, really. Getting the team to a place where the answer to “what did I even do this week?” can be “you held it together” and everyone in the room, including the person who asked, understands that to be a great answer.

So: who on your team does the work that never shows up anywhere?

Name it this week.

That’s the thing most leadership content won’t tell you, because fast is more comfortable to read about. But if the meaning has been draining from someone’s work for months, you’re not going to fix it with a good 1-on-1 and a fresh set of OKRs.

What you can do is start. And starting the right way matters more than most people think.

First: what doesn’t work

The instinct when a team feels disconnected is to do something visible.

An offsite. A team dinner. A strategy day where you put the mission on a whiteboard and ask everyone to draw a line between their work and the company’s goals.

These things aren’t useless.

But they don’t fix meaning deficit. They address the symptom (low energy, low connection) with a social intervention, while the underlying problem — that people don’t feel their work matters — stays exactly where it was.

I’ve watched leaders run great alignment sessions and come back to the same disengaged team two weeks later.

The offsite felt good. The work still didn’t.

The other common failure mode is going straight to fixing.

The manager senses something is wrong, diagnoses it correctly, and launches into solutions — new projects, clearer priorities, better tooling — without ever stopping to acknowledge what happened.

This fails too, for a reason that’s easy to miss: the engineer doesn’t feel seen.

They know something has been off. When the manager skips past it and starts improving things, it sends an implicit message — that what they experienced wasn’t real enough to name.

The fixes land on top of an unaddressed wound and don’t stick.

The repair

There are three steps. They need to happen roughly in this order.

Step 1: Name it

This is the most important one.

Before you try to fix anything, sit down with the person and acknowledge the gap, not in a clinical, performance-review way, but as one human to another.

Something like: “I’ve been watching how you’ve been showing up lately, and I think the work has felt pretty hollow for a while. I don’t think I’ve been doing enough to change that. I want to.”

That’s it. You don’t need a script. You need to say that you’ve noticed and that you take some responsibility for it.

This does something that no process change can do: it makes the person feel seen. Which is, not coincidentally, the precondition for caring again. People reengage when they feel like someone is paying attention to whether it’s good for them.

Step 2: Renegotiate the contract

Every working relationship has an implicit contract, an understanding about what the person is there to do, what they’re building toward, and what they can expect in return.

When meaning breaks down, that contract has usually drifted. The work the person is doing has stopped connecting to what they actually care about — their growth, their craft, the impact they want to have — and nobody has noticed or addressed it.

The conversation here is not a performance check-in. It’s more of a “What would make the next 90 days feel worth it to you?”

You might hear things that surprise you.

Someone who’s been quietly bored by execution work might want to lead something.
Someone else might want to go deeper into a technical area they’ve been kept away from.
Someone might just want to understand where the company is going and whether their role in it still makes sense.

You won’t be able to say yes to everything. But the act of asking resets the relationship. It signals that their experience of the work matters, not just their output from it.

Step 3: Find the smallest possible win and make it land

This is where most repair attempts get too ambitious.

The instinct is to give the person something big — a significant project, more responsibility, a visible opportunity. Sometimes that’s right. But more often, the thing that actually moves someone from disengaged back to present isn’t a grand gesture.

It’s a small thing that works.

• A ticket they own end to end.

• A decision they get to make.

• A piece of feedback from a user that comes back directly to them.

Something that lets them feel the loop close, even in a small way.

Meaning is rebuilt in proof points. The grand project you’ve put them on doesn’t restore meaning until it ships and they can see it mattered. The small win does it now.

Find the smallest version of meaningful work you can create for them this sprint. Make it land. Then build from there.

A word on timelines

If you’re in month one of this, expect things to get a little worse before they get better.

Naming the problem makes it more real. The conversation in Step 1 can surface things that have been hidden for a long time. You have not made things worse by askig, it’s just a sign that they’ve been sitting with this problem for a while.

Genuine re-engagement usually shows up gradually, a few weeks in.

The questions come back. The energy shifts. Someone volunteers for something they’d normally wait to be asked about.

That’s the thread reconnecting.

You’ve now read three pieces about meaning in engineering teams — how to diagnose it, who’s responsible for it, and how to rebuild it.

So here’s the question I want to leave you with:

Is there someone on your team right now who has already lost the thread — and who you’ve been hoping will sort themselves out?

They probably won’t. Not without you.

And the longer you wait, the more meaning debt compounds and the harder the repair becomes.

The good news is you know what to do now.

Start this week.

This concludes The Meaning Problem — a 3-part series on burnout, leadership, and the one thing that actually keeps great engineers engaged. If this resonated, forward it to a manager you know who needs it.

The answer you give tells me almost everything.

• Some say “the company” — as in, if the mission were clearer, people would be more motivated.

• Some say “the engineers themselves” — they need to take ownership of their own engagement.

• A few say nothing, which is its own kind of answer.

Almost nobody says: “Mine.”

And that’s the problem.

The mission statement won’t save you

There’s a belief that meaning flows down from strategy. That if the company has a compelling enough vision, it trickles down through teams and lands on individual contributors as motivation.

It doesn’t work that way.

I’ve seen engineers at companies with genuinely important missions who were completely checked out. Honestly, I have been that engineer myself.

And I’ve seen engineers at boring B2B SaaS companies who were deeply engaged, because someone had taken the time to connect their work to something they cared about.

Meaning isn’t delivered by the company. It’s constructed in the day-to-day relationship between a manager and their team.

That’s not an inspiring thing to hear. It means more work, not less. But it’s the truth.

The three levers you actually control

You can’t hand someone meaning. But you can create the conditions for it to exist. There are three levers every manager controls and can use deliberately.

1. Context — the why before the what

Every piece of work carries a reason it exists. Most managers communicate the what (the task, the ticket, the deadline) and skip the why.

This sounds small but it isn’t.

“Build the new onboarding flow” lands differently than “Build the new onboarding flow. We lose 30% of users in the first week and this is the one lever we haven’t pulled yet.” Same work. Completely different relationship to it.

Engineers don’t need a TED talk before every ticket. They need enough context to understand where the work sits in the larger picture — what it’s supposed to change, who it’s supposed to help, why now. That takes an extra sentence. Most managers don’t write it.

As a bonus, when you give engineers the “why”, they can actually execute the “what” and the “how” better, because they transform from task executors to problem solvers who look for creative ways to achieve the result, not just meet the acceptance criteria.

2. Visibility — closing the loop after

Meaning isn’t only about anticipating that your work matters. It’s about knowing that it did.

Most teams ship and move on. The next sprint starts before anyone has had a chance to see what the last one actually produced. The feedback loop is broken.

This is fixable. Not with elaborate analytics dashboards — with a habit. When something ships and the data comes in, tell the people who built it. When a customer mentions a feature in a call, forward it. When the metric moves, say so and name the people whose work moved it.

It takes three minutes. It closes a loop that would otherwise stay open indefinitely, leaving engineers to assume, in the absence of signal, that their work didn’t matter.

3. Narrative — helping people see their own growth

This one’s the hardest to do well and the most underused.

People inside their own careers are terrible at seeing how far they’ve come. They’re too close to it. What feels like treading water to them often looks like significant growth to an outside observer.

Your job is to be that outside observer.

I don’t mean it in a performance-review way (”you’ve really grown this year”). Be specific: “Six months ago you wouldn’t have pushed back on that product decision. You just did it naturally. That’s a different engineer than the one I hired.”

That kind of reflection does two things. It makes past work feel meaningful retroactively because it produced real growth. And it makes future work feel meaningful because the person can see that what they do now will compound into something later.

The reason managers don’t do this

It’s not that they don’t care. In my experience, most engineering managers care a lot about their teams.

The reason is simpler: nobody told them this was the job.

The path into engineering management usually runs through technical excellence. You’re good at the work, you get promoted, and suddenly you’re responsible for a team of people and the job is almost entirely different from the thing you were good at.

The craft is now invisible. The output is the team.

Meaning maintenance isn’t in any job description. It’s not discussed in most engineering leadership programmes. It doesn’t show up in sprint metrics or performance reviews. So it doesn’t happen because it doesn’t feel like your job.

It is.

Pick one person on your team. One person you’re not sure about — someone who might be losing the thread.

This week, do three things:

1. give them the why behind something they’re working on,

2. close a loop on something they shipped recently,

3. tell them one specific way you’ve seen them grow.

Not in a formal or structured way. Just as a human being, a manager who’s paying attention.

That’s the job.

Next week we’ll explore How to Rebuild It After It Breaks — what to do when the meaning debt has been compounding for months.

Make sure you’re subscribed so you don’t miss it.

Subscribe now

Some would say it’s exhaustion or stress but it’s subtler than that.

It’s the engineer who ships everything on time, attends every meeting, and has stopped asking why. Who does the work without caring whether it works. Who would describe their job, if pressed, as “closing tickets.”

That’s not burnout from overwork. That’s burnout from meaning loss. And it’s a completely different problem that requires a completely different fix.

The wrong diagnosis costs you the right people

The go-to play that leaders use to respond to burnout is the same: reduce load. They cancel meetings, shuffle sprints, give someone a week off.

Sometimes that helps. Often, it doesn’t. Because they’re treating a meaning problem like a capacity problem.

The engineer who’s lost the thread doesn’t need fewer tickets. What they do need is a reason to care about the ones they have. Giving them more slack doesn’t solve that. It just gives them more time to wonder why they’re there.

The engineers who leave are often the quiet ones. The reliable ones. The ones you assumed were fine.

Three signals your team is losing the thread

You don’t need a survey or an exit interview to diagnose this. You just need to pay attention.

1. They’ve stopped asking why.

Healthy engineers ask why. Why are we building this? Why this approach over that one? Why now? Questions like that are signs someone is engaged enough to care about the outcome.

When the questions stop, it usually doesn’t mean people have run out of questions. It means they’ve stopped believing the answers will change anything.

2. They don’t know what happened after they shipped.

Think about the last three things your team delivered.

• Does everyone on that team know what happened?

• Did the users like it?

• Did it move the metric it was supposed to move?

• Did anyone in the business notice?

Meaning isn’t just about understanding the work before you do it. It’s about closing the loop after. Engineers who ship into a void, who never hear whether the thing they built mattered, will eventually stop caring whether it does.

3. Nobody’s said “I’m proud of that” in a while.

This one’s easy to miss because it doesn’t show up in any metrics.

But think about it: when did someone on your team last express genuine pride in something they built? Not “that went well” or “good job everyone”. Rather “I’m proud of that” or “This was a truly great project”. The kind of pride where someone wants to tell you about a decision they made, a problem they solved, a thing they figured out that nobody else had.

That feeling is meaning in action. When it’s gone, something important has gone with it.

The reframe

Burnout researchers have a useful distinction: there’s burnout from overload and burnout from meaninglessness. They look similar from the outside: low energy, lower output, disengagement. But they have different causes and different cures.

Overload burnout responds to rest. Meaninglessness burnout doesn’t.

If you’ve ever given someone time off and had them come back just as flat, you’ve probably experienced this. They can handle their volume of work. The problem was that they didn’t know why the volume mattered.

The diagnosis is the easy part

If you ran through those three signals just now and felt a disturbing sense of recognition, that’s worth taking seriously.

The good news: meaning problems are solvable. They don’t require restructuring, re-hiring, or a new company mission statement. They require a specific set of actions from the person closest to the work.

That person is you.

The hard question isn’t whether your team has a meaning problem.

It’s whether you know that fixing it is your job.

We’ll dive into that next week in Part 2: Nobody Told You This Was Your Job.

It made the wrong things faster.

We shipped more boilerplate. We prototyped quicker. We spent less time on syntax and more time on integration. But the real bottleneck — the place where work actually stacked up — was exactly where it had always been:

Decisions.

Specifically, the decisions that nobody wanted to own, the ambiguities that needed a human to close them, and the moments where someone had to say “I think this is the wrong direction” in a room full of people who’d been moving in that direction for weeks.

AI didn’t touch any of that. And that told me something important about where senior engineer value actually lives right now.

The model that just broke

For years, a meaningful part of a senior engineer’s value was informational. They knew things. They’d seen the failure modes. They’d read the postmortems. They held context about systems that weren’t documented anywhere except in their head.

Information scarcity made that valuable.

If you wanted to understand how a particular distributed system would behave under a certain load pattern, you asked someone who’d been there. If you needed to know whether a library was actually maintained or just appeared to be, you asked someone who’d tried it. If you wanted to know whether a particular architecture would cause pain eighteen months from now, you found the person who’d lived through the version that did.

That model is breaking.

AI has made information cheaper.

A junior engineer today can get a technically coherent answer to most questions in thirty seconds. They can generate plausible implementations of unfamiliar patterns. They can surface tradeoffs they wouldn’t have known to look for. The information that took years to accumulate is now available to anyone who knows how to ask.

This is good for the industry. It’s also uncomfortable for anyone whose identity as a senior engineer was built on access to scarce knowledge.

AI won’t replace your senior engineers. But it surely will expose which ones were only valuable because information was scarce.

What AI actually exposed

Some engineers who hold senior titles are, functionally, walking libraries. They were indispensable because they knew things other people didn’t, because the cost of figuring it out independently was too high, and because experience had given them pattern recognition that nobody had written down anywhere.

That’s real value. But it’s also value that was partly being propped up by the friction in the system.

When AI lowers that friction, when any engineer can get a reasonable answer to most questions in thirty seconds, you start to see a clearer picture of what different people actually bring.

The senior engineers who are thriving in AI-augmented teams tend to share something. Their value was never primarily informational to begin with.

What remains

There are four things AI has not made cheaper. These are, right now, the clearest expressions of senior engineer value.

1. Judgment about your specific context

AI can tell you how a pattern tends to behave in general. It cannot tell you how it will behave in your system, with your codebase, against your team’s actual skill distribution, given the technical debt you have in the part of the stack it’ll touch, and knowing that one service you’ve been meaning to refactor for eighteen months is sitting right in the blast radius.

That judgment is built from time inside a specific problem. It’s hard to transfer. It’s not searchable. And it’s not something a model trained on generic patterns can replicate.

The senior engineers who know their domain deeply — not just the technology, but the particular shape of how their team uses it — are harder to displace than ever. Because AI amplifies their judgment, not replaces it.

2. Problem framing

AI is very good at solving the problem you give it. It is not good at telling you whether that problem is worth solving or whether you’re actually solving the right problem.

Most of the expensive mistakes I’ve seen in engineering teams weren’t technical failures. They were framing failures. The team solved the wrong problem extremely well. They built the thing they were asked to build when someone, earlier in the process, should have asked why they were building it at all.

Problem framing is

• knowing which question is actually worth asking,

• knowing when the stated problem is a symptom and not the disease,

• knowing when the roadmap item in front of you is going to create three problems for every one it solves

It is still fundamentally a human judgment call. It requires understanding of business context, political context, team context, and a kind of adversarial thinking about your own assumptions that models are really really really bad at.

Senior engineers who are good at this are, in my experience, the rarest type. And right now they’re becoming disproportionately valuable.

3. Risk calibration

There is a difference between “this code is correct” and “this code is safe to ship to production on a Friday afternoon.”

AI is getting better at the first one. It is not good at the second.

Risk calibration is about understanding consequences:

• what happens when this fails,

• who feels it,

• how fast it propagates,

• how visible it is,

• do you have the observability to catch it,

• is your rollback story actually believable under pressure.

It’s about knowing the difference between a risk that looks scary and is actually manageable versus a risk that looks minor and will keep you up at 3 AM.

That calibration is built from watching things go wrong. Engineers who can look at AI output and know which risks are real and which ones don’t matter are the ones everyone else is waiting on.

4. Asking the question nobody wants to ask

The engineer who asks the most uncomfortable questions in your planning meeting is not a problem. They are the only person in the room doing their job.

I’ve watched teams move fast in the wrong direction because the people who could see the problem and didn’t want to be the one who said it out loud. The social cost felt too high, the momentum felt too established, and they weren’t sure their read was right.

Senior engineers who are willing to be that person, who’ve built enough trust and enough self-assurance to slow a room down and say “I think we’re solving the wrong problem” are not just valuable. They’re irreplaceable. No AI is going to do that.

The job has changed again

The job changes when you get to senior. The core shift has always been from solving problems individually to creating the conditions for other people to solve problems better. From being not only the best individual contributor to being a leverage point.

That shift hasn’t reversed, but there’s now a layer on top of it.

The job isn’t just to know, it’s to decide. And more specifically, it’s to decide well in conditions where:

• Information is abundant and judgment is scarce

• AI output needs validation that requires genuine expertise

• The volume of things being built is increasing and the cost of misalignment is increasing with it

• Teams are moving faster on the surface and need someone paying attention to what’s underneath

The senior engineers who are figuring this out are using the new tools to free up time for the things that can’t be delegated.

They’re reviewing AI-generated output at the level of consequence, not syntax. They’re spending more time on problem framing, risk calibration, and the uncomfortable conversations, because the tactical execution is increasingly solved but the strategic layer is still theirs.

That’s the version of the job that actually moves the needle.

If I removed your access to institutional knowledge tomorrow — if everything you know about your specific system were available to everyone on the team via some AI oracle — what value would you still bring?

If the answer is uncomfortable, that’s useful. It means you’ve got work to do.

The engineers who asked themselves that question three years ago and started building toward the judgment, framing, and risk calibration muscles are the most valuable people in the room.

Not because AI didn’t change things.

Because they changed before AI got here.

They’re genuinely excellent — or they were. Deep expertise, strong instincts, huge institutional knowledge. They’ve seen things break in ways the rest of the team hasn’t. They know where the bodies are buried. They remember the migration that nearly killed production in 2019 and exactly why.

When they walk into an architecture review, the room shifts. There’s weight behind their opinions. And usually, they’ve earned it.

Somewhere in the last few years, though, something changed.

Fewer books. Fewer experiments. More reliance on what already worked.

The mental models calcified. Now they’re the ones steering architecture decisions with maps from a different era. The confidence is real. The knowledge is dated.

It looks like strength until the damage is done.

Here are four signals this is happening on your team — and what to do about it.

1. They win arguments with seniority, not substance

When a newer idea gets raised in an architecture discussion, watch how they respond.

Engineers who are still learning engage with the specifics. They ask what problem it’s solving, where it’s been used at scale, what the failure modes are. They may disagree but they disagree with something.

Engineers who’ve stopped learning respond differently. They invoke history. “We tried something like that in 2018 and it was a nightmare.” “I’ve seen this pattern fail before.” “In my experience, this type of solution always causes problems.”

These statements might even be true. But they’re being used as conversation-enders, not contributions. The question of whether the context is different this time — whether the tooling has matured, whether the team’s constraints have changed — goes unexamined.

What makes this especially hard to catch is that the rest of the team usually backs down. They’re junior to this person. They don’t want to seem arrogant. So the argument dies, and it looks like the senior engineer won because they were right. They may simply have been louder.

The fix: In your next architecture review, start asking explicitly — “Has anything changed since then that might affect whether this applies here?” You want to see whether they can engage with the current context, or whether they’re reaching for the past because it’s the only tool they have.

2. Their recommendations look the same regardless of the problem

Good engineers have a toolkit. Great engineers know which tool to pick. Engineers who have stopped learning tend to reach for the same tools, every time, regardless of what you’re actually building.

The microservices advocate who recommends microservices for a three-person startup.

The fan of eventual consistency who applies it to workflows that genuinely need transactional guarantees.

The engineer who knows one way to structure a database and structures every database that way.

This isn’t incompetence. These patterns probably worked, often more than once, in the right contexts. The problem is that the context has been discarded. The recommendation arrives without the reasoning, because the reasoning is “this is what I know.”

You’ll see this most clearly in the gap between their diagnosis and their prescription. The diagnosis is often good — they can still identify what’s broken. But the fix is suspiciously familiar. It maps onto something they’ve done before, sometimes quite precisely.

The fix: Ask them to articulate the tradeoffs of their recommendation. Not “why does this work?” but “what would make you choose something different?” A recommendation with no alternative is a recommendation without real thinking behind it. Engineers who are genuinely reasoning through a problem can always tell you under what conditions their answer changes.

3. Their resistance is non-specific

Healthy skepticism looks like this: “I’ve seen this approach struggle with X and Y, and I think we’ll hit the same problems here because of Z.”

That’s experience being put to work. It’s specific, falsifiable, and engaged with the actual situation.

What calcified skepticism looks like: “I just don’t think we need this,” or “This feels like overengineering,” or “I’m not convinced this is ready for production.” The concern is real. The substance isn’t there.

The distinction matters because one kind of skepticism is a contribution and the other is friction. When a senior engineer raises a specific concern, it starts a conversation. When they raise a general unease, it tends to stop one, because nobody knows quite what they’re arguing against.

The pattern I’ve seen most often: they resist hardest at the edges of their own experience. New tooling they haven’t used. Architectural patterns that emerged recently. Processes that look different from how they learned to work. The resistance scales with unfamiliarity, which is the opposite of how experience-based skepticism should work.

I have fallen into this trap myself multiple times and it took a lot of effort and work on my mindset to stay genuinely open and not resist things just because they’re new and unfamiliar. So I empathize with anyone who experiences this. But they need to push through, because this is the only way to grow.

The fix: When they raise a concern, ask them to make it specific. “What exactly are you worried about here?” Not confrontationally. You genuinely want to know. If they can name it, you can examine it together. If they can’t, that tells you something important about where the concern is actually coming from.

4. The team has quietly routed around them

Watch who your engineers actually go to when they’re stuck. Who gets pinged in Slack when something’s on fire? Whose opinion do people seek out before a big decision? Who gets pulled into the hard conversations informally?

If the answer to all of those questions is no longer your most senior engineer, the team has already made a judgment that the org hasn’t caught up to yet. They’ve decided, probably without ever articulating it, that this person’s input isn’t worth the friction of asking for it. They route around them. They consult them in retrospect. They nod in meetings and then do what they were going to do anyway.

This is usually a slow drift, not a sudden shift. There’s rarely a moment anyone can point to. It just becomes the way things work. And from a management distance, it looks fine — the senior engineer is still delivering, still present, still technically employed. The problem is invisible until it’s not.

The fix: This one requires a direct conversation. Not about performance, but about contribution. “I want to make sure you’re being pulled into the right things. Where do you feel like you’re having the most impact right now?” Listen carefully. If they cite individual delivery and not influence, you have your answer. The team has already moved on. The question is whether they can catch up.

This is almost never a story about a bad engineer. It’s a story about an excellent engineer who got comfortable. The success itself created the conditions for the drift. The more your mental models have worked in the past, the less urgency there is to test them against the present.

Experience without continued learning becomes a liability disguised as authority. The confidence reads as competence. The fluency in the old answers sounds like mastery. But the answers are getting older, and the problems aren’t.

As a manager, you’re not looking for a villain. You’re looking for a person who has stopped investing in themselves, probably without fully realising it, in an environment that never made the investment feel urgent.

Most of them, when you have the conversation honestly, already know. They felt the drift. They just needed someone to name it before they could do anything about it.

Name it.

That’s a hard thing to hear, especially when you’re sitting in a post-mortem listening to someone explain why the feature didn’t ship on time. But here’s what almost never gets asked in those rooms: why did we agree to that deadline in the first place?

The assumption baked into most engineering organisations is that deadlines are a constant and delivery is the variable. Set a date, point the team at it, and if they miss it — that’s an execution problem. An engineering problem.

But almost every missed deadline I’ve ever seen has a management fingerprint on it. Scope that crept in unchallenged. An estimate that got turned into a contract. A warning sign that surfaced two weeks early and went unaddressed until it was too late.

Today, I’m going to walk through the 5 ways engineering managers create the very deadline problems they spend their careers blaming engineers for — and what to do differently.

Let’s get into it.

You set the deadline before engineers estimated the work.

Most missed deadlines are decided before a single engineer looks at the scope.

A stakeholder asks when something will ship. The manager — trying to seem confident, trying to protect the relationship, trying to not look like they’re stalling — gives a number. “Q3.” “Six weeks.” “End of sprint.”

That number gets dropped into a Slack message, then a Jira ticket, then a roadmap. And before anyone has written a line of code, the deadline is already a fact.

The problem isn’t that the engineers can’t hit a target. The problem is that nobody asked them to aim at it first.

Good deadline-setting runs in the opposite order:

1. engineers look at the scope,

2. give an estimate with uncertainty baked in,

3. the manager negotiates between that estimate and business need.

A deadline emerges from that conversation — not before it.

If you’ve ever said “just give me a rough ballpark” to an engineer and then put that number in a document, you know exactly what I’m talking about.

You said yes to scope changes without saying no to the deadline.

Scope creep is not an engineering problem. Engineers didn’t ask for three new features in week four of a six-week sprint. Someone said yes to a stakeholder. That someone was you.

Every time a “small addition” gets absorbed into the work without reopening the deadline conversation, you’ve made a silent decision on your team’s behalf: they’ll either work harder or miss the date. You just didn’t tell them that’s what you chose.

The fix is simple, uncomfortable, and almost nobody does it consistently: every time scope increases, the timeline conversation reopens.

Full stop.

You can add scope or keep the deadline. You cannot do both without an explicit conversation about the trade-off.

A line worth keeping ready for your next stakeholder conversation: “We can add that. Here’s what it costs us in time. Do you want to make that trade?”

You didn’t protect the sprint from “quick” requests.

There is no such thing as a quick request in the middle of a sprint.

A “five-minute fix” still requires context-switching. It still requires testing. If it touches production, it needs a review, a deploy, and someone watching the logs. The work itself might be small. The interruption cost never is.

When multiple people have flagged their thing as urgent, engineers stop trusting the word urgent. They don’t know what to prioritise, so they’re slower on everything. And when the sprint ends, everyone looks at the velocity, not at the four unplanned requests that landed on a Tuesday.

The manager’s job is to be the filter. Every request that arrives mid-sprint should go through you before it reaches your team.

Most can wait. The ones that genuinely can’t should come with an honest conversation about what gets deprioritised to make room.

You treated the estimate as a commitment.

This is my favorite pitfall that we tend to fall into.

Estimates are guesses with professional opinions attached. They are not contracts.

The problem starts when a manager takes an estimate — given with caveats, uncertainty, and a dozen unstated assumptions — and presents it upstream as a hard date.

The caveat gets dropped.

The “depending on the API” disappears.

And now the engineer who said “probably three weeks” is on the hook for a deadline they never actually agreed to.

When engineers figure out this is what happens to their estimates, they stop giving honest ones.

They pad.

They hedge.

They add buffer weeks that get negotiated away anyway. And now your estimation process is broken, your deadlines are still wrong, and nobody trusts each other.

The better approach: when you receive an estimate, ask what it assumes. Ask what could make it longer. Share that context upstream before converting it into a commitment. Your engineers will give you better information when they trust you won’t punish them for accuracy.

You waited too long to have the hard conversation.

Every missed deadline was visible two weeks before it was missed.

The signals are obvious in retrospect: a review where velocity looked off, a standup where someone mentioned they were “still working through” something, a ticket that had been in progress for nine days with no update. The information was there. It just didn’t move.

The hard conversation is the one where you tell a stakeholder, early: “We’re not going to make the original date. Here’s what we know, here’s what we’re doing, and here’s a revised estimate.” That conversation is uncomfortable. It can feel like failure.

But the alternative is delivering that same news two days before the deadline, when there’s no time to adjust, no goodwill left, and everyone is scrambling. That version is ten times worse, and you had two weeks to make it easier.

Early escalation is a leadership skill. It protects your engineers from absorbing blame that belongs higher up. And it builds the kind of credibility with stakeholders that makes every future conversation shorter and less painful.

The pattern across all five of these is the same: the deadline problem was created by a decision the manager made (or didn’t make) long before the deadline arrived.

Your engineers aren’t slow.

They’re carrying the weight of every unclear scope, every unprotected sprint, and every estimate that got turned into a contract without their consent.

Fix the process. The velocity will follow.

Not because nobody thought of it. But because the person who thought of it is two levels below the person who made the call and nobody built a system where that gap could be bridged.

Many engineering teams run on rank-weighted decisions. The most senior person in the room carries the most weight.

Hierarchy fills the silence.

The staff engineer defers to the principal.

The principal defers to the VP.

The VP presents to leadership and calls it “alignment.”

By the time the decision comes out, nobody can quite remember what other options there were.

Ray Dalio wrote about this in Principles, and called the solution an idea meritocracy — a system designed to ensure the best ideas win, regardless of where they come from.

This doesn’t mean chaos where experience and relevant knowledge doesn’t matter. Nor does it mean a hierarchy in disguise where ideas compete but rank quietly tips the scales. It’s something else: a system where your track record, your reasoning, and the quality of your argument determine how much weight your view carries.

I want to show you what that actually looks like inside an engineering team and how to build it without dismantling the authority structures you legitimately need.

Let’s get into it.

Idea meritocracy doesn’t mean everyone’s opinion counts equally.

This is the first thing to get right, because it’s easy to misread Dalio here.

Idea meritocracy is not a democracy. It’s not “we vote on the architecture.” It’s not “the junior dev has as much say as the principal engineer.” Equal voice and equal weight are different things, and conflating them is how well-intentioned leaders produce decision paralysis and ship mediocre outcomes by committee.

What idea meritocracy actually says: your credibility on a given topic should be a function of your track record on that topic — not your seniority in general, or your title, or the volume at which you hold your view. Dalio calls this “believability.”

A junior engineer with five successful production deployments of a specific system has more believability on questions about that system than a VP who hasn’t touched it.

In practice, teams often invert this. Credibility comes from seniority. Seniority is based on title. Title often comes from time served. The engineer with the deepest contextual knowledge gets overruled by the person with the broadest authority, even if that person has not touched the relevant code for years.

The fix starts with disaggregation: stop treating “seniority” as a single variable. Ask instead, on this specific question, who has the most relevant track record? That’s the person whose view should carry the most weight. Of course, reasoning still matters, but this is a good starting calibration.

The HiPPO problem.

HiPPO: Highest Paid Person’s Opinion. You’ve seen this. As a manager, it’s likely you’ve been the HiPPO.

You’re in a design review. Someone proposes an approach. There are three questions in the room, maybe two reservations, but before anyone raises them the most senior person nods and says “I think this is the right direction.” The questions evaporate. The meeting ends. The reservations go with them.

The debate cancelled itself, because the signal from the top made it clear that the decision was already made.

This isn’t bad intentions. People read rooms. They adjust their behaviour based on perceived cost of disagreement. When disagreement feels costly it gets suppressed. And what gets suppressed is almost always the most useful information you had available.

What’s the answer? Radical transparency: say what you actually think, and create the expectation that others will too.

But radical transparency requires something the HiPPO often unintentionally blocks, which is visible tolerance for being wrong. If you’re a senior leader and you’re almost never publicly corrected by someone more junior, that’s not because your ideas are that good. It’s because your team has learned you don’t welcome correction.

Believability weighting.

Once you accept that ideas should compete on merit, you need a system for deciding whose assessment to take seriously.

Make believability visible. Who has demonstrated the most insight on this class of problem? Track it. Reference it. Let it shape whose reasoning gets examined first.

In engineering, this looks like a few concrete things. Run RFCs where authorship and seniority are de-emphasised and the argument stands alone. Log decisions and their outcomes so you can actually see who called it right over time. Establish domain expertise as a formal input to architectural discussions — not “this is the senior person’s call” but “this is the person with the most relevant production experience on this problem, let’s start with their assessment.”

The practical question to ask in any technical discussion: who in this room has the most evidence on this question, and have we heard from them first?

Often the answer is not the most senior person. Usually it’s someone who hasn’t spoken yet because the room already converged.

Radical transparency only works if disagreement has a real cost for the status quo, not for the person disagreeing.

Here’s where most attempts at idea meritocracy quietly fail.

Leaders adopt the language. They say “I want to be challenged.”

They run post-mortems, ask good questions in design reviews. But when someone disagrees, like really disagrees, not “I have a small concern” but “I think we’re solving the wrong problem”, the consequences of that disagreement land on the person raising it, not on the idea being challenged.

They get the “we appreciate your input” and the decision stands. Or they get remembered as “the one who always pushes back.” Or their challenge gets quietly filed as a lack of team-player instinct.

For idea meritocracy to work, it has to be genuinely safe to raise the right point at the wrong time, about the wrong idea, in front of the wrong person. Not theoretically safe but actually safe, where you can see evidence that people who disagreed didn’t end up worse off for it.

You need to build a pattern where you are visibly corrected by junior team members in public, and where you name it positively when it happens. Not “good point” and move on. “I was wrong about this. [Name] caught something I missed.”

Done once in a team meeting, it changes the room. Done consistently, it changes the culture.

Your job isn’t to have the best idea — it’s to find it.

This is the reframe that we often need as leaders.

If your job is to have the best idea, then your team’s job is to compete with yours and lose politely.

Every design review is a performance. Every disagreement is a threat.

You end up with very efficient alignment on your ideas, which is the opposite of what you want.

If your job is to find the best idea — wherever it lives — then your team’s job is to surface it. The dynamic inverts. Disagreement becomes useful. Being wrong in public becomes the mechanism by which you get better outcomes.

This is hard.

It’s hard because it requires accepting that the best thing that can happen in a technical discussion is that someone proves you wrong. And most people, whatever they say, are not ready to experience that as a win.

Start small: in your next architecture discussion, genuinely advocate for the opposing position before arguing for your own. See what that surfaces. The team that watches you do that once will start doing it themselves.

Ray Dalio didn’t build Bridgewater on consensus. He built it on the discipline of surfacing the best available thinking, regardless of where it came from — and on leaders who wanted to be corrected more than they wanted to be right.

Engineering teams that get this right not only just ship better products, but also become the place where people feel their thinking matters. And it turns out that’s a much harder thing to leave than a competitive salary.

Boredom doesn’t announce itself. It doesn’t show up in engagement surveys. It doesn’t produce the kind of friction that makes it onto anyone’s radar. Your most capable engineers don’t complain when they’re bored — they go quiet.

They stop pushing back on decisions.

They start doing the work exactly as asked, nothing more.

They’re polite in 1:1s.

They hit their deadlines.

They answer questions in standups.

And behind the scenes, they’re refreshing their inbox waiting on that one recruiter reply.

The engineers you’re least worried about are sometimes the ones closest to the door, because the work stopped requiring anything from them, and capable people eventually go where they’re needed.

Today I want to give you five signals your best engineers are bored — and what to do before they disappear.

Let’s get into it.

1. They’ve stopped arguing, and that’s not a good sign.

Here’s a reliable heuristic: great engineers argue.

Not obnoxiously, not constantly, but they push back. They ask “why are we doing it this way?” They raise concerns in planning. They catch the thing nobody else noticed and bring it up anyway.

When that goes quiet, it’s tempting to interpret it as growth. Maturity. Trust in leadership.

Sometimes it is. Most of the time, it means they’ve stopped caring enough to disagree. The arguments stopped because the investment did.

The fix: bring the argument to them.

In your next 1:1, ask — “What are we getting wrong right now?”

I don’t mean asking “Is everything okay?” That question has one answer.

You need a question that requires an opinion. The engineer who’s still engaged will have one. The one who’s checked out won’t be able to manufacture one on the spot. That silence is your signal.

2. They’re executing flawlessly on work that’s too small for them.

This one is deceptive because it looks like performance. Tickets are closing. Quality is high. Nothing to flag.

What’s missing is any sign they’re being stretched.

Bored engineers often become very efficient. They’re not distracted. They’re not struggling. They’re doing in two hours what used to take a day, and nobody asks why, because the output looks fine.

The tell is the ratio: how much time are they spending at the ceiling of their ability versus well below it? If there hasn’t been a genuinely hard problem in the last six weeks — something they hadn’t done before, something that required real thinking — they’re probably not being challenged. And “not being challenged” has a shelf life.

The fix: audit their last month of work.

Not for quality, because it’s probably fine. Look for difficulty.

If nothing in there required them to figure something out, you have a challenge problem. Pull them into a conversation about what they’d actually want to sink their teeth into. Most will tell you exactly what it is.

3. They’ve become the team’s unofficial mentor.

This one catches people off guard because it looks like generosity. And it might be.

But it’s worth asking why they suddenly have the bandwidth for it.

When an engineer starts showing up for every new hire’s questions, volunteering for pair programming they didn’t used to do, writing documentation nobody asked for, make sure you track it.

Sometimes that’s a natural evolution into seniority and a sign of growth. But sometimes it’s because their actual job isn’t providing enough stimulation and they’re filling the gap.

The difference is usually visible in the timing. Did this behaviour increase over the last quarter? Did anything else change — a project wrapping up, a scope reduction, a promotion that didn’t come through?

The fix: have the conversation about growth trajectory.

I know it may feel awkward, but it’s your job to ask “where do you want to be in 18 months, and is this job still the best path to get there?”

If they answer entirely in terms of helping others and have nothing to say about their own technical or leadership growth, they’ve stopped picturing a future here. That’s what you’re listening for.

4. Their 1:1s have no friction in them.

A 1:1 without friction is not a sign that everything is fine. It’s a sign the person doesn’t expect anything to change.

Great engineers who are invested bring things to 1:1s. I don’t only mean complaints. Sometimes it’s ideas, concerns about the roadmap, opinions about the team, something they want to try. The conversation has texture.

When 1:1s become smooth and empty:

• quick status updates,

• “nothing much to report,”

• out in ten minutes

someone has given up on the conversation. They’ve done the math and decided that what they raise won’t go anywhere, so why raise it.

The trap is that this feels pleasant. No confrontation, no emotional labour, easy to fill the time and feel like you had a good meeting.

You didn’t.

The fix: change the questions.

Stop asking “how’s it going” and start asking harder, more specific ones.

• “What’s the most interesting problem you worked on this month?”

• “What’s something you wish we’d done differently on the last release?”

• “What would make your job significantly better that I haven’t thought to ask about?”

These questions can’t be answered with “fine.” They require thought. And the engineer who still has something to say will say it.

5. They’re quietly building their next chapter.

This one’s the hardest to see early, but the signals are there.

Their LinkedIn got updated. They’ve become suddenly curious about how performance reviews work and what the compensation bands look like. They’re more interested in external visibility than usual — asking to present at conferences, write things publicly, be attached to the work that gets seen. They’re still doing the job. They’re also constructing a portfolio.

None of these is conclusive on its own. These can be very good signs of someone who is genuinely passionate about the work and wants to grow in multiple directions. But together, they tell a story: this person is preparing to leave, and they’re using their time to build the launch pad.

The fix: don’t try to win a retention battle you let get this far.

The time to address boredom is before the LinkedIn update, not after.

But if you’re already here, the only honest move is a direct conversation: “I want to understand whether you see a future here, and whether I can help build it with you.”

A real conversation about whether there’s a path worth staying for.

Sometimes there is. Sometimes there isn’t. But if you genuinely care about the people on your team (and you should), the kindest thing you can do may be to help them leave well.

Frustration is loud. Boredom is quiet. And quiet is how you miss it.

The engineers most likely to leave aren’t the ones banging on your door about problems. They’re the ones who stopped seeing the point in doing that. They’ve already made their peace with going. They’re just waiting for the right moment.

By the time you notice, the decision is usually already made.

The good news: every one of those five signals is visible before the exit interview, if you’re looking.

The question is whether you’re asking the right questions, or just enjoying the absence of noise.

This is the episode where things stop working.

Not for Richmond, Richmond is fine. Richmond is winning. Sam is on form, total football is clicking, the results are coming in. Externally, things look better than they have all season.

But for almost everyone else, the scaffolding comes down. Nate’s West Ham experiment collapses. Keeley’s agency funding vanishes. Sam finds out his national team spot was bought away from him. Rebecca walks into a room of powerful men trying to strip football of the thing that makes it worth anything.

The interesting part isn’t the collapse. The interesting part is what gets revealed underneath it.

When Nate loses West Ham, he finds his parents’ house.

When Keeley loses her agency, she finds Mae with a pint.

When Rebecca steps into the super league meeting, she finds something she didn’t know she was going to say.

When Roy finally shows up at Keeley’s door, he finds three words and an admission that was overdue by months.

The episode keeps asking the same question: when the external structures disappear, what’s actually underneath?

The answer, again and again, is the same. The real thing was always there. You just couldn’t see it through all the rest.

Nate quits West Ham.

He doesn’t announce it. He doesn’t make a speech. We don’t even see it happen, we just find out it happened off screen. And then he goes somewhere he hasn’t needed to go in a long time: home.

He doesn’t explain himself to his parents. He just arrives, goes to his old room, and sits with it. His mother doesn’t ask what happened. She doesn’t offer advice. She doesn’t push. She just brings him food. Quietly, steadily, without commentary she brings him a tray. Comes back for it later. Brings another. The montage is a few seconds long and it’s one of the most devastating things in the season. His parents already knew who he was. They were just waiting for him to come back to it.

Unconditional support doesn’t require an explanation. It just keeps showing up.

Nate spent a season building a version of himself he thought would earn respect, fear and belonging. He wore it at West Ham. He performed it for Rupert. And when it stopped working, the thing waiting for him was his mother with a tray. That’s not a small thing. That’s the thing.

There’s a version of this in every team. The person who goes quiet after a failure, who retreats into themselves, who can’t yet say what happened. The instinct is to probe, to check in, to ask questions, to get them to open up.

Sometimes what they need is the tray. Just presence. Without agenda. Without the conversation they’re not ready to have.

Keeley finds out about losing her funding in the worst possible way.

Not from Jack. Not in a call, not with any of the decency the relationship implied. She walks into her own office and Barbara tells her that the VC has pulled out. Just like that. The company Jack funded, the agency Keeley built, the thing that was supposed to be a partnership and the person on the other side didn’t even pick up the phone.

Keeley goes to the bar. Mae pours. Keeley says she has the Midas shits, not the Midas touch. Mae, without skipping a beat: shit is what helps things grow.

How someone delivers bad news tells you everything about how much you actually mattered to them.

Jack managed the situation. She didn’t manage the person. The funding was pulled through proper channels, and the human being at the centre of it found out last. There’s a particular cruelty in that efficiency. Keeley was a portfolio decision. Not a partner.

Mae’s line is funny and also true. Keeley doesn’t need the Midas touch right now. She needs fertiliser. She needs the shitty part that comes before the growing.

Edwin Akufo comes to Ola’s.

He’s charming, as always. And then he tells Sam that he paid the Nigerian government twenty million dollars to keep Sam off the national team.

As punishment for not signing onto hist team.

Because that’s what you do when you have more money than anyone can say no to: you make sure the people who say no anyway learn what that costs.

Money can buy the absence of someone’s name from a list. It cannot buy the fact of who they are.

Sam hears this and has to sit with the knowledge that his merit was never the obstacle.

He was good enough. He is good enough. He was kept out by something that had nothing to do with football.

There’s a particular kind of injustice in that: not the injustice of failure, which you can at least understand and work with, but the injustice of someone reaching into the space where your ability should be enough, and deciding it isn’t, because they have the money to decide that.

Akufo says it like he’s showing Sam the true nature of things. Like wealth makes you honest. What it actually reveals is that the money is the only thing he has that Sam doesn’t.

That’s a smaller advantage than he thinks.

Rebecca is invited to Akufo’s super league meeting by Rupert.

She goes. She sits in the room. She listens to the pitch. A closed league, fixed membership, guaranteed revenue, the biggest clubs in Europe locked into a structure that removes them from the game everyone else plays. Monetised. Controlled. Profitable.

She sits with it for a moment. And then:

“Is this a fucking joke?”

What follows is one of the best speeches in the season. Football isn’t a product. It’s not a revenue stream. It’s the thing that exists for the fans, the ones who grew up with it, the ones who inherited it, the ones who’ve passed it down. Strip that out and you don’t have a better version of football. You have something that looks like football and generates returns.

Integrity in a room full of financial incentives is the most disruptive act available.

Rebecca wasn’t supposed to be in that meeting as a disruptor. She was Rupert’s guest, there to be managed, perhaps to be converted. Instead she says the thing nobody in the room was going to say. Not with power, she’s the smallest club there. With accuracy. That’s all it took.

Nate finds his violin.

He’s been in his old room, in the space his parents have held without fanfare, and he finds it. Something from before all of this, before the coaching career, before West Ham, before the long arc of the last three seasons. Something that was just his.

Then he talks to his dad. His dad says something he’s probably never said before:

“I didn’t know how to parent a genius.”

The things our parents couldn’t give us were often not from indifference. They were from not knowing how.

Nate’s relationship with his father has been an underlying thread running through the show — the approval that never quite came, the distance that was never explained, the sense that Nate grew up in a house where he was loved but not quite understood.

And here his dad hands him something true: not an apology exactly, but an explanation. I didn’t know what you needed, because what you needed was something I didn’t have a map for.

That’s a different kind of wound than cruelty or neglect. It’s the wound of good intentions without the right tools. And it turns out it’s enough to hear it said.

Roy brings Keeley a letter.

He’s had it for a while. He shows up, which is already something, given how much of this season Roy has spent not showing up for himself. She says she still can’t read his handwriting, which forces him to very awkwardly read the content of the letter in front of her.

And then he says the thing.

“It was all me. I was stuck in my own shit.”

That’s a real apology. Because it doesn’t ask anything back.

No qualification. No “but you also.” No blame-sharing arrangement, no conditional opening. It was me. I was the obstacle. I was the thing that got in the way.

This is what accountability sounds like. Roy strips the whole speech down to its core. That took more than showing up at her door. It took however many months of being stuck to finally get here.

At the end of the episode, Keeley and Rebecca finally catch up.

Everything — the agency, Jack, the funding, the mess — laid out between them. And then Rebecca says she wants to fund the firm.

This is the image the episode (and the season) has been building toward all along. The discovery that the real support structure was already there. It didn’t leave when things got difficult. It was waiting for the conversation to happen.

The network that matters is the one that’s still there after the collapse.

This is what every thread in the episode has been pointing at.

Nate’s parents.

Mae’s shit-and-growth philosophy.

Nate’s dad saying the true thing.

Roy’s letter.

Rebecca’s offer.

When the external structures fall what you’re left with is what was real the whole time. The tray on the bedside table. The friend at the bar. The letter you couldn’t read. The person who was always going to say yes.

What was always there turns out to be what you actually needed. It usually is.

What Would Ted Do? goes out every week. If this landed, share it with someone who’d appreciate it — or just hit subscribe and I’ll see you next episode.*

You’re thinking: this is the part where someone cites Sun Tzu and pretends it’s a fresh take.

It isn’t. Sun Tzu wrote about strategy. I’m writing about management, specifically, the kind that most engineering leaders get wrong every day. And for that, I need someone who didn’t just think about building organisations but actually built one, at a scale nobody before or since has matched.

Genghis Khan united the warring tribes of the Mongolian steppe, built the largest contiguous land empire in history — stretching from the Pacific coast of China to Eastern Europe — and did it by solving the same organisational problems that trip up engineering managers in 2026.

Meritocracy.

Delegation.

Intelligence gathering.

Reporting structure.

Shared purpose.

Reputation.

He solved all of them. In the 13th century. On horseback.

First: the part everyone gets wrong

Genghis Khan is shorthand for brutal, indiscriminate violence. That image of the savage warlord leaving nothing but ash is so embedded in popular culture that citing him as a management model feels almost offensive.

Jack Weatherford’s Genghis Khan and the Making of the Modern World dismantles that image methodically.

In Mongol culture, blood spilled on the ground was considered pollution, a spiritual and practical problem to be avoided. The Mongols weren’t pacifists, obviously. But they were averse to unnecessary killing in a way that no popular account of them suggests. Before attacking any city, they sent an envoy offering terms: surrender, submit to Mongol rule, and be absorbed intact. Trade routes maintained. Administrators kept in place. Religions tolerated. Often, the deal was better than what the previous rulers had offered.

The fearsome reputation was partly manufactured to make those cities surrender without a fight. A deliberate psychological weapon. Genghis Khan understood that a reputation for overwhelming force was more efficient than actually deploying it. The bloodshed happened when cities refused the terms. It was a last resort.

He was also the most religiously tolerant ruler of his era. He actively recruited talent from the peoples he conquered regardless of their background, faith, or origin. The Mongol empire at its peak ran on Persian administrators, Chinese engineers, and European merchants.

We’re not drawing lessons from chaos. We’re drawing lessons from a functioning, deliberate organisation that out-thought, out-moved, and out-lasted almost everything it encountered.

Here’s the framework.

1. Intel first. Build second.

Before every major campaign, Genghis Khan sent merchants and spies deep into the target territory. Roads. Politics. Supply lines. The loyalty of local rulers. The location of water sources. The strength of city walls. He knew all of it months before the first soldier moved. The Mongols never attacked blind.

They were, in modern terms, an intelligence-driven organisation. The campaign was largely decided before it began.

Engineering teams do the opposite.

They start building in sprint one and discover the constraints in sprint four. The dependency on the external API that wasn’t documented. The stakeholder who had a hard requirement that nobody thought to ask about. The technical debt in the adjacent system that makes the elegant solution impossible. The requirements that seemed obvious and turned out to be assumptions.

Discovery before delivery is the thing that separates teams that ship the right thing from teams that ship the wrong thing very professionally. The time you spend at the start understanding what you’re building into is almost always cheaper than the time you spend pivoting halfway through.

Genghis Khan didn’t attack until he knew. Most engineering orgs don’t know until they’ve already attacked.

2. Delegate decisions, not just tasks.

Genghis Khan didn’t issue orders from a tent in the middle of the battlefield. He set the objective

• take that city,

• control that pass,

• cut off that supply route

and trusted his commanders to figure out how. Field generals had genuine latitude to adapt, improvise, flank, feint, and decide without waiting for approval. The goal was fixed. The method was theirs.

Most engineering managers delegate the work but retain the decisions.

They assign the task, sit in the design review, weigh in on the implementation approach, and then wonder why their engineers don’t seem to have ownership. Because they don’t. Ownership and decision authority are the same thing. You can’t give someone one without the other.

The pattern looks like this: a senior engineer is told to “own” a feature. They write the spec, propose an approach, and then wait three days for the manager to sign off. The manager has a small change. The engineer adjusts. Another review. Another small change. The feature ships six weeks later and the engineer feels like a contractor, not an owner.

Genghis Khan’s commanders moved fast because they didn’t wait. They were trusted to figure out how, and they were held accountable for outcomes.

Delegation without decision authority isn’t delegation. It’s just distributed execution with extra steps.

3. Move faster by trusting the edges.

The Mongol army was the fastest fighting force of its era, because of better organisational design.

Of course, being comprised solely of soldiers on horsback, without anyone on foot gives you mobility. But they eliminated the slow, top-heavy command structures that plagued European and Chinese armies. Field commanders adapted tactics in real time. Flanking manoeuvres that would have required days of signalling and approval in other armies happened in hours. The army moved as one but thought at the edges.

At the same time, Genghis Khan built the Yam, a relay station network that spanned the empire. Riders would hand off messages at each station, mounting a fresh horse, covering distances that would take weeks in a single day. Information moved faster across the Mongol empire than anywhere else on earth at the time. Leadership always knew what was happening at the edges. The edges always knew what leadership needed.

Two systems. One lesson.

Speed is a byproduct of trust. The organisations that move fastest aren’t the ones with the best tools or the most senior engineers, they’re the ones where decisions get made at the right level, not escalated to the wrong one. Bureaucracy is slow because it concentrates decision-making at the top and makes everyone else wait.

Information flow is infrastructure. Most engineering orgs have communication that works fine within teams and completely breaks down between them.

The incident that one team knew about for a week before the affected team found out.

The architectural decision made in one corner that invalidated three months of work in another.

The product change that engineering heard about in a Slack message, in passing, the day before launch.

Genghis Khan solved cross-empire information flow in the 1200s. Most orgs haven’t solved cross-team information flow yet, despite having 24/7 internet access.

4. Meritocracy is a system, not a value.

During one of his early campaigns, Genghis Khan was nearly killed when an enemy warrior shot his horse out from under him. After the battle, he had the warrior brought to him. Most rulers would have executed him on the spot.

Genghis Khan promoted him.

The warrior (Jebe), went on to become one of the greatest Mongol generals. He had demonstrated skill, courage, and the willingness to aim high. That was the only criterion that mattered. Not loyalty. Not background. Not how long he’d been around. He was an enemy combatant not long ago. Now he had a command.

On the other side of the coin: commanders who lost through cowardice or bad decision-making were replaced immediately, without a performance improvement plan or a long feedback cycle. Those who fought bravely and lost could be forgiven. War is uncertain, and Genghis Khan was pragmatic and grounded in reality. But commanders who cost lives through bad decisions, through hesitation, through incompetence? They were out.

Two sides of the same system. Competence gets rewarded, visibly and quickly. The absence of it gets punished, just as visibly and just as quickly.

Engineering orgs tend to think they value meritocracy. Yet at the same time they promote the person who’s been around longest, or the person who’s easiest to work with, or the person whose departure would be most disruptive. The actual output

• the quality of decisions,

• the speed of delivery,

• the growth of the people around them

is considered, somewhere, eventually.

Saying you value meritocracy while promoting based on tenure and comfort is the most common lie in engineering management. It’s just what happens when you have the value but not the system.

Genghis Khan had the system.

5. Structure is clarity.

The Mongol army ran on units of ten.

Ten soldiers, one commander. Ten of those, one commander. Ten of those, one commander. All the way up to the tumen — ten thousand soldiers under a single general. Every person in the organisation knew exactly who they reported to, what they were responsible for, who was responsible for them, and what their unit’s role was within the whole.

No ambiguity, matrix reporting or “we’re all kind of responsible for this.”

Engineering orgs often treat org charts as evidence of corporate failure. Flat is good. Hierarchy is bad. Structure is what happens when culture dies and process takes over.

That’s backwards.

Fuzzy ownership and shared responsibility are just disorganised. The work that’s nobody’s fault is also nobody’s job. The feature that three teams are “all aligned on” but nobody is accountable for. The incident post-mortem where every action item goes to a shared channel and none of them get done. The architectural decision that needed someone to make the call and instead became a six-week Slack thread.

Clear structure doesn’t constrain great teams. It gives them the clarity to move. When everyone knows exactly who owns what, you spend less time negotiating and more time building. The Mongol decimal system was the thing that made a hundred thousand people from different tribes operate as a single coherent force.

Your org structure should do the same thing. If you ask any engineer on your team “who owns this?” and they hesitate, you have a structure problem.

6. Reputation is a force multiplier.

Many cities surrendered to the Mongols without a fight.

Why? Because the stories that preceded them made resistance feel futile before it started. The reputation arrived weeks before the soldiers did, and it did most of the work. By the time the envoy showed up with the terms of surrender, the local rulers had already heard what happened to the last city that refused.

The reputation was, in part, deliberately constructed. Genghis Khan understood that a story about your organisation is more scalable than any individual interaction.

Your team’s reputation works exactly the same way.

A team known for shipping consistently, on time and without drama gets the interesting projects before they’ve been pitched.

A team known for high standards attracts better engineers before a job posting goes live.

A team known for being good to work with gets the benefit of the doubt in the cross-functional meeting, the stakeholder who makes the introduction, the executive who goes to bat for the headcount.

Reputation compounds. It gets you access, trust, and latitude that most teams have to fight for one interaction at a time.

Most managers think about their team’s reputation reactively - after a failure, after a missed deadline, after someone complains. The best managers build it deliberately in advance, through visible wins, clear communication, and consistent follow-through. Small things, done reliably, over time. The stories write themselves eventually.

7. Steal the best ideas. Never rebuild what exists.

Every empire Genghis Khan conquered, he looted for knowledge.

Engineers. Doctors. Administrators. Craftsmen. Siege weapon specialists. Financial experts. They were absorbed into the Mongol operation regardless of where they came from or who they’d been working for an hour ago. The Mongols had no tradition of siege warfare and walled cities were a problem. So when they encountered Chinese siege engineers, they didn’t try to develop their own siege doctrine from first principles. They captured the engineers and built what already existed, immediately.

Persian administrators ran the financial systems. Chinese physicians treated Mongol generals. The empire ran on borrowed expertise, acquired deliberately from every direction.

“Not invented here” is not a viable philosophy.

The best engineering organisations steal shamelessly. Open source libraries. Architectural patterns from other industries. Processes that worked somewhere else. Frameworks that already have ten years of battle-testing behind them. The question is never “did we build this?” The question is “does it work, and can we use it?”

Every time an engineering team rebuilds something that already exists, like

• a custom auth system,

• a bespoke data pipeline,

• an internal framework that does what three open source tools already do better

it’s not because the existing option wasn’t good enough. It’s because building felt better than adopting. That feeling is a weakness.

Genghis Khan saw knowledge as the real spoil of conquest. The territory was secondary.

8. Unite around the enemy, not around each other.

The Mongolian steppe was full of tribes that had been raiding and killing each other for generations. Ancient grievances. Blood feuds. Deep cultural differences. These were not people who were going to bond over a team offsite and a shared values document.

Genghis Khan didn’t try to make them like each other.

He gave them something bigger to point at together. A common enemy. A shared campaign. An external target so significant that the internal friction became background noise. The tribes didn’t stop being different, but the goal mattered more.

Engineering teams don’t need to be friends. They need a real external challenge.

A competitor gaining ground on a feature your team owns. A deadline that actually means something, like a customer commitment, a regulatory date, a product bet the company is making. A hard technical problem that none of them can solve alone. Something outside the team that makes the inside of the team feel small by comparison.

Team offsites don’t create cohesion. Culture decks don’t create cohesion. The quarterly all-hands where leadership talks about the mission doesn’t create cohesion. Shared stakes do. The moment where the team realises they either figure this out together or they don’t figure it out is the moment the team becomes a team.

Genghis Khan united warring tribes into the most effective fighting force in history by pointing them at something real. Your team already knows how to work together. They just need something worth working towards.

What this is, and what it isn’t

Genghis Khan conquered most of the known world. He also presided over an empire whose expansion caused enormous death and displacement. I’m not endorsing the full package.

But the reflexive association of Genghis Khan with pure barbarism, mindless violence and historical accident is wrong, and it causes us to dismiss one of the most interesting organisational minds in recorded history.

• He was religiously tolerant at a time when that was genuinely unusual.

• He built infrastructure that connected continents and enabled trade across thousands of miles.

• He ran a more genuinely meritocratic organisation than most of the companies you’ve worked for.

He also never did a 1:1.

Engineering management wasn’t invented by Andy Grove or Jeff Bezos or the person who wrote your company’s leadership principles. The underlying problems of trust, structure, meritocracy, intelligence, delegation, shared purpose are ancient. Someone already worked through most of them, at impossible scale, under conditions that made failure instantly and catastrophically clear.

That person just happened to live in the 13th century and conquer half the world in the process.

Pick one of these eight principles and ask yourself, honestly, where your team is doing the exact opposite.

That’s your sprint zero.

The primary source for the historical claims in this article is Jack Weatherford’s Genghis Khan and the Making of the Modern World (2004). It’s worth reading even if you never think about management or the Mongols again.

Near the end of this episode, Isaac finally confronts Colin about everything he’s been carrying.

He’s hurt. He wants to understand. He asks the question that’s been sitting under all the weirdness between them for weeks:

“What is it about me that made you think you couldn’t tell me?”

And Colin gives him the only honest answer there is.

“It had nothing to do with you. The 1% chance that you wouldn’t support me — that terrified me.”

That exchange is the whole episode. The logic of hiding — the terrible maths of self-protection — laid out in two sentences. We guard ourselves against the small probability of rejection and pay for it with the certainty of distance. We deny the people who love us the chance to show us who they are. And we call it protecting ourselves.

This episode is full of people running that same calculation. Roy, in his own way. Nate, discovering his is broken. Isaac, not knowing what to do with something he didn’t ask to know. The episode keeps asking: what are you protecting yourself from? And at what cost?

Roy skips the press conference. Beard covers for him. It goes badly. Rebecca steps in.

Then she finds Roy and says what she’s been watching build for a while.

“You’re just so convinced that you don’t deserve anything good in your life that you’d rather eat a bowl of shit soup and complain about the portions. Get out of your own way, man.”

The most useful thing a real friend can do is name the pattern you’ve stopped being able to see.

Roy isn’t lazy or indifferent. He’s self-sabotaging, which is a different thing entirely. He pulls away from the things that would be good for him — the press conference, the visibility, the professional belonging — because somewhere underneath the competence and the fury, he’s decided he doesn’t quite deserve them. Rebecca has watched this for long enough. She names it without softness, because softness isn’t what Roy needs and she knows it.

The shit soup line is funny. It’s also one of the most precise descriptions of a particular kind of self-destruction the show has offered - choosing the worst option and then being aggrieved about it. It’s everywhere, in every workplace, in every life. You probably know someone doing it right now.

Isaac has known about Colin since the phone, and he doesn’t know what to do with it.

He can’t pretend he doesn’t know. He can’t bring himself to say something. So he goes sideways: distant, strange, newly awkward in a way Colin can feel but can’t explain. Colin goes to Trent Crimm for advice. Isaac is changing the texture of their friendship because of a secret that isn’t even his to keep.

Unspoken knowledge changes a relationship even when nobody says a word. The thing you know but haven’t addressed is already there, between you, shaping everything.

This is the cost of the 1% calculation from the other side. Colin’s silence to protect himself becomes Isaac’s confusion becomes a distance neither of them wanted. Secrets metastasise. They don’t stay contained to the person keeping them. They leak into the room and change the temperature for everyone.

Isaac lashes out at a fan in the stands who uses a homophobic slur about the team.

The whole dressing room is caught off guard. This isn’t the thing they were expecting from him. He doesn’t explain himself. He just turns to the room and asks, with everything underneath it:

“What if one of us is gay?”

Then he walks out.

Sometimes the clearest act of allyship is the one that happens before it’s been asked for, in a room full of people who don’t yet know why it matters.

Isaac can’t say what he knows. He can’t out Colin and he wouldn’t. But he can put the question in the air. He can force the room to sit with it, to answer it implicitly, to show what kind of team they actually are before the moment arrives. It’s not a perfect act. It’s a clumsy one, full of anger and confusion. But it’s real. And it does the thing it needed to do.

Colin comes out.

The team’s response is immediate and complete. An outpouring of support. The thing Colin spent years protecting himself from turns out to be the opposite of what he feared.

Meanwhile, in a separate room, Roy sits with Isaac and helps him work through his anger. Two different versions of the same moment, happening in parallel. Colin receiving what he was afraid to ask for. Isaac processing the fact that a friend didn’t trust him with something that mattered.

Belonging is not only about being accepted but also about being freed from the cost of hiding.

There’s a version of this that ends at the support — the hug, the locker room, the teammates who showed up. But the episode doesn’t stop there. Colin’s inspired performance in the second half, the 2-1 comeback win — that’s the other half of what happens when someone stops carrying something alone. The energy that was going into the hiding becomes available for everything else. It’s not metaphorical. It’s right there on the pitch.

Jade brings Nate lunch at West Ham.

Their interactions are warm in a way that Nate’s whole arc at the club hasn’t been. She’s easy with him. Comfortable. And when she meets Rupert — the charming, powerful man who runs the place — she’s pleasant but clear-eyed. She’s not taken in. She keeps a quiet, polite distance that says: I see you.

Later, Rupert takes Nate out for what he calls a guys’ night. It turns into something else — Rupert looking for a party, not a colleague. Nate has been loyal to a performance, and the performance just dropped the pretence.

He leaves.

The person you’re loyal to and the person they actually are can diverge slowly and then all at once. Jade saw it before Nate did. She usually does.

Jade has been the clearest-eyed person in Nate’s life all season. She’s not impressed by Rupert’s charm because she wasn’t looking to be impressed by it. She’s looking at Nate. And Nate is starting to look at Rupert the same way she does and not liking what he sees.

After the match, Roy voluntarily goes to the press conference.

Nobody asked him to. Nobody forced him. He shows up which, given the earlier conversation with Rebecca, is its own kind of answer to the shit soup.

He gets asked about Isaac’s outburst. He doesn’t deflect or dodge. He tells a story from when he was young. He made a stupid joke once — the kind of joke you make when you’re young and unthinking and part of a group. And another player heard it and lashed out. Roy didn’t understand why at the time. He does now.

The best way to protect someone in public isn’t always to shield them. Sometimes it’s to tell a story that moves the attention to you and explains everything without saying a word.

Roy just told the press that Isaac’s anger makes sense, that it came from somewhere human and real, without explaining anything he wasn’t supposed to explain. He covered Colin without naming him. He covered Isaac without excusing him. He did it by making himself the cautionary tale. That’s growth.

The season has been quietly building to this episode’s final conversation.

Isaac: heartbroken that Colin didn’t trust him. Colin: it had nothing to do with you. The 1% chance you wouldn’t support me, that terrified me.

And then Isaac has to sit with that. His friend didn’t hide because of something Isaac did or was. He hid because the stakes of being wrong — the tiny, 1% probability of rejection — were unbearable.

The 1% chance of rejection costs people the 99% certainty of being loved. That maths is everywhere. In every team, in every relationship, in every person who hasn’t said the true thing yet.

Isaac is hurt. He has every right to be. And he also has to understand that his record wasn’t the point. The size of what Colin was risking made the probability irrelevant. When the stakes are that high, even certainty isn’t certain enough.

That’s the hardest thing about vulnerability. It asks you to act on the 99% while the 1% has a louder voice.

Roy shows up. Colin stops hiding. Nate starts seeing clearly. Isaac’s anger becomes something real. And the team wins — comes back from behind, led by the person who finally stopped carrying something alone.

The shit soup was optional the whole time. So was the hiding.

What Would Ted Do? goes out every week. If this landed, share it with someone who’d appreciate it — or just hit subscribe and I’ll see you next episode.*

They weren’t absent. They weren’t checked out or hiding in their calendar. They were busy doing something upstream: absorbing the chaos, deflecting the politics, attending the meeting about the meeting so you didn’t have to. Maybe you didn’t fully appreciate it at the time. You just knew that somehow, in their team, the work felt possible.

The crude but accurate term for this is the “shit umbrella.” Your job as a manager is to stand between your team and the organizational weather so they can focus on what they were hired to do.

It sounds simple. It isn’t.

What the good ones actually do

The best managers I’ve worked with (and ones I’ve heard described by engineers who genuinely loved their teams) did three things simultaneously.

1. First, they asked what was blocking you and then went and removed it. Not “let me escalate that” followed by silence. Actually removed it. Called the person, cut through the process, got the answer. You’d mention a blocker on Monday and by Wednesday it was gone and you weren’t entirely sure how.

2. Second, they absorbed the political noise. The reorg rumors, the shifting priorities from three levels up, the exec who wanted a dashboard that would take six weeks to build for a meeting they’d forget about. None of it reached the team until it was real and relevant. They were in those rooms so you didn’t have to be.

3. Third, and this is the one that separates competent from great, they made it clear that the umbrella wasn’t unconditional. They’d tell you: if things start becoming a detriment to your work, loop me in and I’ll push back. They weren’t promising a fantasy world where nothing bad ever happened. They were promising that if the weather got bad enough to actually hurt you, they’d step in front of it.

A fellow Substacker described a manager like this as having a “shit cannon” - he didn’t just block what came from above, he fired it back. He cared about his people doing good work more than he cared about being easy to manage.

They pushed him out a few years later.

The trap: the hermetically sealed team

Here’s where people misread the pattern.

Some managers hear “shield the team” and interpret it as “shield the team from everything.” They create a bubble. The team has no idea why priorities shifted. They don’t know the company is having a rough quarter. They can’t see the strategic context for the work they’re doing. They just get tickets and ship code and wonder why nothing makes sense.

That’s not an umbrella. That’s a bunker. And bunkers breed helplessness.

When you over-shield, you rob people of the ability to self-advocate. You rob them of context they might actually need to make better technical decisions. You create a team that falls apart the moment you’re not there to intercept everything because they’ve never built the muscle to handle anything themselves.

Teams don’t need to be protected from reality. They need to be protected from waste:

• wasted time,

• wasted effort,

• wasted emotional energy on things they can’t influence and didn’t ask for.

There’s a real difference between “I won’t tell you about the reorg because I don’t want you to worry” and “I’ll tell you the reorg is happening, here’s how it might affect us, and I’ll handle the fallout if it starts hurting our work.”

The first one is paternalism. The second one is leadership.

The calibration: what separates good from great

The best version of this pattern isn’t silence. It’s selective transparency with full energy absorption.

Let the information through. Absorb the chaos.

The manager that comes up most in conversations I have with happy engineers — the one people describe with something close to reverence — does exactly this.

• He tells the team what’s going on.

• He tells them how it might impact them.

• He makes it clear that if it started being a detriment to their work, clue him in and he’d push back.

He doesn’’t shield them from everything, because that is a nearly impossible task. He trusts them to do their jobs, communicate their needs, and loop him in for support if things turned ridiculous.

The calibration question isn’t “should I tell my team about this?” It’s “does my team need to spend energy on this?”

If the answer is no, because

• it’s political noise,

• it’s someone else’s emergency,

• it’s a fire drill that will be forgotten by Friday

you absorb it. You let it hit you instead of them. That’s the job.

If the answer is yes - if it’s real context they need to make good decisions, if it affects their work directly, if ignoring it would be worse than knowing about it, you share it. But you share it with the implicit promise: and I will handle the part of this that isn’t your job to handle.

That’s the whole skill. Information passes through. Chaos doesn’t.

The cost — and what it tells you

These managers often get pushed out. The one with the shit cannon? He “cared too much about his people and doing things right and not enough about what upper management wanted.” That’s almost a direct quote. And it’s a devastating one, not because of what it says about him, but because of what it says about the organization.

When your org ejects the people who protect teams from dysfunction, the dysfunction isn’t a bug. It’s the operating model. The company doesn’t have a management problem. It has a culture that punishes good management.

If you’re the shit umbrella and you’re getting punished for it, if saying “no” to protect your team’s focus is being read as “not a team player”, the signal isn’t that you’re doing your job wrong. The signal is that your org doesn’t actually want the job done well. They want compliance. They want noise passed downward without friction. They want managers who are funnels, not umbrellas.

That’s a culture diagnosis. And it’s one worth taking seriously, because it means the system is selecting against the people who make teams work.

The easiest way to evaluate a manager is to ask their team one question:

Does your manager let you focus on the work?

If the answer is yes, someone upstream is getting wet so you don’t have to. They’re in the rooms you don’t know about, having the conversations you’ll never hear, absorbing the energy that would otherwise land on your desk as yet another “quick sync” or “just checking in on priorities.”

That’s the job. Be the shit umbrella. Just make sure you’re shielding your team from waste, not from reality.

And if your org fires you for it, take that as the compliment it is.

Lots of output numbers. Lots of celebration.

Nobody’s posting their cycle time. Nobody’s showing their deployment frequency or change failure rate. Nobody’s mentioning that half those AI-generated features are sitting in a review queue, or that production incidents quietly ticked up last quarter.

Output went up. Outcomes didn’t move.

This is what happens when you hand a powerful tool to someone who hasn’t asked the most basic question in operations: where is my bottleneck?

A 40-year-old idea that just became urgent

Eliyahu Goldratt published The Goal in 1984. The core insight is almost embarrassingly simple: every system has a constraint - one point that limits the throughput of the entire system. Improve anything that isn’t the constraint, and you’ve improved nothing. You’ve just built up inventory in front of the bottleneck.

Goldratt laid out five focusing steps:

1. identify the constraint,

2. exploit it (squeeze every drop of capacity from it),

3. subordinate everything else to it (don’t let non-bottlenecks overproduce),

4. elevate it (invest to expand it),

5. and then go find the next one.

For 40 years, this has been one of those ideas that everyone nods at and almost nobody actually applies. And now AI has made it urgent, because AI is the most powerful non-bottleneck accelerator ever invented, and most engineering teams are using it to build the most impressive pile-ups their constraints have ever seen.

The trap: automating what’s easy to automate

Here’s the pattern I keep seeing.

• A team gets access to AI coding tools.

• They look around and ask: “What can AI help us with?”

• The answer is obvious: writing code. It’s the most visible, most measurable part of the job. AI is pretty decent at it.

• So they point AI at code generation and watch the output numbers go vertical.

But writing code was almost never the bottleneck.

Or at least- not the only one, not for every org and not in every circumstance.

The bottleneck was understanding what to build. Or getting changes reviewed. Or having confidence that the thing is safe to ship. Or making the hard product decision that nobody wants to make. Those things are exactly as slow as they were before.

So now you have more code, sitting in longer review queues, being assessed by the same overloaded senior engineers, going through the same deployment pipeline that was already the chokepoint. You haven’t gotten faster. You’ve gotten busier. There’s a difference.

The code flood

Let’s be specific. If your team generates 3x more pull requests but has the same number of reviewers, you haven’t tripled your throughput. You’ve tripled the wait time in your review queue. Every one of those PRs represents context a reviewer has to load into their head, and AI-generated code often requires more careful review, not less, because the reviewer can’t rely on the author’s intent being obvious.

If your constraint was deployment confidence — the team’s collective ability to say “yes, this is safe to ship” — then more code without a proportionally better testing and observability harness is actively harmful. You’re feeding the machine faster than it can digest.

The documentation flood

Then there’s the PRD problem. Teams are using AI to produce product requirement documents, technical specs, architectural proposals. The volume of documentation goes up. The quality of decision-making stays flat.

Here’s why: the PRD was never really about the document. It was about the thinking you had to do to write it. When you sit with a problem long enough to articulate it clearly in writing, you discover the gaps in your understanding. You find the contradictions. You realize the thing you were about to build doesn’t actually solve the problem you thought it did.

When you generate a PRD with AI, you get a document that looks like thinking happened. It has the right headings. It uses the right vocabulary. But the thinking didn’t happen. The person who prompted it still doesn’t understand the problem, they just have a convincing artifact that says they do.

And you know what? Everyone else in the org can tell.

AI-generated documents have a particular smoothness to them, a distinct absence of struggle, that experienced people recognize immediately. It reads like a book report by someone who read the synopsis.

The bottleneck was never “produce more documents.” It was “make better decisions.” And you can’t automate your way to that.

The Slack flood

Same pattern, different medium. AI can summarize threads, generate status updates, draft messages, produce weekly roundups. So now there’s more communication. More updates. More words.

The bottleneck was never communication volume. It was attention. Your senior engineers already couldn’t keep up with their Slack notifications. Now there’s more to read, and paradoxically it’s harder to find the signal because the AI-generated messages are just coherent enough to seem worth reading, but just hollow enough to waste your time. The ratio of signal to noise probably just got worse.

The outsourced humanity

This one is my pet peeve, so let me be direct: if you’re using AI to write performance reviews, you have fundamentally misunderstood what performance reviews are for.

The point of writing someone’s review is the thinking. You sit with it. You struggle with how to phrase something difficult. You agonize over whether you’re being fair. You notice patterns you hadn’t articulated before. That struggle is you actually engaging with your teammate as a person: their growth, their potential, the hard thing they need to hear and the way you’re going to say it that shows you actually care.

When you hand that to AI, you didn’t save time on the review. You skipped the review. You produced a document that looks like a review. The person receiving it can tell the difference. They always can. And what they hear, loud and clear, is: “I couldn’t be bothered to actually think about you.”

The same applies to 360 feedback, to mentoring conversations, to anything where the slow, difficult process of articulating your thoughts is where the actual value is created.

These are not bottlenecks to be eliminated. They’re the work itself.

The distinction that matters: thinking work vs. toil

Here’s the framework I want to leave you with, because I think it’s the single most important filter for any AI adoption decision.

There are two kinds of slow work.

Toil is slow because it’s repetitive, mechanical, and draining. It has to happen, but nobody gets smarter or wiser by doing it.

• Formatting spreadsheets.

• Writing boilerplate tests for well-understood code.

• Parsing logs manually.

• Compiling release notes.

• Translating documentation.

Toil should be automated ruthlessly and without sentimentality.

Thinking work is slow because the slowness is the mechanism.

• Writing a strategy document forces you to clarify your strategy.

• Reviewing a teammate’s code forces you to understand their approach.

• Drafting a difficult message forces you to examine what you actually want to say.

The effort is the process by which understanding is produced. Remove the effort, and you remove the understanding.

AI pointed at toil is liberation. AI pointed at thinking work is lobotomy with a nice interface.

Most teams don’t make this distinction. They see “slow” and reach for AI, treating all slowness as waste. Goldratt would wince. Not all constraints should be eliminated. Some constraints are there because the work genuinely requires that time and attention. The question isn’t “can AI make this faster?” It’s “if I make this faster, do I still get the thing I actually needed?”

Now the good news: AI at the actual constraint

So, now that I’ve spent a lot of this article being critical, let me be clear — AI is extraordinarily powerful when you point it at the right problem. The key is to start with Goldratt’s first step: identify your actual constraint. Then ask whether AI can help you exploit it.

Here’s where I’ve seen it work.

When the bottleneck is understanding a legacy system

Almost every company of meaningful size has codebases that are poorly documented, written by people who left, and structured in ways that make sense only if you were there in 2013 when the original decisions were made.

The constraint is: nobody understands this well enough to change it safely.

AI is genuinely excellent here. Summarizing complex call graphs. Explaining unfamiliar code patterns. Mapping dependencies across services. Answering “what happens if I change this?” with actual context.

This is applying AI directly at the constraint by reducing the thing that was actually slowing you down.

When the bottleneck is incident response

It’s 3am. Something is broken. Your senior on-call engineer is staring at dashboards and logs, trying to piece together a causal chain from fragments of evidence scattered across twelve services, seven of which they are seeing for the first time. Every minute costs money and customer trust.

AI as a diagnostic accelerator, correlating signals, suggesting hypotheses, surfacing relevant past incidents, directly exploits the constraint. The bottleneck is a human trying to synthesize too much information under pressure. AI is made for that.

When the bottleneck is onboarding

New engineers taking months to become productive in a complex codebase is one of the most expensive constraints in engineering. The knowledge is tribal, the documentation is outdated, and the people who could explain things are the same senior engineers who are already the constraint elsewhere.

AI as a codebase guide, answering questions about architecture, explaining historical decisions, walking someone through unfamiliar patterns, directly attacks this constraint. It scales the knowledge without scaling the demand on the people who hold it.

When the bottleneck is your scarcest people

In most teams, the real constraint is the 2-3 senior engineers whose judgment and context make them the decision point for everything important.

They’re in every design review. They’re the ones who know which shortcuts are safe and which aren’t. They’re simultaneously the most valuable and most overloaded people on the team.

AI can’t replace their judgment as that’s thinking work, and we’ve covered why you don’t automate that. But AI can handle the mechanical parts of their day:

• triaging what actually needs their attention,

• pre-analyzing pull requests so they spend time on what matters,

• drafting the routine parts of technical documents so they can focus on the hard decisions.

The goal is to make sure the constraint spends 100% of its capacity on the work only it can do.

This is Goldratt’s “exploit” step, applied precisely. Don’t try to eliminate the bottleneck. Squeeze every drop of value from it by removing everything that isn’t bottleneck-level work from its plate.

The question to ask before adopting any AI tool

Before you add another AI tool to your workflow, before you generate another metric about how much output AI produced, ask this:

What is my actual bottleneck?

If you don’t know (and most teams don’t, because they’ve never looked) then you’re not ready for AI. You’ll just move faster in the wrong direction. You’ll generate impressive numbers that don’t connect to outcomes. You’ll build beautiful pile-ups in front of constraints you haven’t identified.

If you do know your bottleneck, then the next question is: does this AI tool address the bottleneck, or does it accelerate a non-bottleneck? If it’s the latter, it doesn’t matter how impressive the demo is. It doesn’t matter how much output it produces.

It won’t make your system faster.

Goldratt figured this out in 1984 with a manufacturing novel. Forty years later, we have the most powerful acceleration technology in human history, and the lesson hasn’t changed: faster only matters if you’re speeding up the right thing.

The teams that will actually benefit from AI aren’t the ones generating the most code or the most documents or the most messages. They’re the ones who took the time to understand where their system actually gets stuck and pointed AI there.

Everyone else? They’re just producing inventory.

Richmond is on a winning streak. The tactic is working. The team is climbing the table.

And Ted Lasso spends most of this episode thinking about Paris.

His ex-wife is there with Dr. Jacob. They’re going for a surprise trip. Ted is convinced that Jacob is going to propose. He spends the episode managing a crisis that hasn’t happened and may never happen, while his son Henry is right there in front of him, visiting for exactly this stretch of days.

Rebecca names it mid-episode, the way only a real friend can:

“You need to stop letting yesterday get in the way of today.”

That’s the whole episode. Everyone in it is, in some way, living in a time that isn’t now, haunted by what was, anxious about what might be, performing a version of themselves that belongs to a different moment. The leadership lesson isn’t about tactics or culture or team dynamics this week. It’s quieter than that. It’s about whether you can be where you actually are.

Ted asks Rebecca to hire a private investigator to find out if Jacob is proposing in Paris.

Let’s sit with that for a second. The PI request. Ted Lasso, the man who built an entire philosophy around belief and presence and trusting the process, is spending mental energy trying to surveil his ex-wife’s holiday because he cannot tolerate not knowing.

The Diamond Dogs, to their credit, tell him the obvious thing: find out if it’s actually happening before you flip out.

The anxiety of anticipating bad news is almost always worse than the news itself. And it costs you the present on credit for something that might never arrive.

The Diamond Dogs exist precisely for moments like this. The group of friends who tell you what you need to hear rather than what you want to hear, who name the thing you’re doing so you can see it from the outside. Ted built that structure instinctively. He knows what good support looks like. He just can’t access it this week, because too much of him is in Paris.

Meanwhile, Nate is conducting his own version of the Diamond Dogs meeting.

He calls it the Love Hounds. He gathers his West Ham staff to discuss Jade’s reluctance to label their relationship, and the result is… well-intentioned, earnest, and spectacularly awkward. The form is there. The agenda is there. The support structure, as a concept, is being attempted. What’s missing is the trust that makes it work.

The advice that comes back is: insult the girl you like. Never express emotions. Nate shuts the Love Hounds down after one meeting.

You can’t replicate a support structure by copying its procedure. The thing that makes it work isn’t the meeting. It’s the years.

The Diamond Dogs function because of Roy’s bluntness, Beard’s silence, Higgins’ warmth, and Ted’s willingness to be the one who asks for help. Remove the history and what you have is just four people sitting in a room, unsure of what they’re allowed to say. Or worse, confidently saying the wrong thing. Nate’s Love Hounds are trying. That actually matters. But the one-session lifespan is a reminder: you build trust slowly, and you can’t shortcut it with a format.

A private video of Keeley is leaked online.

Two people respond.

Jack, her girlfriend, who funds her agency, hands Keeley a statement. It’s apologetic. It positions Keeley as someone asking forgiveness for a thing that was done to her. Jack wants the story managed. Jack wants it over.

Jamie Tartt comes to visit. He apologises. He forgot to delete old emails, and he thinks that’s likely how the images leaked. He’s not defending himself or offering strategy. He’s taking responsibility for his part in something that hurt someone he cares about.

There are two responses to a crisis involving someone else’s dignity: manage the narrative, or show up. They’re not the same thing.

Jack’s instinct is understandable. She’s a business person, this is reputational, there are levers to pull. But Keeley doesn’t need a statement. She needs to not be treated like the problem. Jamie, of all people, gets this right. The man who once made everything about himself calls to say: I’m sorry, this might be my fault, what do you need.

The relationship between Jack and Keeley doesn’t survive this episode, and the statement is part of why. You can tell a lot about how someone sees you by watching how they respond when you’re the one who’s been wronged.

The Richmond players, responding to Keeley’s situation and inspired by Jamie and Isaac, start deleting old photos on their phones: images people sent them years ago that they never thought about, but which could, in the wrong hands, become someone else’s worst day.

Colin quietly leaves the locker room before finishing, not wanting anyone to see what he’s erasing. Isaac notices. He thinks Colin doesn’t want to join in solidarity. He follows. He takes Colin’s phone himself and looks.

He doesn’t say anything. He just sees that the stuff that Colin is deleting isn’t woman’s photos.

Sometimes the most important act of leadership isn’t the conversation. It’s the recognition, the moment you finally understand what someone has been carrying, without making it about you.

This wasn’t a passive glance. Isaac went after him. He took the phone. He looked deliberately. And then he said nothing. Given the weight of what he just found out, is its own kind of answer.

Isaac is the captain. He’s been Colin’s teammate for years. And in thirty seconds, without a word being spoken, something shifts. What he does with that shift will matter later. For now, the seeing is enough. The seeing is everything.

Ted, Henry, and Beard go to a West Ham match.

Nate spots them in the stands. There’s a moment of eye contact, a wave. It’s friendly. Warm, even. And Nate is immediately conflicted. Something in him wants to lean into it, and something else is very aware of Rupert and the persona he’s been performing at West Ham all season.

He does both badly. He’s too warm for the cold act. Too guarded to actually reconnect.

The cost of performing a version of yourself you don’t believe in is that you can’t be fully present in any moment, not the one the performance is for, and not the one you actually want.

Nate has been trying to be someone sharp and closed and unimpressed. It worked for a while because the anger underneath it was real. But something is thawing. And the thaw shows, right there in the wave, in the conflict on his face. You can’t be two people in the same moment. Eventually one of them wins.

Michelle comes back from Paris.

No ring.

Ted watches. He’d hired the investigator. He’d spiralled. He’d lost days of actually being with Henry to the management of a dread that turned out to be baseless.

Rebecca was right. Yesterday got in the way of today, but not completely. Ted managed to snap out of it and actually enjoy his son’s company.

The things we spend our energy anticipating aren’t the ones that usually cost us. The cost is what we missed while we were bracing.

This isn’t a lesson Ted learns dramatically, with music and a speech. He just sees the hand. No ring. And has to sit with what that means- not the relief of being wrong about Paris, but the quieter reckoning with how much of this week he spent somewhere else.

Being present isn’t a value you hold. It’s a practice you either do or don’t. And it’s easy to believe you’re doing it right up until you look up and find you missed it.

The episode doesn’t make a meal of any of this. Richmond is winning, things are mostly functional, the catastrophes are personal rather than professional.

But underneath the winning streak, everyone is somewhere else in their heads.

Ted is in Paris. Nate is between two versions of himself. Keeley is navigating a relationship that’s starting to show its shape. Isaac is processing something he saw on a phone. And none of them can fully be where they are because of where they’ve been, or where they’re afraid they’re going.

Rebecca says it to Ted but it applies to all of them.

Stop letting yesterday get in the way of today.

Today is the only place anything actually happens.

What Would Ted Do? goes out every week. If this landed, share it with someone who’d appreciate it — or just hit subscribe and I’ll see you next episode.

It turns out the opposite is happening.

What AI actually does to a team

AI gives specialists a faster version of what they already do. The senior backend engineer writes code faster, reviews faster, ships faster. The data engineer builds pipelines in hours instead of days. The improvement is real, but it’s incremental. They were already good at this. Now they’re good at it with a tailwind.

The generalist gets something different. Not speed. Reach.

A generalist who understands enough about data engineering to ask the right questions can now use AI to execute in that domain. Not at expert level, but at a useful level. The gap between “I understand this area” and “I can produce work in this area” used to be years of specialisation. AI compresses that gap dramatically.

For the specialist, AI is a faster horse. For the generalist, it’s a new set of legs.

The result: the generalist’s ceiling rises faster than the specialist’s floor. The person who already operated across domains can now operate across more of them, with more depth in each one. That changes the math on which person adds more value to a team.

The Einstellung trap

There’s a concept in David Epstein’s Range that becomes more relevant every month AI tools get better.

The Einstellung effect describes what happens when deep expertise works against you. An expert, faced with a new problem, reaches for familiar patterns, even when those patterns don’t fit. The master chess player sees a complex position and reaches for a known solution. They miss the simpler, better move because their expertise pulls them toward what they’ve seen before.

In engineering, this shows up constantly. A senior specialist designs a solution using the tools and architecture they know best. Even when a simpler approach from a different domain would work better. They don’t do this out of laziness. They do it because deep expertise creates deep grooves, and the brain follows the grooves.

AI amplifies this. An LLM prompted by a specialist will produce output shaped by that specialist’s assumptions, including the blind spots. The model reflects the framing back at you. If you ask it to solve a problem within a narrow domain, it will stay inside that domain. It won’t step back and ask whether the domain is the right one.

The generalist is the natural corrective. They don’t have the deep grooves the Einstellung effect exploits. Their experience is broader, not deeper. They’re more likely to ask “why are we solving it this way?” before they ask “how do we solve it faster?” That reframing question is the one AI can’t generate on its own. It needs someone who sees beyond the frame.

The constraint is the specification

There’s a practical version of this that’s already playing out in teams using AI agents.

An agent given “build me an auth system” will build you one. Whether it matches your architecture, your threat model, your existing patterns, or your team’s conventions is a different question entirely. The agent doesn’t know what it doesn’t know. It fills the gaps with confident assumptions.

The craft has shifted. The skill is knowing what to tell the agent to build and what to tell it not to build.

The constraint is the specification.

The engineer who gets reliable output from AI tools is the one who defines tight, explicit boundaries: what the agent must not touch, must not assume, must escalate.

Generalists are built for this. They’ve always operated at boundaries. They’ve always had to translate between domains, define scope in unfamiliar territory, and hold multiple contexts at once. The person who spent their career crossing team boundaries is the same person who can tell an AI agent where the boundaries are.

The new team shape

The team model that’s emerging isn’t all generalists. It isn’t all specialists either. It’s a new structure:

1. One or two generalists who understand enough of every domain to direct work, evaluate output, and connect the dots.

2. AI tools that extend their reach into areas where they couldn’t previously execute.

3. Focused specialists who go deep where depth still matters: security, performance, reliability, the domains where getting it wrong is expensive.

The generalist becomes the orchestrator. They’re still hands-on, but their primary value shifts. It moves from “I can do the work in multiple domains” to “I can direct and evaluate work across them, including work done by AI.” They look at the output and know whether it’s right. Not because they’re experts in that area, but because they understand enough to spot the gaps.

This structure outperforms the pure-specialist team at most company sizes, because the integration layer, the person connecting the outputs, is what determines whether the team ships a product or a pile of well-built parts that don’t quite fit together.

The original LinkedIn post that started this series used a line most people get wrong.

“Jack of all trades, master of none.”

That’s where we usually stop. The full version continues: though oftentimes better than master of one.

The original wasn’t a criticism. It was a defence. It was always a defence.

The generalist is not an accident or a compromise. They’re a strategy. And in a world where AI makes depth cheaper and integration harder, they’re the strategy that wins.

If this series resonated, forward it to someone who needs to hear it. Or reply and tell me what you’d add.

Leave a comment

But they will miss the person who holds the whole thing together. Not because that person fails the interview. Because the interview never tests for what they do.

The CV problem

The first filter most candidates hit is the resume screen. And for generalists, this is where it often ends.

Their CV looks like a series of pivots.

• Two years in backend,

• a year in data engineering,

• a stint in platform,

• a move into a cross-functional role.

To a conventional screener, this reads as “couldn’t commit.” The pattern looks like someone who hasn’t found their thing yet.

David Epstein’s research in Range suggests the opposite. He calls it “match quality”: people who sample broadly before committing tend to find better long-term fit. The pivoting CV is often evidence of a healthy search. Someone who tried enough domains to know what they’re good at and where they create the most value.

The screening question should shift. Not “did they stay?” but “did they get better at each step?” Look for trajectory, not tenure. Look for whether each move made them more capable, not whether it was in the same direction.

What to listen for

If a generalist makes it past the resume screen, the interview itself often still misses them, because most interview rubrics are calibrated for depth signals. Here’s what to listen for instead.

1. They describe problems in terms of what was at stake, not just what they built. The specialist walks you through the architecture of their system. The generalist tells you the situation the team was in. Why that problem mattered more than the three other things they could have worked on. They lead with context, not components.

2. They talk about the people around them. They naturally frame their own contribution relative to the team. They mention what other people were doing, what information was missing, who needed to be connected. This isn’t modesty, it’s just how they think. They see the system of people, not just the system of code.

3. They reach for analogies from outside the domain. This one is subtle, and most interviewers miss it. A generalist might explain a caching strategy with a metaphor from logistics. Or describe a team dynamic using sports coaching language. Epstein identifies this (analogical thinking) as one of the strongest predictors of creative problem solving. It means the candidate is drawing on a wide base of mental models, not just the patterns from their specific domain.

Three questions that surface these signals:

• “Walk me through a time you worked on a problem that crossed team boundaries.”

• “What’s a decision you influenced that wasn’t technically yours to make?”

• “Tell me about a time you borrowed an idea from one field to solve a problem in a completely different one.”

The third question tends to separate generalists from specialists. Specialists struggle with it because their work doesn’t usually require them to cross domains. The generalist lights up.

The job description problem

Even if you fix the screen and the interview, the job description itself might be filtering generalists out before they ever apply.

“Senior Backend Engineer.” “Staff Platform Engineer.” “Principal Data Engineer.” The generalist reads these titles and thinks: that’s someone else’s job. The specificity of scope tells them there’s no room to move. And moving is what they do.

The fix is to describe the problems, not the stack.

Before: “We’re looking for a Senior Backend Engineer with 5+ years of experience in distributed systems, strong knowledge of Kafka and PostgreSQL, and a track record of building high-throughput data pipelines.”

After: “We’re looking for an engineer who can work across teams to solve problems that don’t have a clear owner. You’ll spend time in backend systems, data infrastructure, and cross-functional planning, wherever the hardest problem is that week. You should be comfortable operating without a fixed scope.”

Same role. Different framing. One attracts specialists. The other attracts the person you actually need.

The trust prerequisite

One honest caveat: hiring a generalist and dropping them into a role with rigid scope and tight oversight will fail. Sure, they can follow rules, but the value they create depends on freedom to move.

The best delegation model I’ve seen comes down to two words: “be careful.”

Trust plus guardrails. Autonomy with a safety net.

The generalist needs room to go where the problem is. They need a manager who trusts them to do that without micromanaging the path.

If your organisation isn’t ready for that, hiring a generalist won’t fix the problem. You’ll hire them, constrain them, watch them plateau, and watch them leave. Which is where we started in Post 2 of this series.

You don’t need to redesign your entire hiring process. You need to stop accidentally filtering out the person who would have made your team better.

Screen for trajectory. Interview for context awareness. Write the job description for the problem, not the stack. And make sure the role has room for someone who moves.

In rhe final post we’ll look forward: what the generalist becomes on an AI-augmented team and why it matters now more than ever.

Share this with a hiring manager on your team. Or reply with the interview question you’d add to this list.

Leave a comment