« All Episodes

Management Anti-Pattern - Detail Abstraction

Published 1/24/2020

The anti-patterns we are talking about today are details. Who manages the details and when is management getting too involved or not getting involved sooner in the details of a project?

🧡 Leave a Review

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.

🍵 Subscribe to the Tea Break Challenge

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/.

🙏 Today's Episode is Brought To you by: Linode

Whether you’re working on a personal project or managing your enterprise’s infrastructure, Linode has the pricing, support, and scale you need to take your project to the next level. Get started on Linode today with a special $20 credit for listeners of Developer Tea.

Visit: linode.com/developertea and use promo code developertea2020

P.s. They're also hiring! Visit https://www.linode.com/careers to see what careers are available to you.

Transcript (Generated by OpenAI Whisper)
If you're standing in a building or maybe you're riding in a vehicle right now, I want you to look around and think about some of the details. The details of why the room is shaped the way that it is or whose decision it was to use those particular colors. Or maybe why is the button on the radio where it is? Whose job is it to manage the details? Not just in this kind of design work, but when we're talking about executing a project, whose job is it to manage the details? And on the flip side, the anti-pattern that we're talking about today, what happens when you try to manage from too high of a level? My name is Jonathan Cutrell, you're listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective, and purpose in their careers. And this happens on teams all the time. This seems to be a misconception about leadership, a misconception about management, the idea that managers are responsible for sitting up at a high level and only getting involved when they're explicitly asked to be involved. And otherwise, looking at the big pieces of the puzzle, moving big blocks around on the project timeline, for example. And while this isn't totally untrue, the manager does need to have kind of a perspective that is zoomed out at times. It is also not a complete representation of the job of the manager. Managing the details is indeed important for the individuals who are contributing to this project. But if the manager tries to manage the big pieces, devoid of those details, then they're very likely to make some, perhaps, very costly mistakes. Think about it this way. Imagine that the smallest detail in a project is a Lego piece. Because someone hands you a bucket of Lego pieces. They ask you to tell them about the Lego pieces that are inside of that bucket. Summarize what is in the bucket. Now, if the bucket has a lid on it and if it's opaque, then really the only information that you're going to be able to have is from shaking it and trying to infer what may be in the bucket. Another information is going to be totally hidden from you, for example, the color. Or maybe whether or not some of those Lego pieces are broken on the inside of that bucket. And when you try to manage a large sum of work in this way, you're going to see similar types of problems. Someone may ask you to estimate how long a given chunk of a project is going to take, for example. This is like trying to estimate how many Legos are in that bucket. And so you might try to wrap your head around it, pick up the bucket, shake it, try to pick up a different bucket, and compare. But at the end of the day, it's all guesses until you pour out those Legos and actually count them. So what do we do to fix this problem? That's what we're going to talk about right after we talk about today's sponsor, Linode. Today's episode is sponsored by Linode. You can do so many things with Linode. For example, you can have a Nanode plan and starts as low as $5 a month. This is a Linux server that you get root access to for $5 a month. Just for the learning benefit of that, it's worth the $5. Much less the fact that it's actually a production level server. You get dedicated CPU plans if you want with physical cores that are reserved just for you. That means that nobody's going to be stealing your cycles. You can even get GPU compute plans that are suitable for things like AI or machine learning and video processing. Linode has 11 data centers worldwide, so latency is going to be at a minimum, including their newest data center in Sydney, Australia. They have enterprise grade hardware in these data centers, S3 compatible storage options, and their next generation network. Linode delivers the perfect balance of the performance you expect at a price that you don't. You can get started on Linode today with $20 worth of credit. For listeners of this show, head over to linode.com slash Developer Tea. Use the promo code Developer Tea 2020 as Developer Tea 2020 at checkout. Thanks again to Linode for sponsoring today's episode of Developer Tea. The management pattern or anti-pattern that we're talking about today is the tendency to try to abstract away details and to imagine that you can do so with some level of repeatability and accuracy. In other words, taking those buckets we were talking about earlier and based on your experience with buckets of Legos, knowing about how many of those Legos are in that bucket. But here's the problem. When you have a bucket that you can't look into, in other words, when you're unaware of the details, in fact, imagine a bucket that you can't even pick up and shake around. You have so little information, somebody tells you about the bucket from a kind of a fuzzy picture that they provide to you. Realistically, you know almost nothing about that bucket. No matter your experience with previous buckets of Legos, this one is going to be invariably different in some way. And maybe you'll get lucky from time to time and get within that 10% kind of number of details that you get right about the bucket, but most of the time, there's going to be some margin of error. And when you stack those margins of error, you end up having perhaps some very big problems. For example, projects that run two times over what they were supposed to run or maybe miscommunications between two different organizations. You may have a lot of tension between one team and another because one team believes that their responsibility doesn't include something, but the other team believes their responsibility does include something. This can happen when we create these abstractions away from the details. And so it doesn't necessarily mean that you have to get in and understand every single detail, but what it does mean is that you need to have a transparent bucket. The simple idea is that the only way for you to understand the units, the abstracted units, is for that information to be accessible in some way. And sometimes that means that you need to rely on your teammates, building trust, for example, so that a teammate can come to you and tell you that they have a hundred Legos that they're going to put into the bucket. But here is the anti-pattern. The belief is that managers should have a superpower or some kind of x-ray vision to see what everyone else doesn't see. To look into those feature buckets or to look into the details and just infer to have a gut intuition or to be able to predict based on some very vague descriptions, what else may be involved. And this is problematic and it happens with developers all the time as well. By the way, this doesn't just apply to managers. It applies at any time when you have an abstract kind of collection of details and you refer to them at that abstract level. When you bucket things together and you don't make them small enough to consume, you very often ignore a lot of those details. They go underserved or maybe you add extra detail that isn't actually even there. Find a way to make those details accessible, visible, and a part of the conversation. Remind yourself constantly that the abstraction includes a lot of complexity or that the abstraction really needs to be detailed out so that we understand the same thing. When you point to that abstraction, we both know what you mean. This can't just be done in one place. It can't just be done in a document. It can't just be done in a single meeting. It's an ongoing representation that has to be shared. It has to be talked about. To spell with the idea that managers can manage bigger, more hairy levels of detail that they can manage 10 times the level of detail that an individual contributor could. This simply isn't true. We can't think about our abstract management as a replacement for that detail. This requires that we collaborate. Thank you so much for listening to today's episode of Developer Tea. Think we're getting to today's sponsor, Linode. With Linode, you can get $20 worth of credit on any of their plans and services. By the way, this plan starts at $5 a month, head over to linneode.com slash Developer Tea. To get started today, use the code Developer Tea 2020 and check out, by the way, Linode is hiring head over to linneode.com slash careers to check out their open positions. Thank you so much for listening to today's episode. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell. Until next time, enjoy your tea.