Skip to main content
Operating Models

How Engineering Organizations Sabotage Their Own Success

The most common assumption in organizational improvement work is that the problem is external. Market conditions are unfavorable. The talent pool is thin. The technology is immature. The customer requirements are unclear. The budget is insufficient. Each of these can be true, and often is. But the organizations that consistently fail to perform do so not because external conditions overwhelmed them. They fail because of forces that originate and operate entirely inside the organization — forces that the organization is actively, persistently, and sometimes expertly refusing to look at.

The five dynamics described here are not obscure pathologies. They are operating, right now, in most technology organizations at some level. They produce technical debt that cannot be named, change management processes that generate the chaos they were designed to prevent, leadership cultures where nobody tells the truth, cultures that reflect the unexamined patterns of the people at the top, and measurement systems that have displaced the missions they were built to track. They are familiar. They are painful. And they are almost never the subject of an honest organizational conversation.

The reason is simple: each of these forces gains power precisely through the organization’s refusal to look at it. That is not a metaphor. It is a mechanism.

The Dysfunction You’re Nourishing by Fighting It

Tsultrim Allione spent decades in Buddhist practice and psychology studying what happens when we fight our inner conflicts rather than meeting them. Her conclusion, documented in Feeding Your Demons, is counterintuitive and precise: “when we try to fight against or repress the disowned parts of ourselves that I call demons, they actually gain power and develop resistance.” [[Feeding Your Demons]] The harder you fight the thing you don’t want to look at, the stronger it gets — because the act of fighting is itself an act of attention, and attention feeds whatever receives it.

The organizational translation is direct. The technical debt conversation the team is avoiding, the cultural conflict nobody will name, the architectural decision everyone knows was wrong — these don’t resolve through neglect. Every sprint planning meeting that passes without honest acknowledgment of the real capacity situation makes the next one harder. Every performance conversation deferred to spare feelings transfers the problem, plus interest, to the next manager who inherits the situation. The energy an organization spends suppressing the official acknowledgment of the dysfunction is the energy that could be resolving it. Allione: “The alternative to feeding our demons is to engage in a conflict we can never win: our unfed demons only become more and more powerful and monstrous as we either openly battle them or remain ignorant of their undercover operations.” [[Feeding Your Demons]]

Cheri Huber, in The Fear Book, names the underlying mechanism: “Resistance is one of the processes that mask fear. Every time we choose safety, we reinforce fear.” [[The Fear Book]] Every time the engineering team chooses the comfortable conversation over the accurate one, every time leadership chooses the optimistic dashboard metric over the true status, every time a project is declared “on track” to avoid the discomfort of saying otherwise — the organization’s capacity to tolerate honesty contracts. The suppression is not protecting the organization from difficulty. It is training it to require less and less truth.

Ken Blanchard, in The Heart of a Leader, states the operational conclusion: “In life, what you resist, persists. Until you deal with your feelings, you will be stuck with them.” [[The Heart of a Leader]] Not eventually stuck. Immediately and structurally stuck. The unfaced dysfunction does not go away while it is being managed around. It occupies the room, drains the energy, and grows.

When Your Protections Become Your Problems

Every organizational protection system was built in response to a genuine threat. The change advisory board was built after a botched deployment brought down production. The multi-level approval chain was built after an unauthorized architectural decision cost the company three months. The exhaustive documentation requirement was built after a critical system failed because only one person understood it. These were real problems. The protections were genuine solutions.

And then the context changed. The organization grew. The technology evolved. The original threat transformed or disappeared. But the protection system did not. And in the absence of the threat that justified it, the protection began generating the very harm it was designed to prevent.

Ellyn Bader and Peter Pearson, in Daring To Love, identify this as the defining pattern of psychological defense: “A defense is very much like scar tissue from a burn — the scar originally protected us from further damage, but now it only disfigures us. And yet there’s good reason for optimism. When we become aware of our defenses, and when we understand how they limit us, we can take action to break the defensive habits that are interfering with love.” [[Daring To Love]] The CAB meeting that consumes four engineering-hours per week to approve changes that take twenty minutes to implement. The documentation standard that produces artifacts nobody reads. The approval chain that creates the bottleneck it was designed to prevent — these are organizational scar tissue. They disfigure what they were meant to protect.

Gene Kim, Kevin Behr, and George Spafford document the mechanism in The Phoenix Project with operational specificity: “When you spend all your time firefighting, there’s little time or energy left for planning. When all you do is react, there’s not enough time to do the hard mental work of figuring out whether you can accept new work.” [[The Phoenix Project]] The change management process that fails to control the inflow of work — the problem it was specifically designed to prevent — generates the unplanned work (fires) that makes planning impossible. The defense has become the attack.

