There's a specific kind of meeting that engineers learn to dread.
Not the ones where things are going wrong - those are expected, they're manageable, they're part of the job. The ones I mean are the meetings where things are clearly going wrong, someone in the room says exactly what needs to be said, and nothing changes. The concern is heard, noted, and set aside. The decision was already made before anyone walked in.
I've been in that meeting. I've raised the right concern, watched it land, watched it get dismissed, and then watched the person who dismissed it repeat it back minutes later as their own reasoning for doing the opposite. And I've sat with the quiet frustration of knowing that the DevOps engineer in the same meeting saw it too, agreed, and was overruled just the same.
What do you do with that?
For a while, you keep trying. You document. You find better ways to make the case. You hope that the evidence will eventually be loud enough that it can't be ignored. Sometimes it works. Often it doesn't. And in the case I'm describing, the evidence eventually got very loud indeed — in the form of a system that stopped working and costs that had climbed well past what anyone wanted to admit.
That's what this post is about. Not just bad technical decisions, but the leadership dynamic that makes them inevitable.
The Lead Who Couldn't Be Wrong
There's a particular failure mode in technical leadership that's hard to name without sounding like you're just complaining about someone you didn't like. So let me try to be precise about what I mean.
The lead I'm describing wasn't incompetent in the conventional sense. He could talk about architecture. He had opinions. He made decisions. What he couldn't do, or wouldn't do was hold those decisions lightly. Couldn't entertain the possibility that a call made three months ago might need revisiting now that the system had taught us something new. Couldn't hear a concern from his team without experiencing it as a challenge to his authority.
At one point, I asked him directly to walk me through the reasoning behind a particular technical decision. His response was that I couldn't question those decisions.
Not that the reasoning was complex. Not that it was documented elsewhere. Not that this wasn't the right time. Just: you can't question this.
That's not technical leadership. That's positional authority dressed up as technical leadership. And the difference matters enormously, because one of them makes systems better and one of them makes systems fragile.
Ego Is an Architectural Decision
Here's something that took me a while to articulate: the way a lead responds to being challenged is itself an architectural input.
When a lead creates an environment where concerns can't be raised, what they're actually doing is removing a feedback loop from the system. And feedback loops, the ability to sense when something isn't working and correct for it, are not optional features in complex systems. They're load-bearing. Take them out and the system becomes brittle. It can hold together for a while on momentum and good fortune, but it loses the ability to adapt. And systems that can't adapt don't survive contact with reality for very long.
This is what I mean when I say ego is an architectural decision. Every time a lead shuts down a question, dismisses a concern, or makes themselves the single point through which all technical truth must pass, they're making a choice about how information flows through the team. They're deciding, in effect, that their own judgment is more reliable than the collective intelligence of the people closest to the work.
Sometimes that's true. Mostly it isn't. And the cost of being wrong about it isn't just a bad meeting — it's a system designed around blind spots.
What Good Actually Looks Like
I want to be careful here not to paint a picture where the lesson is simply "be humble", because humility without substance is just another kind of performance.
What I've seen work, in the teams and leads worth learning from, looks more like this:
They separate the decision from the ego. A good lead can say "I made that call, the evidence now suggests it was wrong, let's revisit it" without experiencing it as a personal collapse. The decision was wrong. They're not. They know what they don't know. The DevOps engineer in that meeting understood the infrastructure constraints at a level the lead didn't. A good lead uses that. They don't override it.
They stay close to the problem. The further a lead gets from the actual work, the code, the errors, the logs, the cost reports, the more they start making decisions based on the architecture in their head rather than the system in production. These two things diverge faster than most people expect.
They treat questions as information. When an engineer asks why a decision was made, that's not insubordination. That's someone trying to understand the system well enough to work in it effectively. The right response is an explanation, not a shutdown.
None of this is complicated in theory. In practice, it requires something that's genuinely difficult: the ability to hold authority and uncertainty at the same time. To be the person responsible for the direction without needing to be the person who is always right.
For the Engineers in the Room
If you're not the lead, if you're the one raising the concern and watching it go nowhere, this part is for you.
Document everything. Not out of paranoia, but because clear written records of what was raised, when, and what the response was serve everyone when the reckoning eventually comes. And it usually comes.
Find your allies. In the situation I described, I wasn't alone in that meeting. The DevOps engineer saw the same thing I saw. That matters, not because two voices are always louder than one, but because it confirms your read on the situation and keeps you grounded when the environment starts making you doubt yourself.
Know when you've done what you can. There's a point where you've made the case as clearly as it can be made, through every appropriate channel, and the decision still isn't changing. Recognising that point, and deciding what to do with it, is one of the harder professional skills to develop. Staying indefinitely in a situation where good work goes nowhere and good judgment gets overridden has a cost that tends to show up slowly and then all at once.
And write it down. Not just for the legal record, though that matters too. Write it down because experiences like these are genuinely instructive, and the detail fades faster than you expect. The clearer you can be about what happened, what you tried, and what the outcome was, the more useful it becomes to you, and eventually to others.
The Thing About Systems
Systems tend to reflect the people who build them. Not always in obvious ways, but the assumptions, the blind spots, the things that were never questioned, they end up embedded in the architecture. In the choice of tools, in the way services talk to each other, in the decisions that were made once and never revisited.
A system built by someone who couldn't be questioned will have unquestioned assumptions running through it. And those assumptions are fine until the moment they aren't, at which point they're very expensive to find and very difficult to remove.
This is why the human side of technical work isn't a soft topic. It's not the optional extra you get to once the real engineering is done. It is engineering. The way a team communicates, challenges each other, surfaces concerns, and makes decisions together — that's part of the system. It shows up in the output.
The lead who shut down questions didn't just create a difficult work environment. He created a fragile system. Those two things were the same decision, made over and over, in meeting after meeting, until the system ran out of room to absorb the cost.
Part 1: Serverless Is Not a Silver Bullet — Understanding What Lambdas Are Actually For
Part 2: Microservices Doesn't Mean Lambda Everything
Part 3: When the Lead is the Bottleneck
This series started with a technical post about Lambda functions. It was always going to end here — because the technical decisions and the human ones were never really separate.
Top comments (0)