There are 2 things even the most opinionated software engineers can agree on:

1. Naming is hard.
2. 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

• What being blocked looks like
• How to unblock yourself
• What to do if you can’t unblock yourself

What being blocked looks like

To clarify, this post is for when you are blocked by external factors, people, or teams.

You might also be “stuck”, or unsure how to work past a problem. I plan to write about how to overcome that in a future issue.

With that said, here are a few examples of being blocked:

• You put your code up for review and have been waiting for reviews for 2 days
  ‍
• Your backend developer needs to spin up an API for you and is taking forever
  ‍
• You need to move forward on a project, you asked for feedback on your design doc and it takes a few days for all the feedback to come through
  ‍
• You need another team to add an API endpoint but they have other priorities
  ‍
• You’re waiting on IT to provision an account for an app you need to use
  ‍
• Your designer needs more time to work on designs for a frontend feature
  ‍
• … and plenty more.

These things happen all the time. I’d argue almost every day.

Handling these situations effectively can give you hours back per day in getting things done.

The next 2 sections give very tactical tips you can apply to your day-to-day to make those situations a lot less frustrating and allow you to get time back.

✅ How to unblock yourself

Slack/Snooze 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 checking in again, 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.

Find an intermediary solution: Consider what the root is 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 UI, you can easily mock out the data in the meantime.

• Personal example: For me, I’m working on building out frontend components that often have a heavy design requirement from our designer—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 🚢 !

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 immediately rather than creating a constant back-and-forth through multiple rounds of review.

Incentivize them: Tell them how unblocking you helps 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.

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:

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.

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 the logic for them but at least write out what you know you need to test.

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.

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)
• Make an internal tool that automates a tedious team process
• For more ideas, check my post on going from junior → senior in 2 years here

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.

📖 TL;DR

• How to unblock yourself: Offload when to re-ping into Slack/Snooze 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.

‍

This article was originally on Jordan Cutler’s newsletter, High Growth Engineer