Robert Glover, in Mr. Nice Guy, traces the same pattern in human behavior: “Nice Guys believe that if they are good, giving, and caring, they will in return be happy, loved, and fulfilled. Sound too good to be true? It is.” [[Mr. Nice Guy]] The organization that has built a defense of perpetual agreeability — saying yes to every stakeholder request, avoiding every difficult conversation, never declining anything on grounds of capacity or strategic fit — has created a protection against conflict that generates far more conflict than the conversations it was avoiding. The protection has become the wound.

Why the Most Confident Leadership Creates the Most Fragile Organizations

There is a specific form of organizational fragility that looks, from the outside, exactly like strength. The leadership team is confident, unified, and certain about direction. Uncertainty is treated as a communication problem — something to be managed rather than surfaced. Bad news moves slowly up the hierarchy and is edited at every level. The official story is always positive. The real story circulates in side conversations, in whispered retrospectives, in the topics that never appear in all-hands meetings.

Terryl and Fiona Givens, in The God Who Weeps, describe the paradox of power and vulnerability: “Vulnerability is both the price of the power to save, and that which saves.” [[The God Who Weeps]] The leader who appears invulnerable — who has no doubts, admits no failures, projects total certainty — has purchased the appearance of strength at the cost of the actual mechanism of influence. Cheri Huber, in The Fear Book, distills this to its sharpest form: “The way to be invulnerable is to be completely vulnerable.” [[The Fear Book]]

David Deida, in The Way of the Superior Man, frames this as a direct confrontation with fear rather than its suppression: “Your fear is the sharpest definition of yourself. Own your fear, and lean just beyond it. In every aspect of your life.” [[Superior Man]] The leader who has not examined and owned their own fear produces an organization full of people performing confidence for the same reason the leader is — because they have learned, by observation, that uncertainty is not safe to surface. James Hollis, in Under Saturn’s Shadow, names the cultural consequence: “men’s lives are essentially governed by fear… but the healing of a man will require that he cease feeling shamed by his fear. I have always admired the freedom of women to acknowledge their fears, to share them, and thereby reap the support of others.” [[Under Saturn’s Shadow]]

The CTO who projects total confidence about a digital transformation timeline creates a team that cannot surface bad news until it has become a crisis. The VP Engineering who treats uncertainty as a leadership failure creates engineers who hide unknowns rather than escalate them early. The engineering leader who never publicly owns a mistake creates a team where mistakes are concealed until they are catastrophic. The fortified leadership persona — certain, decisive, unshaken — generates organizational brittleness at every level below it. The only raw material from which good organizational decisions can ever be made is the truth, which is the first resource to disappear in an environment where uncertainty is treated as weakness.

The Culture You’re Leaking Downward

James Hollis, in Under Saturn’s Shadow, makes the connection between individual psychology and collective culture with unflinching clarity: “What we do not understand in ourselves is projected onto our surroundings, and so the sum of our society is the aggregate of what is unconscious in each of us.” [[Under Saturn’s Shadow]] Organizations do not create culture intentionally. They create it through what leadership has not yet examined in itself — which then flows downward through every layer of the hierarchy as behavioral defaults, unwritten rules, and patterns that everyone can see and nobody is naming.

Tsultrim Allione, in Feeding Your Demons, documents this transmission across generations: “Making a demon map can be useful in breaking vicious cycles of demons that have been passed from one generation of a family to the next. Many of us can trace our demons back to previous generations, yet we may be unaware of how they are affecting our current relationships, our work environment, our children, and even our grandchildren. It’s often easier to see the demons we have received than the demons we have passed on.” [[Feeding Your Demons]] Engineering culture works the same way. The unexamined anxiety of a CTO about control propagates downward as micromanagement, which becomes the team’s learned helplessness, which becomes the engineers’ reluctance to take initiative, which becomes the product’s slowness to adapt. The leader sees the symptom at the bottom of the chain. They rarely see that they are the source at the top.

Kim, Behr, and Spafford provide the engineering-specific version in The Phoenix Project: “Every time that we let Brent fix something that none of us can replicate, Brent gets a little smarter, and the entire system gets dumber.” [[The Phoenix Project]] Brent’s behavior is not malicious. It is the behavioral expression of an unexamined belief — that being indispensable is the same as being valuable. That belief, formed somewhere in Brent’s professional history and never interrogated, has propagated through the system as organizational ignorance and dependency. His pattern has become the system’s architecture.

