I cannot believe that happened. I can't believe we didn't catch that. I can't believe that went so long unnoticed. How could we possibly have failed in that particular way? It seems like the most elementary thing that we should have caught, and it cost us. If you've heard these words, then you know the pain that's likely associated with those words. The feeling that someone has done something terribly wrong, and no one understands how it happened. Now, sure, of course, they can look and see technically how it happened. Someone put a line of code in that changed the way something was working. Maybe they broke an important link, or they accidentally put a test key where a production key was supposed to be. In any case, the problems tend to be simple, but the implications tend to be huge. These stories are very common. Most of the time, we don't feel the same way about things that are more complex. We don't feel the same way about bugs that are difficult to track down, that even our smartest engineers overlooked for a long time. This pain is felt primarily when it's something that was simply dropped. The bases weren't covered. Somehow, a very simple mistake was made. Even by our most senior engineers. You might be one of those senior engineers. You might feel the pain of that executive looking at you and saying, how in the world did you let this go through? But if you are one of those executives or one of those senior engineers, a manager, I challenge you to run your retro, run your post-mortem, whatever it is, through the lens of the accountability triangle. If you haven't heard of that concept, well, that's because the first time it's ever been said on a podcast, as far as I know, was about 10 seconds ago. But the underlying concept is very simple. And hopefully, this will stick with you in your mind the next time you're diagnosing a failure, especially a failure that you can't understand how it happened. The accountability triangle. The accountability triangle consists, like the name suggests, of three parts. Those three parts are person, process, and proof. Person, process, and proof. It shouldn't sound crazy or surprising that these simple errors are not a problem of capacity or ability. Problems like accidentally changing a link, that's a typo. Any one of us could have made that error. And it doesn't reflect on somebody's seniority. It doesn't reflect on their capacity as an engineer, their ability to solve hard problems, their ability to deliver. This reflects mostly on the human condition. We are error prone. And so a failure of accountability should be your first suspect when a problem like this occurs. But where most... Most people fail when trying to implement accountability is they start and end in the same place. They simply assign someone to the accountability. This is only one part of the triangle. That is the person part. Perhaps even more insidious is when the person who is accountable is not actually told that they are accountable. They are not accountable for that particular thing. Similarly, when it's not just a person but an entire group of people, for example, a team or an entire engineering department. Engineering is accountable to make sure that we aren't shipping bugs. This is a common implicit expectation, sometimes even explicit. Engineering is accountable to make sure we don't ship bugs. This is a very weak two-pointed shape. Rather than a triangle. You're identifying people by saying engineering, but you're not really explaining what it means to ship without bugs. There's no way to prove that your software is shipping without bugs. Good accountability starts with being explicit about who is accountable. And the next piece is to provide an avenue of proof. In other words, how do we know that the thing that they are accountable to, they've taken care of? There's an important nuance that's built into the triangle that I want you to pay attention to here. It is not actually possible to prove without a doubt that you're shipping bug-free software. So if you can't prove it, then you can't be held accountable to it. Think about this. If you can't prove it, then you can't be held accountable to it. Now you might say, well, of course we can prove when there are bugs in software. And yeah, that makes sense. But you can't prove the inverse. That there are no bugs in the software. Trying to hold somebody accountable to something that they cannot prove creates anxiety. And it creates a shifting standard that they can never actually meet. And a better type of accountability. Is more explicit and includes proof. Person X or team Y is explicitly responsible for writing tests that ensure that regressions. For a particular happy path in their software are caught as early as possible. This kind of accountability can be proven. The engineers that are working on that particular project can write tests that validate that. The happy path is still accessible. And if some change causes a regression and makes that path inaccessible, those tests should fail. Providing a signal and allowing that team to deal with those regressions before they actually impact something in production. Now recognize what I've been talking about here. There is some type of process that is attached to the accountability. In this case, writing tests and responding to regressions. And that's the process that's attached to the accountability. In this case, writing tests and responding to regressions. Regressions is the process. But here's the important part about the process. Process is the most likely of the three parts of the triangle to change. This is because one process may not necessarily be yielding the results that you care about in the proof. You can think about these. This this dichotomy is split as some kind of implementation versus an outcome. Implementation may change often. While the outcome may. Stay a little bit more static. This accountability triangle is kind of a litmus test. Whenever you assign accountability or maybe when you're thinking about the job responsibilities of a particular role, use this triangle to ensure that there is a complete picture for that particular accountability point. It's important to note, by the way, that you may as a manager or maybe a director level, executive level, you may identify only the first two points, the proof and the person, and then allow that person to identify the proper process. But importantly, if a process can't be defined similarly to if a proof can't be defined, then true accountability will become impossible. Let's talk about an abstract example to to make this point. Imagine that you identify Lisa. Lisa is the person who is responsible for the process. The accountable person and the proof they are looking for is that Lisa has arrived across the ocean. She's currently in the United States. She has arrived in, let's say, London in her car in two hours. So you have very clear criteria. Your proof is there and your person has been identified. But the problem is, if you try to hold somebody accountable to this, it's very obvious that they're not going to be accountable. There's no process that exists, at least today, that would allow them to achieve this. And so this accountability means essentially nothing. Until a process is defined and agreed upon, holding somebody accountable to something that does not have a process may actually be holding somebody accountable to something that is impossible. This is why process is a part of that triangle, even if you are not necessarily directly responsible for defining that process. So the next time you are diagnosing a failure of processes in your company or failure of a given team or some particular aspect of your product, try to remember this accountability triangle concept. Do you have a clear person or group of people, a team, who is responsible for a particular outcome, for a particular set of proof? If they are responsible, is there an identified process by which they accomplish that proof? If any of those pieces are missing, then it's not actually accountability. For example, if you have a process and a proof, but you don't necessarily have the person, really what you have is a job description. If you have a person and a proof, what you have is a question or maybe an idea. If you have a person and a proof, what you have is a question or maybe an idea. If you have a person and a process, but no specific proof, then you have a moving target or perhaps busy work. Any of these combinations without the other is ultimately not actually something that represents accountability. Thanks so much for listening to today's episode of Developer Tea. I hope this concept is helpful to you, meaningful to you. Of course, there are other aspects of accountability that come into play. For example, who is going to hold the person accountable? But hopefully this gives you some kind of rubric or a mental model to judge the way that you are holding people accountable, to judge whether or not those points that you're holding them accountable on are actually valid. If you enjoyed this discussion, I'd encourage you to join the Developer Tea Discord community. Head over to developertea.com slash discord to join today. It's totally free. There's no upsell or anything like that. We're just accommodating. We're a community of people who are talking on a relatively regular basis. Come and check it out. Developertea.com slash discord. Thanks so much for listening. And until next time, enjoy your tea.