Team Topologies promised us faster flow, stronger ownership, and autonomous delivery. Many companies have embraced it: small, cross-functional teams led by a PM and an EM, each owning a slice of the domain. It sounds clean and modern. But in a distributed architecture, this structure breaks down fast, and the paradox underneath becomes hard to ignore.

Where the Model Breaks

A service-oriented architecture promises modularity. Systems are broken down into smaller, independently deployable services, each owned by a team. The benefits are well-understood: teams can move faster, scale more predictably, and make decisions locally. From a platform and infra perspective, it makes sense. From an engineering perspective, it lets teams limit their cognitive load. But here’s where the first crack shows. A feature, especially a user-facing one, doesn’t care about team boundaries.

Most features a PM is tasked with delivering will span multiple domains and touch multiple systems. That’s the nature of any non-trivial product in this architecture. A simple tax-filing flow? That’s not just a UI. It’s customer data, service eligibility, authentication, document storage, invoicing, reconciliation, tax logic, submission APIs, and the list goes on. And each of those pieces? Owned by a different team.

But PMs don’t own systems. PMs own problems and outcomes. The moment we expect a PM embedded in a single team to “own” the delivery of a feature that relies on many systems outside that team’s scope, we’re setting up a contradiction. We tell the PM they have autonomy. We tell the team they are autonomous. But to deliver the thing, they are not autonomous. They depend on systems, and therefore on teams, outside their control.

The org might try to resolve this by encouraging “strong ownership” or “full accountability” within the team. But that creates another tension. For a team to own something end to end, it would have to take responsibility for systems it does not own, understand codebases it doesn’t touch daily, and coordinate work with people who don’t report into their EM or PM structure. That isn’t autonomy, that’s orchestration. We’re just not acknowledging it for what it is.

So we end up in this in-between state. The PM is measured on outcomes that require multi-team execution. The team is staffed and planned as if it can deliver independently. But reality doesn’t comply. The work needs cross-team coordination, dependency management, and shared priorities. And the way we’ve structured teams and leadership models assumes the opposite.

This is the autonomy paradox.

We want teams to own their domain, but we also want them to deliver outcomes that span many domains. We want PMs to drive features, but we anchor them in teams that only own fragments of the necessary scope. We say we value speed and flow, but the moment a feature crosses a team boundary, and most do, we hit coordination overhead, roadmaps misaligned by quarters, and duplicated discovery efforts. We push for “ownership,” but the things we’re asking people to own don’t match the boundaries we’ve drawn.

Local Optimization and the Legacy Trap

Engineering teams try to collaborate, but they don’t have time, because they also have a full roadmap. The team is still expected to deliver in the original timeframe. So they optimize for what they were assembled around: autonomy. They build their own solution, promise to migrate later, and ship it. Now there are duplicated systems to maintain. Migrations that need to be planned and prioritized never get prioritized. The new system becomes legacy from day one.

Conway’s Law in Action

It’s a textbook example of Conway’s Law in action: teams are structured to be autonomous, so they build autonomous systems, even when those systems duplicate logic or drift from shared architectural principles. The shape of the org leaks into the shape of the software.

Conway’s Law: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway, 1968

It’s a structural tension between the way we define ownership and how systems are architected, not just a planning issue. The more we insist on holding both ends of the rope, “teams should be autonomous” and “PMs should deliver outcomes end to end,” the more strained it becomes.

At some point, we have to acknowledge this for what it is. A paradox born not out of bad intentions or poor planning, but out of the friction between product thinking and distributed systems design. Until then, we keep seeing teams caught in the gap: accountable for things they don’t control, delivering features that always seem harder than they should be, and wondering why autonomy feels so elusive.

Systems as Products, EMs as Owners

If we expect EMs to own the technical strategy for the systems they’re responsible for, and we should, then we also have to treat those systems as more than back-end infrastructure. They are products. Internal products, sure, but products nonetheless. Systems that map to specific business domains, evolve over time, and offer value to other teams through clear APIs. When these systems are built and maintained thoughtfully, they reduce what other teams need to build and own to deliver their own outcomes. They make everything faster and cheaper. They shrink the cost of change.

So if we’re already asking EMs to think this way, what’s the role of the PM? Do we need to pair every team with one? Can’t we expect EMs to weigh bugs, tech debt, and system improvements against the new features required for upcoming initiatives? And if so, why do we still treat PMs as the ones responsible for prioritizing every team’s backlog?

