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 two heights? High of a level. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on the 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, a 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. Let's put it this way. Imagine that the smallest detail in a project is a Lego piece. And someone hands you a bucket of Lego pieces. And 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. Other 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. It starts as low as $5 a month. And 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, obviously, and they have a lot of hardware options, and their next-generation network. Linode delivers the perfect balance of the performance you expect at a price that you don't. And you can get started on Linode today with $20 worth of credit. For listeners of this show, head over to linode.com slash developer T. Use the promo code developer T 2020. That's developer T 2020 at checkout. Thanks again to Linode for sponsoring today's episode of Developer T. 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 own experience, 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. And 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. This 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 100 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 say, when you point to that abstraction, we both know what you mean. And 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. So dispel with the idea that managers can manage bigger, more hairy levels of detail. That they can manage ten 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. And so this requires that we collaborate. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Linode. With Linode, you can get $20 worth of credit on any of their plans and services. By the way, those plans start at $5 a month. Head over to linode.com slash developer tea. To get started today, use the code developer tea 2020 at checkout. By the way, Linode is hiring. Head over to linode.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 Cottrell. And until next time, enjoy your tea. Thank you.