You'll Be Fired

An empty leadership chair overlooking a football pitch beside a strategy board

Why engineering leaders need a philosophy before the system chooses them as the problem

The room is quiet because everyone already knows what is about to happen. The chairman has the statement prepared, the communications team has a quote ready, and the assistant coaches have heard enough whispers to stop pretending this is just another difficult week.

The players have not been told yet, but some of them have guessed. Results have been poor. The team looks nervous, the press is disorganized, the forwards are isolated, and the defenders keep making the same mistakes. The supporters are angry. The journalists are circling. So the club does what clubs do: it fires the manager.

Not the striker who missed the chances. Not the defender who lost his man. Not the midfielder who gave the ball away under pressure.

The manager did not touch the ball once, but he is the cleanest person to remove. By morning, the club has a new story. The squad still has quality. The season can still be saved. The players need a fresh voice. The club thanks him for his service and wishes him well. Training continues, and the brutal economy of leadership reveals itself:

when the system fails, leadership becomes the easiest thing to change.

Engineering leaders should pay attention because companies do this too. When delivery slows, quality drops, deadlines become fiction, morale thins out, and senior leadership starts asking why a team full of smart people keeps missing important outcomes, they rarely begin by replacing the whole team. That is too expensive, too disruptive, and too difficult to explain. So they look for the cleaner answer: the Engineering Manager, the Director, the VP.

Replacing the leader gives the organization a story:

“The team has potential. We just need different leadership.”

Sometimes that story is cowardice. Sometimes it is true. The hard part is that, from the outside, both versions can look exactly the same.

The Safe Bet

In sports, firing the manager is often the safest visible action. It signals urgency without forcing the club to admit more uncomfortable things: maybe recruitment was poor, maybe the squad was imbalanced, maybe ownership was confused, maybe the strategy was never coherent, or maybe there was never a real footballing philosophy in the first place. Those are harder to fix. The manager is simpler.

Bad squad planning? Fire the manager. No identity? Fire the manager. Players underperforming? Fire the manager. Fans angry? Fire the manager.

It is not always rational, but it creates motion. It gives everyone the feeling that something decisive has happened, and organizations love that feeling. Engineering organizations are no different. A team may be drowning in unclear priorities, unstable product direction, legacy architecture, weak staffing, brittle systems, and a roadmap built from executive anxiety. Then one day, someone asks:

“Why is this team not performing?”

The truthful answer may be complicated. The convenient answer is not: “The manager is not strong enough.” And here is the uncomfortable part: sometimes they are right.

Not because the manager caused every problem. Not because the manager personally created the legacy system. Not because the manager changed the roadmap six times. Not because the manager wrote the bad code, missed the edge case, or broke production.

But because leadership is not only responsible for the work. Leadership is responsible for the conditions around the work. That is the job, and that is why you can be held accountable for problems you did not personally create.

The Manager Without a Philosophy

Many engineering leaders are not fired because they are obviously incompetent. They are fired because nobody can tell what they actually believe. Not in the abstract, because everyone believes in ownership, quality, collaboration, business impact, psychological safety, and moving fast until those ideas start competing with each other. The real question is what you believe when there is pressure.

What happens when Product wants the date but Engineering does not believe the scope?

What happens when a senior engineer is brilliant but corrosive?

What happens when the team keeps almost hitting commitments?

What happens when quality is slipping, but the business is desperate for speed?

What happens when an executive wants a simple answer and the truth is not simple?

This is where philosophy stops being decorative. A manager without a philosophy becomes a weather vane.

When Product pushes, they say yes. When Engineering complains, they sympathize. When executives escalate, they panic. When delivery slips, they narrate. When quality suffers, they ask for “more ownership.” When morale drops, they schedule a retro.

I am not mocking retros. Retros are useful, but a retro is not a substitute for leadership. After a while, everything becomes reactive and nothing compounds. The team cannot tell what the leader stands for under pressure.

That is dangerous because leadership is not just coordination. Calendars can coordinate. Process can coordinate. Leadership is interpretation.

Your team is always asking questions, even when nobody says them out loud:

What matters here? What gets rewarded? What gets punished? What are we allowed to challenge? What kind of excellence is expected? What kind of dysfunction will be excused? What happens when speed and quality collide? What happens when the loudest stakeholder is wrong?

If you do not answer those questions deliberately, the system will answer them accidentally, and accidental culture is usually just the loudest incentive winning. This is how teams drift, not dramatically, but quietly.

A missed deadline becomes normal. A rushed release becomes normal. A vague requirement becomes normal. A production incident with no real follow-up becomes normal. A senior engineer rescuing everything becomes normal.

Then one day, the team is not just underperforming. The team has become its habits, and the leader is surprised that everyone else can see it.

You May Be the System

Weak football managers blame the players: “They didn’t execute the plan,” “They lacked intensity,” “They made individual mistakes,” “They need to take responsibility.” Maybe all true. But after a while, the question changes.

Why do they keep making the same mistakes?

Why does the team look confused in transition?

Why does confidence collapse after one setback?

Why do good players look ordinary here?

Engineering managers fall into the same trap: “The engineers need more ownership,” “The team needs to move faster,” “They are not proactive enough,” “They don’t communicate well,” “They depend on me too much.” Again, maybe true. But if the same patterns keep repeating, the leader has to stop diagnosing the team as if they are standing outside it. You are not outside the system. You are inside it. More painfully:

you may be the system.

Performance is not just a sum of individual talent.

Performance = f(talent, clarity, standards, trust, constraints, leadership)

If leadership shapes the function, leadership cannot pretend to be outside the result.

If engineers lack ownership, what decisions have they actually been trusted to own?

If the team moves slowly, what constraints have you allowed to remain unnamed?

If communication is poor, what operating rhythm is unclear?

If quality is low, what does the team believe leadership truly values when deadlines get tight?

If people depend on you too much, what have you kept centralized because it made you feel useful?

If the team cannot say no, where have you failed to model tradeoffs?

That last one matters. A lot of teams are not weak. They have simply learned that saying no is punished, saying yes is rewarded, and raising risk too loudly makes you look negative. So they become polite, then quiet, then late, and eventually someone calls them low ownership.

At some point, “my team is not stepping up” becomes less of a diagnosis and more of a confession. Not always, but often enough to make a serious leader uncomfortable.

The Engineering Version

Here is how it usually happens. A team commits to a launch. The date was always aggressive, but nobody wants to be the person slowing momentum. Product needs it, Sales has started hinting at it, and Leadership wants a win. The engineers raise concerns, but softly. The manager hears them, but translates the risk upward in softer language.

“Some complexity, but manageable.”

“Some dependency risk, but we are tracking it.”

“We may need to watch scope.”

None of that is technically false, but it is not clear enough to force a decision.

The architecture has weak seams. The dependency on another team is unresolved. The test coverage is thinner than anyone wants to admit. The scope keeps expanding in small, reasonable ways.

Nothing looks reckless in isolation: one extra integration, one extra workflow, one exception for an important customer, one shortcut to preserve the date, one “we’ll clean this up after launch.”

Then launch week arrives. The team is tired. The demo environment behaves differently from production. A senior engineer becomes the human load-bearing wall. QA finds issues late. Product is frustrated. Leadership is surprised. The manager is now in meetings explaining what happened, and the explanation is accurate: the team had dependencies, the scope changed, the system was more complex than expected, the estimates were uncertain, and the risks were real.

But somewhere in the room, a more dangerous question appears:

“Why are we only hearing this clearly now?”

That question changes the temperature. I have seen teams miss dates for technical reasons, but lose trust for communication reasons. The issue is not only that the launch slipped. The issue is that the organization no longer trusts the leader’s read of reality. That is when the title starts to weaken.

Philosophy Is Not Decoration

The answer is not to become paranoid. The answer is to know what you believe before pressure tests you. Not a motivational poster, not “servant leadership,” not “high ownership,” and not “move fast.” Those phrases can mean anything. A real philosophy has edges.

Something like:

“I build teams that make reality visible early, convert pressure into explicit tradeoffs, protect technical standards where they affect future speed, and grow people through ownership with feedback.”

You may word yours differently. You should. It should sound like you, not like a company value statement. The point is that people should know what to expect from your leadership. The team should know what gets rewarded, Product should know how to partner with you, executives should know how you think, and you should know how to make decisions when the room gets tense.

Under pressure, leaders do not rise to their LinkedIn bio. They fall to their habits, and those habits are built in ordinary moments: the planning session where you accepted a date without naming the tradeoffs, the incident review where you allowed the team to move on too quickly, the one-on-one where you softened feedback until it became useless, the architecture discussion where you knew the shortcut would become expensive but stayed quiet, the executive update where you made the project sound healthier than it was.

These are not small moments. They are rehearsals, and the team is learning what leadership means here.

What Strong Leaders Practice

Strong leaders make reality visible early. They surface risk while it is still useful. They do not catastrophize, dramatize, or throw engineers under the bus, but they refuse to let optimism become theatre.

A good update is not:

“We are on track.”

Not when everyone privately knows the team is drowning.

A better update is:

“We can still hit the date, but only if we cut scope, resolve this dependency by Friday, and accept this known limitation. Otherwise, the honest date is two weeks later.”

That is leadership, not because it is pleasant, but because it gives the organization a decision while there is still time to make one.

Strong leaders also convert pressure into tradeoffs. Pressure is inevitable. Raw pressure passed downward becomes chaos. The leader’s job is to translate pressure into choices.