In many setups, PMs spend more time project-managing engineers than solving customer problems. Their calendar is filled with sprint planning, backlog grooming, and chasing alignment across three other PMs. Their role becomes more about coordination than clarity. That’s a poor use of a product function. We don’t need PMs babysitting engineers, we need them driving product thinking, working with design, research, analytics, and other disciplines to shape and refine real solutions. They should consult engineering on feasibility and iteration planning, yes. But once the initiative is shaped and prioritized, that work should be handed over to the teams whose systems are impacted.

The expectation, then, is that the business defines and prioritizes the initiatives. The PMs responsible for each initiative bring that list to the EMs, who assess which of their teams should contribute based on system ownership and available capacity. If something doesn’t align with their system, they shouldn’t be forced to own it. If it does, they step in. The negotiation happens at the boundaries. Questions get clarified between EMs and PMs. Tradeoffs are made. Once the picture is clear, the EMs commit to delivering the necessary changes in their systems. They own that delivery.

A given team might work across multiple initiatives at once. That’s fine. That’s how distributed systems work. Each team contributes to the pieces that intersect with the systems they own. EMs are the ones accountable for defining these collaborations and aligning with other EMs to make sure delivery happens. It’s honest, even when it’s neither clean nor neat. And it gives engineering leaders real responsibility, instead of pretending that every team is autonomous and every PM is the CEO of their own mini-startup.

This model acknowledges that systems are long-lived, and that the cost of building new features should decrease over time as systems evolve and become more reusable. It creates incentives to build the right abstractions, not just ship local solutions. It encourages teams to treat their systems like products. And it gives EMs the space to run their teams while holding them, and the engineers in them, accountable.

What the Business Must Provide

This setup also assumes something critical from the business: clarity of priorities. If we expect EMs to decide where their teams contribute, there needs to be a ranked, non-negotiable list of what matters most to the company at any given time. That list needs to be maintained, communicated, and respected.

This shouldn’t be controversial. Someone in leadership, the CEO or the CPO or a cross-functional exec group, should be able to say: “These are the most important problems we need to solve this quarter.” Without that, planning devolves into lobbying, local prioritization, and disconnected bets. You get misaligned teams, partially built features, and a lot of time spent doing work that doesn’t compound.

In a service-oriented setup, that kind of clarity matters even more. If initiatives are going to be staffed across multiple teams, each contributing just a piece, then everyone needs to be solving for the same goal. Otherwise, the architecture takes the blame for a prioritization failure.

Structure is only half the question. The other half is what teams are empowered to focus on, and who gets to decide what matters. If we want engineering teams to behave like owners, we need to give them clear signals, not vague mandates. We need to stop confusing autonomy with isolation, and stop pretending that PMs embedded in every team are the only way to deliver product value.

Decoupling Teams and Initiatives

The traditional PM–EM pairing tightly couples initiatives to teams. As the number of initiatives grows, the model pressures organizations to scale headcount, replicate roles, and anchor new PMs to new teams, even when the underlying systems don’t require that scale. But initiatives and teams don’t need to grow in lockstep. In fact, they shouldn’t. This model breaks that dependency. It lets initiatives scale independently, spanning systems and domains as needed, while the engineering organization stays focused. Engineering only scales when the domain grows in complexity, not when coordination grows in volume.

It’s Conway’s Law again, but in reverse. We’ve let organizational structure dictate not just the shape of systems, but the flow of initiatives. When every PM is tied to a specific team, we force initiatives to mirror that structure, splitting work across systems that don’t naturally align, or bloating teams just to reflect growing scope.

A Better Operating Model

This model is about product management as much as engineering, and about making sure they focus where it matters most. It pulls them out of backlog mechanics and into the harder work: problem discovery, customer understanding, cross-cutting initiative leadership. When both disciplines are trusted to operate at their highest level, we stop wasting cycles on ownership theater and start building systems and products that move together.

The Velocity Trap

If anything, AI sharpens this paradox. When a team can spin up its own version of an existing system in days instead of months, the duplication trap closes faster. The friction that used to slow a team down long enough to ask “wait, doesn’t another team already own this?” has gotten cheap to ignore. Without the discipline of treating systems as products and decoupling initiatives from teams, we get the same paradox at higher velocity, with more autonomy theater and faster legacy.

