« All Episodes

A Pragmatic Definition for Accountability

Published 8/14/2026

Accountability is a word you'll hear in your performance reviews, from your manager, and increasingly as you step into leadership. It's also one of the most abused and misunderstood concepts in our industry. Many of us have a visceral, negative reaction to it—not because the concept is broken, but because the companies and people we've worked with have bastardized its meaning. In today's episode, I want to strip away the scary parts and offer you a pragmatic, working definition of accountability: one that a good engineer would actually invite rather than dread.

What We Cover

  • The Bad Version of Accountability: Recognize the weaponized version of this word—being audited for things you didn't know you were responsible for, having unrealistic goals coerced onto you, and getting surprised at performance review time. This is how leaders shirk their real responsibility to grow people and create clarity, hiding hard performance conversations behind a single loaded term.
  • Accountability as Debugging: Shift the frame to how we think about software. When payroll software overpays your team by $100, you file a bug report—something deviated from the agreement about what should happen. The engineer who investigates is performing an accounting function, tracing a root cause. That's what being "held to account" really means: identifying what happened against a known standard.
  • The Churning Customer Problem: Understand what happens when the bug report never gets filed. A customer who hits something unexpected and just leaves never gives the company a chance to fix it. The same thing happens between you and your manager when the communication lines aren't established—you find out at review time instead of when it could have mattered.
  • Accountability at Every Step: In a healthy team, accountability isn't a once-a-year audit. It's continuous, giving you the ongoing opportunity to notice when something has deviated from the agreement—so you have something concrete to hold to account before it becomes a surprise.
  • Estimates vs. Commitments: Learn to separate the two things you say to a stakeholder. One is a forecast, a guess, a belief. The other is a commitment. Bad accountability coerces the estimate into a commitment it never was; too-soft accountability treats everything as up in the air. The healthiest organizations hold both: a high-confidence forecast, plus a commitment to do whatever is necessary if it looks like it won't get done.
  • Why Good Engineers Invite It: If you want to grow in your career and confront reality, you invite accountability and commitment inspection. Done well, it creates clarity of expectation for exactly how you're doing—which is a gift, not a threat.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

🗞️ Subscribe to The Tea Break

We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review!

Transcript (Generated by OpenAI Whisper)

