Accountability Without Scapegoats

The date is Tuesday, October 14, 2003. The Chicago Cubs are five outs from winning the National League pennant for the first time in fifty-eight years. They lead the visiting Marlins by a score of 3-0. There's a runner on second with one out. The Cubs have a 97% chance of clinching¹. But... they lose. And it was all this random guy's fault. Except, not really.

1. Scapegoats Coast-to-Coast

²

The date is Wednesday, April 6, 2016. I've worked in the software engineering industry for a few years. I've seen projects succeed. And I've seen some fail. Unfortunately, most organizations aren't great at dealing with either case.

The main issue is where to assign credit and where to assign blame. I don't mean to people, at least directly. At the end of the day, a person somewhere is responsible. But more generally I mean that retrospectively the result was effected by some actions an employee did or did not take, and an essential part of improving the organization is identify those through-lines.

It's easiest to judge this improvement process when it was handled through an actual meeting: the postmortem. I've had a couple teams that followed the retrospective/postmortem practice religiously. I'm currently on one of those teams. Major incident with the live site? Postmortem. A big update on an enterprise customer contract? Postmortem. Three weeks since the last postmortem? Postmortem.

The live site ones are the most useful, not that I've been involved in a ton of those, which I take as a point of pride. But should I? It means the things I work on don't sputter and die in the wild. But on the other hand could it mean my impact is not as high as it could be? I file this thought away for now. I'm prepared to go into one of those live site postmortems. But it's okay, these are the ones that result in course-corrections, more often than not. They have the benefit of a clean break from expectations: we expected the DBController to run without purging customer data. When it was deployed, it starting purging customer data. Oops. So they got the people who designed it, built it, tested it, and their managers in there to figure out what went wrong. I was one of the builders/testers. Sometimes the individuals involved would not see each other face-to-face during the process; they were interviewed by a neutral party whose job it was to file the report. If the process was run like this, it was most likely to get a real, actionable work item out of the report. I walk into the room, and it's just me and two people I've seen around but never worked with directly. Bingo.

They ask me the questions, I answer honestly to the best of my ability. It takes about 10 minutes. The following week, I get an email with the report, and my manager adds the recommended tasks to our next sprint. No one is blamed or reprimanded, as far as I notice.

Those are how the failures are handled. Most postmortems aren't like this; they are way less organized. Some are okay and involve sticky notes and writing things down "anonymously" so they can be transcribed to the whiteboard in three columns: "What went well", "What went poorly", and "What could be better". Every once in a while reasonable action items make it out of these meetings but for the most part they seem forgotten, except for in the mind of the manager who randomly brings up topics tangentially related to the "poorly" sticky notes. These ones don't have much value except as a routine reprieve from executing day-after-day. To be honest, it's sometimes nice to simply sit in a room with your co-workers and complain about things that all of you are dealing with together. So, at least there's that. Those are how the successes are handled.

Generally, it seems "accountability" rolls up to my manager. They're the ones fielding the reports, the developer feedback, and taking actions on it (or not), and they're the ones who need to report up the chain what things went wrong last quarter and what they're doing about it. I never feel scapegoated or set up to fail; even on those teams where the action items aren't flowing from mistakes. So that's good I suppose.

A round of layoffs happens. A co-worker of mine is let go. My manager is let go. I survive, thanks to the intricacies of a process that is opaque to me. I think back to the postmortems, and something about them, even the good ones, doesn't sit right.

2. Keep On Until You Reach Higher Ground

The date is Friday, November 19, 2021. I'm finally a senior dev, and people look to me for leadership, at least in a few domains like Databases, API Design, and Documentation. I frequently get complimented on my documentation, a skill which I developed more for myself than anyone else, because I cannot for the life of me read my own code from six months ago and understand what it does. I don't believe this is an author defect. The code is asynchronous, thread-safe, tightly scoped, and designed to live for a long-time, so for now I'm happy to have this skill that will be completely obsolete in 4 years.³

I sense more flaws in my org's ownership and accountability rules. My projects are largely successful, and I've moved to an R&D team, so there's not a ton of live-site firefighting (good) and for the most part any retrospective I am involved with is the second, stupider kind (not too bad, but to the extent we have retros they seem like a waste of time). I frequently raise tech debt as "could be better", and when I get really unhappy: "what went poorly". While I'm working on all this infrastructure, which I feel accountable for not only my code but all the code that it will support, I get more and more frustrated that I am not given the time to make it extremely solid. Instead, it seems every month the PM/Manager comes to use with a new Feature/Story/Use Case we hadn't planned for. Which is fine. I like new features. But my infra is just sitting there, meticulously organized tasks screaming out to me in the form of TODOs.

