The Slow Erosion of an Organization

The core idea

Bad leadership corrupts organizational judgment.

One person stops raising risks because the last person who did was ridiculed. A manager takes credit for a successful release, then searches for someone to blame when the next one fails. An engineer learns that careful analysis is less valuable than agreeing quickly. The dashboards may remain green and the meetings may stay full, but the organization is already losing access to reality.

At a glance

How leadership failure becomes a system

A harmful behavior becomes an organizational problem when people must adapt around it. Those adaptations filter information, weaken decisions, and reinforce the original behavior.

01 Control, absence, or blame

Authority is used without clear, fair accountability.

02 People adapt for safety

Questions soften. Risks stay private. Initiative contracts.

03 The signal degrades

Leaders receive agreement instead of evidence.

04 Decisions fail later

Hidden risks become rework, attrition, outages, or drift.

The destructive feedback loop

Failure is blamed on execution, which invites more control and makes the next warning even harder to raise.

Failure modes

Seven ways authority becomes damage

Bad leadership is not a single personality type. It is a set of repeatable behaviors that teach people to protect themselves instead of protecting the work.

Control the work

Micromanagement replaces judgment with compliance and turns the leader into a permanent bottleneck.

Shift blame

When success flows upward and failure flows downward, people learn to manage appearances rather than surface risks.

Withhold context

Teams are asked to deliver outcomes without priorities, constraints, dependencies, or explicit tradeoffs.

Reward loyalty

Favoritism makes candor professionally expensive and gives the leader increasingly filtered information.

Treat people as tools

Capacity is extracted while growth, dignity, health, and the realities of human life are treated as inconveniences.

Mismanage change

Leaders either protect obsolete systems or manufacture constant disruption to appear decisive.

Confuse fear with high standards

Fear may produce short bursts of compliance, but it also hides uncertainty, weakens learning, and makes failure harder to prevent.

The quiet failure

The most damaging leader may be the one who is absent

When people picture a bad boss, they often imagine a loud, aggressive micromanager. That leader exists, but hostility is not the only form of failure.

In The Most Common Type of Incompetent Leader, Scott Gregory argues that absentee leadership is especially common. These leaders accept the status, authority, and rewards of the role while avoiding the difficult work of direction, involvement, feedback, and decision-making.

Important decisions remain unresolved.

Conflicts continue until they become personal.

Strong performers compensate for missing management.

Weak processes survive because no one owns their repair.

People eventually stop waiting for direction and build their own local rules. Different parts of the organization begin rowing in different directions, often with sincere intentions. When the results no longer line up, the same absent leader may blame the team for lacking alignment.

Leadership absence is not neutrality. It transfers leadership work to people who may have neither the authority nor the context to perform it.

Productive friction

Conflict is not the same as dysfunction

Teams should disagree. Many apparent personality conflicts are unresolved tradeoffs. Leadership turns opposing perspectives into decision inputs before they harden into factions.

Common tensions worth managing, not eliminating
Tension	One side protects	The other protects	Leadership’s job
Strategy vs. process	Speed and opportunity	Repeatability and control	Separate essential controls from removable delay.
Change vs. continuity	Adaptation	Stability and institutional knowledge	Define what must change and what must remain dependable.
Long-term design vs. delivery	Future capability	Present customer value	Set an explicit time horizon and debt boundary.
Architectural rigor vs. pragmatism	System coherence	Usable delivery	Agree on fitness criteria before debating solutions.
Edge-case safety vs. launch speed	Failure prevention	Feedback and momentum	Classify risk instead of treating every failure as equal.
Consistency vs. local judgment	Maintainability	Situational effectiveness	Establish standards and a documented exception path.

The goal is not consensus. It is a decision that accounts for the risks each perspective is trying to protect.

A useful vocabulary

The Business Chemistry framework described in HBR distinguishes Pioneers, Guardians, Drivers, and Integrators. People are composites, not fixed labels. The practical lesson is to notice when the dominant working style consistently drowns out the others.

Psychological safety

Make reality safe to discuss

Google’s Project Aristotle found that how a team worked together mattered more to effectiveness than who was on the team, with psychological safety emerging as the most important of five team dynamics in Google’s analysis.

Psychological safety means people can take interpersonal risks: ask a basic question, admit an error, challenge an assumption, or present an unfinished idea without expecting embarrassment or punishment.

Safety needs a shared method

Psychological safety is necessary, but it is not a substitute for a shared method. An open forum gives people permission to speak; it does not give everyone the same context, expertise, or evidence. Some participants understand the domain deeply, others know adjacent systems, and others do not yet know what they are missing. Status and confidence can make that unevenness difficult to acknowledge.

