There are 2 things even the most opinionated software engineers can agree on:
- Naming is hard.
- Being blocked sucks
But you need to deal with both of those—Every. Single. Day.
Today, we’ll talk about #2, how to overcome it, and how not to be like the skeleton below.
Knowing how to handle being blocked effectively can easily 2-5x your output.
⭐️ Main takeaways
- How to unblock yourself
- What to do if you can’t unblock yourself
✅ How to unblock yourself
(1) Slack reminders
I talk more about it here but the general idea is to set reminders when someone says they will get something to you by a certain time. Or, you set a reminder to yourself to check in with them a few days after. This will offload your brain to not need to constantly check in or think about checking in. You have your reminders do the work for you and it frees your brain 🧠 up to do the real work.
Personal example: I was waiting on our Infra team to set up an AWS S3 bucket with the correct permissions. They told me they’d have it done by next week, so I set a Slack reminder on that message for the following week. This allowed me to remove the thought of checking in with them from my mind. After 1 week, I hadn’t heard back, but my Slack reminder told me to check in with them–after doing that they finally got to it. Normally, after checking in the second time, they get on it because they don’t want to let you down twice.
(2) Find an intermediary solution
Consider what is the root of what is blocking you, and why? Is it data from an API? If so, is it blocking because you are ready to ship or are you just starting to build out the UI? If you’re just starting to build out the latter, you can easily mock out the data or start building out the UI.
Personal example: For me, I’m working on building out frontend components that often have a heavy design requirement—needing to see how all the different states work (hover, disabled, active, focused, etc.). I don’t block myself from starting on the component though. I build out what I can; like the API, tests, and the base version of the styles. Once our designer is able to get to the final pieces, I’m able to quickly fill them in and ship it 🚢 !
(3) Make it easier for them
Whatever you’re blocked on, you should ask yourself, “How can I make it easier for this person or team to unblock me?” Here are a few ways you can typically do that:
- Use clear, concise language in your request. Point out exactly what is needed.
- Include relevant links, screenshots, and context, but leave it in a “Further context” section that’s clear they don’t need to read it.
- Offer to work on it with them. This will make it feel less like a “can you do this for me” and more like a collaborative request. It also differentiates you from most of the things on their backlog.
Personal example: Sometimes I write super long pull requests. Like 1,000+ lines. I don’t recommend it. But it happens. Whenever this does happen, I almost always offer to pair review it with the person I request it from. This allows them to get instant answers to any questions rather than creating a constant back-and-forth through multiple rounds of review.
(4) Incentivize them
Understand how unblocking you helps them and help make it clearer to them.
Personal example: At one point, I was working on a project with another engineer, and I was having a hard time getting a fast turnaround on code reviews. It might take 3 days unless I ping them about it. In our next 1-1, I brought up that it would be great if we could have both sides of the code reviews get done within 24 hours because it will help us get the project done sooner. After that conversation, it was no longer a problem and we were able to get a lot more done.
(5) Do it for them
In some cases, none of the above will work. In that case, you could try a last resort of offering to do the thing for them. This might not be possible, like if you are blocked on a code review, you can’t just approve your own PR. But it might be possible if you’re looking for an endpoint to get built out and you just need them to write the code for it.
Personal example: I was on a “Financial Products” segment where we had sister teams that relied on each other for data from their respective databases. We were working on building out a new feature, and instead of asking them to make an endpoint that gave us the data, we gave them a design document of the APIs we wanted to add and offered to build it under their supervision and approval. This dramatically helped reduce the timeline of the project.
✅ What to do if you can’t unblock yourself
You may have read all the above and thought, “Ok, I’ve tried all of those before and I’ve still been blocked.” Yep, sometimes that’s life. Maybe that team is swamped with 100 other requests and yours is #57 on the list.
Here’s what you can do to look like a rockstar even when you’re 100% blocked:
(1) 10x your result
You might have been asked to do X and you’re waiting to get unblocked to do it. But now that you are blocked, can you do X and Y?
Personal example: I was blocked on building out some APIs because I was waiting to hear back from database admins on the DB table structure. I normally wouldn’t have written a README file for the APIs if I was unblocked right away. However, since I was blocked, I set up a README to make the APIs clearer and when I got unblocked, I finished shipping the original task. I accomplished the main task but also shipped something else that makes the result even better.
(2) Get ahead on the next set of tasks
Think about what else you might need to do once you’re unblocked. Some things like…
- Planning the steps that occur after you get unblocked—if you’re waiting on an API, do you know what your implementation of using that API will look like?
- Identifying all edge cases and how to handle them—do you know how you will handle what happens when the API you’re waiting on fails?
- Writing outlines for tests—you don’t need to write them but at least write out what you know you need to test.
(3) State your “move forward date”
If you’re blocked on an approval, state that you’ll move forward by X reasonable date if you don’t hear back. Often, putting a deadline helps reinforce the seriousness and forces the other side to prioritize. Just make sure your deadline is reasonable.
(4) Help out the team
Being blocked is a great opportunity to build capital with the rest of the team. Here are several ways:
- Ask in Slack if anyone wants to pair on something they are working on
- Unblock your teammates by reviewing their PRs. Your teammates will love you.
- Fix an issue bugging the team (like flaking tests)
- Refactor ugly code
- Start a new initiative like a team process improvement (on-call, design doc templates, eng <> design handoffs, anything that could be better that you’re passionate about)
- For more ideas, check my post on going from junior → senior in 2 years here
(5) Do something you've been itching to do
You might have recently worked in some code that was a massive pain. Go refactor it! You have the time so go have some fun.
- How to unblock yourself: Offload when to re-ping into Slack reminders, find an intermediary solution, make it easier for the other side to unblock you, or do the thing for them.
- When you can’t unblock yourself: Do the original task AND other tasks you originally wouldn’t have done, get ahead on the next set of tasks, state your “move forward” date, find ways to help out the team, or do something you’d enjoy doing.
- In conclusion: If you’re blocked, you should either be able to take action to unblock yourself or find something to do in the meantime. Doing either of those is a great quality of seniority.
If you found this post valuable, you might like my newsletter with more posts like this! Check it out here: https://careercutler.substack.com/
If you made it all the way here, I'm also sure you'll like Taro Premium, the premier resource for growing as a software engineer. You can get a discount by using my special referral link: https://www.jointaro.com/r/jordanc063/
To go deeper on unblocking yourself, check out these resources: