Vox

Leitura de 12 min

Management Anti-Patterns - Implicit Assignment of Responsibility

Summary

This episode examines a common management anti-pattern: the implicit assignment of responsibility. Host Jonathan Cottrell begins by asking listeners to write down their top three responsibilities for the day, then uses the metaphor of a seatbelt to illustrate how we often misattribute responsibility. A seatbelt’s actual responsibility is to withstand specific engineered forces, not to “keep us safe”—a broader outcome influenced by many factors beyond its control.

The discussion extends this concept to professional contexts, particularly email systems. Many professionals wrongly assume that clearing their inbox means they’ve fulfilled their communication responsibilities, ignoring the need to evaluate information sources and engage in proactive communication. This pattern of offloading responsibility onto systems rather than maintaining personal accountability creates inefficiencies and misunderstandings.

In management contexts, this manifests as believing managers must know more than everyone they supervise, or that developers are merely responsible for executing specified tasks rather than thinking critically about solutions. The episode connects this to software design principles, specifically the Single Responsibility Principle in object-oriented design, which emphasizes clear, limited scope for each component.

The final section encourages listeners to revisit their listed responsibilities and consider whether they’re properly attributing accountability. By making responsibilities explicit rather than implicit—whether dealing with people, code, systems, or organizational departments—we can better understand reciprocal obligations and improve how we interact with all entities in our professional ecosystem.

Recommendations

Concepts

  • Risk Compensation — Mentioned in the context of seatbelt safety—the phenomenon where safety devices might encourage riskier behavior, affecting overall safety outcomes beyond the device’s direct control.
  • Single Responsibility Principle — A principle of object-oriented software design that addresses the same issue of misunderstanding responsibility scope. The episode encourages listeners to Google this concept for deeper understanding.

People

  • Jonathan Cottrell — The host of Developer Tea podcast, who presents the episode’s content and can be reached on Twitter @JayCottrell or via email at developertea@gmail.com for feedback.

Resources

  • Developer Tea podcast — The podcast itself, where this and other episodes can be found at spec.fm. Listeners are encouraged to share this episode with others who might appreciate the content.

Topic Timeline

  • 00:00:00 — Introduction and responsibility exercise — Jonathan Cottrell introduces the episode and asks listeners to write down their top three responsibilities for the day. He explains that the episode will explore our relationship with assigning responsibility, particularly focusing on management anti-patterns. The goal is to help developers find clarity and purpose in their careers by examining how responsibility is often misattributed.
  • 00:01:47 — The seatbelt metaphor for responsibility — Cottrell introduces the seatbelt as a metaphor for examining responsibility. While many would say a seatbelt’s responsibility is to “keep us safe,” this is actually too broad—safety depends on many factors beyond the seatbelt’s control. The seatbelt’s actual responsibility is more specific: to withstand the forces it was engineered to handle. This illustrates how we often assign responsibility at too high a level.
  • 00:03:13 — Risk compensation and agency — The discussion introduces the concept of risk compensation—how safety devices like seatbelts might encourage riskier behavior, actually affecting overall safety outcomes. The key point is that seatbelts have no agency; they cannot make choices. This reinforces the importance of defining responsibility based on what an entity can actually control, not desired outcomes.
  • 00:04:12 — Email systems as universal example — Cottrell applies the seatbelt metaphor to professional communication, using email as a universal example. Many people wrongly believe that clearing their inbox means they’ve fulfilled communication responsibilities. This is flawed because it ignores the need to evaluate information sources and engage in proactive communication rather than just reactive responses.
  • 00:05:17 — Management misconceptions about responsibility — The episode examines how managers often misunderstand their responsibilities. One common error is believing managers must know more than everyone they supervise—an impossible standard. Another is treating developers as mere executors of specified tasks rather than critical thinkers who should collaborate on solutions. Both represent implicit, unrealistic assignments of responsibility.
  • 00:06:18 — Connection to software design principles — Cottrell connects the discussion to software design, specifically the Single Responsibility Principle in object-oriented design. This principle addresses the same issue: misunderstanding the scope of responsibility. Developers often wrongly attribute responsibility to test suites for software reliability, when actually test suites only execute tests and report results—the human maintains responsibility for quality.
  • 00:07:33 — Practical application and conclusion — Listeners are encouraged to revisit their listed responsibilities and consider whether they’re properly attributing accountability. The episode concludes by emphasizing the importance of making responsibilities explicit rather than implicit when dealing with people, code, systems, or organizational departments. This clarity helps understand reciprocal obligations and improves professional interactions.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-01-20T10:00:00Z
  • Duration: 00:09:30

References

Podcast Info

Transcript

[00:00:00] If you’re listening to this episode in the morning, I want you to find a few moments

[00:00:12] whenever you are not driving, for example, where you can sit with a piece of paper and

[00:00:19] I want you to write down your top three responsibilities today.

[00:00:24] And then I want you to listen to the rest of this episode and then I want you to revisit

[00:00:31] those top three responsibilities and see if your perspective has changed.

[00:00:37] In today’s episode, we’re talking about our relationship with assigning responsibility.

[00:00:43] My name is Jonathan Cottrell and you’re listening to Developer Tea and my goal on the show is

[00:00:47] to help driven developers like you find clarity, perspective, and purpose in their careers.

[00:00:52] And this week on Developer Tea,

[00:00:54] we’re talking about how to be a better developer.

[00:00:54] We’re talking about management anti-patterns.

[00:00:57] We’re going to cover all of them.

[00:00:59] There are so many, so many ways to be wrong as managers.

[00:01:03] And as we said in the last episode, everyone is a manager of something.

[00:01:08] You manage your own time at the very least.

[00:01:11] And at the very most, you are responsible for managing a whole lot more than that.

[00:01:19] Being a manager requires some delicate mixture of

[00:01:24] being a manager and being a manager.

[00:01:24] Tapping into the things that make us uniquely human, but also being aware of the weaknesses

[00:01:34] that come along with being human.

[00:01:37] And one of the weaknesses that comes along with being human is incorrectly assigning

[00:01:43] responsibility.

[00:01:45] So I want you to do a very simple exercise.

[00:01:47] Of course, you’ve already written down your top three responsibilities for today, but

[00:01:51] now I want you to think about the responsibilities of being a manager.

[00:01:54] And I want you to think about the responsibility of a seatbelt.

[00:01:58] When you get in your car, you can put a seatbelt on.

[00:02:01] And if you use a seatbelt, on average, you’re going to be much safer.

[00:02:06] You’re going to end up being much safer in the event of a wreck.

[00:02:12] So what is the responsibility of the seatbelt?

[00:02:14] And the easiest kind of intuitive answer is the responsibility of a seatbelt is to keep us safe.

[00:02:21] If you have an engineering mindset, you may also,

[00:02:24] dive into the responsibility of a seatbelt based on the manufacturer’s

[00:02:29] kind of details about that seatbelt.

[00:02:32] What load will that seatbelt hold?

[00:02:35] But if you think about this from too high of a level,

[00:02:38] then you assign the responsibility of keeping us safe to the seatbelt.

[00:02:43] You ignore the fact that safety is outside of the scope of all that a seatbelt can control.

[00:02:52] Of course, this specific,

[00:02:54] kind of situation doesn’t matter as much as the metaphor matters.

[00:02:58] So let’s follow through with the example,

[00:03:00] and then we can kind of extrapolate it into our work as developers.

[00:03:05] If you think about the responsibility of the seatbelt to keep us safe,

[00:03:10] you ignore the fact that, for example,

[00:03:13] seatbelts may make people feel as though they can take more risks and average out to be safer than without a seatbelt.

[00:03:23] This idea,

[00:03:24] is called risk compensation.

[00:03:27] And of course,

[00:03:28] a seatbelt cannot control for that because the contract that you’ve signed with the seatbelt,

[00:03:35] the level of responsibility that a seatbelt can have,

[00:03:40] well,

[00:03:40] it has no agency.

[00:03:41] For example,

[00:03:42] the seatbelt cannot choose anything.

[00:03:46] The seatbelt’s responsibility then is better labeled as to withstand the forces that it was engineered to,

[00:03:54] whether it’s a vehicle,

[00:03:54] or what it is,

[00:03:57] or goal,

[00:03:58] it’s a huge stuff to deal with.

[00:04:00] So what does park a seatbelts mean?

[00:04:02] Always start you with standing.

[00:04:05] So why have we talked so much about seatbelts in this episode?

[00:04:07] And what does it have to do with your career and with your management style?

[00:04:12] Well,

[00:04:12] it’s easy for us to implicitly assume responsibility that doesn’t exist.

[00:04:20] One of the most universal examples of this that exists in

[00:04:23] virtually,

[00:04:23] every,

[00:04:24] our emailing systems. For example, we believe that as long as we have caught up to our inboxes,

[00:04:32] as long as we have responded to every email, that our communications, our professional

[00:04:38] communications are taken care of. We’ve offloaded our responsibility of being caught up to an inbox.

[00:04:48] And this idea is broken because if all we’re doing is checking our inboxes and replying to emails,

[00:04:57] then everyone else is doing the same thing. Then we have to evaluate the source of the information.

[00:05:04] And of course, this applies in so many scenarios when we begin to talk about management, management

[00:05:10] of our time and of other human resources. If we are a manager, for example, we may wrongly believe

[00:05:17] that our response to emails is not the same as the response to emails.

[00:05:18] Our responsibility as a manager is to know more than everyone that we manage.

[00:05:25] This is kind of an impossible scenario to live up to. Similarly, we may wrongly communicate

[00:05:32] that the individual developers on our team are only responsible for executing cards that come

[00:05:41] through, that all of their work should be directly controlled by some other system.

[00:05:48] And that their job is only to execute whatever was specified. And typically, this is a wrong picture

[00:05:57] of the responsibility of a developer. A much better picture of the responsibility of a developer is

[00:06:02] to think and process those incoming specifications and to collaborate with other developers and

[00:06:11] figure out what the best solution is to address those things. This also has implications into

[00:06:16] the actual design of our software.

[00:06:18] In fact, this is so applicable that there is a principle of object-oriented software design

[00:06:24] called the single responsibility principle. We’ve talked about it on the show before,

[00:06:28] and I encourage you to go and Google it. But the simple concept here is that we very often

[00:06:35] misunderstand the scope of responsibility. And usually, this is done in a way that makes it

[00:06:44] simpler to understand responsibility. For example,

[00:06:48] if I’m a developer and I’m working on a project, I’m going to be working on a project that’s going to

[00:06:48] I believe that part of my responsibility is to ensure the reliability of the software that I

[00:06:55] deliver. Well, I may wrongly take that responsibility off of me as a human and try to put it onto my test

[00:07:04] suite. And of course, test suites don’t have the ability to catch every single bug. Test suites are

[00:07:10] only as good as the person that’s writing them. And even then, they fall behind. And so it’s much

[00:07:16] better for a human to catch every single bug. And so it’s much better for a human to catch every single

[00:07:18] bug. And so it’s much better for a human to catch every single bug. And so it’s much better for a human to

[00:07:18] to carry that responsibility and to use the test suite as a tool. The fundamental level, the test

[00:07:25] suite’s only responsibility is to execute the test and report the results back to you. So I want you

[00:07:33] to go back and look at your top three responsibilities today and consider whether there are

[00:07:39] other responsibilities that you should have in mind. Performing this same exercise with almost

[00:07:45] everything that you deal with, whether it’s a person,

[00:07:47] a piece of code that you’re working on, maybe a system or a department in an organization that

[00:07:56] you’re working with, figuring out what the responsibility is of all of these entities

[00:08:01] in an explicit way rather than an implicit way. Being able to identify this directly

[00:08:07] can better help you understand kind of your reciprocal responsibility. There’s a lot of

[00:08:15] assumed responsibilities. There’s a lot of assumed responsibilities. There’s a lot of assumed

[00:08:17] responsibilities. A lot of implicit responsibilities that if we were to ask

[00:08:21] who or what is responsible for this particular aspect of the thing, then perhaps the way that

[00:08:30] we treat those systems, the way we treat those people, those different entities would change

[00:08:34] drastically. Thank you so much for listening to today’s episode of Developer Tea. I hope you will

[00:08:41] think a little bit more about where you assign responsibility and ways that maybe you are

[00:08:47] assigning responsibility improperly today. Thank you so much for listening to today’s episode.

[00:08:53] In lieu of a sponsor today, I’d love for you to share this episode with someone

[00:08:57] you believe will appreciate the content. Additionally, I’d love to hear your feedback.

[00:09:03] You can reach out to me on Twitter at at Jay Cottrell, and of course at Developer Tea.

[00:09:08] You can always email me as well at developertea at gmail.com. Today’s episode and every other

[00:09:14] episode of Developer Tea can be found at spec.fm.

[00:09:17] Today’s episode was produced by Sarah Jackson. My name is Jonathan Cottrell,

[00:09:21] and until next time, enjoy your tea.

Visão de gráfico