You know the feeling. Your team's retros are positive. Velocity is stable. People genuinely like working together. Psych safety is high — folks admit mistakes, ask dumb questions, challenge each other without it getting weird. By every internal measure, you're a healthy, high-performing team.

And yet.

Every dependency is a nightmare. Every cross-team interaction feels like pulling teeth. You're waiting three weeks for a PR review from another squad. Their API keeps breaking yours. Planning sessions with them feel like hostage negotiations. And the conclusion your team reaches — naturally, inevitably — is: "We're fine. It's them."

I've been in this room. Multiple times. On both sides of it. And I've come to believe that this specific pattern — a team that feels healthy internally but generates friction at every boundary — is one of the most dangerous failure modes in engineering orgs. Not because it's dramatic, but because it's invisible. The team genuinely is healthy by local measures. That's what makes it so hard to diagnose.

I've started calling this the insular health fallacy — the belief that internal team health equals systemic health. The team isn't broken. The interface is broken. But from inside, it looks like everyone else is the problem.

Social psychology has a name for the underlying mechanism: in-group bias. The minimal group experiments in the 1970s showed that people will favour their own group — even when the groups are assigned randomly. Give people a label, any label, and they'll start preferring "us" over "them." Now imagine what happens when "us" is a team that's genuinely built trust, shared context, and psychological safety over months or years. The in-group cohesion becomes a fortress. And fortresses, by design, keep people out.

Three structures I keep thinking about​

Here's the thing I keep coming back to. There's this idea from Team Topologies (and org sociology before it) that every organisation has three structures running simultaneously:

1. The formal structure — the org chart. Who reports to whom. This exists mostly for HR and finance.
2. The informal structure — who actually talks to whom. The Slack DMs, the coffee chats, the "hey, quick question" interrupts.
3. The value creation structure — how work actually flows from idea to customer. The path a feature takes through design, code, review, deploy, feedback.

Most teams optimise their informal structure beautifully. They build trust, they communicate well, they develop shared context. That's what good team-building does. But here's the trap: if that internal cohesion doesn't align with the value creation structure — the actual flow of work across boundaries — you end up with a team that's a joy to be inside and a wall to everyone outside.

Conway's Law makes this concrete. Your software architecture is a mirror of your communication structure. If the communication between teams is defensive, guarded, or just... absent — your architecture will reflect that. Tightly coupled monoliths. Unclear ownership boundaries. Integration points that nobody wants to touch because touching them means talking to that other team.

And there's another psychological trap compounding this: the fundamental attribution error. When we miss a deadline, it's because of circumstances — the requirements changed, the dependency was late, we were under-resourced. When they miss a deadline? It's because they're incompetent, or they don't care, or they're not prioritising properly. We judge ourselves by our intentions and others by their actions. Scale that across ten teams and you get an org where everyone believes they're the only competent group surrounded by idiots. Nobody's lying. Everyone's just... human.

But wait — if the team is healthy, why does everything break at the edges?​

Patrick Lencioni's five dysfunctions model is usually applied within a team — and most teams have internalised it by now. But here's what I think gets missed: these same dysfunctions show up between teams. And at the team-of-teams level, they're harder to see because no single team owns the problem.

The pattern I keep seeing: each of these dysfunctions is invisible from inside the team. Your team has trust — with each other. Your team has healthy conflict — with each other. The dysfunction lives at the boundary, where nobody feels ownership and everyone assumes it's the other side's fault.

The root of it, I think, is how organisations define the primary boundary of belonging. If leaders build their identity around the team they manage rather than the peer group they're part of, their reports mirror that. And you get fiefdoms — each one internally healthy, collectively stuck. (More on this in a moment.)

Which got me thinking about why this happens structurally — not just behaviourally.

OK so why does the system stay stuck though?​

There's a core idea in systems thinking — captured well in Donella Meadows' Thinking in Systems — that the performance of a system is governed by how its parts interact, not by how they perform in isolation. You cannot divide a system into independently optimised parts and expect the whole to be optimised. That's not how systems work.

And yet. That's exactly what most orgs do. (I keep catching myself doing it too — optimising my team's workflow without asking "but what does this do to the team downstream?")

Here's a scenario I keep seeing. You have three teams in a value stream: a frontend team, a backend team, and a platform team that handles deployments and infra. The frontend and backend teams are fast — they've got spare capacity, good tooling, strong engineers. The platform team is smaller, handles more services, and is already at capacity.

What happens? The frontend and backend teams, under pressure to show output, keep shipping features. PRs pile up waiting for platform review. Infra tickets queue up. The platform team — already the constraint — now drowns in coordination overhead from two teams pushing work at them simultaneously. Lead time for the whole system inflates. Not because anyone's slow, but because the non-bottleneck teams are producing faster than the bottleneck can absorb.

The instinct is "platform team needs to be faster." The counterintuitive move is "everyone else needs to produce less — or produce things that don't hit the constraint." It feels like waste. But the alternative is a queue that grows forever.

Little's Law describes this dynamic: Lead Time = Work in Progress / Throughput. Push WIP up without increasing throughput at the constraint, and lead time goes up. It's a simplification — real orgs aren't stable steady-state systems — but the directional truth holds. More work in flight with the same capacity at the constraint means longer waits. Every time. (I explored this through the lens of game theory in Why Everyone's Busy But Nothing Ships Faster — same dynamic, different angle.)

And there's an emotional dimension to this stuckness that pure systems thinking misses. Otto Scharmer's Theory U names three "voices" that keep systems frozen:

• Voice of Judgment — "We already know how they work. They're just slow."
• Voice of Cynicism — "Why bother reaching out? They'll just say no."
• Voice of Fear — "If we change the interface, everything might break."

These aren't rational assessments. They're emotional defence mechanisms. And they're contagious across teams. One bad interaction poisons the well for months.

The fix isn't to make teams work harder. It's to make the interactions work better.

Alright, so what actually helps?​

Alright, here's where I shift from diagnosis to "here's what I've seen move the needle." I want to be honest — there's no silver bullet. And I'm not sure I've fully cracked this myself. But a few structural interventions have consistently made a difference in places I've worked. Bear with me — some of these sound obvious, but the devil is in actually doing them.

Cognitive overload kills the boundary first​

There's a reason the insular health fallacy thrives in overloaded teams. When a team's cognitive capacity is maxed out — too many domains, too many services, too much context to hold — they don't just slow down. They start shedding context. And the first context they shed is the cross-boundary stuff. The integration points. The shared contracts. The things that make the system work. Internal work feels urgent and controllable. Cross-team work feels optional and exhausting. So it drops.

Team Topologies calls this out directly: a team can handle 2-3 simple domains, maybe one complicated domain, and absolutely cannot handle two complex domains simultaneously. Robin Dunbar's research on social group sizes points to the same constraint from a different angle — our brains can only maintain so many stable relationships before communication overhead overwhelms capacity. If the team boundaries are drawn wrong (too broad, too many services, too much cognitive load), no amount of good intentions will fix the boundary friction. The team will always retreat inward.

I explored this in Your Agents Are Running. So Why Are You Still Exhausted? — cognitive load isn't just about individual developers. It's about teams. And it's about what happens when you exceed the limit.

The team interface as a product​

This is the "Team API" idea, and it's the single most practical intervention I've seen for the insular health fallacy.

The concept: every team publishes and maintains a lightweight interface — like a software API, but for the team itself. It answers:

• What do we own? What's our mission?
• How do you reach us? (Not "DM someone" — a channel, office hours, a request template)
• What's our intake process? What does "ready" look like for a request?
• What are our SLOs? How fast will we respond?
• What are our dependencies? What are we blocked by?
• Where's our documentation? Our APIs? Our schemas?

Here's what this looks like in practice. A platform team I worked with was drowning in ad-hoc requests via DMs. Every interaction was a negotiation. Response times were unpredictable — sometimes same-day, sometimes two weeks. Other teams resented them. They resented other teams for "not reading the docs."

They published a Team API: a single wiki page with their intake template, a public Slack channel for requests, stated SLOs, and a clear "Definition of Ready" for what they needed before they could start. Within a month, the DMs dropped by 80%. The resentment dropped with it. Not because people changed — because the structure changed.

The shift is from diplomacy to contract. Instead of cross-team collaboration depending on personal relationships — who you know, who owes you a favour, who's in a good mood today — it depends on a predictable, published interface. Teams can change their internals however they want, as long as the API holds.

This connects to something I wrote about in The Prisoner's Dilemma Is Why You Got Ghosted on Slack. The reason you get ghosted isn't malice — it's that the game doesn't reward responding. A Team API changes the game. It makes responsiveness a structural property, not a personal one.

Map the value stream before reorganising anything​

Before touching team boundaries or org charts, the most useful thing I've seen is simply mapping how work actually flows end-to-end. Pick a recent feature that touched multiple teams. Trace it from idea to production. Mark every handoff, every queue, every wait.

What you'll typically find: 80% of the elapsed time is waiting, not working. The feature sat in someone's backlog for three weeks. Then it waited for a review for five days. Then it waited for a deployment window. The actual coding took two days. The system took six weeks.

This makes the insular health fallacy viscerally visible. Your team's two-day turnaround is real — but it's invisible inside a six-week lead time. The value stream map shows everyone where the time actually goes. And suddenly "we're fine, it's them" becomes "oh... we're all part of this."

Embed people across the boundary​

Temporarily sending someone from Team A to sit with Team B for a sprint — not a reorg, just exposure. I've seen this kill the fundamental attribution error faster than any process change. It's hard to dehumanise people once you've paired with them, sat in their standups, felt their constraints firsthand. The person comes back and says "actually, they're dealing with way more than I realised." That one sentence does more for cross-team trust than six months of joint planning sessions.

Joint retros across team boundaries​

Not just "our retro" — a quarterly retro between the two teams that interact most. Forces the conversation nobody wants to have. "What's working between us? What's not? What do we keep misunderstanding about each other?" It's uncomfortable the first time. By the third time, it's just how things work. The boundary stops being a wall and starts being a shared surface.

The Inverse Conway Maneuver​

This one's counterintuitive. Conway's Law says architecture mirrors communication structure. The inverse: deliberately restructure communication to force the architecture you want. If two services need a clean API boundary, make the teams interact through that API — not through Slack threads and shared meetings. The social structure shapes the technical structure. So the lever is the social structure — not the code.

Leadership has to go first​