Author Notes

I’ve led engineering teams across more than 15 years and several companies, and I’ve seen both models in action. The teams operating under the second one were consistently the healthier ones — better architecture, stronger engagement, real ownership, engineers proud of what they shipped. They aligned with other teams without being told to. They had real technical discussions. They were proud of how they shipped, not just that they shipped.

What I keep coming back to is why the first model became so dominant, and why it’s so hard to challenge. The second one asks product to operate without a dedicated delivery team for every initiative, and shifts more responsibility onto engineering. Both costs feel real to the people paying them. Neither, in my experience, is bigger than what the first model quietly costs everyone else.

Next week’s piece picks this up with the AI lens turned on directly: what team boundaries, ownership, and coordination cost look like when so much of the work runs through models.

Last week I was reading a piece by Gergely Orosz on what he calls “tokenmaxxing.” Companies, eager to prove their employees are using AI, have started measuring adoption by tokens consumed. The more tokens you burn, the more “AI-native” you must be. The metric climbs, and the chart gets shared in the all-hands.

And of course, humans being humans, the metric gets gamed. Long, padded prompts. Openclaw instances (or any other personal assistant tool) that don’t bring any real value. Tokens spent for the sake of spending tokens. Somewhere in the middle of that vertical climb, the question quietly disappears: what were we trying to achieve in the first place?

I read it and thought about every cultural change I’ve led, and every one I’ve been on the receiving end of. The pattern is older than AI. The names and the dashboards change with the times, but the underlying failure is consistent: we reach for the tactic before we’ve done the work that makes it earn anything.

What We Forget Before We Push

We’re driven by incentives. That’s an observation, not a moral statement. Gamifying things works. Carrots work and so do sticks. Public dashboards work, often well enough that leaders treat them as a substitute for the harder, slower work that needs to come first.

The harder work is two questions, and they need to live in people’s heads before any incentive is announced:

1. What are we changing?

2. Why? What business outcome are we expecting from this change?

If those two questions aren’t engrained, the metric becomes the goal and the dashboard becomes the work. People will hit the number, and the company will mistake the number for the change. By the time leadership realizes “tokens spent” doesn’t equal “better engineers,” a quarter has been spent training the wrong reflex.

This is the most common way change initiatives quietly fail. The incentive isn’t usually wrong on its own. The problem is that nobody finished the sentence before reaching for it.

The Three Groups

Once the what and the why are clear, you can think about who you’re moving.

In every change I’ve led, the room has split into roughly three groups.

The early adopters move on their own. They’ve already been thinking about it, or they trust the direction. You don’t need to convince them, you need to hand them the keys. Done well, they become your most credible promoters, much more credible than you, because they’re not the ones being paid to push it.

The vast majority are persuadable but not eager. They’ll come along because the why makes sense and the mission resonates. Leaderboards don’t move them on their own. The leaderboard might help once they’re already moving, but what really moves them is understanding why this matters, and trusting that the people asking aren’t doing it for a quarterly slide.

The detractors won’t be convinced. Some are protecting something. Others don’t like the idea for reasons they may or may not articulate. A few are right, and you should listen carefully before assuming they’re not. The rest will come along eventually, late, mostly out of fear of being left behind, and that’s fine. Not everyone needs to believe. Pretending otherwise just leads to performative agreement, which is worse than honest dissent.

The Path of Least Resistance

Something I’ve come to believe over the years: people don’t dislike change so much as they dislike friction. We’re creatures of habit, yes, but more precisely, we’re creatures of efficiency. The known path is paved while the new one is still gravel. When the choice is “do the thing I’ve always done in two clicks” versus “learn a new tool, fight an unfamiliar UI, and produce something I don’t even know is good yet,” the brain picks gravel last every time.

So the first job of the leader driving the change is to pave the new path so aggressively that the old one stops being the easier one. Pushing harder doesn’t accomplish much when the old path is still smoother.

Show people exactly how to do it the new way. Document it, build templates, run lunch-and-learns, find the early adopters and ask them to build the visible examples. Make the first attempt frictionless, even if you have to absorb the cost personally.

And then watch for the first friction. This is the part most leaders miss. People who are already feeling the discomfort of doing something unfamiliar will drop the new way the instant they hit a snag. Not the third snag, the first one. A link that 404s, or a doc that’s out of date. They quietly revert, and they don’t tell you, because reverting feels less like failure than persisting and looking foolish.

