If you're listening to this episode in the morning, find a few moments with a piece of paper to write down your top three responsibilities for this week. In today's episode, we're talking about assigning responsibility.
There are so many ways to be wrong as a manager and this week, we're talking about management anti-patterns. One thing we all do is assign responsibility to ourselves and possibly to others around us.
In today's episode, we're talking about our relationship with assigning responsibility.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
If you're listening to this episode in the morning, I want you to find a few moments, whenever you are not driving, for example, where you can sit with a piece of paper. And I want you to write down your top three responsibilities today. And then I want you to listen to the rest of this episode, and then I want you to revisit those top three responsibilities and see if your perspective has changed. In today's episode, we're talking about our relationship with assigning responsibility. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And this week on Developer Tea, we're talking about management anti-patterns. We're going to cover all of them. There are so many ways to be wrong as managers. And as we said in the last episode, everyone is a manager of something. You manage your own time at the very least. And at the very most, you are responsible for managing a whole lot more than that. Having a manager requires some delicate mixture of tapping into the things that make us uniquely human, but also being aware of the weaknesses that come along with being human. And one of the weaknesses that comes along with being human is incorrectly assigning responsibility. So I want you to do a very simple exercise. Of course, you've already written down your top three responsibilities for today. But now I want you to think about the responsibility of a seatbelt. When you get in your car, you can put a seatbelt on. And if you use a seatbelt on average, you're going to be much safer. You're going to end up being much safer in the event of a wreck. So what is the responsibility of the seatbelt? And the easiest kind of intuitive answer is the responsibility of a seatbelt is to keep us safe. If you have an engineering mindset, you may also dive into the responsibility of a seatbelt based on the manufacturers' kind of details about that seatbelt. What load will that seatbelt hold? But if you think about this from too high of a level, then you assign the responsibility of keeping us safe to the seatbelt, you ignore the fact that safety is outside of the scope of all that a seatbelt can control. And of course, this specific kind of situation doesn't matter as much as the metaphor matters. So let's follow through with the example and then we can kind of extrapolate it into our work as developers. If you think about the responsibility of the seatbelt to keep us safe, you ignore the fact that, for example, seatbelts may make people feel as though they can take more risks and average out to be safer than without a seatbelt. This idea is called risk compensation. And of course, a seatbelt cannot control for that because the contract that you've signed with the seatbelt, the level of responsibility that a seatbelt can have has no agency, for example. The seatbelt cannot choose anything. The seatbelt's responsibility then is better labeled as to withstand the forces that it was engineered to withstand. So why have we talked so much about seatbelts in this episode and what does it have to do with your career and with your management style? Well, it's easy for us to implicitly assume responsibility that doesn't exist. One of the most universal examples of this that exists in virtually every business scenario is email. We put a lot of responsibility on our emailing systems. For example, we believe that as long as we have caught up to our inboxes, as long as we have responded to every email, that our communications, our professional communications are taking care of. We've offloaded our responsibility of being caught up to an inbox. And this idea is broken because if all we're doing is checking our inboxes and replying to emails, then everyone else is doing the same thing. Then we have to evaluate the source of the information. And of course, this applies in so many scenarios when we begin to talk about management. Management of our time and of other human resources. If we are a manager, for example, we may wrongly believe that our responsibility as a manager is to know more than everyone that we manage. This is kind of an impossible scenario to live up to. Similarly, we may wrongly communicate that the individual developers on our team are only responsible for executing cards that come through. That all of their work should be directly controlled by some other system. And that their job is only to execute whatever was specified. And typically, this is a wrong picture of the responsibility of a developer. A much better picture of the responsibility of a developer is to think and process those incoming specifications and to collaborate with other developers and figure out what the best solution is to address those things. This also has implications into the actual design of our software. In fact, this is so applicable that there is a principle of object-oriented software design called the single responsibility principle. We've talked about it on the show before, and I encourage you to go and Google it. But the simple concept here is that we very often misunderstand the scope of responsibility. And usually this is done in a way that makes it simpler to understand responsibility. For example, if I believe that part of my responsibility is to ensure the reliability of the software that I deliver, I may wrongly take that responsibility off of me as a human and try to put it onto my test suite. And of course, test suites don't have the ability to catch every single bug. Test suites are only as good as the person that's writing them and even then they fall behind. And so it's much better for a human to carry that responsibility and to use the test suite as a tool. The fundamental level, the test suite's only responsibility is to execute the test and report the result back to you. So I want you to go back and look at your top three responsibilities today and consider whether there are other responsibilities that you should have in mind. Doing the same exercise with almost everything that you deal with, whether it's a person, a piece of code that you're working on, maybe a system or a department in an organization that you're working with, figuring out what the responsibility is of all of these entities in an explicit way, rather than an implicit way. Being able to identify this directly can better help you understand kind of your reciprocal responsibility. There's a lot of assumed responsibilities, a lot of implicit responsibilities that if we were to ask who or what is responsible for this particular aspect of the thing, then perhaps the way that we treat those systems, the way we treat those people, those different entities would change drastically. Thank you so much for listening to today's episode of Developer Tea. I hope you will think a little bit more about where you assign responsibility and ways that maybe you are assigning responsibility improperly today. Thank you so much for listening to today's episode. In lieu of a sponsor today, I'd love for you to share this episode with someone that you believe will appreciate the content. Additionally, I'd love to hear your feedback. You can read out, reach out to me on Twitter at ad.jcatrall and of course at Developer Tea. You can always email me as well at developerteatatgmail.com. Today's episode and every other episode of Developer Tea can be found at speck.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.