(I almost didn't include this section because it sounds like every leadership blog ever written. But honestly? None of the other stuff works without it. So.)

None of this works if leadership is still optimising for their department. I've seen this pattern play out: leaders who build their identity around the team they manage rather than the leadership group they're part of. Lencioni calls this the "First Team" problem — the idea that a leader's primary allegiance should be to their peer group, not their direct reports.

This is genuinely hard. Performance reviews reward local delivery. Headcount battles reward empire-building. Promotion narratives reward "I grew my team from 5 to 20." The incentives all point toward local optimisation. So practicing "First Team" requires actively swimming against the current.

The "hat swapping" model is the most practical version I've encountered. Every leader wears two hats:

The portfolio hat — advocating for the team's capacity, constraints, and needs. Fighting for resources. Legitimate and necessary.

The organisational hat — making decisions optimised for the system, even when that means the team absorbs cost or gives up resources.

The key is being explicit about which hat is being worn. "Right now I'm wearing my portfolio hat — my team genuinely can't absorb this without dropping something else." vs. "Wearing my org hat — I think the right call for the system is X, even though it costs my team."

What this does is model vulnerability at the leadership level. It shows that strategic sacrifice for systemic health isn't defeat. And it gives other leaders permission to do the same. I've watched a single leader doing this consistently shift the dynamic of an entire leadership group within a quarter.

Culture changes when behaviour changes first​

I want to be honest about something here. Some of what I just described — publishing a Team API, mapping a value stream — that's within reach. A single team can start tomorrow. But embedding people across boundaries, joint retros, the Inverse Conway Maneuver, leadership going first — those need buy-in. From peers. From above. Sometimes from the whole system.

And that's the uncomfortable part of systemic problems: the team that sees the problem most clearly often can't fix it alone. It requires top-down support, lateral trust, and patience that most orgs don't reward. I don't have a clean answer for that. I just know that starting with what's in reach — and being vocal about what isn't — tends to create more space over time than waiting for permission.

Here's the last piece, and maybe the most important. You can't think your way into a generative culture. You have to behave your way into it.

John Shook's insight from NUMMI (the Toyota-GM joint venture) was that trying to change people's mindsets first is almost always ineffective. What works is changing what people do — the structures, the practices, the daily rituals — and letting the mindset follow.

Ron Westrum's cultural typology gives you a way to sense where you are:

• Pathological — information is withheld, messengers are shot, failure leads to blame, novelty is crushed.
• Bureaucratic — information is compartmentalised, messengers are ignored, failure leads to more process, novelty causes problems.
• Generative — information is actively sought, messengers are trained, failure leads to inquiry, novelty is implemented.

Most orgs I've seen aren't pathological. They're bureaucratic. And the move from bureaucratic to generative isn't about grand cultural transformation programs. It's about small structural changes that make generative behaviour the path of least resistance.

And if this feels like a problem unique to your org — it's not. Randy Shoup's talk on eBay's Velocity initiative is one of the most honest case studies I've seen. His team doubled engineering productivity, improved deployment frequency 10x, lead time 5x — genuinely elite technical execution. And it still didn't save the company. Waterfall planning, empire-building, and what Shoup explicitly calls a "pathological" culture of fear meant the system stayed stuck despite the parts getting faster. The technical bottlenecks were solved. The structural and cultural ones weren't. That's the gap this whole post is about.

Two things I keep noticing in teams that escape this trap — and both are conspicuously absent in insular teams:

The healthiest teams I've seen actively imagine what could go wrong, even when everything looks fine. Research on High Reliability Organisations (think aircraft carriers, nuclear plants) calls this requisite imagination — the ability to look past comfortable assumptions and sense weak signals before they become crises. The insular team lacks this entirely. They can't imagine that their internal health might be the system's bottleneck.

And those same teams treat silence from other teams as a warning sign, not a green light. Safety science and James Reason's work on organisational accidents calls this chronic unease — a healthy vigilance where the absence of problems makes you more anxious, not less. Complacency — the belief that because nothing has gone wrong, nothing will — is the most dangerous state.

The insular health fallacy is, at its core, a failure of both. The team can't imagine it's the bottleneck, and the absence of internal problems feels like proof everything's fine. The structure has to create the conditions where these qualities emerge naturally.

Where this leaves us​

The insular health fallacy is comfortable. It feels good to be on a team that works well together and to believe the problem is everyone else. Letting go of that narrative means admitting that maybe the team's health is incomplete. That internal cohesion without external alignment is... incomplete.

I don't think most teams do this consciously. I certainly didn't, the times I was part of it. But recognising the pattern is the first step. And the fix isn't to break what works internally — it's to extend that same intentionality to the boundaries.

The team that's genuinely high-performing isn't the one with the best retros. It's the one that other teams want to work with. That's the bar.

Deming said it decades ago: "A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centres, and thus destroy the system."

That's the insular health fallacy in one sentence. Your team isn't the system. The system is what happens between teams. And that's where the real work lives.

A debate breaks out among leaders. The team just shipped something significant. Someone suggests giving "champion points" to the person who drove it. Someone else pushes back — "It was a team effort. Reward the whole team." A third person raises the obvious: "If we reward everyone equally, what's the incentive to go above and beyond?"

I've been in this room. It was equal parts funny and frustrating — everyone had a strong opinion, everyone had a good argument, and nobody was wrong. That's the problem.

This isn't a values debate. It's a design problem.

The Case for Rewarding the Team​

Let's start with the strongest arguments for team-level rewards — because they're genuinely compelling.

W. Edwards Deming — the father of quality management — argued that 94% of performance variation is attributable to the system, not the individual. He was talking about manufacturing, but the principle scales: in software, the system (tooling, process, team composition, codebase quality) shapes individual output more than we admit. The person who "drove" the feature had a designer who shaped it, a QA engineer who caught the edge cases, a platform team that kept the infrastructure alive, and a product manager who cleared the path. Rewarding one person for a system output is like giving the trophy to the striker and ignoring the midfield.

A meta-analysis of incentive programs found that team-directed incentives had a markedly superior effect on performance compared to individually-directed incentives. The overall average effect of all incentive programs was a 22% gain in performance — but team incentives outperformed individual ones consistently.

Then there's the Navy SEALs. Simon Sinek describes a conversation with the training director for SEAL Team Six. They evaluate candidates on a 2×2 matrix: Performance (vertical) vs Trust (horizontal). The finding?

They'd rather have medium performance and high trust than high performance and low trust. Every time.

The toxic high performer — brilliant on the battlefield, corrosive off it — gets cut. The highest-performing organisation on earth explicitly chooses team cohesion over individual brilliance.

The New Zealand All Blacks — 77% win rate over 100+ years, the most successful sports team in history — formalised this as the "No Dickheads" rule. If a player undermines trust, ability stops mattering. They're out. After every match, the most senior All Blacks sweep the locker room. No one is above the team.

Alfie Kohn, in Punished by Rewards, goes further: extrinsic rewards don't just fail to motivate — they actively undermine intrinsic motivation. "Do rewards motivate people? Yes. They motivate people to get rewards." When you dangle individual bonuses, people optimise for the bonus, not the work. They take fewer risks. They hoard knowledge. They avoid helping others because helping others doesn't show up on their scorecard.

The evidence is clear: when work is interdependent, individual rewards destroy the cooperation that makes the work possible.

The Case for Rewarding the Individual​

Now the other side — because ignoring it is how you lose your best people.

The Ringelmann Effect (1913): when people pull a rope together, individual effort decreases as group size increases. In a group of eight, each person exerts only about half the force they would alone. This isn't laziness — it's a rational response to diffused responsibility. If the reward comes regardless of my effort, why give 100%?

This creates the Sucker Effect: high performers observe free riders getting the same reward for less effort. They feel exploited. They reduce their own effort to match — or they leave. Research consistently shows that high performers are often the most likely to leave, partly because their exceptional work becomes "expected" rather than recognised.

The Recognition Paradox: managers spend disproportionate time coaching struggling employees, while high performers get less attention because they "don't need it." The result? The people carrying the heaviest load feel the least seen.

There's also a practical reality: not all work is equally interdependent. Some tasks genuinely are individual — a brilliant architectural insight, a solo debugging session that saves the team days, a piece of documentation that nobody asked for but everyone uses. Pretending these contributions are "team efforts" is dishonest, and people know it.

Pure team rewards, applied uniformly, produce:

• Free riders who coast on others' effort
• Resentful top performers who update their LinkedIn
• A culture where mediocrity is comfortable and excellence is invisible

Why Both Fail Alone​

Here's the payoff matrix. If you've read the game theory post, this will look familiar:

Neither is a stable equilibrium. Both produce outcomes nobody wants.

(Microsoft's "Lost Decade" is well-documented — stack ranking was the poster child for individual rewards gone wrong.)

The question isn't "team OR individual?" The question is: what does the work actually require?

The Answer: Match the Reward to the Work​

The companies that get this right don't pick a side. They ask a different question:

"What behaviour does this reward produce, given the structure of the work?"

• If the work is interdependent and you reward individuals → you get competition where you need cooperation
• If the work is independent and you reward the team → you get free riders and resentful stars
• If you match the reward to the work structure → you get the behaviour the system actually needs

This isn't theory. It's what the best-performing organisations have converged on. Here are four cases — each solving the same problem differently.

Case 1: Microsoft — The Clearest Before/After​

Under Steve Ballmer, Microsoft used stack ranking — pure individual rewards. Employees were ranked against each other. Someone had to get the lowest score, regardless of team performance.

The result? Engineers actively avoided joining teams with strong people (because they'd rank lower by comparison). They sabotaged each other. Collaboration died. Vanity Fair called it Microsoft's "Lost Decade."

Microsoft abolished stack ranking in late 2013 under Ballmer's "One Microsoft" reorganisation. Satya Nadella, who became CEO in early 2014, then built the replacement system around three pillars:

1. Your own individual impact — what you shipped
2. How you contributed to others' success — the collaboration factor
3. How you leveraged others' work — the "One Microsoft" principle

That's literally "reward individual AND team contribution, weighted by interdependence." Microsoft went from ~$300B to$3T+ market cap. The culture shift is widely credited as a key driver.

Correlation isn't causation — Microsoft's market cap growth was driven by cloud strategy, not just culture. But the culture shift removed a barrier to the collaboration that cloud strategy required. You can't build Azure across dozens of teams if those teams are ranked against each other.

Case 2: Google — Layered Recognition​

Google runs multiple reward mechanisms simultaneously:

• Peer bonuses — any employee can nominate any other for a cash bonus. This makes contribution to others visible without waiting for a manager to notice.
• Team awards — for shipping something that required genuine collaboration
• Promotion committees — independent panels review evidence of impact, including peer feedback. You can't get promoted purely on solo output.

Peer bonuses require manager approval and are capped per quarter — the friction makes gaming not worth the reputational cost. The bigger risk isn't gaming; it's that extroverts get nominated more than quiet contributors who do equally valuable work. That's why peer bonuses work best as one layer in a system, not the whole system.

The design principle: individual recognition for how you helped the team, team recognition for what the team shipped together.

Case 3: Navy SEALs — Both, But Trust Is Non-Negotiable​

We covered the SEALs' trust-over-performance stance earlier. But their reward structure is worth looking at separately.

They still measure individual performance. They still have rankings. But they refuse to reward performance in isolation. Performance without trust is a net negative.

The reward structure:

• Team membership is the baseline reward (you stay on the team)
• Individual excellence is recognised on top
• Individual excellence without team contribution = you're gone

Case 4: Toyota — Ideas Are Individual, Outcomes Are Team​

Different industry, same insight. Toyota splits the reward by what's being rewarded.

Toyota's suggestion system has generated 50 million+ ideas over 70 years (averaging 14.4 suggestions per employee per year). The reward structure:

• Individual recognition for suggestions — small monetary + symbolic rewards
• Team-level bonuses tied to quality, delivery, and safety metrics
• No individual performance ranking — evaluation includes how you develop others

The principle: individual ideas are rewarded (because ideation is independent work), but outcomes are rewarded at the team level (because execution is interdependent).

The SDLC Spectrum: Not All Work Is Equal​

Here's the thing most reward debates miss: software development isn't one type of work. It's a spectrum of interdependence. And the reward structure should follow that spectrum.

The pattern:

In practice, most work sits in the ambiguous middle. A "feature implementation" might be 90% one person's effort or 90% coordination — it depends on the feature, the team, and the codebase. The point isn't to classify perfectly. It's to ask the question before defaulting to one approach. The table is a starting point for the conversation, not a lookup table for the answer.

The more coordination the work requires → the more the reward should be team-based. The more it depends on individual judgment → the more it should be individual. Always: make the contribution visible.

Back to the Champion Points​

So — should the champion points go to one person or the whole team? Ask what was shipped:

• Solo technical breakthrough — a debugging insight, a performance optimisation, a piece of tooling that one person built → reward the individual. Make it visible.
• Team delivery — a feature that required design, engineering, QA, coordination, and cross-team dependencies → reward the team. The "driver" had a team that made driving possible.
• Both — and it usually is → do both. Recognise the individual's specific contribution publicly ("Priya's caching strategy saved us 40ms on every request") AND reward the team for shipping ("The checkout squad hit their Q1 target").

It's not "team OR individual." It's "what does the work structure tell us about where the value was created?"

The Design Principles​

If you're building a reward system — or arguing about one in a leadership meeting — these are the principles the evidence supports. Pin this to the wall.

What You Can Do Tomorrow​

One caveat before the action table: if Team A does highly interdependent work and gets team rewards, while Team B does independent work and gets individual rewards, you risk creating a two-tier system. The star on Team A who could earn individual recognition on Team B feels penalised for their team assignment. You need org-level consistency in how you assess interdependence, or you'll just move the unfairness from one dimension to another.

The One Takeaway​

You don't have a "team vs individual" problem. You have a design problem. The reward structure is a feedback loop — it produces behaviour. If you're getting the wrong behaviour, you've designed the wrong loop.

The best teams — SEALs, All Blacks, Microsoft post-Nadella, Toyota, Google — don't pick a side. They match the reward to the work. They make contribution visible. They refuse to trade trust for performance.

The champion points? Give them to the person when the work was theirs. Give them to the team when the work was shared. And always, always make the contribution visible — because the worst outcome isn't giving the reward to the wrong person. It's making someone feel invisible for work that mattered.

This post connects to the game theory series (why cooperation breaks down under individual incentives), The Price of Anarchy (local vs global optimisation), and The Luck Paradox (the egocentric bias that makes everyone overestimate their own contribution). The research draws from Deming's systems thinking, Alfie Kohn's Punished by Rewards, and Daniel Pink's Drive.

In software engineering, cognitive load refers to the total amount of mental effort being used in a developer's working memory to complete a task. Think of it like the RAM in a computer: if you try to run too many heavy applications at once, the system slows down, glitches, or crashes.

When a developer's cognitive load exceeds their mental capacity, productivity drops, the quality of code suffers, and the risk of burnout increases.

The Three Types of Cognitive Load​

The concept, originally developed by educational psychologist John Sweller, is typically broken down into three distinct categories in a technical context:

Why It Matters in Software Development​

In modern software environments, cognitive load has become a primary bottleneck. As systems move toward microservices, cloud-native architectures, and "you build it, you run it" philosophies, developers are often overwhelmed by the sheer volume of information they must hold in their heads.

Signs of High Cognitive Load​

• Analysis Paralysis: Taking a long time to start a task because the system feels too "heavy" to touch.
• The "Fear" of Changing Code: Developers become afraid to refactor because they don't fully understand the ripple effects.
• Frequent Context Switching: Jumping between different domains, tools, or Slack interruptions shreds mental focus.

How to Manage and Reduce It​

Managing cognitive load isn't about making the work "easy"; it's about clearing away the "noise" so developers can focus on the "signal."

• Limit Team Scope: Popularized by the book Team Topologies, this involves ensuring a single team isn't responsible for too many complex domains.
• Improve Developer Experience (DevEx): Investing in internal platforms, clear documentation, and "Golden Paths" reduces extraneous load (the "how do I deploy this?" struggle).
• Encourage Small, Decoupled Components: Smaller, well-defined services are easier to fit into working memory than massive, tangled monoliths.
• Standardization: Using consistent patterns and tools across a company allows developers to move between projects without having to relearn basic workflows.

The Golden Rule: If a developer has to spend 80% of their energy just figuring out how to run the environment or navigate the folder structure, they only have 20% left to actually solve the business problem.

The Psychology Behind the Load​

To understand cognitive load from a psychological perspective, we have to look past the code and focus on the biological architecture of the human brain. While software engineering feels like a purely logical exercise, it is actually a high-stakes performance of human memory and attention.

1. The Working Memory Bottleneck​

"The magical number seven, plus or minus two: some limits on our capacity for processing information." — George Miller, 1956

At the heart of cognitive load is Working Memory, the psychological "workspace" where we temporarily hold and manipulate information.

• The Constraint: In 1956, George Miller famously suggested that humans can hold roughly $7 \pm 2$ "chunks" of information at once. Modern research suggests this might be as low as 3 to 5 chunks for complex tasks.
• The Engineering Connection: When a developer looks at a function that has 15 different variables, 4 nested loops, and 3 external API calls, they are physically exceeding their working memory capacity.
• The Result: "Cognitive Overflow." This is the moment a developer says, "Wait, what was I doing?" Their brain literally ran out of temporary storage, and the previous context was overwritten.

2. Schema Theory: How Experts "Cheat" the Load​

Psychologists define a Schema as a mental structure that organizes categories of information and the relationships among them. This is the difference between a junior and a senior engineer.

• Chunking: An expert doesn't see "an if statement, a for loop, and a try-catch block." They see a "Circuit Breaker Pattern." By grouping individual items into a single mental schema, they reduce 10 chunks of information into 1.
• Germane Load as Investment: Germane load is the mental effort spent building these schemas. When you struggle to learn a new architectural pattern, you are performing "productive" psychological work that will lower your intrinsic load in the future.

3. Dual Process Theory (System 1 vs. System 2)​

Popularized by Daniel Kahneman, this theory suggests our brains operate in two modes:

"Thinking is to humans as swimming is to cats. They can do it, but they'd prefer not to." — Daniel Kahneman, Thinking, Fast and Slow The Psychological Angle: High Extraneous Load (bad tools, loud offices, messy code) forces a developer to stay in System 2 for tasks that should be System 1. This is why a developer can feel physically exhausted after 8 hours of "just sitting at a desk"—they have depleted their limited pool of "Executive Function" resources.

4. The Flow State and Attentional Blink​

The ultimate goal in software engineering is the Flow State (proposed by Mihaly Csikszentmihalyi)—a psychological state of deep "immersion."

• Interruption Cost: When a developer is in flow, they have built a fragile "house of cards" in their working memory.
• Attentional Blink: When a Slack notification or a meeting request pops up, the brain undergoes a "switch cost." It can take upwards of 20 minutes to rebuild that specific mental model.
• Cognitive Friction: High extraneous load acts as "friction" that prevents the brain from ever reaching the flow state, leading to frustration and lower job satisfaction.

5. The Psychological Impact​

Psychological Insight: We don't "write" code; we "model" it in our minds and then transcribe it. The bottleneck is never the typing speed; it is the mental modeling speed.

The Agentic Shift​

"Automation does not replace human work. It changes it — often making it harder." — Lisanne Bainbridge, Ironies of Automation, 1983 In the era of Agentic AI, the narrative of cognitive load shifts from "The Burden of Creation" to "The Burden of Orchestration." If traditional software engineering is like being a lone writer at a desk, managing multiple AI agents is like being the director of an experimental theater troupe: you aren't writing every line anymore, but you are responsible for the coherence, timing, and "hallucination" control of every actor on stage.

1. The Psychological Shift: Builder → Director​

In a traditional workflow, your cognitive load is primarily creative. You hold the logic in your mind and transcribe it. With multiple agents, your role shifts toward evaluative load.

The "Reviewer's Fatigue" (The System 2 Trap)​

Psychologically, writing code often engages a flow state. However, reviewing code—especially code generated by multiple agents—requires constant System 2 (Slow Thinking).

• The Problem: The brain finds it more exhausting to find a needle in a haystack (debugging an agent's subtle logic error) than to build the haystack itself.
• The "Losing It" Factor: When you run 5 agents in parallel, you aren't doing 5x the work; you are doing 5x the critical auditing, which depletes your executive function significantly faster.

2. The New "Agentic" Cognitive Load Map​

The three types of cognitive load we discussed previously evolve in an agent-heavy environment:

3. Why Multi-Agent Systems Create a "Complexity Trap"​

From a Systems Thinking perspective, every new agent added to a system doesn't just add capability; it adds communication channels.

• The Formula: $n(n-1)/2$. If you have 5 agents, you have 10 potential points of failure in communication.
• Semantic Noise: Agents often work from "conflicting assumptions." If Agent A assumes a "User" is an ID (integer) and Agent B assumes it's an Email (string), the human manager must now resolve this "hidden" conflict. This is a massive hit to your working memory.

4. How to Manage Agents "Without Losing It"​

To keep your cognitive load manageable while orchestrating AI, you must move from "Micromanagement" to "Governance."

A. Establish "Hard" Task Boundaries​

Don't build a "Bag of Agents" where everyone talks to everyone. Use a Hierarchical Topology:

• The Lead Agent (The Architect): Only this agent talks to you.
• Specialized Sub-Agents: They only talk to the Lead.
• Psychological Benefit: This "chunks" the information. You only need to hold the Lead Agent's state in your working memory.

B. Invest in "Context Engineering"​

The greatest source of "Agentic Anxiety" is the Trust Gap. You don't know why the agent did what it did.

• The Fix: Use frameworks that provide full execution traces (like LangGraph or LangSmith).
• Action: If you can't "see" the thought process, don't ship the agent. Observability is the only antidote to the cognitive load of uncertainty.

C. The "Human-on-the-Loop" Strategy​

Stop trying to be "Human-in-the-loop" for every step. It's too taxing.

• Strategy: Define "Critical Gates" (e.g., Schema changes, API deployments). Let agents run autonomously for 80% of the task, but force a "hard stop" for human review at high-risk junctions. This preserves your System 2 energy for when it actually matters.

The Engineering Leader's Takeaway​

In 2026, the most successful engineering leaders aren't those with the most agents; they are those with the cleanest mental models of their agentic workflows.

The Narcotic of Productivity: It is easy to feel productive because "work is happening," but if the Reviewer's Fatigue leads to a 35% failure rate in production, the cognitive load has simply been deferred, not deleted.

"The real problem of humanity is the following: We have Paleolithic emotions, medieval institutions, and godlike technology." — E.O. Wilson The tools changed. The bottleneck didn't. It's still the space between your ears.

This post connects to the broader theme of how systems shape behaviour. For how game theory explains why teams defect instead of cooperate, read The Prisoner's Dilemma Is Why You Got Ghosted on Slack. For what happens when everyone optimises locally, read Why Everyone's Busy But Nothing Ships Faster.

Somewhere in your organisation right now, an engineer wants to use a tool. It's open source. It's battle-tested. Half the Fortune 500 runs it in production. But first, they need to fill out a vendor assessment form, get InfoSec sign-off, wait for procurement to confirm there's a contract in place, and then — maybe, in four to six months — they'll get a "yes" or a "no" from a committee that's optimised for risk avoidance, not risk management.

This isn't an argument against governance. Governance matters — especially in regulated industries. This is an argument that the way most enterprises do governance today is broken: optimised for the appearance of control rather than the reality of it. The question isn't whether to govern. It's whether your governance framework is actually reducing risk — or just reducing speed.

Meanwhile, the startup down the road shipped the feature last Tuesday.

But hey, at least you've got a contract. You can sue them if things go wrong. Right?

The Contract Will Protect Us​

Let's start with the big one — the security blanket that justifies half of enterprise governance: "We need a contract so we have legal recourse."

Let's test that theory with the largest IT outage in history.

July 19, 2024. CrowdStrike pushes a faulty update. 8.5 million Windows machines crash globally. Every Fortune 500 airline goes down. 75% of top healthcare organisations affected. Estimated damages to Fortune 500 companies alone: $5.4 billion.

I know because I was there. Friday night, flight cancelled, standing in a terminal watching departure boards go dark one by one — with a conference talk to give Saturday morning. The approved vendor's approved update took down the approved airline's approved systems. Nobody asked me if I'd approved that.

CrowdStrike was the approved vendor. Every one of those enterprises had a contract. They'd been through procurement. They'd passed InfoSec review. They had SLAs, liability clauses, the works.

So how much have those enterprises recovered?

Zero dollars. As of today — not a cent.

Delta Air Lines — 7,000 cancelled flights, 1.3 million stranded passengers, $500M+ in claimed losses — is still in court. CrowdStrike is "confident" their liability is capped at single-digit millions thanks to the limitation of liability clause in the contract. The same contract that was supposed to protect Delta.

The shareholder lawsuit? Dismissed. The passenger class action? Dismissed. CrowdStrike's stock? Fully recovered within five months. Customer retention rate? 97%.

The contract didn't protect anyone. It protected CrowdStrike.

"But Cloud Vendors Have SLAs"​

Sure they do. Let's read the fine print.

AWS's Customer Agreement, Section 9.1:

"NEITHER AWS NOR YOU... WILL HAVE LIABILITY TO THE OTHER... FOR (A) INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES, (B) THE VALUE OF YOUR CONTENT, (C) LOSS OF PROFITS, REVENUES, CUSTOMERS, OPPORTUNITIES, OR GOODWILL, OR (D) UNAVAILABILITY OF THE SERVICES"

Read that again. They explicitly exclude liability for the service being unavailable. The thing you're paying them for. If it breaks, they're not liable for the fact that it broke.

What you do get: service credits. Not cash — credits against future usage of the service that just failed you. Typically 10-30% of your monthly bill for the affected service.

So if you spend $100K/month on AWS and suffer a 4-hour outage that costs the business$2M in lost revenue, the SLA credit might be $10K. That's 0.5% of the actual loss. Industry analyses consistently show SLA credits cover a fraction of actual outage costs — the math simply doesn't work in the customer's favour.

The contract doesn't transfer risk. It transfers paperwork.

The Approved Vendor List: A History of Spectacular Failures​

The approved vendor list exists to ensure you only use "safe," vetted software. Let's look at how that's worked out.

SolarWinds (2020) — On the approved vendor list of 18,000 organisations including the US Treasury, Department of Homeland Security, and most of the Fortune 500. Russian intelligence inserted malicious code into trusted software updates — the exact mechanism enterprises rely on. Even FireEye, a cybersecurity company, was compromised through their own approved vendor.

CrowdStrike (2024) — The approved security vendor. $5.4 billion in damages. Already covered.

Log4Shell (2021) — 93% of enterprise cloud environments were vulnerable. CVSS severity: 10.0 (maximum). The US Department of Homeland Security estimated finding and fixing every instance would take a decade. Total lawsuits against Apache, the maintainer? Zero. Because the Apache Software Foundation runs on [$3 million a year](https://sanesecurityguy.com/articles/log4shell-giants-standing-on-the-shoulders-of-dwarves/) — roughly$8,600 per project. And Log4j wasn't on your approved vendor list directly — it was inside the commercial software that was.

The approved vendor list didn't prevent any of these. That's not an argument for abolishing vendor vetting — it's an argument that vendor vetting alone is insufficient. These incidents succeeded despite the process, not because of it. The list catches real risks every day. But it creates a dangerous illusion when it becomes the primary line of defence rather than one layer in a deeper stack.

"Do I Still Need Approval to Build a Slack App?"​

Let's zoom in on something that'll make your eye twitch.

An engineer wants to build an internal Slack bot. It reads messages in one channel and posts a summary in another. It touches no customer data. It has no external network access. It runs on the company's own infrastructure.

The approval process (conservatively estimated — your mileage may vary, but probably won't):

1. Vendor assessment form (even though there's no vendor — you're building it)
2. InfoSec review (a few weeks, if you're lucky)
3. Architecture review board (next available slot: TBD)
4. Data classification exercise (it's Slack messages between engineers, but sure)
5. Procurement sign-off (for a tool that costs $0)
6. Privacy impact assessment (it's an internal bot, but policy says...)

Total elapsed time: long enough that the engineer has either built it in secret or stopped caring. For a Slack bot. That took an afternoon to build.

Now multiply that by every internal tool, every automation, every experiment. Every time someone has an idea that could save the team hours a week, they run the same gauntlet. Most of them don't bother. They either build it quietly and don't tell anyone (hello, shadow IT), or they just... stop having ideas.

Vendor onboarding at large companies takes up to 6 months. 52% of companies say third-party assessments take 31-60 days. And the average enterprise wastes $18 million annually on unused software licenses — software that was approved but nobody uses because by the time it arrived, the team had moved on.

The process doesn't prevent risk. It prevents progress.

Code Isn't the IP Anymore​

Here's the existential one. For decades, the governance narrative has been: "The code is the competitive advantage. Leaking it is catastrophic."

But what happens when AI writes most of it?

• 41% of all code is now AI-generated (industry estimates across multiple surveys including Google, Microsoft, and GitHub data — for now)
• GitHub Copilot contributes 46% of code for its active users — 20 million of them
• Microsoft: up to 30% of the company's code is AI-generated. Their CTO expects 95% by 2030
• Google: over 30% of new code is AI-generated

If anyone with the same agent and the same prompt can regenerate functionally equivalent code, the code itself is a commodity. The actual IP is the problem definition, the architecture decisions, the domain knowledge, the data, and the evaluation criteria that guide the agents. Not the for-loops.

Open source already proved this. Linux, Kubernetes, React — all public. The companies using them still have competitive advantages. The code was never the moat. The system was.

And yet, governance frameworks still treat source code like it's the crown jewels. They lock down repos, restrict tooling, and add friction to every commit.

Even domain knowledge — once the ultimate moat — is being disrupted as AI context windows grow large enough to absorb and reason over entire codebases.

What Regulation Actually Says (vs. What People Think It Says)​

What people think: "Regulators require us to use approved, contracted enterprise vendors."

What regulators actually say:

Every single major regulator takes a technology-neutral, outcomes-based approach. They care about controls, audit trails, and accountability — not which vendor's logo is on the invoice.

FINRA said it explicitly: firms must "update their written supervisory procedures to address the use of AI rather than relying on vendors as a shield." The regulator is literally telling you that the contract isn't the governance.

The Real Governance Stack​

So if contracts, approved vendor lists, and code lockdowns aren't the answer — what is?

🛡️ Actual Governance — Controls outcomes:

• Agent sandboxing — what can it access?
• Audit trails — who prompted what, what was generated?
• Output validation — automated tests, SAST, policy gates
• Eval frameworks — is the output correct and safe?
• Data residency — where do prompts and outputs flow?
• Red teaming — actively trying to break it
• Model version pinning — the model you tested is the model you run
• Human-in-the-loop — risk-based, not blanket
• Cost governance — who's accountable for API spend?

The question isn't "is this tool on the approved list?" It's "do we have the infrastructure to use any tool safely?"

If the answer is no, banning tools is a band-aid. If the answer is yes, the vendor's size doesn't matter — the controls do.

The Startup Ecosystem Is Already Enterprise-Grade​

The reflexive response: "We can't use startup tools. They might disappear. They're not enterprise-ready."

The data says otherwise:

• LangChain — $125M Series B at$1.25B valuation. 110,000+ GitHub stars. 47,000+ production installations.
• Promptfoo — Used by over 25% of Fortune 500. Acquired by OpenAI in March 2026.
• Langfuse — 6M+ monthly SDK installs. Acquired by ClickHouse (valued at $15B) in January 2026.
• 62% of Fortune 500 companies now use at least one AI agent framework in production.

These aren't scrappy side projects. They're the tools that the world's largest companies are already running in production — while the procurement team is still evaluating the vendor assessment form.

The hybrid model makes sense: big vendors for infrastructure and data (AWS, GCP, Azure — compliance, residency, stability), startup/OSS ecosystem for tooling and orchestration (speed of innovation, composability, low switching cost). The risk profiles are categorically different. Treating them the same is a category error.

The Cost of Not Moving​

Here's what doesn't show up on a risk register:

• 95% of enterprise AI pilots fail to deliver measurable P&L impact (MIT, July 2025). The report attributes this to a "learning gap" — the inability to integrate AI into existing workflows, poor resource allocation, and brittle processes. Governance theatre makes this worse: instead of building the organisational muscle to adopt AI effectively, enterprises burn their change budget on procurement cycles and vendor assessments that don't address the actual failure modes.
• Two-thirds of companies are stuck in pilot phase (McKinsey). The ones that aren't are pulling ahead fast.
• Top AI performers are 2x as likely to quit their jobs (Upwork Research Institute). The best engineers leave because they can't use modern tools. We're left with people comfortable with the status quo.
• Gartner predicts 75% of large enterprises will adopt dedicated AI governance platforms by 2026. Not "ban AI tools" — govern them.

The risk of adopting is visible. The risk of not adopting is invisible.

Nobody gets fired for maintaining the status quo. People get fired for approving a tool that causes an incident. The incentive structure rewards inaction — the same payoff problem that makes cross-team collaboration break down at scale.

You avoided the risk of a new tool causing an incident. Instead, you got the risk of irrelevance. One is recoverable. The other isn't.

The One Thing​

We don't ban cars because they can crash. We build seatbelts, airbags, speed limits, licensing, and insurance.

Enterprises that ban AI tools are banning cars. Enterprises that build governance frameworks are building roads.

The approved vendor list didn't stop SolarWinds. The contract didn't stop CrowdStrike. The SLA won't make you whole when the cloud goes down. And the procurement process won't protect you from the startup that ships in a week what takes you a quarter.

Stop asking "is this tool safe enough to use?"

Start asking "do we have the governance infrastructure to use any tool safely?"

Build the seatbelts. Then drive.

References: CrowdStrike outage analysis, AWS Customer Agreement, EU AI Act, FINRA Regulatory Notice 24-09, US Treasury FS AI RMF, MAS Project MindForge, MIT GenAI Divide Report, Gartner Market Guide for AI Governance Platforms. The SolarWinds, Log4Shell, and CrowdStrike case studies draw from multiple sources linked throughout.

A new project kicks off — migrating a critical system to a platform nobody on the team has used before. Well, almost nobody. There's one person who's built on it. Shipped production workloads. Knows the failure modes.

They don't get the lead. The person with the most years of experience does. The senior. The one with the title.

Everyone defers. The titled lead chairs the meetings, makes the architecture calls, approves the designs. The person who actually knows the platform sits three rows back on the call, unmuted only when asked a direct question.

Six weeks later, the project is behind. Decisions are being revisited. The team is frustrated but can't quite name why.

You've seen this movie. Maybe you've been in it. Maybe you've been on both sides.

The Default: Title = Lead​

Here's the unspoken assumption: if someone is senior, they must be competent at everything. Years of experience becomes a universal proxy for expertise. Ten years in the industry? You can lead anything.

Except — why would you, when someone on the team already knows it? They could learn it, sure. But the team already has someone who's been there, built on it, and knows where the landmines are. The question isn't capability. It's opportunity cost.

Patrick Lencioni's The Five Dysfunctions of a Team describes the foundation that high-performing teams are built on: vulnerability-based trust — the ability to admit what you don't know without it being used against you. When a senior is handed the lead in an unfamiliar domain, the incentive structure works against that honesty. Admitting "I don't know this space" feels like admitting you don't deserve your title. So you wing it.

And the team? They see the title. They don't push back. Lencioni calls this fear of conflict — not shouting matches, but the healthy act of challenging ideas regardless of who proposed them. The team's silence isn't agreement. It's avoidance.

The dysfunction isn't that the senior person is incompetent. It's that the system made it impossible for anyone to say the obvious: you're junior here.

The Map Is Not the Territory​

Expertise doesn't transfer the way we pretend it does.

Donella Meadows, in Thinking in Systems, describes how every system has its own feedback loops, delays, and leverage points. Understanding one system deeply doesn't mean you understand another. A senior backend engineer who's spent a decade optimising distributed databases has a rich mental model — of that system. Put them in charge of a frontend migration and they're operating on a map of a different territory.

The mental model that makes you effective in one system can actively mislead you in another. The senior person isn't just starting from zero — they're starting from a confident misapplication of the wrong model.

This isn't a failure of intelligence. It's a failure of fit.

The Explore-Exploit Mismatch​

Brian Christian and Tom Griffiths, in Algorithms to Live By, describe the explore-exploit tradeoff (knowing when to invest in learning something new vs. when to double down on what already works — get this wrong and you either waste time reinventing or make decisions on outdated knowledge). When you're new to a domain, you explore. When you're experienced, you exploit what you know.

Putting a domain-junior person in the lead compresses the exploration phase. They're forced into exploit mode with nothing to exploit. Meanwhile, the domain expert is stuck watching.

When you assign leadership to someone who hasn't explored the domain, you're asking them to make decisions with no data.

Authority Without Influence, Influence Without Authority​

Robert Cialdini's Influence identifies authority as one of six principles driving human decisions — we follow people who hold positions of power. It's deeply wired. The problem isn't that authority doesn't work. It's that it works too well in the wrong context. When the authority figure lacks domain expertise, the team still follows — because the authority signal overrides their own judgment.

So if you're the domain expert without the title — the person who knows the right answer but can't make the call — what do you actually do?

Not the idealistic "just speak up" advice. The real moves:

1. Write it down before the meeting​

Don't wait for the meeting where the lead makes the wrong call and try to correct it in front of everyone. You're fighting authority and social proof at the same time — that's a losing move.

Write it down first. Options, tradeoffs, recommendation — before the decision point. The lead reads it privately, without the pressure of looking uninformed. They can adopt your recommendation and present it as the team's direction. You don't get the credit in the room. You get the outcome.

This is Cialdini's commitment and consistency — once someone has mentally agreed with a well-reasoned argument in private, they stay consistent with it in public.

2. Build a trail of small wins​

You don't get influence by asking for it. You get it by being right, repeatedly, in ways people can see.

Volunteer for the proof-of-concept nobody wants to own. Write the migration runbook that becomes the team's reference doc. Spike on the integration approach for a non-critical service and ship it before anyone asks. These aren't glamorous — but they're visible. After three or four of these, the team starts routing questions to you naturally — social proof shifts. Authority given can be taken away. Influence earned through a track record is sticky.

3. Use questions, not statements​

When the lead is about to make a call you disagree with, don't say "that's wrong." That triggers a status defence.

Instead:

You're not challenging their authority. You're offering to do work. The spike reveals what you already knew, the decision changes based on "new information," everyone saves face.

4. Co-opt the lead, don't compete​

The lead has things you don't: stakeholder access, org context, the ability to escalate. You have things they don't: domain knowledge, technical credibility with the team.

Make the lead look good through your expertise. Brief them before stakeholder meetings. Flag risks early so they can raise them as their foresight. When the lead starts relying on you to not look bad, you have influence — the kind where they come to you before making calls.

This is Cialdini's reciprocity: when you consistently make someone's life easier, they return the favour. In this case, the favour is listening to your technical judgment.

5. Know when to escalate​

Sometimes none of this works. The trigger: when the same decision gets revisited for the second time, or when you can see a concrete technical risk that the lead has dismissed and the timeline is about to eat it. That's your signal.

Don't go over their head. Go beside them. Find a peer of the lead who respects technical evidence. Present the problem as a technical risk, not a people problem.

Now it's not "the junior disagrees with the lead." It's "there's a technical concern that needs a second opinion." The framing matters more than the content.

Let the Topology Match the Reality​

Matthew Skelton and Manuel Pais, in Team Topologies, describe how team structures should match cognitive load. When you force someone to lead in an unfamiliar domain, you're maxing out their cognitive load on just understanding the basics. Nothing left for actual leadership.

But here's the part most people miss: the answer isn't to remove the senior person. It's to reposition them.

Skelton and Pais introduce enabling teams — whose job isn't to build the thing, but to help others build it better. This is the model that actually works:

In the traditional model, the senior owns everything — technical calls, stakeholders, coordination — and the domain expert feeds into them. The bottleneck is obvious: every decision routes through the person who knows the least about the domain.

In the reframed model, the domain expert owns technical direction. The senior owns what seniority is actually good at: clearing the path, managing upward, absorbing organisational noise, and coaching the domain expert on the leadership skills they haven't built yet. Both lead. Neither pretends.

The senior isn't sidelined — they're doing the work that only they can do. The domain expert isn't overloaded with politics — they're doing the work that only they can do. Cognitive load is distributed where it fits.

That's not a demotion. That's a better use of everyone's strengths.

The Steelman: Why Seniority-Based Leadership Exists​

Before you forward this to your skip-level with a "SEE?!" — the counterarguments are real.

The argument isn't that seniority never matters. When seniority and domain expertise align — great, you've got the best of both worlds. This post is about when they don't. And organisations default to seniority alone reflexively rather than deliberately.

The best outcome isn't picking one column. It's combining both — deliberately.

What This Looks Like in Practice​

Normalise "I'm junior in this." Especially from senior people. When a staff engineer says "I've never worked with this — I'm going to lean on the team for technical direction," that's not weakness. That's the vulnerability-based trust Lencioni says high-performing teams are built on.

Decouple technical leadership from the org chart. The person who drives technical decisions should be the person best positioned to make good ones in that domain. Let technical leadership be fluid — it follows the work, not the hierarchy.

Use seniority for what it's good at. Pattern recognition, org navigation, mentoring, knowing when to escalate. None of that requires being the domain expert.

Pair them. Domain expert drives technical direction. Senior handles stakeholders, politics, air cover. Both lead. Neither pretends to be something they're not.

The Rewrite​

Let's go back to that opening scene. New project. New platform.

This time, the engineering manager says:

Priya is two levels below the manager on the org chart. Nobody cares. She knows the platform. She makes fast, informed decisions. The team trusts her because her expertise is visible, not assumed. The manager adds value by clearing the path — not by pretending to know the terrain.

The project ships on time. More importantly, the team wants to work together again.

The Point​

Everybody is junior in something. The CTO is junior in the framework that launched last year. The principal engineer is junior in the compliance domain they've never touched. The engineering manager is junior in the platform their team just adopted.

This isn't a flaw. It's just reality.

The best teams don't ignore seniority. They don't abolish hierarchy. They just refuse to confuse title with expertise. They let people lead where they're strong and learn where they're not. They treat "I'm junior here" as the starting point of trust, not the end of credibility.

This post started with a conversation at home — my wife noticed the same pattern playing out in her office, and it sparked a thread we couldn't stop pulling.

A self-journal. Not a blog post with answers — a collection of better questions I keep coming back to.

Inspired by Shaan Puri's "13 Questions That Will Change Your Life" — where he talks about questions being keys that unlock doors. I wanted to build my own keychain.

These are questions I've reframed for myself over time. The left column is how most people (including past me) would ask it. The right column is how I try to ask it now.

Time​

My rule is simple: I only want to spend time doing one of three things — earning, learning, or relaxing. If something doesn't fall into one of these, it probably doesn't deserve my hours.

Money​

Money, to me, is about one thing: freedom. Not luxury, not status — the ability to choose what I do with my time.

Work & Craft​

I choose work I enjoy. In difficult times, work has always been my anchor — you can't stop thoughts, but you can replace them with something more meaningful. I care about craft — doing things the right way, being opinionated for good reasons.

Relationships​

Every relationship is a journey toward something — with the freedom to change direction when it's needed. The question is whether you're walking it honestly.

Growth & Learning​

Learning truly happens only when there's a real change in behavior. Until then, it's just information — not growth.

Self & Identity​

Happiness isn't a destination for me — it's the journey. If I have to name a goal, it's about being useful and maximizing that usefulness as much as possible. At least, that's what I know for now.

This is a living document. I'll keep adding questions as I find better ones. The goal isn't to answer them all — it's to sit with the right ones long enough that clarity shows up on its own.

Because at the end of the day, the answers to these questions aren't things you can buy — they're things you build.

"A fit body, a peaceful mind, a house full of love. These things cannot be bought. They must be earned." — Naval Ravikant

An inversion manual for engineering leaders

I'm a new parent. I have no idea how to be a good father. I've read zero parenting books. I have no framework, no methodology, no "5 pillars of effective fatherhood."

But I know what a bad father looks like. I know what breaks trust. I know what makes a child stop talking to you. I know what happens when you're physically present but emotionally absent.

I don't have a playbook for getting it right. I have a very clear list of things to never do.

Turns out, that's enough. And it applies to more than parenting.

Invert, Always Invert​

Charlie Munger — Warren Buffett's partner for over six decades — borrowed a line from the 19th-century mathematician Carl Jacobi: "Man muss immer umkehren" — invert, always invert.

Munger's version was characteristically blunt:

In investing, this means: don't just pick great stocks — avoid the catastrophic ones. The math is asymmetric. A 50% loss requires a 100% gain to recover. Avoiding ruin matters more than chasing brilliance.

"It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent." — Charlie Munger

Small bad decisions compound. So do small good ones. The gap between the two curves isn't talent or intelligence — it's the habit of asking "what would fail here?" before you act.

Every leadership book is about what to do. This post is about how to think about what to stop doing.

A caveat: inversion won't make you visionary. It won't teach you to hire brilliantly or set a direction that inspires people. But it will stop the undermining of people who can do those things. And in practice, the distance between a terrible manager and a good one is shorter than most people think — and it starts with learning to see what's already going wrong.

The question is: how do you find that list? Not my list — yours. For your team, your context, your failure modes.

Gary Klein's premortem technique is inversion made practical. Before a project starts, you ask the team: "Imagine it's six months from now and this project has failed spectacularly. Tell me why." People who'd never raise a risk in a planning meeting will happily explain why something already failed — because it's hypothetical, it's safe, and it's fun. The premortem is inversion with a calendar invite.

Three lenses help.

The Three Lenses​

There's no universal checklist for bad management. Every team is different. Every context has its own failure modes. But almost every management failure I've seen — as an engineer growing under bad managers, as a lead making my own mistakes, and now watching the pattern repeat — falls into one of three categories.

Every team runs on three fundamental resources: clarity of purpose (do we know what matters?), ownership and autonomy (can we act on it?), and trust (can we be honest about how it's going?). Degrade any one and the team degrades.

Think of these as lenses. Put on any one of them and look at a decision you're about to make. If the decision looks dangerous through any of the three, it probably is.

Lens 1: Ownership & Autonomy​

"Am I enabling agency or creating dependency?"

Donella Meadows, in Thinking in Systems, makes a claim that changed how I think about everything:

"Missing information flows is one of the most common causes of system malfunction. Adding or restoring information can be a powerful intervention, usually much easier and cheaper than rebuilding physical infrastructure."

A team is a system. It has inputs (context, priorities, constraints), processes (how decisions get made, how work flows), and outputs (shipped software, solved problems, happy users). Between all of these are feedback loops — the signals that tell the system whether it's working or not.

A good manager strengthens feedback loops. A bad manager — often without realising it — severs them.

Here's what severing looks like in practice.

A manager sits in a leadership meeting. They hear about a strategic shift — a product line is being deprioritised, a reorg is coming, a key dependency is being sunset. They absorb it. They go back to the team and share... nothing. Or a sanitised version. Or the parts they think the team "needs to know."

That's an information flow, cut. The team is now making decisions based on an incomplete picture of reality. They're optimising for a world that no longer exists. When their decisions turn out to be wrong — and they will — they'll come to the manager for correction. The manager provides it. And a pattern forms: the team learns that only one person can see the full board. Every decision routes through them. The manager becomes the bottleneck — not because they wanted to, but because they removed the information that would have let the team decide on their own.

Not all context can be shared — confidential reorgs, HR matters, sensitive commercial decisions have real boundaries. The failure isn't sharing selectively when there's a genuine reason. The failure is when filtering becomes the default — when the instinct is to hold back rather than pass through, and the team operates on a fraction of the picture not because of confidentiality, but because of habit.

In psychology, this is called learned helplessness — when people repeatedly experience that their actions don't affect outcomes, they stop trying. The team isn't passive because they're lazy. They're passive because they've been trained to be. Every overridden decision, every withheld context, every "let me handle this" taught them that their agency doesn't matter.

The inversion question: Before any decision, ask — "Am I enabling agency or creating dependency?"

• Keeping context to yourself? Removes a feedback loop.
• Requiring your approval on every PR? Removes the team's ability to self-correct.
• Skipping retros because "we're too busy"? Removes the system's ability to learn.
• Sharing the why behind a decision, not just the what? Adds a feedback loop.
• Letting the team see the same dashboards you see? Adds a feedback loop.
• Making your calendar and priorities visible? Adds a feedback loop.

Andy Grove, in High Output Management, defined a manager's output as: the output of their team + the output of adjacent teams they influence. Not your own output. The moment you start optimising for your own involvement — being in every meeting, touching every decision, being the person who "knows everything" — you're optimising for a metric that actively degrades the system.

The systems lens doesn't give you a list of things to do. It gives you a diagnostic: follow the information.

They don't get it because you didn't give it to them.

If you've read Why Everyone's Busy But Nothing Ships Faster, you'll recognise this pattern at the org level — the Price of Anarchy, where rational local decisions produce irrational global outcomes. The same dynamic plays out inside a single team when the manager becomes the coordination bottleneck. Everyone's busy. Nothing moves.

Lens 2: Trust​

"Am I making honesty cheaper or more expensive?"

The ownership lens asks whether people can act. The trust lens asks whether they will — whether they feel safe enough to be honest, take risks, and disagree.

Patrick Lencioni's The Five Dysfunctions of a Team builds a pyramid. At the base: trust. Not "I trust you to deliver on time" trust — vulnerability-based trust. The kind where you can say "I don't know," "I was wrong," or "I need help" without it being used against you. Amy Edmondson's research calls this psychological safety — and Google's Project Aristotle found it was the single strongest predictor of team effectiveness. Not talent. Not process. Not tooling. Whether people felt safe enough to be honest.

Every layer above depends on it:

Now invert it. If trust is the foundation, what cracks it?

The fastest way to destroy trust is to make honesty expensive.

It happens every time someone is punished for bringing bad news. Every time a manager takes credit for the team's work in a leadership meeting. Every time a difficult conversation is avoided because being liked feels safer than being honest. Every time someone raises a concern and it's dismissed — or worse, remembered during their next performance review.

Lencioni calls the result artificial harmony — a surface-level peace that masks unresolved issues. It feels like a healthy team. It's actually a team where nobody feels safe enough to disagree. And the issues don't disappear. They compound. Every week you delay a difficult conversation, the conversation gets harder and the damage gets deeper. The same compound effect that erodes relationships through small daily silences erodes teams through avoided truths.

Same with kids, by the way. The conversation you're avoiding with your teenager? It's not getting easier with time either.

The inversion question: Before any decision, ask — "Am I making honesty cheaper or more expensive?"

• Taking credit for the team's work? Makes honesty expensive — why would anyone go above and beyond if the credit flows up?
• Deflecting blame downward? Makes honesty expensive — why would anyone admit a mistake if it'll be used against them?
• Naming people specifically when things go well? Makes honesty cheaper — people feel seen.
• Going first in a post-mortem with "here's what I got wrong"? Makes honesty cheaper — you've modelled vulnerability.
• Addressing the underperformer directly and early? Makes honesty cheaper — the team sees that problems get addressed, not ignored.
• Caring enough about someone's growth to tell them the truth, even when it's uncomfortable? Makes honesty cheaper. If you care but won't say it, you're not being kind — you're being cowardly. And the team knows it.

The trust lens isn't about being nice or being tough. It's about asking: after this interaction, will people be more or less likely to tell me the truth?

If the answer is "less" — you've just made your system dumber. Because a team that can't tell you the truth can't tell you when things are breaking. And by the time you find out on your own, it's a P1.

Lens 3: Clarity of Purpose​

"Am I adding noise or signal?"

In software engineering, cognitive load refers to the total mental effort being used in a developer's working memory. John Sweller's cognitive load theory breaks it into three types:

A manager's job, through this lens, is simple: maximise intrinsic and germane load. Minimise extraneous load. Let people spend their brainpower on the actual problem and on getting better at solving it — not on navigating your process, decoding your priorities, or figuring out which of the five "urgent" things is actually urgent.

Matthew Skelton and Manuel Pais, in Team Topologies, took this further: cognitive load isn't just an individual constraint — it's a team constraint. If a team is responsible for too many domains, too many services, too many contexts, their collective cognitive capacity is overwhelmed. They don't need more people. They need less scope.

The same applies to management overhead. Every process you add, every approval gate, every status meeting, every "quick sync" — it's extraneous load. It's weight on the team's working memory that doesn't help them solve the problem. If you've read Your Agents Are Running. So Why Are You Still Exhausted?, you'll recognise this — even with AI doing the heavy lifting, the coordination load can still crush you.

Here's the failure mode that nobody talks about: the manager who creates urgency.

Everything is P1. Every request is "ASAP." Every Slack message is a fire. The team is perpetually in reactive mode, sprinting from one emergency to the next. Deep work disappears. Strategic thinking disappears. What's left is a group of talented people playing whack-a-mole with their calendars.

Michael Porter said it plainly: "The essence of strategy is choosing what not to do." A manager who treats everything as urgent has made no strategic choices. They've abdicated the hardest part of the job — saying no — and passed the cognitive burden to the team.

Eisenhower's framing remains the clearest:

"What is important is seldom urgent and what is urgent is seldom important."

Parents do this too, by the way. Every extracurricular becomes essential. Every homework assignment is a crisis. The kid's calendar looks like a sprint board with no capacity planning. And then we wonder why they're anxious. The load lens works everywhere.

The inversion question: Before any decision, ask — "Am I adding noise or signal?"

• Adding an approval step? Noise.
• Writing a clear decision doc so the team doesn't have to guess your reasoning? Signal.
• Calling a meeting that could've been a message? Noise.
• Saying no to a stakeholder request so the team can focus? Signal.
• Changing priorities mid-sprint without explanation? Noise.
• Maintaining a visible, stable list of the team's top 3 priorities? Signal.
• Requiring the team to context-switch between four projects? Noise.
• Shielding the team from organisational noise so they can go deep? Signal.

If you can't articulate your team's top 3 priorities right now — without checking a document — you don't have priorities. You have a to-do list. And your team is paying the cognitive tax for your lack of clarity.

The Cascade: One System, Three Lenses​

These three lenses aren't independent. They're one system. Remove autonomy (ownership) → the team can't self-correct → decisions bottleneck through one person → trust erodes because people feel controlled → they stop speaking up → purpose gets cloudy because the real problems stay hidden (clarity) → more process gets added to compensate → which removes more autonomy.

Donella Meadows would recognise this immediately — it's a reinforcing feedback loop. The same kind of coordination failure that makes everyone busy but nothing ship faster.

The good news? Reinforcing loops work in both directions. Give the team ownership → they make better decisions → the bottleneck dissolves → trust builds because people feel empowered → they speak up earlier → purpose sharpens because real problems surface → less process needed → which frees up more autonomy.

It doesn't require fixing everything. Find one link in the chain and break it. The loop does the rest.

The Inversion Checklist​

This isn't exhaustive. It can't be — every team has its own failure modes. But if you understood the three lenses above, you could generate a hundred of these. Here are some to get you started.

The real list is the one you build yourself. Take the three questions — Am I creating dependency? Am I making honesty expensive? Am I adding noise? — and run them against every decision for a week. You'll find your own failure modes. They'll be more specific, more honest, and more useful than anything I could write here.

The One Thing​

I don't know how to be a great father. I might never figure it out. But my daughter won't remember whether I read the right book or followed the right framework. She'll remember whether I listened. Whether I showed up honestly. Whether I admitted when I got it wrong.

Your team is the same.

Nobody needs to be a great manager. Just not a bad one. And "not bad"? That's concrete. That's a lens to look through on a Tuesday afternoon when the week is going sideways.

Three questions. That's the whole playbook.

Am I enabling agency or creating dependency?

Am I making honesty cheaper or more expensive?

Am I adding noise or signal?

If the answer leans toward the wrong half — that's the inversion. No framework needed. No book needed. Just stop doing that one thing.

What's left — after you remove everything that's killing the system — might just look like leadership.

Remove what doesn't belong. What remains is the statue.

References: Charlie Munger's inversion mental model. Carl Jacobi's "man muss immer umkehren." Gary Klein, premortem technique. Donella Meadows, Thinking in Systems. Patrick Lencioni, The Five Dysfunctions of a Team. Amy Edmondson, psychological safety and Google's Project Aristotle. Matthew Skelton & Manuel Pais, Team Topologies. Andy Grove, High Output Management. John Sweller, Cognitive Load Theory. Learned helplessness (Seligman).

Look, you worked hard. You stayed late. You shipped that thing nobody else could ship. You earned every single promotion, every bit of recognition, every seat at the table. It was all you. 100%. No asterisks. No footnotes. Definitely no luck involved.

Right?

You Definitely Do More Than Everyone Else​

Here's a fun experiment. Get your team in a room and ask everyone to estimate their percentage contribution to the last project. Go on, I'll wait.

Done? Great. Add them up. If your team is anything like the ones in Ross & Sicoly's research, the total almost certainly exceeds 100%. Congratulations — your team apparently did more work than was physically possible. Someone call physics.

This is Egocentric Bias, and it's not because your team are liars. It's because you were there for 100% of your own late nights, your own difficult emails, your own "glue work" that held the project together. But you only saw about 20% of everyone else's. You remember your heroics in vivid detail. Theirs? Background noise.

The result? Every single person on the team walks away feeling slightly undervalued. And the person who got promoted? They're absolutely certain they deserved it. No luck required.

The Skill Saturation Problem​

Let's talk about astronauts. NASA typically receives 8,000–18,000 applications per intake and selects around 10–12. Everyone who applies is already in the 99th percentile of human capability — PhDs, fighter pilots, engineers who've built things most of us can't even spell.

So what separates the 12 who get in from the 17,988 who don't?

When everyone maxes out the skill variable, it effectively becomes a constant. It cancels out. What's left is the messy, uncomfortable stuff — timing, visibility, which project you happened to be on, who happened to be in the room when your name came up.

Robert Frank's research puts it bluntly: in high-competition fields, even a small luck component disproportionately determines who wins. A simulation by Veritasium modelled this — even when luck is a minor factor alongside skill, the winners were overwhelmingly the luckiest, not the most skilled. That tiny sliver of circumstance becomes the dominant differentiator when everyone's skill is maxed out.

But sure, it was definitely the extra certification that got you the role. Definitely not the fact that the role only existed because someone quit unexpectedly (Vacancy Chain Effect). Definitely not the fact that you happened to be on the project that got executive visibility that quarter (Visibility Bias).

The Cookie Monster Effect​

Here's where it gets properly uncomfortable. Research by Dacher Keltner and colleagues has consistently shown that even small, arbitrary increases in power change behaviour — people in high-power conditions take more resources, interrupt more, and show less empathy toward others. The effect kicks in fast.

Now scale that up. You've been a senior engineer, a lead, a principal for years. You've had a tailwind of good managers, growing markets, and teams that made you look good. But from the inside, it all feels like engine. Your engine. Your grit. Your 4am deploys.

This is Survivor Bias meeting the Tailwind Effect:

Branko Milanovic's data is the real gut punch: more than two-thirds of your lifetime income is determined by the country you were born in. Not your degree. Not your GitHub profile. The latitude and longitude of the hospital your mum happened to be in.

But yeah, it was definitely the side projects.

The Paradox (Here's Where It Gets Useful)​

So if luck matters this much, why bother? Why grind? Why stay up debugging that memory leak at 2am if the universe is just going to flip a coin anyway?

Because here's the paradox you have to hold in your head — two completely contradictory beliefs, simultaneously:

Before the work: Believe you are in 100% control. This isn't delusion — it's fuel. The only way to put in the 95% effort required to even enter the room where luck happens is to believe your effort is the whole story. No ticket, no lottery.

After the success: Acknowledge that luck played a massive role. Not to diminish what you did, but to stay human. To stay approachable. To avoid becoming the person who takes the extra cookie and doesn't even notice.

Yes, these beliefs contradict each other. That's the point. The skill is knowing which one to activate when.

The leaders who hold both beliefs — fierce effort and radical humility — are the ones people actually want to follow.

You Can Actually Attract Luck (No, Seriously)​

Here's where most people stop the conversation. "Luck matters, cool, guess I'll just wait for it." No. That's the wrong takeaway. Luck isn't purely random — there are ways to increase your surface area for it.

Naval Ravikant breaks luck into four types:

1. Blind luck — pure chance. You can't control this.
2. Luck from hustle — you're moving so fast, generating so much energy, that you collide with opportunities others miss.
3. Luck from preparation — you've developed the skill to spot opportunities that others walk right past.
4. Luck from your unique character — you've built such a specific reputation and skillset that luck finds you.

His metaphor is perfect: imagine there's treasure at the bottom of the ocean. Type 1 luck is the tide washing it ashore at your feet. Type 4?

You've become the best deep-sea diver in the world, you've built the equipment, you've studied the currents — and when someone finds a treasure map, you're the only person they call.

That fourth type is the one worth obsessing over. It's not random. It's the compound interest of being so distinctly good at something that opportunities start seeking you out. The "lucky breaks" that senior engineers get — the tap on the shoulder for the high-visibility project, the introduction to the right sponsor — those aren't random. They're Type 4. They went to the person who'd spent years building a reputation for shipping, for mentoring, for being the person who makes things work.

But First, You Have to Be in the Game​

And this is where the conversation gets uncomfortable in a different way.

Consider what "being smart" actually means for most humans on this planet. World Bank data shows that South Sudan has a GDP per capita of under $500 per year. Burundi, Central African Republic, Mozambique — similar numbers. Now imagine being born brilliant in South Sudan. Same raw intelligence as the engineer sitting next to you. Same problem-solving instinct. Same curiosity.

What does that intelligence get you? Not a CS degree. Not a laptop. Not a GitHub account. Not even reliable electricity. It gets you survival. Maybe, if you're extraordinarily lucky (Type 1), a path to a school that has textbooks.

Branko Milanovic's research — already cited above — lands the punch: more than two-thirds of your lifetime income is determined by where you were born. Not how smart you are. Not how hard you work. Where your mother happened to be standing when you arrived.

The smartest person in the world, statistically, probably lives in a country where their intelligence will never be rewarded the way yours has been. They'll never have the infrastructure to convert talent into outcome. No internet to learn on. No market to sell into. No visa to move toward opportunity.

So when you say "I got here on merit" — yes, your merit was necessary. But it was only sufficient because of where you happened to be born, what language you happened to speak, and which economy happened to be hiring when you graduated.

That's not a reason to feel guilty. It's a reason to feel responsible. Responsible for building systems — in your team, your org, your hiring pipeline — where someone's postcode doesn't determine their ceiling.

"But I Earned This"​

Yeah, you did. And so did the 17,988 astronaut candidates who didn't get picked. And so did the engineer on the other team who built the same thing you built but didn't have a sponsor in the room. And so did the person who grew up in a country where "making it in tech" means something entirely different.

You earned your spot and you got lucky. Both things are true. Holding only one of them makes you either defeated or delusional. Holding both makes you dangerous — in the good way.

So What Do You Actually Do With This?​

If you lead people — and if you're reading this on an engineering docs site, you probably do or will — here's the move:

That last one — "increase the luck of others" — is the whole game. It's the same principle behind InnerSource (lowering barriers so talent finds opportunity) and behind fixing the payoff matrix (making cooperation the rational choice). The mechanism is different. The goal is the same: build systems where the best people don't need to be lucky to succeed.

Your goal as a leader isn't to be the smartest person in the room. It's to increase the luck of everyone else in it.

This post draws from Veritasium's analysis, Robert Frank's "Success and Luck," Naval Ravikant's framework on luck, and Branko Milanovic's research on global inequality.

You send a Slack message to another team. It's a reasonable request — a small API change, maybe a code review, maybe just a question about how their service handles edge cases. You write it clearly. You tag the right person. You even add a polite emoji. And then... nothing. No reply. No acknowledgment. Just the quiet hum of a message marked as read and promptly ignored.

You're not being ghosted because they're bad people. You're being ghosted because the game they're playing rewards ignoring you.

This isn't a people problem. It's a math problem.

The Game You're Actually Playing​

Every cross-team interaction in a large engineering org is a move in a game. Not a metaphorical game — an actual, mathematically modelled one. Game theorists call it the Prisoner's Dilemma, and it's been explaining why rational people make collectively terrible decisions since 1950.

Here's how it works in your org. Two teams face a choice: cooperate (help the other team) or defect (ignore the request and focus on your own sprint).

Look at this from Team A's perspective. If Team B cooperates, Team A is better off defecting — they get the benefit of Team B's help without spending any time themselves. If Team B defects, Team A is still better off defecting — why waste time helping someone who won't help you back?

Defection is the dominant strategy. No matter what the other team does, ignoring them is the rational move.

And here's the gut punch: Team B is running the exact same calculation. So both teams defect. Both teams move slower. Both teams accumulate tech debt. And everyone wonders why "collaboration" is just a word on a slide deck.

Why Smart People Choose to Lose​

The math alone would be bad enough. But your brain makes it worse. Three cognitive biases turn a bad incentive structure into an unbreakable one:

Zero-sum thinking. "If their team gets credit for this feature, that's credit my team doesn't get." Promotions feel scarce. Executive attention feels finite. So helping another team feels like handing them your bonus. It's not true — collaboration creates value that didn't exist before — but the lizard brain doesn't do nuance.

Loss aversion. Losing four hours to a cross-team code review hurts twice as much as the abstract "gain" of organisational health. The loss is concrete and immediate. The gain is diffuse and delayed. Your brain treats them very differently, and the loss wins every time.

Hyperbolic discounting. Closing a Jira ticket today feels more valuable than contributing to a shared library that saves everyone time next quarter. The sprint is real. The future is theoretical. So you optimise for the sprint, and the future never arrives.

These aren't character flaws. They're features of human cognition that evolved for survival in small groups. They just happen to be catastrophically mismatched with how modern engineering orgs work.

The Shadow of the Future (Or Lack Thereof)​

Here's the thing that makes cooperation possible in small teams: you know you'll need that person tomorrow. Game theorists call this the shadow of the future — the knowledge that today's actions have consequences in future interactions. In a five-person startup, the shadow is long. You help me today, I help you tomorrow. Defection is risky because reputation is immediate and inescapable.

But at 4,000 engineers? The shadow shrinks to nothing.

Cooperation through direct reciprocity only works when the chance of meeting again outweighs the cost-to-benefit ratio of helping. At 4,000 engineers spread across dozens of teams, that probability approaches zero for cross-team interactions. And when reputation doesn't travel across silos — when nobody knows or remembers that you helped another team last quarter — there's no indirect reciprocity either.

The result? Defection isn't just rational. It's the only stable equilibrium.

The game is broken. Not the people.

Change the Game, Not the Players​

So here's the thing. You can keep sending motivational Slack posts about "one team, one dream." You can run another workshop on collaboration. You can put "teamwork" in the company values and print it on a mug.

Or you can change the math.

The Prisoner's Dilemma only traps you when the payoff matrix rewards defection. Change the payoffs, and cooperation becomes the dominant strategy instead. This isn't idealism — it's mechanism design. You're not asking people to be better. You're making "better" the rational choice.

Three moves. That's all it takes to flip the matrix.

Three Moves That Flip the Matrix​

Move 1: Make Reputation Travel​

The shadow of the future is short because reputation doesn't cross team boundaries. Fix that.

Implement collaborative credit — a visible, tracked record of cross-team contributions. Code reviews for other teams, shared library maintenance, helping unblock a dependency. Make it show up in quarterly reviews. Make it part of how you evaluate engineering managers, not just their team's sprint velocity.

When helping another team visibly counts, the payoff for cooperation goes up and the temptation to defect goes down. Suddenly, "I helped three other teams ship this quarter" is a career-building statement, not a confession of distraction.

Move 2: Shared OKRs That Make Cooperation Pay​

If 100% of your team's key results are local, you've mathematically guaranteed that helping another team is a cost with no reward. The payoff matrix is rigged.

Make at least 30% of every team's OKRs dependent on another team's success or on a global outcome. When Team A's performance is partially tied to Team B shipping on time, the calculus flips. Mutual cooperation becomes more valuable than the temptation to defect, because defection now hurts your own score.

This isn't about forcing collaboration. It's about making the incentive structure honest about what the organisation actually needs.

Move 3: Reduce the Cost of Cooperation​

Even when people want to cooperate, the transaction cost can be prohibitive. Finding the right person, explaining context, negotiating backlog priority, following up — it's exhausting. When cooperation is expensive, defection wins by default.

The fix: make cooperation cheap.

• InnerSource — Let any team submit a PR to any codebase. The requester provides the solution instead of waiting in someone else's backlog. (We wrote about this — satirically, but the point stands.)
• Internal developer portals — Self-service API discovery, documentation, and cloud resources. Kill the search cost.
• Platform teams — Shared infrastructure that nobody has to negotiate for. (The Price of Anarchy post covers why this matters at scale.)

When the cost of cooperation drops, the threshold for reciprocity becomes achievable again — even at 4,000 engineers.

"Sounds Great in Theory"​

If you're reading the three moves above and thinking "this is idealistic" — you're not wrong. Nobody flips a payoff matrix overnight. You probably can't rewrite your org's OKR framework by Friday.

But here's the thing: you don't need to change the whole system. You just need to make cooperation slightly more rewarding than defection in your immediate sphere. Small changes compound.

None of these require a reorg. None of them need executive sponsorship. They just need one person to start, and for that person's team to notice it works.

You don't have to fix the game. You just have to make the first cooperative move.

The One Takeaway​

You've sat through the game theory. You've seen the payoff matrix. You've read about cognitive biases and the shadow of the future. Here's the one thing I want you to remember:

You don't have a collaboration problem. You have a payoff problem. Fix the game.

Stop blaming engineers for being "siloed." They're not siloed — they're rational. They're responding to a system that punishes cooperation and rewards local optimization. If you want different behaviour, build a different game.

Make reputation travel. Tie outcomes together. Make cooperation cheap. Do those three things, and you won't need to convince anyone to collaborate. The math will do it for you.

This is the second in a series on game theory and engineering at scale. Read the Price of Anarchy post for the system-level view, and Why You Should Never Do InnerSource for one concrete mechanism that makes cooperation cheap. The research behind this post draws on Robert Axelrod's work on the evolution of cooperation and the Prisoner's Dilemma literature.

You've seen it. Every team is shipping. Every sprint has velocity. Dashboards are green. And yet somehow, the organisation feels slower than it should. Everyone's busy, but nothing moves faster.

Here's a clue from an unexpected place.

Picture a motorway at rush hour. Every driver is making the smartest choice for themselves — fastest lane, shortest route, optimal speed. Nobody's doing anything wrong. And yet the whole system grinds to a halt. More cars, more rational decisions, more gridlock.

This isn't a failure of individual intelligence. It's a failure of coordination. Game theorists have a name for it — the Price of Anarchy — and it might be the most useful mental model for understanding what management actually is, when it matters, and when it doesn't.

The Price of Anarchy, Explained Simply​

The Price of Anarchy (PoA) measures how much worse a system performs when everyone acts in their own self-interest compared to when someone coordinates the whole thing.

If PoA = 1, selfish behavior already produces the optimal outcome—coordination adds no benefit.

If PoA = 2, the system performs twice worse under selfish behavior than under optimal coordination.

Each driver picks the fastest route for themselves. But collectively, everyone floods the same roads and creates congestion. A coordinated system — traffic lights, lane management, congestion charges — produces better flow for everyone.

Now replace "drivers" with "engineers" and "roads" with "priorities."

Where Does It Break? The PoA Spectrum​

Not every organisation needs the same level of coordination. The Price of Anarchy scales with complexity:

The question isn't whether coordination is needed. It's how much.

When PoA ≈ 1: The Self-Organising Dream​

Five engineers in a startup. Everyone knows what everyone else is doing. Architecture decisions converge through hallway conversations. Priorities are obvious because there's one product, one customer, one goal.

Here, PoA is close to 1. Self-organisation works. A manager in this context is overhead — someone scheduling meetings about things people already know.

"Resilience arises from a rich structure of many feedback loops that can work in different ways to restore a system even after a large perturbation." — Donella Meadows, Thinking in Systems

Small teams are rich feedback loops. Information flows freely. The system self-heals. This is the dream that flat-org advocates sell — and for small, tightly-coupled teams, it's real.

When PoA Grows: The 1,000-Person Reality​

Now scale that to 1,000 engineers across dozens of teams, multiple brands, different time zones, and competing roadmaps.

Here's what happens without coordination: the payments team rewrites the checkout service for speed while the mobile team is building a feature that depends on the old API. A platform team builds a shared logging library that nobody discovers because it lives in a repo no one knows about. Three teams independently build authentication modules — each one perfectly designed for its use case, none of them compatible.

Each decision is rational in isolation. But collectively? Everyone's busy, everyone's productive by their own metrics, and the organisation moves slower than the sum of its parts.

"If the architecture of the system and the architecture of the organisation are at odds, the architecture of the organisation wins." — Matthew Skelton & Manuel Pais, Team Topologies

This is where the Price of Anarchy climbs. Not because people are selfish or incompetent — but because local optimisation and global optimisation are fundamentally different problems.

What Managers Actually Do (When They're Doing It Right)​

What if managers exist primarily to reduce the Price of Anarchy?

Not to control. Not to approve. Not to sit in meetings about meetings. To coordinate a system that can't coordinate itself at scale.

Alignment — Defining shared goals so that local decisions naturally converge toward global outcomes. When Team A and Team B both understand the same north star, their independent choices are more likely to be compatible.

Coordination — Resolving cross-team conflicts, sequencing dependencies, and making trade-offs that no single team has the context to make. This is the traffic light function — not telling people where to go, but preventing collisions.

Global optimisation — Prioritising what matters for the whole system, not just one part of it. Sometimes the right call for the organisation is the wrong call for an individual team. Someone has to make that visible.

But good managers also do things that aren't coordination — they develop people, create psychological safety, and have hard conversations. That's not PoA reduction. That's capacity building — making the individual nodes in the system better, not just better connected.

The best managers do both.

Agile as a Coordination Protocol​

Agile doesn't eliminate the need for coordination. It encodes it into lightweight protocols:

• Shared backlog → alignment on priorities
• Sprint planning → coordination of effort
• Retrospectives → feedback loops for system correction
• Product ownership → a single point of global optimisation for a domain

Within a single team, Agile ceremonies can keep PoA close to 1. Across ten teams? Twenty? You need something more. This is why organisations layer coordination mechanisms: architecture guilds, platform teams, tech radar, RFCs, shared standards. Each one is a protocol designed to reduce PoA without adding hierarchy.

Coordination as Code​

Some of the most effective PoA reducers aren't people at all — they're systems:

The further down this stack you push coordination, the less you need humans in the loop for routine alignment. API contracts prevent incompatible interfaces. Design systems prevent reinvented UI patterns. Platform teams prevent everyone solving infrastructure differently.

These reduce the Price of Anarchy the same way traffic lights do — not by telling people what to do, but by making the right thing the easy thing.

The more you encode into tooling and platforms, the more you free managers to focus on the hard problems — the ones that require judgment, context, and relationships.

The Real Question​

The real question is: how much coordination is needed to keep the Price of Anarchy acceptable?

Different systems need different PoA controls. A five-person startup doesn't need the same coordination overhead as a 1,000-person engineering org. But a 1,000-person org pretending it can self-organise like a startup? That's traffic without traffic lights.

The Takeaway​

The goal is building systems that coordinate themselves, so that management can focus on the things only humans can do: building trust, developing people, and making the hard calls when the protocols aren't enough.

"Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare." — Patrick Lencioni, The Five Dysfunctions of a Team

Next time you're stuck in traffic, remember: the problem isn't the drivers. It's the system. And that's exactly what management is for.

The Price of Anarchy was formalised by Elias Koutsoupias and Christos Papadimitriou in 1999. Go deeper: Thinking in Systems by Donella Meadows, Team Topologies by Skelton & Pais, and The Five Dysfunctions of a Team by Patrick Lencioni.

Annoying, isn't it? You clicked on this article expecting something — a point, a question, an insight — and instead you got... nothing. Just a greeting and dead air.

"Good Morning!" ...At 9pm​

This one's a personal favourite.

them: Good morning! 🌅

You look at your clock. It's 9pm. You've already had dinner. You're watching something. Your phone buzzes with a work notification that says good morning while you're in your pyjamas.

They didn't check your timezone. They didn't check your Slack status. They didn't check anything. They just broadcast a greeting into the void and waited for the void to respond.

And the greeting is wrong. It's not morning. It's not even close to morning. The message is empty AND inaccurate. A two-for-one special of not thinking it through.

The Typing Indicator of Doom​

You know the one. You're deep in a problem. Flow state. The code is finally making sense. Then:

them: Hi

You glance at it. The typing indicator appears. Three little dots, bouncing. You wait. It stops. Starts again. Stops. Starts. You're now fully distracted, watching a tiny animation like it's a thriller movie.

Then finally:

them: How's it going?

That's it? You broke my concentration for a vibe check? The actual question — if there even is one — is still three messages away. Your flow state is gone. That bug you were about to crack? It'll take you 23 minutes to get back into it. Not my number — that's from UC Irvine research.

The Irony We Don't Talk About​

We've all shared the meme. We've all nodded along. "This meeting could've been an email." It's practically a personality trait at this point.

But here's the thing nobody says out loud: we then send messages that aren't even complete.

We complain about 30-minute meetings that waste our time, and then we send a "Hi" that wastes someone's time in a slower, more agonising way — because now they're stuck in limbo, unable to help, unable to ignore, just... waiting for you to finish your thought.

At least the unnecessary meeting had an agenda. Your "Hi" has nothing.

Someone Already Nailed This​

I'm not the first person to be annoyed by this. There's an entire website dedicated to it. Take a minute — seriously, scroll through it:

Do You Feel It Now?​

If you've been nodding along this whole time — welcome. You're not crazy. You're not "difficult." You're not "bad at small talk." Your frustration is valid, and it costs real time, real focus, and real productivity. Every single day.

And if you're reading this thinking "wait... I do this" — remember the top of this article? That empty space? That wait? That feeling of "get to the point already"?

That's what you're doing to people. Every. Single. Time.

You're not a bad person. You're probably trying to be polite. But in async communication, a bare "Hi" isn't polite — it's a hostage situation. You're holding someone's attention captive until you decide to finish your thought.

"But What Do I Do When Someone Just Says Hi?"​

This is the real question, isn't it? You know it's a problem. You've wanted to say something. But you don't want to be that person — the one who sends a passive-aggressive link to a website about chat etiquette.

Here's your toolkit. Tested in the wild. Zero friendships harmed.

The Genuine One — simple, warm, and means it:

"Hello, how can I be of help?"

Sounds friendly. Is friendly. Because it genuinely is — you're signalling that you're available, you're willing to help, and you're ready for meaningful work together. But it also subtly says "I'm not going to guess what you want — the ball is in your court." Works every time.

The Friendly Nudge — reply with warmth, plant the seed:

"Hey! What's up? (Pro tip for next time — feel free to drop your question straight away, I might be in a meeting but can get back to you faster that way 😊)"

The Busy Redirect — honest and practical:

"Hi! I'm in and out of meetings today — drop your question and I'll get to it as soon as I can!"

The Status Move — let your status do the talking:

💬 "Skip the hello — just ask! I'll reply faster."

🎧 "In focus mode — drop your question, I'll get back to you."

The Nuclear Option — send them this article:

"Hey, have you seen this? [link to this post] — it changed how I message people at work. Thought you might find it useful!"

That's literally why this post exists. You're welcome.

And look — you're not being rude by doing any of this. You're being respectful of everyone's time. Including theirs. Because the faster they ask, the faster they get an answer. Everyone wins.

The One Thing​

Next time you open a chat window, just say what you need. All of it. In one message. Greeting included if you want — nobody's banning politeness. Just don't make it the entire message.

"Hi"

✅ "Hey! Quick one — is the deployment pipeline stuck or is it just me? I'm seeing this error: timeout on stage 3. Here's the build link: [link]"

Your future self — and everyone else's — will thank you.

If this resonated, share it. If it called you out, you're welcome. Either way, go update your Slack status.

References

• Gloria Mark, Daniela Gudith, Ulrich Klocke. "The Cost of Interrupted Work: More Speed and Stress" — CHI 2008, ACM Conference on Human Factors in Computing Systems.

"Between what is said and not meant, and what is meant and not said, most of love is lost." — Khalil Gibran

It never starts big.

It starts with a Tuesday evening. You come home tired. Your partner asks, "How was your day?" You say, "Fine." What you meant was: "Exhausting. I felt invisible in that meeting. I could use a hug." But "fine" was easier. Quicker. Safer.

Or it starts in a standup. Your lead asks, "Any blockers?" You say, "Nope, all good." What you meant was: "I've been stuck on this for two days and I don't want to look incompetent." But "all good" was safer. Faster. Less exposed.

One "fine" costs nothing. One "all good" costs nothing. But 365 of them? That's a year of someone living next to you and not knowing you. Or a year of your team thinking everything's on track when it isn't.

This is the daily drift — the tiny, almost invisible gap between what we say and what we mean, repeated so often it becomes the distance between two people who once understood each other without words.

A caveat before we go further: not every "fine" is a suppression. Sometimes it genuinely means fine. Sometimes it means "I don't have the energy to unpack this right now" — and that's a healthy boundary, not a failure. The drift happens when brevity becomes the default, when filtering stops being a choice and starts being the only mode.

"What we don't say is as important as what we do say. In fact, it may be more important." — Virginia Satir, The New Peoplemaking

How the Drift Works​

Think of it like compound interest — but in reverse.

A single miscommunication is a rounding error. But communication debt compounds daily.

• Day 1: "I'm fine." (Small gap. Barely noticeable.)
• Day 30: "We don't really talk anymore." (The gap has a shape now.)
• Day 180: "I don't think you understand me." (The gap has walls.)
• Day 365: "I don't know when we stopped connecting." (The gap is the relationship.)

No one wakes up one morning in a broken relationship or a dysfunctional team. They drift there — one unspoken truth at a time.

The Five Daily Drifts​

These are the small, everyday patterns that create distance. You'll recognize them.

Drift 1: The Shorthand Assumption​

"They should know what I mean by now."

The longer we know someone, the less we explain. We assume shared history equals shared understanding. It doesn't. People change. Context changes. What "I need space" meant two years ago isn't what it means today.

"The single biggest problem in communication is the illusion that it has taken place." — George Bernard Shaw

Drift 2: The Protective Edit​

Typing the real message... then deleting it and sending the safe one.

We self-censor dozens of times a day. Not lies — just edits. Softening, minimizing, rounding the sharp edges off our truth. Each edit is small. But over time, the people closest to us are interacting with a curated version of us — and wondering why the connection feels thin.

Drift 3: The Unasked Question​

Sensing something is off... and choosing not to ask.

We notice. The short reply. The change in energy. The smile that doesn't reach the eyes. But asking means opening a door we might not be ready to walk through. So we let it pass. And the other person registers: they didn't ask. Maybe they don't care.

The cruelest part? Both people are protecting themselves. And both people feel alone.

Drift 4: The Performative Response​

"That's great!" (It's not.) "I'm happy for you!" (I'm conflicted.) "No, I totally understand." (I don't.)

Social scripts keep things smooth. But they also keep things shallow. When every response is performed rather than felt, conversations become transactions — and people start feeling lonely in the presence of others.

"Loneliness does not come from having no people around you, but from being unable to communicate the things that seem important to you." — Carl Jung

Drift 5: The Delayed Truth​

"I'll bring it up later." (You won't.)

The right moment rarely comes. But delay isn't always avoidance — sometimes timing genuinely matters, and raising a hard truth when someone is mid-crisis or exhausted isn't courage, it's poor judgment. The drift happens when "later" always means never. When the truth stays unspoken not because the timing is wrong, but because saying it feels too risky.

"Unexpressed emotions will never die. They are buried alive and will come forth later in uglier ways." — Sigmund Freud

The Flash Fight: When Miscommunication Explodes​

The daily drift is slow. But there's another kind — the flash fight. A single sentence, misread in real-time, that detonates a conversation in under 60 seconds.

These aren't about years of accumulated silence. These are about two people hearing completely different things from the same words — and reacting to what they heard, not what was said.

How a Flash Fight Works​

1. The Trigger — Someone says something with one meaning.
2. The Misread — The other person hears it through their own filter — stress, insecurity, past wounds, assumptions.
3. The Reaction — They respond to what they heard, not what was said.
4. The Escalation — The first person, confused by the reaction, gets defensive. Now both are fighting ghosts.

"We don't see things as they are, we see them as we are." — Anaïs Nin

The Flash Fight Across Relationships​

Between Partners:

Said: "Did you already eat?" Meant: "I was hoping we'd eat together." Heard: "You should have waited for me." (criticism) Fight: "Why do you always make me feel guilty about everything?"

A simple question filtered through a history of feeling judged. The fight isn't about dinner. It never was.

Between Friends:

Said: "Oh, you're hanging out with them again?" Meant: "I miss spending time with you." Heard: "I'm judging your other friendships." (possessiveness) Fight: "You don't own my time."

The real need — I miss you — got encoded as observation, decoded as accusation.

Between Parent and Child:

Said: "That's what you're wearing?" Meant: "I want you to make a good impression because I care." Heard: "You look bad. I don't approve of you." (rejection) Fight: "You never accept me for who I am."

A lifetime of these and the child stops sharing anything at all.

Why Flash Fights Happen​

They're not about the words. They're about the filter the words pass through. Stress compresses patience — neutral sentences land as attacks. History rewrites the present — if you've been criticized before, you hear criticism even when it's not there. And in text messages especially, there's no tone, no face, no context — the reader's mood becomes the tone.

The medium matters more than we think. For anything with emotional weight, the richer the channel, the less room for misread:

We all know the meeting that should've been an email. But the reverse is more dangerous: the text that should've been a conversation. "Could have been a mail" wastes time. "Should have been face-to-face" wastes trust.

Worth noting: this pattern shows up most in anxious or insecure attachment dynamics. Two securely attached people hearing "Did you already eat?" probably won't spiral. The flash fight isn't universal — but if you've been in one, you know exactly what it feels like.

"Every criticism, judgment, diagnosis, and expression of anger is the tragic expression of an unmet need." — Marshall Rosenberg, Nonviolent Communication

Defusing the Flash Fight​

Say what you heard, not what you concluded. "When you said that, what I heard was [X] — is that what you meant?" This one sentence has prevented more fights than any apology ever has.

Name your filter. "I think I'm hearing this through my stress right now. Can you say that again?" This is disarming — it tells the other person your reaction might not match their intention.

Get off text for anything with emotional weight. Text strips tone, face, and context. What's left is raw words filtered through whatever mood the reader is in.

Repair fast. If a flash fight does happen — and it will — the speed of repair matters more than the perfection of the apology. "I think we just had two different conversations. Can we rewind?"

The Drift at Work​

The same patterns play out in business — just in conference rooms instead of kitchens. And the stakes are different: at home, the drift costs intimacy. At work, it costs decisions, trust, and eventually people.

If this looks familiar, it should. The Prisoner's Dilemma at work is partly a communication problem — teams defect because saying "I need help" or "I disagree" feels riskier than staying silent. And when everybody is junior in something but nobody says it, the team follows the wrong map in silence.

A note on power dynamics: the advice to "say what you really mean" is unevenly distributed. A senior leader saying "I disagree" is candor. A junior employee saying the same thing can be career risk. The drift at work isn't just about individual courage — it's about whether the environment makes honesty safe. If your team's drift is growing, the first question isn't "why won't people speak up?" It's "what happens when they do?"

Said vs. Meant — The Translation Table​

A cheat sheet for the subtext you already know but pretend you don't.

The Practical Playbook: Closing the Gap​

Not theory — tools you can use today.

1. The "What I'm Really Saying Is..." Reset​

Mid-conversation, when you catch yourself circling or softening, use this phrase as a hard reset:

"Actually — what I'm really trying to say is..."

• With a partner: "What I'm really saying is I felt hurt when you didn't ask about my interview."
• With a boss: "What I'm really saying is I don't think this timeline is realistic."
• With a friend: "What I'm really saying is I've missed you and I don't know how to say it without sounding dramatic."

Why it works: It gives you permission to be direct without it feeling like a confrontation. The phrase itself signals honesty, and people lean in when they hear it.

2. Name the Dynamic, Not the Person​

When something feels off, resist the urge to say "you're being distant" or "you never listen." Instead, name what's happening between you:

• "I notice we're both being really careful right now."
• "It feels like there's something in the room we're not saying."
• "I think we're having two different conversations — can we reset?"

Why it works: It makes the pattern the problem, not the person. People can look at a dynamic together. They can't look at an accusation together.

3. The Curiosity Over Conclusion Rule​

When someone says something that lands wrong, choose curiosity before conclusion.

Instead of: "That was dismissive." Try: "When you said that, here's what I heard — is that what you meant?"

Instead of: "You obviously don't care." Try: "I want to understand what you meant by that, because the story I'm telling myself is..."

That last phrase — "the story I'm telling myself" — is disarming because it owns the interpretation rather than projecting it.

Why it works: Most conflict isn't about what was said. It's about what was heard. This practice closes the gap between the two.

4. The Evening Check-In (2 Minutes, Not 2 Hours)​

For personal relationships. One question, asked daily:

"Is there anything unsaid between us right now?"

Most days the answer is "no." But the days it's "actually, yes..." — those are the days you prevent a drift from becoming a distance. This won't work for everyone — some people find structured check-ins performative, and that's fine. The point isn't the format. It's creating any regular space where honesty is the default.

Why it works: The gap can't compound if you zero it out every 24 hours.

5. The Repair Bid​

Gottman's research — based on decades of studying thousands of couples — found that successful relationships aren't conflict-free. They're repair-rich. The ratio that predicts relationship stability isn't zero conflict. It's 5 positive interactions for every 1 negative one, and the speed at which couples repair after rupture.

A "repair bid" is any attempt to reconnect after a gap:

• "I think I said that badly. Can I try again?"
• "I've been thinking about what you said, and I think I missed your point."
• "I was short with you earlier. That wasn't about you."

Why it works: You can't prevent every drift. But you can repair before it compounds. The bid itself — the willingness to come back and try again — is the message.

"It's not about never having conflict. It's about the speed of the repair." — John Gottman, The Seven Principles for Making Marriage Work

The Knowing-Doing Gap​

I know all of this. I've read the research, written the playbook, and I still catch myself saying "I'm fine" when I'm not. Knowing the drift exists doesn't stop it. Awareness isn't practice.

The hard part isn't knowing what to say. It's that the moments where it matters most — mid-argument, mid-standup, mid-stress — are exactly when you're least equipped to do it. Asking someone to be radically honest in real time is like asking them to do mental math while skydiving.

So if there's one thing — just one — that actually closes the gap, it's not an in-the-moment hack. It's a reflection:

Not to beat yourself up. Just to notice. And if the answer matters — send that message, make that call, say that thing. Not in the heat of the moment, but from a place where you can actually choose your words.

It's the evening check-in from the playbook, but turned inward. You're not asking someone else "is there anything unsaid between us?" — you're asking yourself. And if you do this enough, you start catching the filter earlier. Not perfectly. Not every time. But more than yesterday.

A Final Thought​

"Between stimulus and response there is a space. In that space is our freedom to choose." — Viktor Frankl, Man's Search for Meaning

The distance between two people is rarely created by a single moment. It's built in the small, daily choices — to say the safe thing or the true thing, to ask or to let it pass, to repair or to let it harden.

The drift compounds. But so does connection. One honest sentence a day, one real question, one moment of "here's what I actually mean" — and the math reverses.

You don't have to say everything. You just have to say more than you did yesterday.

The gap between what is said and what is meant is where love goes quiet. But it's also where it can come back — one true word at a time.

Why Would You Want to Reuse Code?​

There's something deeply noble about writing the same authentication module for the fourteenth time. Each team gets to make their own mistakes, discover their own edge cases, and spend three sprints building what already exists two repositories over. That's not waste — that's character building.

InnerSource would let teams discover, fork, and contribute to shared codebases across the organisation. You'd end up with fewer duplicated services, consistent patterns, and engineers who actually know what other teams are building. Sounds exhausting, honestly.

Who Needs Faster Onboarding?​

New engineers joining a team should earn their stripes the old-fashioned way — six weeks of deciphering tribal knowledge, guessing which Slack channel has the real answer (or was it Teams? Wait, are we back on Slack now?), and reverse-engineering a service that hasn't been touched since someone named "Dave" left in 2022.

With InnerSource, codebases are open and discoverable. There's documentation. There are contribution guidelines. New joiners can read actual code from across the org on day one and start contributing within their first week. But where's the mystery in that? Where's the hazing?

Silos Are Cozy, Actually​

A team has its own repo, its own conventions, its own deployment pipeline that only two people understand, and its own Confluence space that hasn't been updated since the last reorg. That's not dysfunction — that's autonomy.

InnerSource breaks down these beautiful walls. Suddenly, a frontend engineer from another team can submit a pull request to fix a bug in your API. A platform engineer can improve your CI pipeline without filing a ticket and waiting three sprints. People start talking to each other. Across team boundaries. Voluntarily. Horrifying.

Documentation? Wildly Overrated​

If your code needs documentation, maybe the code just isn't good enough. Real engineers read the source. They grep through commit messages from 2019. They ping someone on Slack who might know someone who once worked on that service. That's not inefficiency — that's networking.

InnerSource projects tend to have READMEs that actually explain things, contribution guides that lower the barrier to entry, and transparent decision-making in public channels. A codebase becomes a living, searchable knowledge base. But then anyone could understand it, and where's the fun in that?

The "Trusted Committer" Sounds Like Extra Work​

InnerSource introduces this concept of a Trusted Committer — someone who mentors contributors, reviews cross-team PRs, and ensures quality standards are met. Basically, you're asking senior engineers to help other people get better at their jobs. On purpose.

These Trusted Committers end up building relationships across the org, developing deep expertise in their domain, and becoming the kind of engineers everyone wants to work with. They get recognised for impact beyond their immediate team. Sounds like a lot of responsibility for no reason when you could just... close the PR from that other team and move on.

Innovation Is Risky Anyway​

Here's the thing about letting anyone in the organisation contribute to any codebase — people start having ideas. A QA engineer notices a pattern and submits a testing utility. An SRE improves observability across services. Someone from a completely different department fixes a bug that's been open for months because they actually hit it in production.

This kind of meritocratic, bottom-up innovation is dangerous. It implies that good ideas can come from anywhere, not just the team that owns the repo. It suggests that the best solution might already exist in someone else's branch. It means you'd have to admit that collaboration scales better than control. And who wants to admit that?

Even the Competition Is Doing It (More Reason to Avoid It, Obviously)​

Oh, and here's the kicker — Flutter's already doing it. Yes, that Flutter. They've not only adopted InnerSource, they've built an entire maturity model around it. They call it the InnerSource Pyramid — a structured progression from closed source all the way to maintainers across multiple teams:

Stage 0 is where you keep your code locked in a vault. Stage 1, you let people read it (radical, I know). Stage 2, you actually accept contributions from other teams. Stage 3, you have maintainers embedded across the org working as a virtual team. It's almost like they've thought about this systematically. How annoying.

They've invested in this because — and I quote — "our brands working together gives us a winning edge over our competitors." That's us. We're the competitors they're winning against. But sure, let's not look into it.

So Yeah, Don't Do InnerSource​

Keep the repos locked down. Keep the teams in their lanes. Keep rebuilding the same thing every quarter and wondering why velocity plateaus. It's working great.

Or — and I'm just throwing this out there — maybe take a look at what companies like PayPal, Bloomberg, and Europace figured out years ago. Maybe check out what Flutter is already doing right next door. Maybe read through the InnerSource Commons patterns. Maybe open up one repo, write a CONTRIBUTING.md, and see what happens when you trust your engineers to collaborate like the adults they are.

But what do I know. I'm just an Architect of Chaos.

If you're curious about InnerSource (and you should be), start here: InnerSource Commons Learning Path. It's free, it's practical, and it might just change how we build software.