The answer is not to close the discussion. It is to give the discussion a protocol. Engineering work benefits from the habits of scientific inquiry: define the question, make assumptions visible, form a testable explanation, gather evidence, compare the result with the prediction, and update the decision. This is not a rigid linear recipe. The University of California Museum of Paleontology’s Understanding Science describes real scientific work as iterative and nonlinear while retaining the essential requirement that ideas be tested against evidence.

Parent delivery boundary

Project phase

A project phase defines a final deliverable and the measurable results that justify the work. In this model, a phase does not have to be a sequential calendar stage. Several phases can run in parallel under different teams when the product requires it.

MVP
A usable first release measured through customer engagement and feedback that tests the market assumption.

Customer growth
Product or marketing capabilities tied to acquisition, activation, retention, expansion, or another named growth measure.

Customer support
Defect correction and service improvement measured through reliability, repeat incidents, resolution time, or customer impact.

R&D
Research, experiments, and demonstrations that resolve a defined uncertainty and support a next decision.

contains one or more features ↓

Child delivery unit

Feature

A feature defines one deliverable and the value it is expected to provide. A useful one-sentence starting point is:

As a [person or role], I want [capability or outcome], so that [value].

This sentence preserves the user, requested change, and reason for the work. It is the feature’s goal, not its full specification. Every feature also carries four planning properties:

Value
Which customer or business result makes this worth delivering?

Cost
What money, time, infrastructure, and opportunity cost will it consume?

Risk
What is the likelihood and consequence of failure, delay, misuse, or a wrong assumption?

Effort to maintain
What operational, support, security, upgrade, and knowledge burden remains after release?

The feature-level risk property summarizes the feature’s overall exposure for planning and prioritization. The risks contained by the feature are the individual technical, organizational, legal, security, and environmental threats that support that assessment.

A feature contains:

01 / Risks

Plan what could fail

Track technology-complexity, security, legal and governance, maintenance, and environmental risks—including people, infrastructure, and third-party dependencies. Each material risk needs an owner, response, and reassessment trigger.

02 / Tasks

Complete bounded work

A feature can contain many tasks. Each task is a unit of work that must be completed to produce or verify the final deliverable.

03 / Research spikes

Resolve missing knowledge

Use a time-boxed investigation when the team cannot responsibly estimate, design, or commit because critical knowledge is missing.

A research spike is not a disguised feature or a promise of production code. The Agile Alliance’s discussion of spikes describes a spike as work intended to answer a question or gather information rather than produce a shippable product. A useful spike should leave behind searchable organizational memory: its question, a demo or prototype, findings, tested assumptions, newly exposed risks, and an Architecture Decision Record for the resulting design decision. That record allows a team returning twelve months later to understand why the decision was made instead of reconstructing the argument from code and memory.

The overlooked boundary

We make plans with the knowledge we possess—not with all the knowledge that exists.

That boundary is one of the most overlooked problems faced by teams and by society more broadly. Every roadmap, policy, system design, and explanation is constructed from limited experience, incomplete evidence, inherited assumptions, available tools, and the language we currently have. We try our best from inside that boundary. The danger begins when confidence in a plan is mistaken for completeness of understanding.

Unknown unknowns do not begin as backlog items a team can name, estimate, and assign. They emerge when an experiment contradicts a prediction, an integration exposes a hidden dependency, a customer uses a feature in an unanticipated way, or someone with different experience asks a question the group did not know it needed to ask.

No decomposition can reveal all of those questions at the beginning. Its purpose is to create deliberate observation points where hidden dependencies, false assumptions, and questions beyond the team’s current understanding can surface early enough to change the work.

This is where psychological safety and disciplined protocol become inseparable. Safety lets someone say, “I do not know,” “our assumption may be wrong,” or “there is a question here that we have not learned how to ask.” Protocol ensures that admission becomes a research spike, experiment, demonstration, recorded evidence, ADR, or change in scope—not a source of shame and not an excuse for guessing.

A mature team is not one that already knows everything. It is one that can recognize the edge of its knowledge, investigate beyond it, preserve what it learns, and revise its decisions without treating learning as failure.

It is Permission to be candid Space to admit uncertainty A protocol for testing assumptions Accountability informed by evidence

It is not Avoiding hard feedback Letting everyone have their way A vote on technical truth Lowering the quality standard

Amy Edmondson and Michaela Kerrissey address those misconceptions directly in What People Get Wrong About Psychological Safety. A team needs candor and accountability. Psychological safety makes both possible.

Leadership in practice

Build the conditions for honest, humane work

Good leadership is not charisma. It is an operating discipline. Open the practices below for concrete ways to make the system safer, clearer, and more accountable.

