Vox

Leitura de 14 min

Taking Personal Accountability for Systematic Failures

Summary

The episode begins by distinguishing between common discussions about psychological safety and blameless retrospectives, and the more challenging practice of taking personal accountability for systematic failures. While blameless retros focus on systemic issues without assigning blame to individuals, the host argues that we still make personal mistakes daily that require accountability, often of a repetitive or systematic nature rather than one-off operational errors.

The core of the episode presents a practical exercise: recall a recent situation where you felt defensive about your work, where you explained away problems by citing systematic reasons. The exercise involves writing down three things you personally could have done or can do to improve that situation, focusing solely on your own actions without debating whether they were expected or obvious in hindsight. The goal is to cultivate comfort with taking responsibility for larger, systematic mistakes as a pathway to growth.

The host emphasizes that this personal accountability exercise complements, rather than replaces, systematic investigations. The key insight is that accountability isn’t about accepting blame but about recognizing what went wrong and committing to actionable improvements. By focusing on three forward-looking actions, individuals can transform defensive reactions into opportunities for personal and professional development.

Recommendations

Communities

  • Developer Tea Discord — A Discord community mentioned at the end of the episode where listeners can discuss topics like personal accountability. Described as having meaningful, meaty discussions rather than surface-level chat, and is offered as a free resource.

Tools

  • Jam — A sponsored tool described as ‘Developer Friendly Bug Reports in a single click.’ It automatically captures videos, console logs, and network requests to create perfect, context-rich bug reports, saving engineers time spent chasing information.

Topic Timeline

  • 00:00:00 — Introduction to the challenge of being wrong — The episode opens by framing the difficulty of learning how to behave when you’re wrong and need to take accountability. It differentiates this topic from the more common discussions about psychological safety and blameless retrospectives in engineering teams.
  • 00:02:26 — Distinguishing between operational and systematic mistakes — The host contrasts production incidents (which are often treated as rites of passage) with the more common problem of systematic, repetitive issues. Examples include design decisions causing performance problems, where the focus shifts from individual mishaps to judging intentional work.
  • 00:06:43 — Introducing the personal accountability exercise — After a sponsor break, the host introduces a simple exercise: think of a time you felt defensive about your work, where you explained problems away by citing systematic reasons. The goal is to move beyond that defensiveness and identify personal responsibility.
  • 00:09:10 — The three-things heuristic for improvement — The core of the exercise is revealed: write down three things you personally could have done or can do to improve the situation. The rules exclude discussions about whether actions were expected or obvious in hindsight, focusing purely on forward-looking personal responsibility.
  • 00:12:01 — Accountability as the pathway to growth — The host reframes accountability not as accepting blame but as recognizing what went wrong and committing to action. This personal exercise complements systematic investigations, ensuring individuals don’t only look at system-level accountability while avoiding personal responsibility.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2024-03-08T08:00:00Z
  • Duration: 00:14:38

References

Podcast Info

Transcript

[00:00:00] One of the more difficult skills you can learn is how to be wrong, how to be when you are

[00:00:22] wrong.

[00:00:23] How should you react?

[00:00:25] How should you behave and interact with other people when you’ve recognized something that

[00:00:32] you need to take accountability for?

[00:00:37] We’re going to do a little bit of an exercise in this episode, but I want to kind of differentiate

[00:00:44] this from a more in vogue concept, the idea of having a psychologically safe environment.

[00:00:54] Being afraid to fail or holding a blameless retro, these are things that we discuss regularly.

[00:01:05] We don’t want our engineers, if you’re an engineering manager, you don’t want your engineers

[00:01:12] to be afraid to fail.

[00:01:14] This is a very common saying.

[00:01:17] You want people to be able to fail and learn from it.

[00:01:23] So we have these blameless retros where we review something that has gone wrong and we

[00:01:31] try to figure out what it was that caused the issue without necessarily making any one

[00:01:37] person the point of concern.

[00:01:44] But the truth of the matter, while these blameless retros provide hopefully a more psychologically

[00:01:53] safe environment to fail in, the truth of the matter on the other side is that we do

[00:02:00] indeed make mistakes.

[00:02:04] We have the opportunity to fail every day.

[00:02:12] And very often, the kinds of mistakes that require some level of accountability are not

[00:02:19] the same kind that you’re likely to see in a retro.

[00:02:26] Doing something that takes down production is a rite of passage.

[00:02:31] You’ve probably done this before.

[00:02:33] And this kind of operational mistake or pushing a bug to production, these kinds of mistakes

[00:02:40] are the kinds that tend to feel safer, generally speaking.

[00:02:46] It’s a fairly rare occurrence for someone to experience a significant negative job impact