I want to help my fellow devs succeed, but if we just keep accumulating debt this thing is going to capsize eventually, or we just throw the codebase away. Neither of which I want. Worse, my whole sense of accountability seems wrong. I am overruled when I want to improve this infra code, so it seems wrong to hold myself accountable for it. After all, if I don't have the latitude to do what I think needs to be done, I don't really own it, and it doesn't make sense to hold me accountable for something I don't really own. It's not Steve Bartman's job to help Moises Alou catch foul balls, after all. That seems to fit.

It gets a little clearer: Accountability = ownership of both the success and failure within a defined scope of responsibility. At least, that's what it should be. Organizations (and baseball fans) don't apply that definition so accurately.

I feel accountable for the code I write, but in some places others aren't holding me accountable. If they were, the outcome wouldn't be "Luke makes a good point, but we have more important things to do" and instead would be "Luke says this is essential, and we know he owns this, so we should find a place for it." When others overrule me on a topic I ostensibly own, that's a vote of no-confidence on my conviction, and I either need to make a better case, or move my area of responsibility to one of higher impact.

3. The Buck Stops Here

The date is Friday, July 10, 2026. So now the question is one of career capital accumulation, and it's directly tied in with the seam between senior and staff/principal. Seniors are leaders within their team, technically strong, role model best practices, and solve problems within their scope (which they sometimes have a hand in fencing). But principals "solve the whole problem", and that includes scopes which are outside of their control. Oddly, lack of control seems to be a core differentiator; part of the job is internalizing ownership of something that can't be entirely fenced. The realities of the technology stack, market forces, or customer asks might just force your hand, and these imperfections must be accounted for.

Again, this seems to throw a wrench into my definition of accountability. How can you own what you can't control? Is it a bit of a lie? In some ways I admire those managers that are willing to stick their necks out for their reports, who don't always make the right choices. "I assigned the work to them, it's my responsibility for it to go well." But at the same time, is it really? What about on the pure engineering side? If you build infrastructure that other's misunderstand or misuse, is it their fault for not reading the docs or applying their solution correctly, or is it your fault for not walling off the incorrect behavior? You can't solve for every edge case, but at the same time the infra that does handle those edge cases naturally is better than that which doesn't. To make this even harder, the infra that solves the problems with no fuss doesn't even get noticed; it just worked from the beginning, and nobody congratulates you (at least, not without some ardent self-promotion).

I don't have a silver bullet for this problem, but I do have some strategies. A big one is a mindset shift from shipping a perfect piece of software to delivering a continuous delivery process, made up of perfect pieces of software, in order to chip away at that accountability gap. How might one do that? The good news is, if one is an I.C., one can re-use the senior skills here. Declare and socialize ones designs, scope the problems, get buy-in, make the impact obvious, and build the hell out of it. But this only works if one can judge what's worth working on and what isn't. It's not so simple as feature prioritization, though that is part of it. It's more of, well, a continuous delivery process: like a factory. And that judgment layer is one of the trickiest things to generalize.

Coming back to accountability now, it seems our definition above holds, but the ownership has gone up an abstraction level. The success/failure is not just in the execution, but the judgment in where in the factory to invest.

4. The One Thing AI Can Never Give You

⁴

The date is Wednesday, February 2, 2033.