Your job is to anticipate that first friction and remove it before they hit it. If you can’t anticipate it, react within hours, not weeks. Every time someone hits a wall and you fix it before they give up, you protect a believer.

Subscribe now

The Contract Behind the Change

I wrote a few weeks ago about the unwritten contract between engineering leaders and the engineers they lead. I keep coming back to it because it sits underneath almost everything we do, and change management is no exception.

If you’re driving a change you don’t believe in, your engineers will know. Not from anything you say, but from the half-beat of hesitation when you describe the why, or from the slogans that don’t quite match how you talk privately. They read posture better than slides.

A change initiative is one of the moments where that contract gets stress-tested most. You’re asking people to do something uncomfortable, and the only currency you have to spend is their trust that you’re asking for the right reasons. If you spend that currency on something you yourself don’t think is right, the cost compounds. Every future change you try to drive becomes harder.

The corollary: if you’re being asked to drive a change you don’t believe in, that’s information. The job is to push back upstream until either the change makes sense, or you decide you can’t honestly carry it. Performing conviction you don’t have isn’t the answer.

Then, the Tactics

Once the what and the why are clear, the new path is paved, the first frictions are being hunted down, and you’re honest about what you’re asking, now you can reach for the tactical levers.

This is where gamification, dashboards, leaderboards, and public progress reviews start to work. They amplify a change that’s already moving, but they can’t create one from nothing.

But set them with care. Pick metrics that measure the outcome you said the change would deliver, not a proxy that’s easy to count. And don’t set them alone. Set guardrail metrics next to the headline ones, the kind that tell you when the dashboard is being gamed, or when the new way is being adopted only on the surface. Review them together. If the headline number is climbing while the guardrails are flashing red, the change isn’t working, no matter what the chart says, and you have to steer.

Metrics can always be played. That’s why you should never trust a single one in isolation.

I had a manager once who told me that as a leader driving a change, you should talk about it until people start making jokes about it. About the change, or about you for talking about it. The joke is when you know it’s landed, not the dashboard. The joke means it’s part of the room now, internalized enough to mock and familiar enough to riff on. That’s what cultural change looks like from the inside: a running gag, and the surest sign you’ve done the slow work right.

What Tokens Can’t Buy

Back to the tokenmaxxing piece, because it’s a useful mirror.

The companies counting tokens aren’t wrong to want their engineers using AI more. They might even be right about the strategic urgency. What they got wrong was the order. They reached for the metric before doing the work that makes the metric mean anything. They never defined what the change looks like in practice, why it matters in terms the engineers could believe in, what the new path looks like, or where the first frictions live. Without t

hat groundwork, the metric ends up being the only visible artifact of the change, so it becomes the thing that gets optimized.

Token counts go up. The actual change, engineers using AI to do better work and keep their judgment intact, may or may not happen, and the dashboard can’t tell you which one you got.

So if you’re about to push a change in your org, before you build the dashboard or announce the leaderboard, ask yourself the two questions and don’t move on until they’re answered.

What are we changing?

Why?

If the answers are clear, the rest gets easier. If they’re not, no amount of tactical incentive will save you.

Author Notes

I started writing this after reading Gergely Orosz’s piece on tokenmaxxing and noticing how much it overlapped with patterns I’ve seen for years, long before AI was the thing being pushed. The change is always the new shiny, but the failure mode rhymes: people skip the why and mistake the dashboard for the work.

The thing I find myself thinking about most these days is how much trust gets spent in change initiatives, more than most leaders realize. You only get a few of these in a single tour at a company before people stop showing up to the all-hands. Spend it on changes you believe in, and do the slow work first.

I became an engineer because I’m curious. Not because I loved code, not at first. I wanted to understand how things work. Technology was one of those things. I’d pick something apart, try to make it do what I wanted, and when it didn’t work I couldn’t let it go. I’d stay with the problem until it did. That obsession is what pulled me into software. Code was just the tool that let me scratch that itch.

But curiosity doesn’t stay in one lane. The same thing that made me dig into how systems work made me want to understand how businesses work. How decisions get made. How teams organize around problems. How domains break down into smaller, simpler pieces. And it turned out that ability, to quickly digest a domain, understand how it works, break it apart, translated very well into leadership and eventually management.