Do we want speed or completeness?

Do we want this customer commitment or this platform investment?

Do we want the launch date or the full scope?

Do we want short-term revenue or long-term maintainability?

Many managers think they are being helpful by absorbing pressure quietly. Usually they are just delaying the explosion. Your job is not to make tradeoffs disappear. Your job is to make them visible enough that adults can make decisions.

Strong leaders build systems instead of heroics. If delivery depends on your constant intervention, you do not have a high-performing team. You have a manually operated machine.

Heroic managers feel useful because everything passes through them. They unblock every decision, rewrite every update, mediate every conflict, catch every dropped ball, and rescue every project. Then they call the team immature.

But sometimes the team is simply living inside a system where the manager has made themselves the only reliable interface.

Strong leaders build the boring machinery: cadence, decision rights, escalation paths, technical review habits, incident follow-through, planning discipline, feedback loops.

Boring, yes. But repeatability is the difference between a good month and a good organization.

Strong leaders also protect standards without hiding behind the team. There is a weak version of empathy that slowly destroys teams.

It avoids hard feedback. It tolerates missed commitments. It explains away low ownership. It allows senior people to behave like talented exceptions. It calls every conflict a communication issue.

It protects people from discomfort but not from decline.

Strong leaders do not confuse kindness with softness. They give credit down and take accountability up, but they also tell the truth privately. They coach. They clarify. They confront. They raise the bar. They do not use the team as a shield, and they do not use accountability as a weapon.

They understand that standards are not the opposite of care. Standards are one of the forms care takes when the work matters.

The Real Job Is Not Control

Early managers often think the job is to keep things under control. Eventually, you learn the harder truth: control does not scale.

Clarity does. Judgment does. Trust does. Standards do. A team that understands the business does. A culture where people can say hard things early does.

The manager’s job is not to touch every ball. It is to make the team better when the game becomes chaotic, because chaos will come.

A critical incident. A missed launch. A senior engineer leaving. A product pivot. A reorg. A bad quarter. A stakeholder who wants everything yesterday. A team that has stopped believing.

That is when leadership is revealed. Not during the polished all-hands update, not during the promotion packet, and not during the roadmap kickoff. Leadership is revealed when the plan stops working.

The football manager standing on the touchline knows this. The match turns. The crowd shifts. The players start looking over. The assistant coach asks whether to change shape.

In that moment, the manager cannot say:

“The players should know what to do.”

Maybe they should. It is still insufficient. The job was to prepare them before the moment, guide them inside the moment, and learn from the moment after it passed.

Engineering leadership is the same. You do not get to say:

“They should have known.”

You have to ask:

Did we make it knowable?

Why Leaders Really Get Fired

Engineering leaders get fired for many reasons: politics, poor fit, bad timing, executive impatience, company dysfunction, a new leader wanting their own people, or a strategy shift nobody admitted early enough. Sometimes the firing is not a verdict on the person. Sometimes it is just the organization choosing the cleanest move available.

But the firings that hurt most are the preventable ones, where the leader became a narrator of dysfunction instead of an architect of improvement.

They could explain every problem.

They could name every constraint.

They could describe every dependency.

They could tell you exactly why the team was struggling.

But they could not change the trajectory. That is the line.

Organizations will tolerate problems longer than people think when they believe the leader has a credible grip on reality and a believable path forward. But when a leader can only report the weather, eventually someone looks for a new pilot.

This is why philosophy matters, not because it sounds intellectual, but because under pressure, your philosophy becomes your reflex. If your philosophy is unclear, your reflex will be fear.

You will overcommit to please executives. You will hide tradeoffs to avoid conflict. You will rescue work instead of growing people. You will tolerate low standards because confrontation is expensive. You will call chaos “collaboration.” You will call burnout “urgency.” You will call ambiguity “startup speed.” You will call lack of strategy “being agile.”

And then one day, someone will say the team needs different leadership. Maybe they will be wrong, but they may not be surprised.

The Landing

So yes, you might be fired. Not because you are bad, not because you failed alone, and not because leadership is fair. You might be fired because when outcomes collapse, leaders become the cleanest story an organization can tell itself.

The question is not whether that is fair. The question is whether you are leading in a way that makes replacing you a lazy answer.

Build a team with clarity.

Build a team with standards.

Build a team that can tell the truth early.

Build a team that understands the business.

Build a team that can operate without your constant rescue.

Build a team where ownership is not a slogan but a practiced muscle.

And above all, build from a philosophy, because when the organization starts looking for the simplest thing to change, your title will not protect you. Your effort will not protect you. Your intentions will not protect you. Only your operating system has a chance.

The match is already in progress. The board is watching. The team is looking over.

What exactly do you believe?