Okay... not really. But, unless things get really really weird⁵, one invariant we can count on is that no matter how capable AIs become, they will never provide you with accountability. AIs might start building and managing themselves, but at the end of the day there will always be a human in the hot seat. Someone who designed it, programmed it, set its guardrails (or didn't do any of those things and should have). I expect this to continue for the long-term future; it's one of the few long-term certainties I have about AI.

With that bedrock in mind, as well as the meditations above on accountability and scapegoating in engineering, let's consider the question of how staff engineers ought to approach software in the AI era.

I propose this "zooming-in" optimization framework, starting most generally and diving in from there.

Level 3 - Picking Values

Borderline philosophical, and there's no agreed-upon procedure even among humans. But I believe we need to take a distinctly humanist approach, prioritizing the agency and flourishing of human beings. This would rule out, say, handing over the nuclear codes to AI in any decisive way.⁶ This is the last bastion of accountability, and one that I believe to be immovable. High-minded though it may seem, even in engineering there are times when we need to rely on this philosophical bedrock to make decisions. Indeed, this seems to become more and more salient every year. Anthropic employs a team of philosophers for this very reason.

We have self-driving cars that will need to make split-second life or death decisions, and rely on the training/algorithms written by humans to make those decisions. We have generative AI deployed in healthcare domains, as well as legal. We have AI brushing up against education and getting fed to minors.

There are the cases of AI psychosis. Self-harm at the behest of AI. And more widespread, AI is changing the way the economy and society operate in just about every facet of life.

Like it or not, the engineering decisions we make will affect this new world we are creating. And so, even if we relinquish control to AIs in every other capacity, we will, and should, remain in the driver seat as to what values we uphold, prioritize, and enforce. And how.

Level 2 - Picking Goals Given Values

Once you have selected a set of values, you must turn that into a goal. This is the case with any action a human being might take (at its most basic: Thing X is Good, What is State of World Where I Get A Lot of X?). That "state of the world" you are striving for is the goal. This remains a mostly human endeavor today. Humans wrote "Helpful and Harmless" and Constitutional AI. These are goals for what the state of AI ought to look like if we succeed.

Even if you're not building AI itself, you might be presenting AI to a customer, or using AI to build the product you want to build. There are countless ways to select goals, because there are countless states of the near-future. There's not a trivial way to search among these, so I imagine this task will remain human directed, perhaps with some help from AI in pruning the somewhat-obviously-bad ones, assuming moderately-aligned AI.

Humans should remain accountable for the goals they select.

Level 1 - Picking Fitness Functions Given Goals

This is where things start to get a little less clear on the accountability front. We are already starting to hand goals to AIs and get pretty good results out of it. GPT5.6 Sol/Claude Fable are extremely powerful when handed merely a goal. They can divise their own methods of measuring progress toward that goal and hill climb on that. I've heard this referred to as the "Hill Climbing Machine", and the parts of this "machine" are getting more and more automated every day. I could see this getting "solved" with reasonable mainstream fidelity by 2031.

Human accountability will remain in the cracks between the goals we hand off to AI and what they actually achieve (A.K.A, the Alignment Problem), as well as in the goals themselves.

Level 0 - Picking Actions Given Fitness Functions

Largely solved. AlphaGo/Zero, AlphaEvolve, RL, search. Given measurable score, AI can optimize. We know this. Accountability lies at a more abstract layer than this, in the same way that I wouldn't blame a civil engineer for a crack forming in a single steel beam (though I would blame them for failing to design the bridge such that it would remain strong in the face of occasional steel weakening).

5. Steve Bartman Did Nothing Wrong

I'll end on this note: Scapegoating is a result of a faulty sense of accountability. We might not know who or what to rely upon, so we reach out to something nearby to make sense of that which does not make sense. This might have been understandable (though still irrational and tragic) in the case of inchoate civilization, but now humanity has things like rationalism and the scientific method to guide us. There is no real excuse any more.

In the age of AI, rationally apportioning accountability (and by consequence, eliminating scapegoating) will be essential to our continuing flourishing as engineers, and as people.

Footnotes

1. As of the start of the 2026 season, the home team won 1280/1365≈93.77% games that passed through this exact situation. This was Game 6 so even if they lose they still could have clinched the next game, so add another 3% for that and you get ~97%. Source: https://gregstoll.com/~gregstoll/baseball/stats.html#V.3.8.1.3.0.0. ↩

2. Copyright 1982 Matt Groening, presented here under fair use. The full comic is archived here. ↩

3. Even in the age of AI, human-written documentation is still important. Just not so much the detailed inline docs I became accustomed to writing. ↩

4. Make your own moral decisions here: https://www.moralmachine.net/ ↩

5. For the record, I don't rule out the possibility that developments in AI will result in things getting really really weird. But a future that does not involve any of 1. Human extinction, 2. Human disempowerment/loss of control, 3. Humans remaining accountable... seems entirely contradictory. In other words, if we're still around and making decisions about AI (any reasonably good future), individual humans will remain the accountability end-sinks. ↩

6. There are those who imagine "Plan A"'s where AI-alignment might go so well that we might "pass the torch" to AIs in order to preserve human values - one could imagine a well-calibrated AI protection layer that offers more safety affordance to humans than humans themselves - after all, an insane dictator could decide to end humanity at any moment. This plan posited not so much because this situation is very likely (it's not), but as a north star to reach for. However, even in that vanishingly unlikely scenario I struggle to understand a practical situation where we relinquish control in such a way, even to our supposed benefit. I remain firm in the belief that human agency/self-determination and moral goodness cannot come apart, though I reserve the right to change my mind if presented with good enough evidence. ↩