🦆 Are you blocked? (And how to unblock yourself)

Dear software engineer, identify how blocked you are. Take actions to unblock yourself.

This is my 20th week of writing! And we are 2,500 people! 👏
I’m happy I found consistency in writing, and to validate myself with the discipline and not only results.

---

“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

1. The 3 stages of being blocked.

2. How I navigated a blocker this week.

3. 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.

🥉 Stage 3 - Blocked, don’t know how to proceed.

What it looks like

There’s an obstacle in the way and you don’t know how to overcome it.

You may have run out of options, or you couldn’t conceive any viable option.

At this moment you don’t even know who you should connect with.

Your actions

Lean into your rubber duck ChatGPT. Iterate over the problem with the LLM of your choice. It’ll spark connections to find new potential solutions.

Lean into your tenured peers. At this stage, you don’t think they can solve it. But they can provide you with actions they would try if they were in your shoes. This can bring you back to Stage 2.

Lean into your manager. A manager’s role is working with people. They won’t solve your technical problem, but they’ll open a network of people to consult with

Lean harder into external people. If none in your team know how to proceed, consult people outside your team.
Don’t just post a question but ask for a higher involvement (e.g. running some meetings with a team that worked on the platform). Ask your managers for their support to make the other team collaborate.

A comment on this

Tenured engineers are there to help you.

Other teams are there to help you. You both work in the same company

But they can’t micro-manage you to identify that you need help.

It all goes back to clear and concise communication.

You own your visibility.

✋ A note on organizational blockers

Some blockers are not technical. You know what’s the path forward, but you need approval, or another team’s delivery.

Be specific in WHAT you need and WHEN you need it. Warmly, of course, explaining this is impacting your team’s productivity).

If the warm message doesn’t work, ask manager support to escalate.

Escalations are not ill-mannered or playing dirty. It’s a mechanism to ensure all employees are working for the overall benefit of the organization and not working on a local maximum.

🎯 Conclusion

The best engineers don’t know how to solve everything. That person doesn’t exist.

Some people create this impression because they have been forever working on the same systems.

But if you took them out of their bubble, they wouldn’t be productive at all.

That was also a reason for me to change teams. I wanted to be a good engineer, not just in my comfort zone.

The best engineers are those who can work through the obstacles.

Remember, being self-aware of your blockers and seeking the support you need is also working through the obstacles.

Don’t get too emotional about being blocked. You signed up for it when you decided to be an engineer.

👏 Weekly applause

This is a list of good resources I went through this week:

• Weetlab, by Nicolas Caillieux. Nicolas just gave a talk this week in Madrid about “how to say no”. His slides were full of reframings to see “no“ as something positive when used correctly. Tons of actionable advice!

• How to get from Junior to Mid with

  Jordan Cutler
  . My takeaway: The obstacles are what make you grow. For Jordan, not converting his internship into a full-time job at Twitter created the curiosity to “strategize“ his career 😉
  As the saying goes, handsome guys are unlucky because they don’t develop the skills to date girls

• Fearing Opinionated Voices in Design Meetings? Try these tips. by

  Techlead Mentor
  . An organizational blocker can be people blocking your design. The tips Raviraj shares here help to prevent blockers, and they not only apply to designs.

• The ridiculous policy that forced engineers to come to the office at 2 AM twice a year by

  Leading Developers
  . An engaging real-life story. It’s not clickbait.

🗞️ Other articles people like

🐣 How to gain influence as a junior engineer

🐲 How to prepare the system design interview

🧙‍♂️ How to prepare the behavioral interview

🗺️ How to prepare the technical interview