So I followed it. I led a project. Then a team. Then a few teams. I was still close to the code at first, reviewing PRs, jumping into architecture discussions, maybe shipping a fix here and there on a weekend. But slowly, the distance grew. My calendar filled up with 1:1s, planning sessions, stakeholder syncs, hiring loops. The IDE stayed closed for longer stretches. And at some point, without a specific moment I can point to, I realized I hadn’t written anything meaningful in months.

And for a while, that was fine. The curiosity was being fed, just differently. New domains to understand, new organizational problems to break down, new people dynamics to figure out. The leverage was real. I was helping ten, twenty, fifty engineers do their best work. That mattered. But eventually, that too became familiar. The patterns repeated. The novelty faded. The same curiosity that had pushed me into management started to feel unsatisfied by it. It wasn’t enough anymore. It got boring.

And the builder in me, the one who’d gone quiet, started to feel restless.

What made it worse was the growing sense that the gap had become too wide to close. The ecosystem moves fast. New frameworks every year. New languages gaining traction. The frontend world alone had reinvented itself three times since I’d last built a UI. I’d look at a modern React codebase and feel like a tourist. I still understood the fundamentals, architecture, systems thinking, tradeoffs, but the hands-on fluency? That was gone. And with it, a quiet resignation: maybe I’m just not a builder anymore. Maybe that chapter is over.

Then AI happened.

The Barrier That Disappeared

I don’t mean AI as a concept. I mean AI as a tool you sit down with and build things. The moment I opened a code assistant for the first time, described what I wanted in plain English, and watched it produce working code, something clicked. The code wasn’t perfect. But the barrier I’d been staring at for years, the one between “I know what I want to build” and “I can actually build it,” had just gotten a lot smaller.

Think about what used to stand between an idea and a working prototype. You needed to pick a language. A framework. A build system. You needed to understand whatever frontend ecosystem was trending that year. Bundlers, state management, component libraries. You needed a backend. A database. Authentication. Deployment. Each of these was its own learning curve, its own rabbit hole. And if you’d been away from it for a few years? The rabbit holes had moved.

This was the classic fullstack problem. You know that meme?

That was every engineer who tried to do it all. You could be great at the backend and ship a UI that looked like it was built in 2008. Or you could nail the frontend and have an API that fell over under any real load. Being truly fullstack, the kind where both halves of the horse look good, was rare. It required constant investment across multiple disciplines that were each evolving on their own.

AI erased that problem. Not entirely, but enough to change the game. I don’t need to know the latest React patterns to build a decent-looking UI. I don’t need to remember the exact syntax for setting up an Express server or configuring a Docker container. I describe the intent, review what comes back, adjust, iterate. The cycle that used to take days now takes hours.

Funny enough, the first thing I built with an AI assistant was something I’d been thinking about for over a year but never started because the frontend work alone felt like a weekend I didn’t have. I had it running in a few hours. It wasn’t production-ready, it wasn’t pretty, but it worked. And I remember thinking: I haven’t felt this in a long time.

The joy came back. Having an idea on a Sunday morning and a working prototype by the afternoon. I hadn’t felt that in years. AI didn’t just lower the barrier to entry. It gave me back something I thought I’d lost.

The New Reality

This isn’t just my story. It’s happening everywhere. A designer can prototype a working app without writing a line of code. A product manager who used to file tickets and wait three sprints can now build the internal tool themselves over a weekend. I’ve seen teenagers ship real products without knowing what a framework even is. The entry point to software has moved from “learn to code” to “describe what you want.”

And that’s exciting. For personal projects, for experimentation, for scratching your own itch, this is a great time to be alive. The cost of trying has dropped to near zero. You don’t need to learn a new framework every time you want to build something. You don’t need to understand the full stack. You don’t need years of experience. AI gets that part done for you.

So should everyone code? For their own things, personal tools, side projects, things that make their lives easier, yes. Absolutely. The ability to turn an idea into working software is powerful, and AI has made it accessible to a lot more people. That’s a good thing.

But here’s where I stop.

The Profession Behind the Code

Being able to produce code is not the same as being able to produce software. AI has turned writing code into a commodity. Translating intent into syntax is something it handles well. But software engineering was never just about writing code. It was about knowing which code to write, where to put it, and what happens when it fails.