[00:02:56] over a single bug, over an incident that occurs or over one kind of mishap.

[00:03:06] The more common problem that we have is what we’re going to explore today.

[00:03:11] The kinds of things that we make mistakes on are that we should hold ourselves accountable

[00:03:16] to are less about individual mistakes and much more about systematic issues, issues

[00:03:25] of repetitive nature.

[00:03:28] An example of this might be something like a design decision that your team made and

[00:03:35] moved forward with that’s causing a performance problem.

[00:03:39] This is a situation where instead of saying, oh, look at us, we made a mistake.

[00:03:46] We must not have had our coffee that morning.

[00:03:49] You instead are looking at a systematic decision that was made.

[00:03:56] You’re judging the intentional work that was done.

[00:04:03] We’re going to take a quick sponsor break and then when we come back, we’re going to

[00:04:05] do a little exercise that will hopefully help you dig out things that you might need or

[00:04:13] benefit from taking accountability for.

[00:04:22] Today’s episode is sponsored by JAM.

[00:04:25] JAM is Developer Friendly Bug Reports in a single click.

[00:04:29] If you’re a developer, you probably are if you’re listening to this episode, you may

[00:04:34] work on a team, you may have a front end web product that you work on, and you probably

[00:04:41] have had quite a few bug reports.

[00:04:45] The quality of your bug reports, if they’re like most, are all over the map.

[00:04:51] Maybe you get one from an engineer that has all of the context you need, but more often

[00:04:56] you’re probably getting these with very little context, maybe just a text description.

[00:05:03] Maybe the screenshot is only partial.

[00:05:05] You don’t know what kind of browser they’re using, you know, what kind of phone maybe

[00:05:10] they’re on, on a mobile device.

[00:05:13] You have to go chasing information.

[00:05:15] And this takes up the majority of your bug resolution time.

[00:05:21] Think about it.

[00:05:23] Instead of fixing the problem, you’re going to talk to the person to try to figure out

[00:05:27] what the problem is in the first place, and you go over weeks of back and forth in ticket

[00:05:35] comments and quick Zoom calls.

[00:05:38] So many variables that you had to nail down that can contribute to the application state

[00:05:43] during a bug.

[00:05:45] Zoom is solving this problem by making it impossible to file a bug issue without all

[00:05:52] of that information.

[00:05:54] It’s a free tool that saves software engineers a ton of time and frustration.

[00:05:59] More than 75,000 people are using it.

[00:06:02] It forces the perfect bug report.

[00:06:05] You can’t do it wrong.

[00:06:06] It includes a video of the bug.

[00:06:08] It includes your console log, your network requests, all the information you need to

[00:06:13] be able to debug it.

[00:06:15] Using Jam, you can go from having a bug report that doesn’t have much information at all

[00:06:20] to having something that’s so descriptive you could turn around and make an automated

[00:06:23] test just by copying the attributes from the report.

[00:06:26] Go and check it out.

[00:06:27] It’s at jam.dev to get started totally free.

[00:06:30] That’s jam.dev, jam.dev.

[00:06:35] Thanks so much to Jam for sponsoring today’s episode of Developer Tea.

[00:06:43] So the exercise we’re going to do is very simple.

[00:06:49] It’s very simple.

[00:06:50] I want you to think about the last time your work could have been called into question.

[00:06:59] And you probably have a feeling of defensiveness.

[00:07:03] If this is the right selection, the right thing to think about, I want you to think

[00:07:08] about some time where you felt like you had to defend your work, where you had to defend

[00:07:13] your team, or you had to explain why did something go wrong.

[00:07:19] And the undertone of your explanation is, well, this wasn’t really our fault.

[00:07:26] I can see how you would think it was our fault, but it wasn’t really our fault.

[00:07:30] It was actually the fault of, and then you list the systematic reasons or what led you

[00:07:35] to get to that place.

[00:07:38] And all of this information may actually be true.

[00:07:43] All of the information that you identified in this list may actually be accurate.

[00:07:50] And this is the kind of thing that we do in a blameless retro.

[00:07:53] It is a useful exercise to try to recognize what kinds of systematic issues would cause

[00:08:00] problems like this, because the assumption in a blameless retro is that a, we don’t have

[00:08:10] any malicious people who would cause this problem on purpose, and c, that we believe

[00:08:16] that the people who are doing this job are competent.

[00:08:19] We’re not here to litigate whether they are capable of doing the job.

[00:08:23] Instead, we are assuming they are capable of doing a particular job, and we’re trying

[00:08:28] to find the systematic issues that result in these problems despite those three things

[00:08:33] being true.