01 Give every voice a path into the decision

Telling people to “speak up” is not enough when rank, temperament, interruption, or past retaliation determines who can safely take the floor. Meeting design is part of leadership.

Send the question, constraints, and evidence in advance.
Begin with a short period of silent note-taking.
Give each participant a brief, time-boxed turn; passing is allowed.
Separate clarification from debate.
Name the decision owner and decision rule.
Record the decision, dissent, assumptions, and follow-up evidence.

HBR recommends round-robin participation as one way to prevent a leader from dominating a discussion in How to Run a Meeting Without Talking Too Much. Equal opportunity to contribute does not mean every opinion carries equal technical weight. It prevents conversational dominance from deciding which evidence is heard.

02 Replace blame with evidence-backed accountability

Publicly share credit and accept responsibility for the system in which a failure occurred. Then ask useful questions: What decision was made? What evidence was available? Which safeguard failed? What must change?

Blame looks backward for a target. Accountability looks backward for evidence and forward for repair.

03 Support people without abandoning standards

Engineers are human beings, not compute units assigned to a backlog. People have ambitions, families, health concerns, periods of grief, and skills they have not yet had the chance to develop.

HBR’s guidance on supporting an employee through a personal crisis begins with listening and making appropriate adjustments without demanding private details. The leader protects the person’s dignity, makes a clear coverage plan, and remains honest with the rest of the team about work commitments.

04 Treat learning as part of delivery

Good leaders make room for education, exploratory work, mentorship, and career development while still setting clear expectations. If learning is postponed until the backlog is empty, it will never happen.

Current HBR guidance likewise treats supporting employee growth as part of the leader’s job even when immediate demands are high.

05 Clarify authority before demanding alignment

Define the desired outcome, constraints, quality standard, decision rights, and escalation points. Make clear who recommends, who decides, who executes, and what evidence could reopen the decision.

Alignment is not obedience. It is shared understanding of the destination, the boundaries, and how disagreements become decisions.

06 Intervene when high performance becomes harmful

Psychological safety disappears when leaders tolerate ridicule, exclusion, retaliation, or repeated disrespect from a high performer. Results do not excuse behavior that damages everyone else’s ability to contribute.

A leader should name the behavior, explain its impact, set the expected change, and follow through. Preserving dignity does not require preserving impunity.

Humane accountability

Hold the person, the team, and the mission together

Supporting people and delivering results are not opposing goals. The work is to make all three responsibilities visible at the same time.

The person

What support, privacy, feedback, or growth do they need?

The team

What commitments, boundaries, and redistribution are fair?

The mission

What outcome and quality level must still be protected?

Compassion without clarity can leave coworkers absorbing invisible costs. Accountability without compassion can punish people for circumstances a reasonable system should accommodate.

Cross-functional leadership

Different leaders own different parts of value delivery

An organization does not have one leadership function. It has a chain of responsibilities that turns customer need into working, verified outcomes. Clear boundaries make those responsibilities easier to own and easier to communicate.

Executive leadership

Owns company direction, customer-acquisition priorities, product-portfolio direction, investment boundaries, and acceptable business risk. It must explain why an outcome matters and how value will be recognized.

Product and project leadership

Owns problem framing, roadmap decomposition, scope, sequencing, dependencies, acceptance criteria, and delivery communication. It turns strategic intent into bounded work.

Engineering leadership and teams

Owns technical discovery, architecture, estimation, implementation, verification, deployment, and operational feedback. It produces working deliverables and evidence that they solve the intended problem.

Ownership boundaries are interfaces, not walls
Role	Questions it must answer	Boundary output	Failure to avoid
Executive	Why now? Which customers and outcomes matter?	Strategic context, priorities, funding, and outcome measures	Sending an unexplained feature downstream
Product / project	What is in scope? What happens first? Who decides?	An ordered plan with owners, decision points, and visible risks	Promising dates or behavior without exposing dependencies
Engineering	What constraints exist? Which solution is viable? How will it be verified?	Tested deliverables, documented decisions, and operating evidence	Quietly redefining the customer problem around implementation convenience

Team development

Move through conflict without pretending it can be skipped

Bruce Tuckman’s model describes a progression from orientation and conflict through cohesion and functional roles—the familiar Forming, Storming, Norming, and Performing sequence. Clear ownership accelerates that progression by making the real disagreements discussable.

01 / Forming Orient to the work

Establish the customer outcome, roles, constraints, and decision owners.

02 / Storming Surface the tradeoffs

Expose disagreement about value, scope, timing, risk, and technical approach.

03 / Norming Agree how to work

Set communication paths, escalation rules, and evidence standards.

