The Accountability Problem

"And like medieval scholars drawing elephants they’ve never seen, we make those interpretations through the lens of our own biases."

Those images are quite amusing. They drew an elephant like a boar but with odd tusks. So the tusks were probably described correctly (semi-correctly) for the most part, but the size is totally wrong, which is weird. It's like ... "hey, I saw a thing with huge tusks but it was not bigger than a boar."

Or perhaps the one who drew this just imagined a strange boar, and never heard of the tusks. It's strange.

Assuming you’re earnestly not seeing how this works rather than seeking an argument:

I work in an industry where accountability is the norm. Individual people perform well-known, but difficult-to-execute steps of various processes; strict metrics define success and failure; close calls are not ideal; and the distance between success and failure is usually not revealed without precisely calibrated equipment. The ways to measure the outcomes are legally codified. Everything can be checked and double-checked, and people can, and often do, check those checks. Even then, sometimes the person that determined the metrics got them wrong. Sometimes it was measured wrong. Sometimes the person that said it was wrong turns out to be wrong. My primary professional function is to determine adherence to those standards. Potentially thousands of lives are at stake if we get the wrong thing wrong enough.

With a sane commit history and code reviews, this is a lot easier in software than it is in most realms. It’s definitely easier than mine.

Accountability isn’t just about failure— it’s about owning outcomes and giving an account of what you did to contribute to that outcome, good or bad.

> answerability, culpability, liability

You left off the end of the sentence.

> equated with answerability, culpability, liability, and the expectation of account-giving.

Account-giving is the key, here.

Since we’re focusing on problems: mistakes have different causes: being careless, having outdated knowledge, having the wrong requirements, physical or mental problems, equipment malfunctioning, bad processes… to identify the root problem, you need an account of what happened. To get that, you need to identify the person or people involved, and figure out what went wrong. That’s the only way you’re going to mature enough organizationally to have any semblance of quality. As the saying goes: if everybody’s responsible for something, then nobody’s responsible for it. The distinction is accountability.

So you don’t need to fire someone to hold them accountable— even being ‘in trouble’ every time someone does something wrong is counterproductive if it makes people hide or shirk responsibility for their mistakes. If someone fucks up badly or frequently enough, then maybe they are in trouble, and maybe they do get fired? But there’s a whole hell of a lot accountability that happens before that.

People make mistakes, and any organization that does not tolerate mistakes is run by people without the emotional maturity required to properly run an organization. The same is true of people unwilling to identify those mistakes and figure out either how they can be avoided in the future, or if they can’t be reliably avoided, mitigate their effects. Some of the leadership’s primary responsibilities involve defining the desired outcome, measuring the difference between it and the actual outcome, determining if/how it matters, and figuring out why it’s different. Those that refuse to address, or even acknowledge problems (and again, it doesn’t have to be punitive,) are masking their own laziness or incompetence.

That would be fine if Sales & Marketing wants to discuss priority, aka aligning needs with capacity. It's either make them happy and take the blame when the technical debt is unsustainable, or seen as uncooperative. I think it's hard for them to promise the moon if Engineering keeps reminding them about reality.

In all of these types of stories, it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part.

CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc

CEO determined there was a market fit or vision for a product, convinced an investor or shareholder to invest based on multiple reviews of this vision then hired a set of people to execute on this vision.

Yes, there are plenty of bullshit artists out there. But, the product itself is developed by people below the CEO.

Everyone who has worked in tech should reflect on the fact that it would be shocking to see a product manager produce a spec for the behavior of a feature, or a spreadsheet with discounted value analysis as in TFA. Those are both artifacts that aid in decision making, and especially aid in making the kind of decisions that product orgs have taken from other more qualified people at a company. Unfortunately, product management has become an imposter role, a side door into tech companies for people who can't contribute to the sales, financial, or technical parts of the business. They would just be bloat if that was where it stopped, but these imposter roles task themselves with making important decisions, at the company's expense.

Like the author, I've found some success in forcing accountability, to the point that imposters hand off decisions to someone who can legitimately navigate to a solution. A lingering problem is that business decision making isn't about one-time decisions, it's about decision making rate. As long as poor decision makers can retain their position in the critical loop, they will impede the ability of the business to function. The solution is building the organization around accountability and consequences for misallocating the company's resources: setting up a system where the organization tends towards competent decision makers gaining influence, and incompetent decision makers losing influence or leaving.