Article
Specialty != Right
A reflection on engineering autonomy, accountability, and how AI is changing who can participate in technical conversations.
I have found myself reading more and more discussions lately about operations, governance, and accountability within software engineering.
Predictably, they almost always end the same way.
Engineers push back.
Operations pushes back.
Leadership gets caught somewhere in the middle.
Everyone leaves convinced they were the reasonable one.
At first, I thought this was simply another disagreement between people with different priorities.
I’m not so sure anymore.
Software engineering has occupied a unique place for a very long time.
Not because we demanded it.
Because software was difficult enough that very few people outside the profession could meaningfully participate in the conversation.
When an engineer said, “this is the way it needs to be,” there were often very few people equipped to challenge that statement. Sometimes that was because the engineer was right. Other times it was simply because no one else possessed enough technical context to ask a better question.
That isn’t arrogance.
It’s just where software engineering found itself.
I don’t think any of us believed that would last forever.
I think we were simply naive enough to believe there would never come a day when that distinction actually mattered.
I believe that day has arrived.
AI has done something fascinating.
It hasn’t made everyone a software engineer.
It hasn’t eliminated the need for engineering expertise.
But it has dramatically lowered the barrier to participating in technical conversations.
People who previously had no meaningful way of exploring an architecture, asking questions about an implementation, or challenging a technical assumption suddenly have one.
Not because AI is replacing engineers.
Because AI has become an interpreter.
That changes the conversation.
For years we’ve celebrated engineering autonomy.
In many ways, we should have.
Software has always resisted rigid process. Every project is different. Every business is different. Every set of constraints is different. One of the strengths of good engineers has always been their ability to navigate uncertainty rather than pretend it doesn’t exist.
But somewhere along the way, I wonder if we quietly allowed engineering autonomy and engineering authority to become the same thing.
I don’t think they are.
One of the things I love most about software engineering is that we challenge assumptions.
We challenge architecture.
We challenge frameworks.
We challenge processes.
We challenge each other.
Why, then, would we assume that our own position within an organization should be immune from the very kind of scrutiny we encourage everywhere else?
This isn’t an argument against engineering.
Quite the opposite.
I think software engineering is becoming more important than it has ever been.
Which is exactly why I believe accountability should become more important too.
Not because engineers are less trustworthy.
Because the systems we build matter more than they used to.
I don’t think operations should dictate engineering.
I don’t think engineers should dictate operations.
I think we’re entering an era where neither discipline gets to operate as though it alone possesses the complete picture.
That feels less like a loss of authority and more like the natural maturation of software engineering as a profession.
Perhaps the greatest strength of our profession has never been that we always have the right answers.
Perhaps it has been our willingness to question assumptions until we arrive at better ones.
If that’s true, then maybe the next assumption we should be willing to question is our own.