Originally published on Rough Edges.
There's a pattern I've watched play out in more than one organization. From a distance it looks like high performance. Up close it's something else.
A strong engineer – relentless, demonstrably capable, the kind of person who ships when others stall – has the ear of the CTO. The project is high-stakes. Delivery feels close. And the closer it gets, the more the engineer's behavior gets defended, smoothed over, accommodated. Process is bypassed because process is slow. Other teams who push back get reframed as obstacles. Guardrails that applied yesterday no longer apply. The CTO, who is genuinely well regarded, has decided that this is what it takes to win.
It is not what it takes to win. It is what it takes to lose more slowly while looking decisive.
The visible problems are the easier part
The engineer ships, but each delivery comes with a private mortgage. Things are built to be "good enough for now" with a sincere promise to come back and clean them up later. They never come back. They are too busy shipping the next thing – and the next thing is being judged on the same metric.
This is how technical debt actually accumulates. Not from teams who don't understand quality, but from teams whose working definition of "done" never included it. Ward Cunningham, who coined the metaphor, was careful to point out that debt is only useful when you actually intend to repay it. A debt no one services is just a permanent tax on everyone who comes after.
The engineer is also clearly playing an in-group / out-group game. Pleasant and generous to those they consider part of the project. Dismissive, sharp, or quietly contemptuous of those they don't. Patrick Lencioni's framework from The Ideal Team Player is useful here. He describes ideal contributors as humble, hungry, and smart – the last meaning interpersonally aware. The engineer in this pattern is almost always extremely hungry and missing one of the other two. They are not, in Lencioni's terms, an ideal team player. They are a productive risk.
The engineer is the symptom
This is where I want to be careful, because the easy mistake is to make the article about the engineer. The engineer is the symptom. The real subject is the leader who has chosen to invest in them without examining what that investment costs.
Ben Horowitz writes about this directly in The Hard Thing About Hard Things. He categorizes the problem employees a leader has to decide about – the Heretic, the Flake, and the Jerk – and his stance, especially on the brilliant Jerk, is harder than the leaders defending such people tend to expect. The damage from a Jerk who is unquestionably brilliant compounds, because the bite carries weight: meetings go quiet, conversations stop happening, the executive team slowly stops communicating. Horowitz's position is that this is usually not worth tolerating, regardless of output. The discretion exists, but it cuts toward removal more often than toward accommodation. Leaders flatter themselves into believing they have the rare exception. They almost always don't.
Robert Sutton makes the math more explicit in The No Asshole Rule. He coined a framework he calls TCA – the Total Cost of Assholes – which adds up the lost productivity, the demotivated teammates, the engineers who quit, the engineers who stay but disengage, the management time spent smoothing things over, the recruiting cost of replacing the people who walked. When the calculation actually gets done, the brilliant ones are rarely as net-positive as their advocates assume. The trouble is that almost no one runs the numbers.
Run them, in the scenario I am describing. Two people moving fast, creating drag for somewhere on the order of seventy other engineers. Two, full-throttle. Seventy, demotivated. The arithmetic is not subtle.
The leader's credibility is what's actually at stake
I want to be charitable here. The CTO in this kind of story is usually a good leader having a bad season. Often they have been around long enough to have built real credibility. They have, in calmer times, talked persuasively about doing things the right way – sustainable pace, good engineering practice, healthy team culture, the value of process as accumulated learning rather than bureaucracy.
And now, under pressure to prove a project will succeed, all of that has gone quiet. The same leader who once defended guardrails is undermining them. The same leader who once talked about respecting other teams is reframing those teams as friction. The same leader who once spoke about long-term thinking is operating on a horizon of weeks.
This is where the deeper damage happens, and it has very little to do with the project. If the things you said yesterday don't apply when you are under pressure, the question every observant engineer in the organization is now asking is: which other things you said didn't you actually mean? The values speech at the all-hands. The line about quality being non-negotiable. The commitment to growing the team. How much of that was load-bearing and how much was scenery?
Reputation is built slowly and lost in patterns. A single decision under stress is forgivable. A sustained shift in what the leader will tolerate – especially in service of one person – is not a one-off. It is a revealed preference.
Simon Sinek's framing in The Infinite Game gets at the underlying mistake. A leader determined to win a specific argument – to prove a specific group of doubters wrong, to land a specific project no matter the cost – is playing a finite game inside an infinite one. The organization continues after the project ships. The engineers who watched what was acceptable continue. The teams who learned that the rules bend for favorites continue. Winning the project and degrading the system you needed for the next five projects is not a victory worth booking.
There is also a quieter empirical point. The Accelerate research by Forsgren, Humble, and Kim makes clear that high-performing organizations do not trade quality for speed – they achieve both, and the mechanisms that get them there are the same mechanisms being bypassed in this scenario. The leader convinced that delivery requires breaking the rules is operating on a folk theory that the data does not support.
What good leadership looks like here
If you recognize yourself in any of this, on either side, the corrective is not dramatic. It is just unglamorous.
Run the actual math. Not the visible delivery from the favored person. The total cost. Who is leaving meetings frustrated. Who is quietly looking elsewhere. How much management time is being spent smoothing over conflicts they created. How much engineering time will be spent paying down the choices made under pressure. If you don't know the numbers, you are choosing not to know.
Apply the same standards to your favorite as to everyone else. Sutton's most underrated point is that exceptions create the problem. The rule isn't what's written down. The rule is what gets enforced. If the standards apply selectively, the standards don't exist.
Defend your own previous position. If you have spent years arguing for sustainable pace, healthy process, respect across teams – when the pressure is on, that is not the moment to discover those things were optional. That is the moment they matter most. The credibility of everything else you have said depends on what you do when it would be
expedient to do otherwise.
Treat process pushback as information. When other teams resist accommodating the favored project, the default assumption shouldn't be that they are obstacles. It should be that they are operating in guardrails that exist for reasons you may not currently remember. Listen before overriding.
Build for the team you'll have in two years. The engineer who refuses to grow others, who keeps knowledge close, who treats juniors as a tax on their time – they are not building your future engineering organization. They may be building this quarter's deliverable. Those are not the same thing.
The hardest part of leadership is not the moments when the right answer is obvious. It is the moments when one person seems indispensable, the project seems urgent, and the path of least resistance is to make an exception. That is exactly when the rest of the organization is watching most closely. What you do then is what you actually believe.
