Published on 16/06/2022 byNevulo
Being(a phrase used in project management, especially software development in agile teams) typically means there’s something external, outside your control, that is preventing you from making progress in a particular task or project. When this is the case, it can be frustrating, but some blockers are almost impossible to get around.
Think about bringing a new person on the team and bringing them up to speed with the codebase (which will inevitably take some time), or contacting a third party who has long reply times.. Some blockers can’t be solved for. However, some can be. Think about technical blockers, which typically happen when developing or planning a solution in software, and you’re having trouble progressing. Unlike dealing with an external entity that is largely out of our control, we’re really only dealing with ourselves here.
Don’t get me wrong, not all blockers are like this. Regarding technical blockers, you might be faced with technical debt or architectural problems that really do need your attention and take time away from deadlines because that’s ultimately what’s best for the project. There’s a fine balance between quality and producing what you require as fast as possible.
Let’s break this all down. What does being blocked actually look like, and what are some actionable tips for ensuring good flow in a project?
A quick note, what I’m mentioning isn’t necessarily industry standard or anything, but a practical approach to the way I, personally, see blockers. Some can potentially be solved quickly, some probably can’t. Ultimately, to stay productive, we want to try to identify when we’re blocked but also what type of block we’re experiencing.
A lot of my experiences are project management in the eyes of a software engineer, but I’m hoping they apply broadly to other roles.
I see external blockers as true blockers. At the end of the day, if you’re relying on a third party to complete something, and it’s a must-have, there’s probably not much you can do in a practical sense.
A good example of this is a SaaS (software-as-a-service) provider that you’ve made an agreement with, but doesn’t offer exactly what you need.
With some blockers that last a few hours or days, or when you have obligations, it’s not really sensible to entirely change around your approach just to get around one thing.
External blockers give you a good opportunity to pick up new work though to keep up the general flow of the project, ideally work with a turn-around rate that is within the timeframe you’re roughly expecting to be unblocked in.
In a complete worst-case scenario, you can try a few other pragmatic actions:
Internal blockers occur internally within an organisation or team. Common internal blockers include:
A lot of these blockers boil down to the need for more planning. Playing devil’s advocate, there’s also a downside toif you have a strict deadline. If you’re trying to get something done in 3 months, you typically don’t want to spend 2 months planning.
It also comes down to resource and priority management within your team; making sure you’re not spending too much time doing things that don’t bring value to the final results of the project.
This is where you can often put power in your hands and take action towards blockers.
There’s the argument that a personal blocker isn’t really worth noting down as a blocker, but the truth is, we’re all human, and occasionally, we unintentionally go down a rabbit hole, get stuck, or have many priorities.
Some examples that come to my mind for personal blockers include:
It’s true that even some personal blockers take longer than we might expect to get around. But often, I find with personal blockers, there are a few key things I ask myself:
Is there a different, sensible approach to get to the same solution?
Sometimes, we need to settle with a solution for the sake of time that works now, but we might want to change down the line. This can lead to technical debt – and though you don’t want too much, a little isn’t bad. Don’t overshoot for perfection, especially with a strict deadline.
Is there a quicker way to do this?
Instead of doing something manually, could I automate it? If it’s practical, could I get the help from somebody else to solve this faster (through pairing or reviews, for example)?
What resources are available to me to get around this blocker?
Such as asking team members for help, getting in touch with a support person, looking online for documentation to get clarification, etc.
Often, the first thing I’ll do if I’m blocked is try to see if I’m actually blocking myself, as mentioned earlier. If you are, set out to follow a series of logical steps to find a way to unblock yourself.
Ensure you’re not spending too much time in a certain area, and keep track of your personal flow to find room for improvements. Remember – it’s always okay to ask for help!
You want to avoid spending too much time in the wrong areas. Use tools liketo ensure you’re allocating a specific amount of time to certain tasks, or a system like to know ahead of time the amount of effort, risk, or complexity involved with a certain task.
There are a few benefits to picking up new work to get around a blocker in existing work. There’s some research around the fact that, and I’ve personally found this to be true when working through a different problem. Usually, I’ll be able to come back to the original work that was blocked and see with “clearer eyes” 👁
The main thing to watch out for is, which tracks how much time team members actually have to complete tasks given other priorities they’re already working through. In other words – you want to avoid overloading anyone.
Subscribe to the Nevuletter so you never miss new posts.