[00:08:36] So we have this baseline assumption in a blameless retro, but I want you to take this idea, this

[00:08:44] feeling that you have of, okay, we kind of escaped the pressure.

[00:08:50] We escaped the sense of direct accountability by focusing the issue on a larger thing, on

[00:09:03] a larger problem.

[00:09:07] Now here is the exercise.

[00:09:10] I want you to write down three things, three things that you personally could have done

[00:09:20] or can do to improve the situation.

[00:09:24] This is a very simple heuristic.

[00:09:28] Three things that take you towards a better future or could have helped you avoid a worse

[00:09:35] past.

[00:09:36] And here’s the thing.

[00:09:38] We’re not going to bring into discussion whether or not you think that those things were expected

[00:09:44] or part of your job.

[00:09:47] We’re not going to discuss whether there’s hindsight, is 2020 here?

[00:09:53] Looking back, you could have done x, but how could you have known that you could do x?

[00:09:58] Those discussions are off limits for this exercise.

[00:10:02] The goal here is to learn how to get comfortable with taking responsibility for something more

[00:10:14] than just a mishap.

[00:10:16] Taking responsibility for larger mistakes, larger things that do have systematic interactions.

[00:10:25] What part of responsibility can you take?

[00:10:29] And the important thing here, perhaps one of the most important parts of this exercise

[00:10:33] is that forward-thinking responsibility.

[00:10:37] We’re not talking necessarily about just falling on your sword here.

[00:10:40] That’s not the goal of the exercise.

[00:10:42] The goal of the exercise is to try to improve.

[00:10:46] Not try to figure out who else needs to improve or what system should improve, but you personally.

[00:10:53] How do you grow and get better from this situation?

[00:10:59] Focus on that idea of three actions that could take you in the future, and I would

[00:11:08] even say if you’re struggling in which direction you should look, then the future is almost

[00:11:13] always a better option.

[00:11:17] Taking you to a better place in the future.

[00:11:20] What are the three things that you can do in response to this specific circumstance

[00:11:25] that move you towards a better outcome?

[00:11:30] These three things will help you grow.

[00:11:33] This lens is going to improve your way of thinking the next time you make a mistake.

[00:11:40] You will make another mistake.

[00:11:42] There’s one lurking around the corner right now.

[00:11:45] If you don’t like the feeling that you have when you’re making excuses, if you don’t

[00:11:52] the fight or flight mode of having to justify why you went the direction you went.

[00:12:01] If that’s uncomfortable, then I encourage you to get more comfortable with the idea

[00:12:07] that accountability is the other side of the coin of growth.

[00:12:16] Accountability is not just saying, okay, you can point at me for what went wrong.

[00:12:25] Accountability is saying, I am recognizing what went wrong and I’m going to do something

[00:12:31] about it.

[00:12:32] I could have done something about it.

[00:12:34] I’m checking into what I could have done personally to have avoided this mistake.

[00:12:44] Hear me very loud and clear that this is not a one-to-one substitute for something

[00:12:50] like a systematic investigation.

[00:12:53] There are indeed many system level effects that would cause somebody who is very good

[00:12:59] at their job to still fail and those should be investigated.

[00:13:04] But you shouldn’t only look at the ways to hold a system accountable, devoid of holding

[00:13:11] yourself accountable.

[00:13:13] Thanks so much for listening to today’s episode of Developer T. Thank you to today’s sponsor

[00:13:18] Jam.

[00:13:19] Head over to jam.dev.

[00:13:20] It’s totally free to get perfect bug reports right now.

[00:13:24] That’s jam.dev.

[00:13:27] If you enjoyed this episode and you’d like to listen to more episodes of this show, you

[00:13:31] can make sure you don’t miss out by subscribing to whatever podcasting app you’re currently

[00:13:35] using, your favorite podcasting app, hopefully, and you will get this show delivered to you

[00:13:41] every time we publish, which right now is on a cadence of about two episodes a week.

[00:13:47] If you enjoyed this episode, you can also join the Developer T Discord community.

[00:13:52] We’re talking about these kinds of topics on a pretty regular basis there.

[00:13:55] It is not an overwhelmingly chatty Discord.

[00:13:59] It is one that is full of meaningful content, but it’s not just, you know, kind of surface

[00:14:09] level discussions.

[00:14:10] Usually people are asking meaty questions in the Discord community.

[00:14:14] Go and check it out.

[00:14:15] It’s at developert.com slash Discord.

[00:14:17] It’s totally free.

[00:14:18] We’re not trying to monetize that community right now.

[00:14:21] We’ve made a commitment to make it a free resource for everyone who uses it.

[00:14:26] That’s developert.com slash Discord.

[00:14:28] Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico