Why Anti-Patterns Matter

Leadership anti-patterns are not the domain of bad leaders. They are the domain of good leaders whose strengths have been taken too far, or applied in the wrong context, or never updated as their role changed.

The expert who became a manager and cannot stop solving technical problems - they are not being lazy or selfish. They are doing what made them successful. The problem is that what made them successful as an individual contributor is now making their team dependent and themselves a bottleneck.

The consensus-seeker who cannot make a decision without everyone's agreement - they are not being cowardly. They value inclusion and want people to feel ownership. The problem is that their commitment to inclusion has become a mechanism for avoiding accountability.

Understanding this is important for two reasons. First, it makes the anti-patterns recognisable without making them about character defects. Second, it makes the fix clearer - you are not asking someone to become a different person. You are asking them to apply their strengths differently, or to recognise when their default mode is not serving the situation.

Why They Compound

The second thing to understand about leadership anti-patterns is that they get worse over time. Not because the leader deteriorates, but because the team adapts. Once a team has learned that the leader solves all problems, they stop solving problems. Once a team has learned that decisions get made by consensus, they stop making individual calls. The team's behaviour reinforces the leader's pattern, and the leader's pattern reinforces the team's behaviour.

By the time most leaders become aware of an anti-pattern, they are not just dealing with their own habit - they are dealing with a team that has been shaped by it. Changing the pattern requires changing both.

Why They Are Invisible to the Person Exhibiting Them

Anti-patterns are rarely obvious to the person exhibiting them because they are usually being done with good intentions and with evidence that they work. The expert who solves all the problems sees problems getting solved. They do not see the capability not being built, the confidence not developing, the team not growing. The evidence they have access to confirms the pattern. The evidence that would challenge it is in the absence - in what is not happening.

This is why feedback, specific and direct, from people who trust you enough to give it, is the primary mechanism for surfacing anti-patterns. Self-reflection alone is rarely sufficient.

The Expert Trap

This is the most common anti-pattern in engineering leadership, because the pipeline into engineering leadership runs almost exclusively through individual technical excellence. You were the best engineer on the team. You got promoted. Now you are the engineering manager - and you are still the best engineer on the team, and you know it, and you cannot help yourself.

What the Trap Looks Like

• In technical discussions, your view is treated as correct by default - not because it was tested but because you are the senior person in the room.
• In code reviews, your comments are effectively directives. The engineer changes what you say to change, not because they understand why, but because it is easier than arguing.
• When there is a hard problem, people bring it to you. And you solve it. And they come back with the next one.
• In architecture discussions, you have a view early and the conversation tends to end up there.
• Your calendar is full of problem-solving conversations that did not need you.

The output looks fine. Problems get solved. The team ships. From the outside, this can look like technical leadership working well.

What It Costs

The cost is not immediately visible in delivery metrics. It shows up in:

Team capability - engineers who have their problems solved for them do not develop the problem-solving muscles. They become skilled at describing problems to you and implementing your solutions. They do not become skilled at moving through the ambiguity that leads to good solutions independently.

Team confidence - engineers who consistently defer to the leader's technical judgement stop trusting their own. They become hesitant, qualifying everything with "I think" and "but maybe check with [name]." This is not humility - it is learned deference.

Architectural quality - any architecture that primarily reflects one person's thinking is fragile. It is optimised for that person's mental model. When the problem domain evolves in ways that require different intuitions, the architecture does not adapt well.

Retention - excellent engineers who want to grow their own technical judgement leave organisations where they are not given the space to do it. The engineers who stay are those who are comfortable being directed.

The holiday test - the clearest diagnostic: what happens to the team's decision quality when you are on leave for two weeks? If the answer is "it degrades significantly," you have built a dependency, not a team.

Stepping Back

The practical moves for dismantling the expert trap:

Ask before you answer. When someone brings you a problem, before you engage with the technical content, ask: "What have you already considered? What options do you see?" Make it a genuine question. You might learn something. At minimum, you shift the starting point of the conversation from you having an answer to them developing one.

Let decisions be made without you. Identify technical decisions that are being escalated to you that should not be. Explicitly give the decision back. "This is your call - I trust your judgement and I'd like to see you make it." Then live with the decision, even if it is not what you would have chosen.

Make your reasoning visible. When you do give a technical direction, make the reasoning explicit rather than just the conclusion. "I'd go with approach A because the consistency constraint here matters more to me than the performance gain from B - do you see it differently?" This teaches the reasoning, not just the answer.