04 / Performing Produce value

Deliver, test, observe, learn, and adjust without reopening every boundary.

Speed comes from clarity—not suppressed disagreement.

Teams move slowly when everyone can influence a decision but no one owns it, or when one function makes commitments another function must absorb without context.

Engineering ownership

The most important questions start with why

“Why?” is not resistance when it is asked in good faith. It is the first step toward ownership. An engineer who understands only the requested implementation can follow instructions. An engineer who understands the customer problem, business consequence, and definition of value can evaluate tradeoffs and propose a better solution when the original request does not fit the environment.

Why does this outcome matter? Identify the customer need, business objective, urgency, and consequence of failure.
What problem is in scope? Define affected users, current and desired behavior, exclusions, and acceptance criteria.
Which constraints are real? Map legacy dependencies, security, data, staffing, cost, time, compliance, and operational limits.
What solutions are possible? Compare tradeoffs, reversibility, migration paths, and failure modes.
What evidence will guide and verify the decision? Record the decision, test the behavior, observe the integration, and define what would reopen the choice.

Executives clarify the purpose and commercial boundary. Product and project leaders frame the problem and coordinate the delivery system. Engineering owns the technical investigation, solution, and evidence.

Long-term confidence

Engineering inherits systems—and the missing memory around them

Engineering teams routinely enter old codebases with weak documentation, uneven tests, and none of the people who made the original decisions. The code shows what the system does today. It rarely explains why a constraint exists or whether its original context is still valid.

Preserve decisions, behavior, and boundaries

Michael Nygard’s original Architecture Decision Record proposal preserves the context, decision, status, and consequences of architecturally significant choices. Unit tests preserve local behavioral expectations. Integration tests expose whether components, databases, APIs, queues, identity systems, and third-party services still work together.

None eliminates the need for judgment. Together they give a new team evidence about what must remain stable, what can safely change, and where the system’s real risks live.

A blast radius is not a trust radius

Canary releases, circuit breakers, feature flags, isolation boundaries, and rollback plans can reduce the technical reach of one failure. They cannot prevent customer trust from being lost in buckets when a product fails repeatedly over months or years.

Blast-radius controls limit how much of the system an incident can reach. They do not limit how many failures a customer remembers.

When technical debt becomes decay

Martin Fowler’s Strangler Fig application pattern offers an incremental alternative to a high-risk, all-at-once rewrite: build new capability around the legacy system, redirect behavior gradually, and allow the old implementation to shrink as replacement paths prove themselves.

The pattern still depends on tests, ADRs, and clear ownership. A team must know which behavior to preserve, which decisions are superseded, how work moves between old and new paths, and what evidence permits the next cutover. That is how technical debt that has become decay can be shed without gambling customer confidence on one replacement event.

The leadership standard

Strategy explains why. Delivery leadership defines the work. Engineering owns how—and proves it works.

If we cannot row in the same direction, we will not arrive where we intended. Alignment is not produced by demanding obedience. Executive leadership must explain why the destination matters. Product and project leadership must make the route, scope, and responsibilities clear. Engineering must own how the system is built and produce evidence that it works. Those boundaries let teams move through Forming, Storming, and Norming into delivery without asking anyone to operate on blind faith.

Sources

References and further reading

Scott Gregory, “The Most Common Type of Incompetent Leader,” Harvard Business Review, March 30, 2018.
Laura Delizonna, “High-Performing Teams Need Psychological Safety. Here’s How to Create It,” Harvard Business Review, August 24, 2017.
Amy C. Edmondson and Michaela J. Kerrissey, “What People Get Wrong About Psychological Safety,” Harvard Business Review, May–June 2025.
Suzanne M. Johnson Vickberg and Kim Christfort, “Pioneers, Drivers, Integrators, and Guardians,” Harvard Business Review, March–April 2017.
Google re:Work, “Understand Team Effectiveness,” originally published in 2015.
Carolyn O’Hara, “How to Manage an Employee Who’s Having a Personal Crisis,” Harvard Business Review, July 5, 2018.
Bruce W. Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin, 1965, 63(6), 384–399.
Michael Nygard, “Documenting Architecture Decisions,” Cognitect, November 15, 2011.
Martin Fowler, “Strangler Fig,” martinfowler.com.
Ham Vocke, “The Practical Test Pyramid,” martinfowler.com, February 26, 2018.
University of California Museum of Paleontology, “Summing Up the Process,” Understanding Science.
Gregory Engel, “The Practice of Sizing Spikes with Story Points,” Agile Alliance, November 6, 2018.

Dependency-free HTML/CSS article — native browser <details> elements provide progressive disclosure without adding a JavaScript package.