A salary rewards your employment. It doesn't validate your judgment. Somewhere along the way, plenty of organizations let those two things blur together — as long as you show up, say the right things in the meeting, and don't rock the boat, the paycheck keeps clearing, and it's easy to mistake that for professional competence. It isn't. If your only objective is making it to the end of the month without questioning anything, that's a choice you're entitled to make. What you don't get to do is call that engineering.
Engineering demands curiosity. It demands evidence. It demands a willingness to challenge an assumption, including your own. Nodding through a decision you know is wrong because disagreeing would be politically inconvenient isn't protecting the business. It's protecting your own comfort, and dressing it up as loyalty.
The most dangerous person on an engineering team usually isn't the junior developer willing to say "I don't know." It's the experienced one who's forgotten how to. Rejecting ideas without evidence, defending decisions they can't actually explain, hiding behind a title or "that's how we've always done it" instead of engaging with a real question — that's not seniority doing its job. Organizational theorist Chris Argyris spent decades studying exactly this pattern and gave it an uncomfortably accurate name: skilled incompetence — people who are highly practiced at protecting themselves from embarrassment, and whose skill at doing so is precisely what makes them unable to learn or change. It's not a lack of ability. It's a well-rehearsed defense that happens to produce bad decisions as a side effect, over and over, without the person doing it ever quite noticing.
There's nothing impressive about advancing because you controlled information, made a colleague look worse than they were, blocked a better idea because it wasn't yours, or stayed quiet when you knew a call was wrong. That's office politics wearing engineering's clothes. If your career moves forward because better engineers got pushed aside along the way, the promotion is telling you something about the organization's incentives. It's not telling you anything about your ability.
If shipping a routine change requires three calls, four approval meetings, twenty people watching a deploy, and an hour spent deciding who clicks the button, that's not a deployment process. That's organizational dysfunction wearing a process's clothes. A mature engineering organization automates the repeatable parts of shipping software; it doesn't schedule recurring meetings around them. This isn't an abstract preference — it's measurable. The DORA research behind Accelerate, one of the most cited studies of software delivery performance, consistently finds that elite-performing teams deploy on demand, often multiple times a day with lead times measured in hours, while low performers are stuck deploying once every month or two — and the gap between those two groups isn't talent. It's automation, small batch sizes, and the absence of exactly the kind of manual ceremony that turns a five-minute deploy into an hour of scheduling. Every recurring deployment meeting should trigger the same question: why isn't this automated yet?
Engineering isn't decided by whoever talks longest, whoever has the biggest title, or whoever leads with "I've been doing this for twenty years." Show the evidence. Show the measurements. Show the trade-offs and the production data. Engineering respects facts. Egos demand applause, and a team that's stopped being able to tell the difference between the two has usually stopped being able to catch its own mistakes before they ship.
If someone shows you a better idea, take it. If someone finds a real flaw in your design, thank them for finding it before production did. If the evidence says you were wrong, change your mind — that's what a professional does with new information, not a threat to their standing. Software doesn't care about your ego. Production doesn't care about your title. The people using what you build only care whether it works, and every hour spent defending a decision purely to avoid admitting it was wrong is an hour not spent making the system better.
There's a version of this that's worth naming directly, because it's easy to tell yourself a story that sounds responsible on the surface: I just need this paycheck for my family, so I'll stop pushing, stop questioning, stop caring about whether the work is actually good. It feels like prioritizing what matters. It's usually the opposite. Disengaging from your own craft doesn't protect the people depending on you — it quietly erodes the thing your income actually depends on, which is your ability to do the job well enough that it keeps being yours. Caring about your family and caring about doing good work were never actually in competition; the trap isn't caring about family, it's mistaking coasting for security when the two rarely turn out to be the same thing. The engineer who keeps sharpening their judgment protects their family more reliably than the one who's decided thinking hard isn't worth the effort anymore, because the first one is the harder person to replace.
The engineers worth following are rarely the loudest in the room. They're the ones quietly removing unnecessary complexity, automating what shouldn't require a human, sharing what they know instead of hoarding it, and changing their minds the moment the evidence tells them to. Those engineers move the field forward. Everyone else is mostly just moving meeting invitations around.
If engineering, to you, means surviving the month without ever questioning anything, that's your decision to make. Just don't mistake passive participation for professional excellence — they're not the same thing, no matter how long either one has kept a paycheck coming. Engineering is built on evidence, accountability, and the willingness to keep learning, including from your own mistakes. The people who actually improve software are the ones willing to challenge a bad idea, even when it's theirs. The people who don't are usually the loudest defenders of whatever's already in place. Software has a way of exposing the difference eventually — it just doesn't always do it on a schedule you get to choose.
Why Writing Engineering Blogs Is Hard
Everything here is a report from where I'm standing, not an argument built to relocate you there. If you land somewhere different after actually thinking it through, that's not a miss — that's the point.
Stop Turning Deployments Into Board Meetings
A deployment call with a dozen stakeholders watching one engineer click deploy isn't engineering maturity. It's engineering anxiety, dressed up as process — and it's usually compensating for a rollback plan nobody trusts.