So let's set the scene for a moment. You're in your standup 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, 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 Cutrell, you're listening to Developer Tea. 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 does feel the duty and the power to come in and unblock. In fact, this is so common that we even put it into our job descriptions. And we feel like it's the right thing to do. Often it is. But if there is a systemic root issue, it needs to be found. We're going to talk about four themes or kind of general categories that these root causes can show up in. The first one, and perhaps the most common 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's story doesn't cover every possible avenue. The states in the design are not necessarily completely thorough. There's a lot of reasons this can happen. But if this is happening constantly, 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. 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 specification process itself should be refactor. The second cause for this kind of lack of clarity is that the engineer isn't familiar enough with the product to fill in the gaps. It sometimes the spec leaves off in a reasonably detailed place and kind of expects the engineer to interpolate as needed. If the engineer is new to this problem domain or new to this specific product, they might take some time to develop that intuition. 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. The most important sub bullet that I want to talk about when it comes to lack of clarity or feeling like they're in 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 and 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. It's likely not going to cause a serious issue, a problem that takes down production. If you are a manager, consider pushing 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, his lack of clarity. The second reason why engineers tend to get blocked is simply access issues. This can come about for a lot of reasons. Sometimes access is necessarily held to a smaller group of people. In this case, we're talking about access to, for example, some production resources. 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, 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 essentially acts as a pre-production environment that the engineers treat as if it was a production environment. This is just an example. 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 Tea 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 developertea.com slash square. That's developertea.com slash square. Thanks again to Square for sponsoring today's episode of Developer Tune. We're talking about categories of problems, general categories of problems that cause Developer To get blocked, and calming 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, if it's simply a service that might enable you to get your job done. Because the other team has too much work on their plate, the other engineer is not able to get to the thing that you need because they have their own priorities. The second, the third and the fourth categories all 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. A lack of resources has caused an access issue. Solving the access issue is actually the real root cause is a lack of resources. This may not actually be a hard restriction. It might not be a lack of availability. It may just be an allocation problem, a planning problem. We shouldn't 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. A lack of resources doesn't mean a global lack or a 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 coworker, you have the opportunity to fix that. The fourth and final category, which is 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 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. What is this? 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. This might be a reliance on another team's work. It might be a service that's upstream from them that they need something from and that's service for whatever reason. It's difficult to collaborate with that team, that external team. It could be that the organizational, the meeting times are not aligning with people's schedules, maybe you have remote people all over the world and you require some kind of scheduling to work properly. Identifying these organizational issues is critical. Let's say for example, let's take the last one that 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. Perhaps there is the requirement or the need for someone who is within two or three hours who can approve that work. 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. This is very important to try to keep your finger on the pulse up because your job, especially if you are a manager, this is really where unblocking comes in to play. Your job is to make your team as independently maneuverable, independently agile. I use that term in the truest sense of the word. 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 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. I think you're again to today's sponsor Square, head over to developertea.com slash square to get started with Squares free APIs and SDKs, building tools for sellers. Thanks again for listening and until next time, enjoy your tea.