Responsibility and Authority

by Samir Talwar

Friday, 26 September 2025 at 13:00 CEST

Imagine, if you don’t mind, having to clean a kitchen, but someone else tells you if you’re allowed to use a sponge or not.

Imagine, now, being the person who has to decide who gets a sponge.

Both jobs are no fun, right? (Though the first one seems worse, IMO.)

So why is this normal in software development?

Ancient, or not-so-ancient, history

If you’re a programmer, you may not have to stretch your imagination very far to think of a time where someone with no skin in the game told you which programming language you had to use on a specific project. Or library, or framework, or database. (Nowadays, I hear managers are even telling techies that they must use a bullshit machine called an “LLM”, which I find absolutely baffling.)

And, well, historically… this made total sense. A software developer was not, back in the day, responsible for their software. They wrote the code, ensured it compiled, and, hopefully, checked it into version control. And then, every month or so, someone would package it up into something runnable, and hand it over to the testers. The testers would test it, report a lot of bugs which would be summarily ignored but take up a lot of paper, and then they would hand it to the operations team, who would put it on a server.

So yes, it was important that the programmers wrote the software in Java, because the sysadmins in the operations team knew how to run a Java program, monitor it, interpret stack traces, and restart it.

So who was responsible? Well, if the programming team wrote the code and the operations team ran it, neither was. Instead, it was the person who unifies the two, which in many organisations would be a senior manager. And so, having to take on the responsibility, the manager also assumed the authority.

The modern day

Nowadays, things are a bit different, at least in many software teams.

For one thing, it’s a lot more common to have a “software” team, not a “programmer” team and an “operations” team. (We don’t have “testing” teams either, but unfortunately that’s because we don’t have testers… that’s another rant.)

And instead of throwing code “over the wall” to operations, we say: “You build it, you run it.”

But we still tell people that they must write code in Java, or write their data to MS SQL Server.

Or, much worse: that they must hit a specific internal deadline, with no stakes except a manager’s pride.

And here’s the smell. When we say, “You build it, you run it”, we are telling the software development team (which may contain programmers, sysadmins, testers, designers, product managers, etc.) that they are responsible.

And unfortunately, too many of those teams do not have the authority to make certain decisions.

If you want authority, take the responsibility

Who really has the responsibility for picking a programming language?

Intuitively, you might say the programmers. They are, after all, stuck with the decision.

There’s a little more to it though. If you want the authority to decide your own programming language, you take on all the responsibility attached. This means not just making sure that it’s the right tool for the job, but that everyone on the team can work in it, that you can hire people who will be able to contribute in that language, that any necessary libraries are available (or that you take on the burden of maintaining your own), etc.

There’s a lot to it. And if you don’t want to be responsible for all that, that’s fine. (Many programmers don’t directly manage interviewing, for example.) But if you’re partially responsible, you get part of the authority. Not all of it, which means you have to negotiate.

In most real-world scenarios, this is how it goes. No one person or team can handle all the responsibilty. Instead they work together to share it, and share the authority too.

No responsibility without authority

I very rarely meet a software developer who is loathe to assume responsibility. Often, they welcome it: it’s a chance to do things their way, to show their skills, to take on a challenge.

But I do meet many who suffer because of it. Not because they can’t handle the responsibility, but because they lack the authority to make sensible decisions.

So here’s my request to you: next time you either take responsibility, or delegate it: make sure the authority transfers with it.