Can AI generate a login flow? Sure. Will it handle rate limiting, session management, token rotation, CSRF protection, and audit logging correctly out of the box? Probably not. Will it know that the database schema it just designed will cause a full table lock under concurrent writes? No. Will it understand that the microservice it just scaffolded violates the bounded context you’ve spent six months defining? Definitely not.

These aren’t edge cases. They’re what separates a prototype from a production system. A demo from a product. Something that works on your laptop from something that serves a million users without falling over, leaking data, or costing ten times what it should.

So when someone says “AI will replace software engineers,” I think they’re confusing coding with engineering. The typing part got easier. The thinking part didn’t. If anything, it got harder, because there’s more code being generated faster than ever, and someone still has to decide whether it should exist, whether it’s correct, and whether it belongs. Reading code now matters more than writing it.

And honestly, if I had to tell an engineer one thing about staying relevant: stop worrying about whether AI can write your code. Start worrying about whether you can tell good code from bad code when it’s generated at ten times the speed you’re used to reviewing it. That’s the real challenge now.

The Joy and the Responsibility

So here I am. Building again. Shipping side projects on weekends. Prototyping ideas that have been sitting in my head for years. The gap I thought was too wide to close turned out to be smaller than I feared. AI didn’t replace what I know. It just removed the friction that was keeping me from using it.

I still carry something that a non-engineer using the same tools doesn’t: the instinct for when something is wrong. That feeling when a pattern is off, or a dependency feels risky, or a shortcut is going to cost more than it saves. A surgeon and a first-year med student can both hold a scalpel. The difference is knowing where to cut. That’s not gatekeeping. That’s the profession.

So if you’re an engineering leader who’s been feeling the same drift, too many meetings, too far from the code, quietly convinced that modern tooling has moved on without you, just try it. Open a code assistant. Describe something you’ve wanted to build for months. Start small. You’ll be surprised how quickly the muscle memory comes back. What you know hasn’t gone anywhere. And the joy is still there.

And this isn’t just for leaders. If you’re an engineer earlier in your career, AI won’t replace what you know, it’ll amplify it, if you’re building real judgment underneath. If you’re a student, treat AI as the most patient tutor you’ll ever meet, but don’t confuse using it with learning the thing itself. And if you’re a parent, like I am, wondering what your kid should study, don’t worry about the specific degree. What matters is judgment. Understanding how things work. Being able to think clearly. AI will change most professions. It won’t change our need for people who can make good calls.

Author Notes

I wrote this article partly for myself. The transition from builder to manager is something most engineering leaders go through, and very few talk honestly about what it costs. You gain leverage and influence, but you lose the direct connection to the craft. That simple, addictive loop of write, run, see. It goes away so gradually you almost don’t notice.

AI gave me that back, and I’m grateful for it. But it also made me think about what I actually bring to the table after all these years. And I think the answer isn’t the code. It’s everything around the code. The context, the judgment, the scar tissue from systems that failed in ways you only understand after you’ve lived through them.

The tools changed. The craft didn’t.

Subscribe now

Share

There’s a moment, and it’s never the one you expect, where you realise you’re going to leave. It doesn’t come during a heated argument or a bad quarter. It comes on a Tuesday afternoon, mid-sentence in a meeting, when someone says something and you feel nothing. No pushback. No frustration. Not even the energy to disagree. Just a flat recognition that the gap between what you believe and what you’re being asked to do has gotten too wide to bridge.

I’ve led engineering organisations for over fifteen years. I’ve weathered bad quarters and difficult reorgs, strategies I didn’t love, people decisions that kept me up at night. That’s part of the job. You don’t leave because things are hard, you stay because the hard things are worth doing. Because you believe the direction is right even when the path is rough.

But what do you do when you stop believing?

What Alignment Actually Means

I want to be precise about this, because alignment gets thrown around a lot in leadership circles and it’s worth defining what I mean.

Alignment is not agreement. I’ve disagreed with my manager and my peers. That’s healthy. If you’re surrounded by people who agree with you on everything, you have a different problem. Disagreement on strategy, on timelines and/or on sequencing is the normal friction of building something complex. You argue, you commit, you move forward.

