September 18, 2023

Internal vs. External Accountabilities

One of the concepts that’s commonplace on software development Twitter / Reddit et al is the notion that management is ultimately responsible for everything that’s done by their employees - i.e. the captain is responsible for the behavior of the crew.

And in a sense this is true - from the point of view of an external stakeholder like a customer or a shareholder, the buck stops with management when it comes to failures… However, that’s not the whole story.

Internal vs. external accountabilities

Within an organization accountabilities are structured thusly for each individual:

  1. Accountable to customers or potentially other external stakeholders, like investors. This is the greatest level of responsiblity and the buck ultimately stops with these people. These individuals also have the most ambiguity in their everyday work.
  2. Accountable to team - this is the middle management-tier responsibility. These people have more ambiguity in their work but also more structure than the highest tier of management; they are primarily responsible for making sure that their teams’ members meet their goals and that those members have what they need to do so.
  3. Accountable for individual performance - this is individual contributor responsibility. These folks have more highly structured roles and are largely accountable for their performance and contribution towards the greater team goal.

These accountabilities compound on top of each other - high-level executives are still accountable to the team AND still accountable for their own performance.

What the Twitterati get wrong is eliding being accountable for individual performance from the conversation about who is responsible for what, essentially infantilizing individual contributors and depriving them of agency when it comes to consequences for on-the-job screw-ups.

Accountability in Context

Consider the following:

  1. Company has important production website that generates tens of thousands of dollars per day;
  2. VP of Engineering is responsible for overseeing orgs that maintain / develop website - reports directly to CEO;
  3. VP of Engineering delegates deployment and CI/CD to Engineering Manager; and
  4. Engineering Manager delegates end-to-end QA sign-off to a Software Engineer who owns this particular feature that is going into production.

The website has an automated battery of tests and an approval gate that prevents it from being released into a customer-facing environment without the approval of the Engineering Manager. However, many parts of the website that are uncovered by automated tests and these are well-known / on the backlog - so in the meantime Engineering Manager has a QA checklist to be completed by the developer overseeing the release of each feature.

Software Engineer blows through the checklist without actually running any of the tests and tells the Engineering Manager that the release is “good to go.” Engineering Manager doesn’t double-check or scrutinize the Software Engineer’s work and releases the Approval Gate. The VP of Engineering is uninvolved in the release process altogether.

The website goes live and an undetected bug causes it to silently fail to process every 10th order - no one notices until the revenue graph is down for two consecutive days. Who is at fault?

The correct answer is “all of them.”

  1. The VP of Engineering didn’t poke into the release process to discover potential weaknesses / blind spots that were vulnerable to human error - the VP will have to be the one to apologize to the CEO and possibly do a post-mortem for affected customers;
  2. The Engineering Manager overly trusted the word of the Software Engineer and didn’t verify the results for themselves; and
  3. The Software Engineer, through negligence, incompetence, or laziness, went off-script and didn’t do their job and didn’t tell the truth when asked about it.

Software Twitter would tell that this is the Engineering Manager’s fault for creating a process where this type of error could happen in the first place - but how true is that?

Is the Engineering Manager supposed to drop everything put “write automated tests for complex user scenarios” at the front of the queue just because the developers on the team might be lazy or careless? This is where “Accountable for Own Performance” enters the picture - in an ideal world, yes we’d have flawless automated quality checks and illegal states would be unrepresentable in software.

But we live in the real world, and that means sometimes having to do the best we can with manual processes and trusting employees to follow them. When individual contributors demonstrate bad judgment, don’t live up to the organization’s standards or values, or simply aren’t up to the task of doing the job then the manager’s error is allowing that employee to remain in their current role.

I’m a CEO; I’m accountable to our customers when things go wrong that impact them. But if a member of our team demonstrated poor judgment or values, they’re accountable to me. Everyone is accountable to somebody.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..