The organizational consequence is that culture change cannot be achieved by changing stated values, running culture surveys, or launching employee engagement programs. These operate at the level of articulated belief — which is almost entirely downstream of the actual behavioral patterns the culture is made of. Those patterns originate in what leadership has not examined in itself. The culture will not change until the examination begins. And the examination will not begin until leadership is willing to look first.

When the Measure Becomes the Mission

The most reliably destructive thing a technology organization can do is become very good at optimizing the wrong metric. It is destructive precisely because it looks like progress. The velocity points are going up. The deployment frequency is improving. The utilization rate is at capacity. Every line on the dashboard is moving in the right direction. And the actual mission — delivering value to the people the organization exists to serve — is quietly starving.

Kim, Behr, and Spafford identify the mechanism in The Phoenix Project: “any improvements made anywhere besides the bottleneck are an illusion. Astonishing, but true! Any improvement made after the bottleneck is useless, because it will always remain starved, waiting for work.” [[The Phoenix Project]] Teams optimize their local metrics. They run fast, they work efficiently, and they produce output — which accumulates upstream of a bottleneck that is processing at its own pace, regardless of what the dashboard says. The local numbers look excellent. The system performance is degrading.

Ken Blanchard, in The Heart of a Leader, names the distortion: “Managing only for profit is like playing tennis with your eye on the scoreboard and not on the ball.” [[The Heart of a Leader]] And: “Things not worth doing are not worth doing well. We must look at the big picture to make sure the important things are not being pushed out of the way by the urgent needs of the moment.” [[The Heart of a Leader]] The metric was designed to make the mission legible. When the metric becomes the mission, leadership is watching the scoreboard while the ball lands somewhere they cannot see.

Elder David A. Bednar, writing in Increase in Learning, identifies why behavioral metrics consistently fail to produce the change they measure: “True Doctrine, understood, changes attitudes and behavior. The study of the doctrines of the Gospel will improve Behavior quicker than a study of behavior will improve Behavior.” [[Increase In Learning]] Applied to engineering organizations: the team that genuinely understands why code quality matters — that understands the compounding cost of technical debt, the relationship between architectural coherence and team velocity — will naturally produce quality. The team managed by a code quality metric will produce artifacts that satisfy the metric while the underlying understanding, and its behavioral consequences, remain unchanged.

David Deida, in The Way of the Superior Man, closes the argument at the level of purpose: “Without a conscious life purpose a man is totally lost, drifting, adapting to events rather than creating events.” [[Superior Man]] The engineering organization without a mission it can articulate in terms of the value it produces for the people it serves has only its metrics left — and a team optimizing for metrics without a mission is, by definition, adapting to events rather than creating them.

So, What Is Your Organization Refusing to Look At?

Five questions surface where these patterns are operating.

First: What dysfunction is your organization managing around rather than addressing directly? The technical conversation being deferred. The performance situation being worked around. The architectural decision everyone knows was wrong that nobody is saying out loud. The managed-around thing is the thing draining the most capacity — because avoidance has overhead. Name it.

Second: Name one protection system that is now generating the problem it was designed to prevent. The change process, the approval chain, the documentation requirement, the “alignment” meeting that has become a bottleneck to the alignment it was supposed to produce. What did this protect against? What is it costing now?

Third: What does your leadership team project certainty about that it does not actually have certainty about? The timeline. The market direction. The architectural bet. The team’s actual capacity. These are invitations to notice where the organization has trained itself not to surface what is actually known.

Fourth: What unexamined pattern in leadership is showing up as an organizational behavior at the bottom of the hierarchy? The team’s inability to make decisions without escalating. The culture of avoiding conflict in retrospectives. The pattern of heroics over documentation. Trace it upward.

Fifth: What metric is your organization optimizing for that has displaced the mission it was designed to track? Sprint velocity. Utilization rates. Feature count. Deployment frequency. Each of these was a legitimate proxy — and each, in organizations that use them most aggressively, has become the thing being optimized rather than the thing being measured.

These are not comfortable questions. That is precisely why they are the right ones.

Operating Models

More Field Notes

Operating Models

The Accumulation Trap: Why Engineering Organizations Grow Without Maturing

Operating Models

Architecture of Excellence: Great Teams Are Built

Operating Models

The Default Organization: Your Culture Is Already Designed

From insight to a decision

Turn the Pattern Into Clearer Operations

Inspect the WixCorp coordination recordStrengthen deliveryStart a Structured Brief

Make the constraint visible before it gets expensive.

Start a Structured Brief