Alignment breaks somewhere deeper. It breaks when the values shift. When the way a company thinks about its product and its people changes in a way you can’t reconcile with your own principles. It’s not about a single decision. It’s about a pattern. The company you joined, the one whose mission made you show up early and stay late, starts making choices that feel wrong. The company stops caring about building a great product. Engineering judgment, the kind that says “we can build this, but we shouldn’t build it like that,” starts getting treated as an obstacle rather than a contribution. Requirements become mandates. Timelines become deadlines with no negotiation. And the question “is this the right thing to do?” is replaced by “when will it be done?”. And then, people stop raising their voice. No one challenges or questions anymore.

That’s not misalignment on tactics. That’s a fundamental divergence in what the company values are.

The Invisible Cost of Ignoring Engineering Judgment

Here’s something that’s always bothered me. If a civil engineer tells you a bridge can’t support a certain load, nobody asks them to prove their calculus. The conversation is over. The load gets reduced or the design changes. There’s a respect for professional judgment that’s built into how we treat physical engineering.

Software engineering doesn’t get that. And I think I understand why: the consequences are invisible. A bridge built wrong collapses. A system built wrong degrades slowly. It accumulates operational burden, creates on-call nightmares, becomes the thing every new hire is warned about. The organisational scar tissue builds up over months and years, and by the time anyone outside engineering notices, the cost is already enormous.

So when a senior engineer or an EM says “yes, it’s technically possible, but the cost of building and maintaining it this way would be irresponsible,” that gets heard as “they’re being difficult.” Because the thing can be done. “Technically possible” is all some stakeholders need to hear. Feasibility isn’t binary, the real cost isn’t just in the initial build but in the years of maintenance, the operational overhead, the cognitive load spread across the entire organisation gets lost. Or worse, it gets dismissed.

The Contract

This is the part that made leaving inevitable.

When you lead engineers, they trust you and you have a contract with them. It’s unwritten, but it’s real, and if you’ve ever been on either side of it you know exactly what I’m talking about. You represent their craft upstream. When a business decision will compromise the quality of what they build, you push back. When timelines are unrealistic, you say so. You make sure the cost of shortcuts is understood before anyone commits to them. You protect their ability to do work they can be proud of. That’s what professional leadership looks like in any discipline.

And in return, they trust you. They follow your judgment. They take on hard problems because you’ve told them it matters, and they stretch beyond what’s comfortable because they believe you wouldn’t ask if it wasn’t worth it.

The moment you can no longer honor that contract, when you’re asked to push decisions downstream that you know are wrong, when the requirements you’re told to deliver make you uncomfortable, that’s when staying becomes the betrayal.

I thought about this a lot before I made my decision. Could I compartmentalise? Just execute, disagree privately, let the results speak for themselves? Maybe some leaders can. I couldn’t. Maybe I was wrong. You always have to ask yourself that question honestly. But then I’d talk to my engineers, hear the frustration in their voices when describing what they were being asked to build, and I’d know. This wasn’t me being inflexible. This was the organisation losing something it shouldn’t have lost.

I wasn’t willing to spend my credibility pretending otherwise.

Leaving

People assume leaving is the hard part. It’s not. By the time you actually resign, the decision has been made for weeks, sometimes months. The hard part is everything before it. The part where you’re still trying. Where you show up to meetings hoping something has changed, that someone will say the thing that makes it make sense again. The part where you wonder if you’re overreacting, or if your standards are too high, or if this is just what companies do when they scale.

I didn’t leave angry, and I didn’t leave with a desire to burn anything down. I left disappointed because the job was not done, because I still believe that products should be built with care, that engineering judgment is an asset, that you owe the people you lead honesty about what you’re asking them to do and why.

Those beliefs aren’t going to bend. And the company’s direction isn’t going to change because I want it to. At some point, you have to accept that the paths have diverged and no amount of influence will bring them back together.

So you go.

Author Notes

This is my first piece on this Substack, and it felt right to start here, with the thing that set this in motion.

I’m writing this Substack because, after fifteen years of leading engineering organisations, I’ve accumulated a set of convictions about how to build products and lead teams that I want to put somewhere permanent. Somewhere that doesn’t depend on an employer’s direction or a company’s appetite for honesty. I’ve spent my career thinking about engineering leadership, org design, the craft of software, and the messy human problems that sit underneath all of it. That’s what you’ll find here.

I’m still in the arena. Still building. Still leading. Just from a place where the principles aren’t negotiable.