so let's set the scene for a moment you're in your stand-up and everyone is giving their updates what they did yesterday what they're planning on doing today and the dreaded blockers and 95 of the time all of your teammates probably say nothing's blocking me or maybe they say something that has been blocking them you know for months at a time but the status quo is that this isn't really much of a talking point most of the time we don't talk about blockers very often and then it comes around to you now the truth is you are actually blocked and you start to share that and your manager swoops in and says that they will work immediately to get you unblocked now this is generally speaking probably a functional team but it doesn't have to be like this every time in fact if you find yourself repeatedly getting blocked especially for the same reasons over and over well the system has a problem and we're going to talk about the four main root causes of getting blocked in today's episode my name is jonathan you're listening to developer team my goal on this show is to help driven developers like you find clarity perspective and purpose in their careers this is a problem even if it doesn't feel like it we might believe and this is true that we can't avoid every instance of getting blocked we should just deal with it as it comes but the truth is that we should probably be thinking about common root causes and addressing those if we can instead of using our manager privileges to just save the day every time the manager doesn't have to be a manager to be able to do that but he does have to be a manager to be able toension him andension him andension him andension him andension him andension him andension him and one, right? This is the most common cause I've seen at least, is a lack of clarity. This is so common that we put it into the kind of tagline of this show. The mission of this show is to help you find clarity. And this is true not just for your career, but in your day-to-day work, finding clarity about what you should be doing. And so the most common cause I've seen of blocked engineers is indeed a lack of clarity. Like for example, I'm not sure what to do in this particular edge case. The spec doesn't explain it. It's ambiguous. This is such a common problem. This is kind of par for the course. No one is necessarily at fault here. Sometimes our specs are just not complete. The user story doesn't cover every possible avenue. The states in the design are not necessarily completely thorough, right? There's a lot of reasons this can happen. But if this is happening constantly, right? If this is happening on every story that you pick up, for example, a few things might be wrong. One, the spec just isn't detailed enough, right? This is a balance that you have to strike, but this one seems kind of obvious. It might be time to audit how the work is being specified, at what level of detail. And if you are commonly needing more detail, perhaps the spec is not the best fit for you. So, if you're not sure what to do, you can always look at the spec and see what's going on. And if you're not sure what to do, you can also look at the spec and see what's going on. And if you're not sure what The specification process itself should be refactored. A second cause for this kind of lack of clarity, uh, is that the engineer isn't familiar enough with the product to fill in the gaps. Sometimes the spec leaves off in a reasonably detailed place, and kind of expects the engineer to interpolate as needed. But if the engineer is new to this problem domain, or new to this specific product, uh, they might take some time to develop that intuition. And so the fix for this is not easy. It might just take some time. Another fix might be having another engineer who does have that intuition come in and help and perhaps even review the code that they're writing. Talk about those solutions together. However, perhaps the most important kind of sub-bullet that I want to talk about when it comes to lack of clarity or an engineer feeling like they're blocked because they don't have clarity on a particular decision is that an engineer may have a lack of agency in making their own product-level decisions. What does this mean? Well, when you run into that edge case, what would you as the engineer choose to do? Without asking anybody else. At some point, it is likely helpful to allocate some of this agency to the engineers themselves to make decisions in the face of ambiguity. And if their decisions are wrong, it's likely wrong in a very low-stakes way. And it's likely not going to cause a serious issue, a problem that takes down production. If you are a manager, consider pushing this. This idea of agency forward. Consider giving your engineers the green light to make decisions on their own when they aren't certain about how something works. In the worst case, you can just roll back. But in the best case, your engineers are much less often blocked. So that covers the first category of reasons why engineers tend to get blocked is lack of clarity. The second reason why engineers tend to get blocked is lack of clarity. They may have a producer who may have signed off on bringing these players together and bringing these players together. All right, this can come about for a lot of reasons. Sometimes access is necessarily held to a smaller group of people. And in this case, we're talking about access to, for example, some production resources, right? Now, here's the problem. If your engineers are situated, organizationally speaking, in a way that their access problems are constantly becoming an issue, where they need access to a particular platform on a regular basis, but they don't have it, right? Then one of two things needs to happen. Either one, they need to be given that access, put into that group, into that small group of people who need that access. Or perhaps more effectively, your organization could be changed so that they don't need access to that. Particular resource. What does that mean? Well, in some cases, this might mean simply having a layer between production and development that essentially acts as a pre-production environment that the engineers treat as if it was a production environment. Now, this is just an example, right? This is not a specific solution. It's an example of a way to think about solving these access problems. How can you make the access unnecessary? Rather than making it a blocking problem. We're going to take a quick break and talk about today's sponsor, and then we're going to come back and discuss the other two categories. Developer T is supported by Square. There are millions of sellers across the globe using Square to run every aspect of their business. Many are looking for customized solutions that are deeply connected and easy to use. This is where developers come in. You can grow your business by extending or integrating with Square using free APIs and SDKs to build tools for sellers. Learn more by going to developer T.com slash square. That's developer T.com slash square. Thanks again to Square for sponsoring today's episode of developer T. we're talking about categories of problems kind of general categories of problems that cause developers to get blocked and common root causes of team roadblocks the first one was lack of clarity the second one is access issues the third is a lack of resources this is related in some ways to access issues but a lack of resources in this case could simply mean that you would be able to get your work done that you have in front of you but something that you're waiting on from another team or even from within your own team is unavailable because you either can't pay for it, right? If it's simply a service that might enable you to get your job done. Or because the other team has too much work on their plate, right? The other engineer is not able to get to the thing that you need because they have their own priorities. Now, the second, the third, and the fourth categories all kind of intermingle in some ways. You could imagine how they interact as we go through them. This could be an access issue because perhaps you don't have enough to pay for another seat on a software service, right? So a lack of resources has caused an access issue. So solving the access issue is actually, you know, the real root cause is a lack of resources, right? And this may not actually be a hard restriction. In other words, it might not be a lack of availability. It may just be an allocation problem, a planning problem. And so we shouldn't, you know, read into this as you need more money to be able to unblock people. That's not always necessarily the case. It may be that the resources are there, but they're not being allocated correctly. So a lack of resources, it doesn't mean a global lack or a, or a, you know, company-wide lack of resources. It may simply mean that that engineer is lacking the resources they need. And you as the manager, or you as a, or you as a manager, or you as a manager, or you as a manager, or you as a manager, or you as a co-worker, you have the opportunity to fix that. The fourth and final category, we're just going back through the first three, lack of clarity, access issues, and a lack of resources. The fourth and final category is organizational alignment issues. This one is a hard one to solve. It's even a hard one to detect, especially if the organization has been set up the way that it is for a long time. And, and even worse, if it's worked well for a long time. There might be organizational issues that are causing blocking that are new. The issues have become a problem only recently. And what is this? Well, essentially what it means is your team is trying to work on something. And for some reason related to how the team is situated in the organization, they become blocked. And this might be a reliance on another team's work. It might be a service that's, you know, upstream from them that they're trying to work on. And it might be a service that's, you know, upstream from them that they're trying to work on. And it might be something from and that service, for whatever reason, it's difficult to collaborate with that team, that external team. It could be that the organizational, you know, the meeting times are not aligning with people's schedules, maybe have remote people all over the world. And, you know, you require some kind of scheduling to work properly. And so identifying these organizational issues is critical, right? Let's say, for example, let's take the last one. You have people who are working in different time zones and you have a much longer turnaround for a given issue, a given kind of feature. Finding a way to make that work independent of the people who are in different time zones, right? Perhaps there is, you know, the requirement or the need for someone who is within two or three hours who can approve that work, right? This is a simple example. Someone who is able to approve the work so that you're not blocked until the next day to move forward. These are really simple examples. And in reality, this is a much more complex problem. Most of the time, these kinds of problems are only detected once they have become significant, right? So this is very important to try to keep your finger on the pulse of because your job, especially if you are a manager, this is really where unblocking comes into play. Your job is to make your team as independently maneuverable, independently agile. And I use that term in the truest sense of the word. And if your team is getting stopped by all of these different categorical issues, and if your team is dependent on another team and that kind of dependency is causing problems, if your team is not able to have the resources they need, right? Or if they have a lack of clarity, it is your role, your job to identify and remove those blockers. Not just go and get clarity, not just come in and approve the PR instead of waiting on someone else to do it, but fixing the root problem. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Square. Head over to developertea.com slash square to get started. With Square's free APIs and SDKs, building tools for sellers. Thanks again for listening. And until next time, enjoy your tea.