In today's episode, I want to talk about an amorphous subject, something that's difficult for people to wrap their minds around, but something that keeps coming up over and over and over in our conversations as we grow in our careers. You're going to hear this in your performance reviews. You're going to hear it from your manager. And it's this term, it's this term that often gets abused and misunderstood. And unfortunately, it also is very important. It's an incredibly important concept. And the more you can understand about it, especially if you're an engineering leader, especially if you are, if you have people reporting to you, if you are a senior engineer, if you're some kind of, you know, if you're responsible for, you know, some kind of, you know, performance situation, whether that's you're mentoring other engineers, whatever it is, if you are in any kind of leadership position, and probably you will be at some point in your career, especially if you're listening to this show, then this concept is going to become more important to you as you grow in that leadership. And the concept is accountability. Accountability. If you hear, if you have a visceral reaction to this, I hope that you will stick around because so many people have unfortunately, have unfortunately had bad experiences with this word, with this concept, with this amorphous subject of accountability, because, you know, the companies they've worked at or the people they've worked with have bastardized the meaning of this word. And I want to kind of help you set straight, you know, some, some concepts about accountability that may help you in your career. And unfortunately, we don't have a perfect agreement system in this industry. We don't have, you know, certifications on defining accountability. That doesn't exist, right? Maybe that's unfortunate. Maybe it's perfectly fine. Okay. Okay. So as a manager, I want to kind of impart to you, you know, what I believe a good working definition is of accountability, of a pragmatic functional definition. And it'll take some of the scary parts out of it for you. If you're a engineer that's listening to this, maybe you can give this to your leaders and ask, do they agree with this, right? Do they agree with, you know, this, this framing for accountability? Let's talk about the bad version first. And hopefully this, you'll kind of see why I believe it's been bastardized so much. The bad version of accountability. If you hear this word and you immediately think, oh, that's somebody coming in and explaining to me everything I've done wrong. Or if you hear this word and the first thing you think is that's somebody who has no idea, you know, they're setting unrealistic goals. They're setting unrealistic goals. They're setting unrealistic goals for me. I tell them that I can't do them and then they punish me for not being able to do something that I told them I couldn't do. Right? That's a bad definition of accountability. If you have the experience of being held accountable to something that you didn't know you were responsible for, right? You know, performance review rolls around and you're being held accountable to something that you... that you didn't know you were responsible for. That's a surprise. Something that is news to you. Something that you didn't predict was going to happen. Right? There's a lot of definitions of accountability here that fall in this bad category because it has been weaponized. It has been weaponized. It's been turned into a way of, you know, kind of backdooring performance management, hard performance management conversations. And, you know, in this bad version, leaders kind of shirking their responsibilities for growing their people, for communicating to their people, for creating clarity. You know, we can hide behind this idea of accountability and say, well, you know, you didn't do your job well and therefore I'm going to hold you accountable. And I want to kind of set that definition out as, you know, that's not... that's not... a version of accountability that I would accept as authoritative. So, and it's amorphous because there are so many different applications of this and so many of those bad versions of it that people start to lose sight of the fundamental meaning of accountability in the first place. And perhaps most importantly, what is the function of it? And what is the pragmatic reason why we even use this word? Why this word? Why this concept comes up in business at all? And, you know, I think we, maybe when we were younger, certainly in school, you know, you know, when we are held to account, it usually is a negative event for us. Right? In most of these circumstances, you know, this experience of being held to account tends to mean that you're being audited in some way. Right? I want to talk about this from a... from a productive, positive perspective. Because I think that's the useful version of accountability and it's something that if you want to get better at what you do, you would invite. But if you want to grow in your career, you're going to invite accountability. If you want to confront reality, you're going to invite accountability. You're going to invite accountability. I want to kind of shift the frame to how we think about software. If I build a, you know, a platform that performs a set of critical functions for my business, you know, let's say I run payroll through this platform and I have a set of expectations of the platform. Right? You know, these expectations might be features that they publish. They may be, you know, things that we take for granted that are not necessarily published but are maybe their legal requirements that they say, you know, we follow all legal requirements. They may be some table stakes things that we take for granted like financial accuracy. Right? That's not a feature that they have to tell us about but it certainly is something we would expect. And so if I build this software... Or if I'm, let's say I'm using this software rather, right? And, you know, I perform a function. Let's say I run payroll. I click a button. I run payroll. And nine out of ten times things go as expected. Right? And then every once in a while I get a major deviation from the correct output. Let's say I overpriced. I overpay all of my employees by $100. Or maybe worse. I underpay them by $100. And I don't know this. So if I file a bug report, the basis of this bug report is, hey, this is something unexpected happened. Something that deviates from our agreement about what the software should do has occurred. And if the person who wrote the software was to receive this feedback and go and try to figure out what happened, they're performing an accounting function. They're performing, and not just because it's financial in nature, but because observability and debugging fundamentally depends on some kind of data. And so, what we mean in this kind of functional scenario of accountability is being able to identify the root cause of some event. Being able to trace what happened in each situation. Right? This is why it feels like auditing when we are, quote, held to account. And so, in a good accountability scenario, what we're really wanting to identify is what is the expected outcome? What is the agreement? What is the promise? What is the standard that I am setting or that is set for me to meet? Do I agree to it? Right? Good managers will talk about both the explicit and the implicit thing. Right? We expect you to not do illegal things, for example. Right? Some of this stuff would show up in an employee handbook. Some of these things would show up on a skill matrix. Some of these things would show up in your direct feedback from your manager. Right? That last one tends to be where things fall apart. Where, hey, you know what? I thought I was doing a good job. And, you know, performance review time comes around, and I wasn't. Somebody believed I wasn't. They didn't give me that feedback. And so, you know, it would be like that customer never actually filing the bug report and just churning. They just leave the company because, hey, you know what? You did something unexpected and, therefore, immediate consequence. I'm holding you to account by leaving. Right? And so the company never had a chance to fix the problem. We have this situation all the time in the workplace. Where, you know, something has gone wrong, but the communication lines are not really well established. And so what you want in a healthy organization and a healthy team and a healthy relationship between you and your manager is accountability at all steps. Because it gives you the opportunity to recognize when something has deviated from the agreement. When something has deviated from the agreement, then now you have an accountability issue. You have something to hold account to. So if I agree, so let's set up a basic example of this. Most, and just as heuristic, most good engineers will invite accountability. And they will invite, you know, a commitment inspection. Which I would say is like a form of holding people accountable. So how do you hold somebody accountable? Let's say that you have, let's say you're working on a project. You're working in increments. You have a sprint. You have a sprint. Most people work in sprints or have at least been exposed to this idea. You have some increment. You have some two-week period or whatever the amount of time is. It doesn't really matter, right? But in that time, you talk with a stakeholder. Maybe it's a product manager. Maybe it's your engineering manager. Maybe it's the CEO of your company or a customer, whoever it is. You talk with this person. You say, yes, I think. I think I've done X done. But I can definitely commit to getting this part of it done. Right? There's two things that you've said here. You've said one that is a guess or is some kind of forecast. It's some kind of, you know, belief. It's a, you know, it's an estimate. Right? And then the other is a commitment. And what very often happens, again, in a bad application of accountability, is we coerce the estimate, the guess, the forecast into a commitment when it never really was. Right? And then on the flip side, when we are being too soft on accountability, when we're not holding anybody accountable, we treat everything as if it's up in the air. And maybe it will happen and nothing is ever a commitment. Right? And truthfully, the healthiest organizations I've been a part of didn't have both. Didn't have both. Right? We have a high confidence interval that something is going to get done. And we're willing to accept some risk in order to make sure that it happens. So, hey, you know what? I think it's going to get done. I have a pretty high confidence. If it's not going to get done, then I'm going to commit to doing whatever is necessary to make sure it does. Right? And, you know, what this does for you as the person being held accountable, is it creates clarity of expectation for how you are doing.