Create structures that do not need you. Architecture decision records, documented standards, design principles that the team wrote together - these are the mechanisms through which your technical judgement becomes distributed rather than centralised in you.

Seagull Management

The seagull manager is absent most of the time, flies in at moments of high visibility, makes a lot of noise, creates a mess, and flies out again. The team is left to clean up what the intervention created.

This pattern appears in leaders who are significantly removed from the day-to-day work - often senior leaders with multiple reports or broad portfolios - but it also appears in managers who are absorbed by meetings and stakeholder management and appear to the team only in crisis.

What It Looks Like in Practice

A team has been working through a complex migration for two months. They have made considered trade-offs, built confidence in their approach, and are mid-execution. A senior leader attends one sprint demo, hears one aspect of the approach, and asks "have you considered just doing X?" - where X is an alternative the team considered and rejected six weeks ago for good reasons.

Now the team has to:

• Explain their reasoning to someone who did not participate in developing it
• Navigate whether this is a direction change or a question
• Manage the political uncertainty of disagreeing with seniority
• Handle the disruption to their own confidence in the approach

The leader flies out, feeling like they have added value. The team spends two days in uncertainty.

The Signal It Sends

Seagull management sends the following signals to a team:

• Our work is not well understood by people above us.
• Our decisions can be overturned by someone who has not been involved.
• Building alignment upward is as important as making good decisions.
• We should protect ourselves from visibility rather than seeking it.

None of these are the signals you want to be sending. They produce defensive behaviour, sandbagging, and a reduction in the transparency that good leadership depends on.

The Fix

The fix is not reducing feedback - it is providing feedback through a relationship rather than through episodic interventions. Leaders who are close enough to understand context before they challenge it can challenge effectively. Leaders who are not close enough should ask before they comment: "Help me understand the context before I react to this."

If you are the seagull, the question to ask is: am I creating more value with my intervention than the disruption it causes? In most cases, the honest answer is no.

The Brilliant Jerk

The brilliant jerk is the highest-output, most technically capable person on the team who is also corrosive to the environment around them. They interrupt. They dismiss other people's ideas without genuine engagement. They are condescending about what they consider mediocre work. They may be right more often than they are wrong technically. The team tolerates them because of their output.

This is one of the most consequential leadership failures because it is also one of the most visible. Every person on the team is watching what happens to the brilliant jerk.

What Tolerating One Signals

When a team sees that a person who exhibits genuinely disrespectful behaviour - dismissing ideas publicly, being condescending to less experienced engineers, treating process and communication as beneath them - faces no consequences, they update their model of what is acceptable.

The message received is: output is the only thing that actually matters here. If you produce enough, you can treat people however you want.

The second-order effects:

• Other high performers who have other options leave, because they do not want to work in an environment like this.
• Mid-level engineers stop proposing ideas, because they have seen what happens to ideas that do not pass the brilliant jerk's sniff test.
• Psychological safety is reduced for the whole team, not just the people the brilliant jerk targets.
• Other team members start adopting elements of the same behaviour, because the signal is that it is rewarded.

A single brilliant jerk, tolerated over time, can define the culture of a team more powerfully than any value statement or leadership principle.

Why Leaders Tolerate It

The toleration is almost always because the output is real and the leader does not want to lose it. The brilliant jerk gets things done. They may be genuinely difficult to replace. And the leader knows that addressing the behaviour will create conflict - possibly very loud conflict.

The calculation the leader is making - usually implicitly - is: the output I would lose by addressing this behaviour is worth more than the harm being done. This calculation is almost always wrong. The harm to the team's collective output, to retention, to psychological safety, and to the culture - is usually much larger than the leader can see from their position.

The Conversation You Have to Have

The conversation is not about performance. The output is not the problem. The conversation is: "Your impact on the team is not acceptable. The specific behaviours are X, Y, and Z. They need to change. The output you produce does not offset the cost of them, and if they do not change, the outcome for your role here is [specific consequence]."

This is a hard conversation. It is also not optional. The alternative is to signal to the entire team that this behaviour is fine, which is a choice with consequences that persist long after the brilliant jerk has moved on.

The Consensus Trap

The consensus-seeking leader values inclusion and wants people to feel genuine ownership over decisions. These are good values. The anti-pattern emerges when the commitment to consensus becomes so absolute that it is impossible to reach a decision without everyone's agreement - and the pursuit of universal agreement becomes the mechanism through which the leader avoids accountability.

What It Looks Like

