Are you blocked? (And how to unblock yourself)
Dear software engineer, identify how blocked you are. Take actions to unblock yourself.
Get the free AI Agent Building Blocks ebook when you subscribe.
“No. I’m not blocked. I just need more time to make it work”
That’s a red flag if you hear it in a standup update.
Why?
Because it doesn’t seem this engineer even knows what steps will bring completion to the task.
Sure, results aren’t immediate and you need time to work
But you should be able to explain what you are working on and even an estimated time to completion of the sub-milestones of your tasks.
If you can’t, then you are likely blocked.
“Then all junior engineers are blocked by definition”
Not really.
Can this person tell you what are their next steps?
They will need more time to read docs, have slower feedback loops with code revisions, and need to ask more questions.
But they can explain what documentation they are reading, what approach they are trying in code and who are they following up with.
Knowing if you are blocked is not about tenure. It’s about self-awareness and working with intention.
In this post, you’ll learn
The 3 stages of being blocked.
How I navigated a blocker this week.
How to escalate an organizational blocker.
Stage 1 - Unblocked
What does it look like?
You have a series of milestones and you are achieving them promptly for the expectations.
Your actions
Deliver artifacts along the way. It’s common to think of yourself as unblocked, but if you don’t have anything working something can be slowing you down.
Give clear standup updates. You can identify the work a few steps ahead.
Stage 2 - Blocked, with actions identified that can unblock you
What does it look like?
You discovered complexity after diving deeper into something.
The top-of-your-mind approach won’t work. So you have a list of things to try and you don’t know if they’ll work or not.
Your actions
Call out to your team the complexity. They may be able to help based on their experience.
Call out to your team the next things you’ll try. You are applying the scientific method: Hypothesis → Test it out → Result.
Connect with the people who can help you. Working on a task in software development is not going into a cave and coming up with an artifact.
As the owner of the task, you own connecting with the relevant people, obtaining the information, and achieving a result described in the acceptance criteria of your ticket.
Don’t wait until you have run out of options
Set yourself personal deadlines for those experiments. You can’t try things out forever. Make a plan of the things you’ll try and by when.
Record those attempts and communicate them with your team. If some of them unblock you, that’s great. If none of them does, then you have to prepare for the Stage 3
A comment on this
I was here this week.
I had to manually test a flow the customer follows… and it didn’t work as expected.
I had to debug but I’m just onboarding in a new domain. I had no idea why the expected push notification didn’t arrive.
Calling out the moment I faced the blocker and the actions I was going to take gave awareness to my peers.
A tenured engineer in my team told me how to call the involved dependencies to debug. This created more actions I could take independently.
I ended up connecting with the relevant teams and found one team deprecated something, the second team didn’t know about it, and the third team (us) was impacted by this 🙃
Early self-awareness of a blocker and clear, concise communication make this seem like not even a blocker. I was never out of options to try, so my productivity was not impacted.