• Decisions that involve ten people when five people have the relevant knowledge
• Decisions that are deferred until the next meeting, then the next, waiting for someone in the room to agree
• Decisions that are nominally made but that any single team member can effectively veto by expressing discomfort
• Post-decision revision when someone who was not in the room objects to the conclusion

The leader who says "I want everyone to be aligned on this" is often saying "I want the decision to be distributed enough that if it goes wrong, it is not clearly my fault."

The Cost of the Consensus Trap

Speed - consensus-based decisions are slow. Every decision requires the agreement of everyone, which means every decision requires managing the slowest person to agreement. In a fast-moving technical environment, this is debilitating.

Quality - the decision that everyone agrees with is often not the best decision - it is the most palatable one. Hard trade-offs get softened. Uncomfortable options get removed. The consensus that emerges from a room often reflects what people can agree on, not what would actually work best.

Accountability - when everyone is responsible, nobody is. The consensus decision, if it fails, belongs to the group. Nobody learns from it. Nobody is accountable for improving next time. The diffusion of accountability is a diffusion of learning.

Team culture - teams that learn that any member can veto a decision by objecting learn to use that power. The group dynamic shifts from "how do we decide?" to "how do we each protect our position?" This is corrosive.

Genuine Inclusion vs Accountability Avoidance

The distinction is important because genuine inclusion - bringing the right people into a decision, consulting those affected, giving people a real chance to influence the outcome before it is made - is valuable. The test is not "did everyone have input?" but "was the input used to make a better decision, or was the consultation performative, and was the decision maker willing to make the call when input was complete?"

Real inclusion requires a clear decision-maker. The leader consults, considers, and then decides. If the decision is wrong, they are accountable for improving it. This is different from a process where consultation never ends because the decision-maker is not willing to be accountable.

Heroic Leadership

The heroic leader is the most important person in every incident, every critical project, every difficult stakeholder conversation. They are the person who saves the day. They are also the person who has systematically prevented anyone else from being capable of saving the day.

What Heroic Leadership Looks Like

• In incidents, the leader is paged in and takes over. Everyone else assists them.
• In critical deliveries, the leader is coding or directing the critical path.
• In escalations, the leader handles the stakeholder conversation because nobody else is trusted to do it.
• In architecture decisions, the leader's view is the deciding one.

This is not malicious. It often comes from genuine capability - the leader is very good, and their involvement genuinely does improve outcomes. The problem is the systemic effect.

What It Costs

The heroic leader is solving individual instances of problems without building the system that prevents the problems. Every time they save the day in an incident, the team does not develop incident response capability. Every time they handle the difficult stakeholder conversation, nobody else builds that skill. The organisation becomes more capable at getting the leader involved, not more capable at solving the underlying problems.

The test: is the same class of problem recurring? If the leader has handled the same type of incident, the same type of stakeholder crisis, the same type of architecture breakdown multiple times - they are fixing instances, not addressing causes.

Long-term cost: The heroic leader's team does not develop resilience. When the leader is not available - through promotion, departure, illness, or leave - the team is exposed. The heroic leader creates the conditions for the next crisis by ensuring the team never built the capability to prevent it.

Shifting from Hero to Coach

The shift from heroic to systemic leadership is the same shift described in the coaching section, but applied to crisis contexts. Instead of jumping in during incidents, the leader asks: "What do you think the diagnosis is? What options do you see?" - and provides a safety net without removing the learning opportunity.

This requires being willing to watch a situation take longer to resolve than it would have if you had jumped in. That is the cost of building capability. It is almost always worth it.

The Absentee Empowerer

The absentee empowerer gives people autonomy without context, authority without support, and freedom without feedback. They call it delegation. Their team calls it abandonment.

What It Looks Like

• Engineers are told they have full ownership of a domain but are never given the context to make strategic decisions within it.
• "I trust you to figure it out" is the response to requests for direction.
• Feedback is rare - either because the leader is not paying attention or because they believe that giving feedback undermines autonomy.
• Problems surface late because nobody is checking in enough to notice them.
• The leader is surprised by incidents and delivery failures, because they had no visibility into the signals that preceded them.

The Difference Between Autonomy and Abandonment

Genuine autonomy requires:

• Context - the person needs to understand the goals, constraints, and strategic direction to make good autonomous decisions.
• Authority - real authority to make decisions, not authority that gets overridden when the leader does not like the outcome.
• Access - availability to the leader when the person genuinely needs input or escalation.
• Feedback - honest, regular feedback on whether the autonomous decisions are working.

Abandonment removes the support while maintaining the language of empowerment. "I trust you" is the cover for "I am not engaged enough to help." The person is nominally in charge and genuinely on their own.

How to Diagnose Whether You Are Empowering or Abandoning

Ask the people you believe you are empowering:

• Do you have enough context to make the decisions your role requires?
• When you are uncertain, is it easy to access support?
• Do you get useful feedback on the decisions you make?
• Do you feel set up to succeed, or do you feel like you are working without a net?

The answers tell you more than your own assessment of your leadership style.

How to Diagnose Your Own Anti-Patterns

Questions to Ask Yourself

These questions are most useful when answered honestly rather than aspirationally:

• What does the team do when I am not available? (Capability, independence, or paralysis?)
• When was the last time a team member overruled my technical view? (Is it even possible for that to happen?)
• When I think I am coaching, could someone observing the conversation see me delivering answers in question form?
• What happens when someone brings me bad news? What does my response actually look like?
• Which decisions on my team required my involvement that probably should not have?
• Are there people on my team whose career growth has stalled? What role have I played in that?
• If three of my team members described my leadership style to someone else, what would they say?

Signals From Your Team

The team's behaviour is the best diagnostic for leadership anti-patterns. Observable signals:

Using Feedback

The most reliable route to surfacing anti-patterns is direct feedback from people who observe your leadership. This requires asking directly, responding non-defensively, and actually acting on what you hear.

"Is there anything about how I work with you that gets in your way?" is a real question. It needs to be asked in a context where the answer will be received as useful information, not as a criticism to be managed.

The leaders who grow most significantly are the ones who have built the relationships and the safety for their team to tell them the truth.

Connection to Your Operating Model

Anti-patterns are not individual failures. They are systemic problems - they shape the organisation around them, they compound over time, and they undermine the structural elements of the operating model that are designed to enable high performance.

An operating model built on team autonomy, distributed decision-making, and continuous improvement cannot function when:

• The leader retains all technical authority (expert trap)
• Decisions require full consensus before moving (consensus trap)
• Brilliant jerks define the cultural norms (brilliant jerk tolerance)
• Problems are solved at the leader level rather than systemically (heroic leadership)
• Teams have nominal autonomy without real support (absentee empowerer)

Each anti-pattern has a specific structural countermeasure:

The anti-pattern is the problem. The structural countermeasure makes it harder for the anti-pattern to establish itself, even under pressure. Neither is sufficient alone - you need both the behavioural change and the structural support.

Anti-Patterns Under Pressure

Most leadership anti-patterns are latent. They exist in mild form under normal conditions, and escalate under pressure. Understanding this is important because pressure is not exceptional - it is a normal condition of engineering leadership. Delivery pressure, resource constraints, organisational change, and ambiguity are the water, not the weather.

How Pressure Amplifies Anti-Patterns

Expert trap under pressure: When a deadline is approaching, the expert leader's instinct is to take over the technical critical path because it is faster than coaching the team through it. They are probably right in the immediate term. But the pattern reinforces itself - the team learns that under pressure, the leader steps in, so they stop investing in developing the capability to handle pressure themselves.

Seagull management under pressure: Senior leaders who are normally somewhat distant become more interventionist when business stakes are high. They start attending standups, questioning technical decisions, inserting their view into the critical path. This is the worst possible time for this behaviour - the team is already under strain, and the intervention adds uncertainty and second-guessing.

Consensus trap under pressure: The consensus-seeker becomes more consensus-seeking when the stakes are high and they are most anxious about being wrong. Decisions that should take a day take a week because the leader is unwilling to make a call before they have everyone's agreement.

Heroic leadership under pressure: The heroic leader becomes literally indispensable during crises. Every critical decision, every stakeholder conversation, every code review on the critical path runs through them. They work extremely long hours. The team, in the background, has stopped developing the capability to handle this without them.

Building Pressure Resistance Into Your Leadership

The question to ask is not "how do I manage my anti-patterns under pressure?" It is "what have I built that is resilient enough that my anti-patterns matter less under pressure?"

The practical answers:

• A team with real decision-making capability can absorb the expert trap under pressure because they have alternatives to the leader's involvement.
• Clear escalation criteria and documented context mean that seagull visits are less disruptive because the team can navigate them without losing confidence.
• Explicit decision rights and a single Approver per decision make the consensus trap less paralysing because the process does not depend on everyone agreeing.
• Distributed incident response capability means heroic leadership is less necessary because the team can handle crises.

The anti-pattern management work is mostly done before the pressure arrives.

Anti-Patterns and Their Impact on Diversity

Leadership anti-patterns have disproportionate impact on engineers from underrepresented groups. This is not accidental - it reflects the way power dynamics interact with leadership behaviour.

Expert Trap and Representation

When a leader defaults to solving problems themselves, they are most likely to have that habit reinforced by the engineers who are most similar to them - who communicate in familiar ways, who have similar technical backgrounds, whose thinking patterns the leader recognises as credible. Engineers from different backgrounds, communication styles, or experience profiles are less likely to be brought into the problem-solving conversation.

The result: the expert trap produces a development distribution that is uneven. The engineers who get coaching (even accidental coaching) are the ones the leader instinctively engages with. The others get direction.

Brilliant Jerk and Psychological Safety by Group

The brilliant jerk's behaviour is rarely equally distributed. Engineers who are most similar to the brilliant jerk are most likely to be treated as peers, even difficult ones. Engineers who are different - in seniority, background, gender, communication style - are more likely to be the targets of dismissiveness, condescension, or exclusion.

Tolerating a brilliant jerk therefore has uneven psychological safety consequences across the team. The signal that "output overrides behaviour" is received by everyone, but the cost of the behaviour falls most heavily on specific subgroups.

Seagull Management and Who Is Visible

Seagull management is driven by visibility - the leader engages most with the work that is most visible to them. In engineering teams, visibility is not evenly distributed. Engineers who are in the room when senior leaders visit, who present work at demos, who are on the team roster the senior leader knows - these are the ones who receive seagull attention, positive and negative.

Engineers who are doing excellent work in less visible areas are often neither helped nor harmed by the seagull. But they are also not sponsored, not mentored, not considered for the opportunities the seagull is in a position to create.

The Structural Correction

Addressing the uneven impact of anti-patterns requires making the anti-patterns visible - specifically identifying where their effects are falling - rather than treating the impact as an equity issue separate from leadership behaviour. The leadership behaviour is the equity issue.

The questions to ask:

• Across the anti-patterns I have recognised in my own leadership, whose development is most affected?
• Who am I least likely to coach, and why?
• Whose work is least visible to me, and what could I do to change that?

Getting Feedback on Your Anti-Patterns

The section on diagnosis earlier covered questions to ask yourself. This section is about the harder work of getting honest external feedback, because self-diagnosis of anti-patterns has a fundamental limitation: the same blind spots that create the anti-pattern make it hard to see.

Creating the Conditions for Honest Feedback

The single biggest barrier to receiving honest feedback as a leader is that the social dynamics make honest feedback costly for the giver. People do not tell leaders their anti-patterns because the consequences of doing so are uncertain and the benefits primarily flow to someone else.

The conditions that make honest feedback more likely:

• You have asked specifically (not just "any feedback?")
• You have responded non-defensively to previous feedback
• You have been visibly changed by previous feedback (so the act of giving it has some payoff)
• The conversation is private and there is trust that what is said stays between you

None of these conditions can be created quickly. They are the product of a relationship built over time.

360 Feedback - When It Works and When It Does Not

Formal 360 feedback processes can surface anti-patterns, but only if they are designed and used in ways that make honest responses safe and useful.

360 processes that work:

• Are anonymous and the anonymity is credible
• Are specific about behaviours, not general about character
• Are followed by visible action from the leader
• Are run by someone the respondents trust to handle the data carefully

360 processes that do not work:

• Are run by the leader's own manager in ways that do not feel genuinely confidential
• Ask questions so general that the responses are not actionable
• Produce a report that the leader thanks everyone for and then does not act on
• Are a one-time event rather than a regular rhythm

The most useful feedback is not the aggregate score from a 360 - it is the qualitative comments, specific and detailed, that describe actual behaviour. Those are the data points to act on.

The Coaching Relationship as a Feedback Channel

An external coach - someone with no stake in the leader's organisation and no relationship with their team - can be an effective feedback channel because the coaching relationship creates a space where the leader can be more honest about their own behaviour than they can be with their own organisation.

A good coaching relationship for a senior engineering leader:

• Provides a thinking partner for difficult situations without the political constraints of internal relationships
• Surfaces patterns across many conversations that the leader might not see in individual instances
• Challenges the leader's interpretation of events without the risk that comes from internal challenge
• Holds the leader accountable to commitments they have made between sessions

This is not a luxury. For senior leaders who receive limited honest feedback from their organisations, an external coach is one of the few reliable sources of accurate data about their own behaviour.