Stuck in Traffic
Blocked By Another Team
Understand and explain. Why is the work is important? What do you want from them and by when? Give them another chance to indicate feasibility and/or alternatives.
Make the work easier. Can you ask for a smaller subset of features? Can you help unblock their dependencies. Note that supporting your foray into their code base might cost them more in support and they might decline your offer.
Get organizational support. If priorities are unclear, ask your leadership to adjudicate on relative priorities. If your leaders agree, consult with project sponsor on how to politely escalate to a mutual leader.
Make alternative plans. Rescope the project; choose a different direction; push the shipping date.
Blocked By a Decision
Understand and explain. Get the information or approval they need to make a decision. Explain what can’t happen until and unless they decide – use impact on things they care about. If they’re blocked, understand who/what they’re waiting for.
Make the work easier. If their decision is blocked by conflict, play mediator to find a solution that suits both. If blocked by their decision makers, give information in the format they need to take back. Explain which parts of the decision are important and expensive to reverse later.
I’ve had cases where the two parties that need to have a conversation don’t know about each other. Introducing them to each other and then monitoring the email thread has been low-effort but high-impact for me.
Get organizational support. Talk to your project sponsor about what they’d like to do. Maybe they’re in some rooms where they can push for a decision to happen.
Make alternative plans. Can make your best guess about the decision, document it and its tradeoffs, and mitigate risks. Be realistic – are workarounds enough or is the project infeasible?
Blocked By a Single Button Click
Understand and explain. If you really need to skip the queue, politely ask. If they go out of their way to help you, publicly recognize, e.g., peer bonus, launch email credits, etc.
How do you know if the wait time is atypical? Some teams publish SLAs for requests, but that might not be representative.
On the receiving end, I can try to make the queue and its “processing time” observable. For example, all PRs that need my team’s attention should have the same assigned reviewer, such that the list of PRs assigned to that reviewer group becomes the observable queue.
Make the work easier. Structure your ticket to be one of the easy ones, e.g., as small as possible; succinctly include all relevant information, etc.
If it’s a sign-off on a PR, what kinds of issues have they raised in similar PRs? Are those addressed in yours? Some teams have reviewer bots that automate common issues – have all automated suggestions been considered?
Get organizational support. Escalating to skip the line is thorny; mitigate by being explicit about the importance of the team’s process, and why you’re requesting to circumvent it just this once.
Make alternative plans. Connecting with someone on the team is usually enough to raise priority, but if nothing works, notify stakeholders that there’ll be a delay.
That someone on the team can feel singled out, especially when you pick them for having reviewed other requests in the recent past. Sometimes they’ve redirected me back to the group, implying that there is a queue and a process of doing things.
Blocked By a Single Person
Understand and explain. Be clear about the request’s importance, especially when waiting on a senior colleague who is making deliberate judgments about relative importance. Give them a chance to revise their availability; set a go/no-go deadline to start finding alternative approaches.
Make the work easier. Add structure; break the problem down. Consider the “three bullet points and a call to action” technique. If the colleague is overwhelmed, reassure them that the request is legitimately difficult but learnable. Help them, but don’t take over lest they not learn.
Get organizational support. If they’re the reason a project is going to fail, you’re not doing your job if you ignore it. Escalating means asking for help, e.g., talking to the manager might be the only way to adjust priorities.
How to communicate intent to escalate? Tricky to do this right. As an IC, I don’t like someone escalating to my manager because it feels like I’m not doing my job. But if the recommendation comes from me, then I feel more at peace with it, e.g., your feature is not a top priority for my team; to change that, please raise this with my manager.
Blocked By Necessary But Unowned Work
Understand and explain. Interpret the information gleaned from various conversations, and write down conclusions in a rollup document. Perhaps Alex says, “The new library will give us authentication for this end point,” and later Meena tells you, “We can’t upgrade to the new library till Q3”. In the rollup document, explicitly state, “We won’t have authentication until at least Q3”.
Make the work easier. If you have time to mentor, advise, or join the team, mention that in the rollup. Leadership might be more inclined to build a team around an existing volunteer.
Get organizational support. Your highest-value work for this is advocating for organizational support and an owning team. Hone the elevator pitch for why the problem is worth your organization’s time – your sponsor needs to justify this to their peers.
Make alternative plans. If you can’t get a commitment for anyone to own the work, then your project isn’t high priority and should be postponed.
Blocked By a Huge Crowd of People
Understand and explain. Re-affirm the narrative of a migration as it can get lost, e.g., “that infrastructure team just wants to play with new technology.” Understand both sides and help tell both stories.
And the strongest version of both stories. I’ve encountered instances where the one side was caricatured to the point where the other side’s solution seemed like the only thing that should have been done. That’s not in line with the “respect what came before” mantra.
Make the work easier. The team pushing for the migration should do as much extra work as possible, e.g., automating steps; being specific and explicit about what other teams need to do; minimal gotchas in the new system; make the new way the default for new projects. Show the progress of the work as people tend to be eager to do their part to get the numbers down.
Get organizational support. If you can’t convince your leadership that the migration should be reflected in the organization’s quarterly goals, then this is not where you should be spending time right now.
Fine, the migration is important in my organization. How can I make it important in theirs? Is it a matter of my sponsor getting their organization to adopt it too?
Make alternative plans. With organizational mandate, can you withdraw support for the old way? Can the remaining teams be the sole supporters of the old system?
You’re Lost
You Don’t Know Where You’re All Going
Usually happens when everyone agrees that something should be done, but they can’t align on what, e.g., an organizational goal to “modernize the architecture”.
Clarify roles. Be explicit that you want to hear from everyone, but that you’re not aiming for complete agreement. Ask your project sponsor to back you up in being the decider.
Choose a strategy. Until all agree on exactly what problem you’re solving, then no one is allowed to discuss implementation details. Any strategy will, by definition, make tradeoffs. Some real problems will remain unsolved for now.
Choose a problem. If you can’t rank all available problems, choose something, any real problem, and set expectations that the group should not be diverted by the other (very real) issues. Wrong is better than vague; deliberate action is better than staying frozen in indecision.
A document seems apt for acknowledging other real problems, and why you didn’t choose them as the immediate problems to solve.
Choose a stakeholder. Reorient the project around getting something to someone (solving a vertical slice). Progressing in some direction can help break the deadlock and clarify next steps.
You Don’t Know How to Get There
Articulate the problem. Notice places where you could be more precise about who/what you’re referring to or what is happening versus what should be happening.
Revisit your assumptions. Instead of aiming for an improvement on every axis, are there acceptable tradeoffs? Have you already assumed a specific solution? Can you specify the precise problem to be solved independently of the methods used in the solution?
Design docs are encouraged to have at least one other plausible solution. Helps with not being tunnel-visioned.
Give it time. Take a few days away from the problem. Even if you haven’t thought about it in the meantime, chances are that you’ll come back with better ideas.
Look for prior art. Unlikely that you’re the first person to ever solve a problem like this. Other industries have well-thought-out solutions to problems tech people think we’re discovering for the first time!
Having taken Electrical Engineering during my first 3 years of undergrad, I was familiar with debouncing from a circuit perspective. Imagine my surprise to find it in UI development.
Learn from other people. Most technical domains have active internet communities. Spend time there absorbing how they think and what keywords and solutions they mention that you don’t know about.
Try a different angle. Maybe an organizational solution to solve a technical problem and vice-versa?
Start smaller. Try solving one single small part and see if the sense of progress makes the rest of the work feel more achievable.
Ask for help. If hesitant, remember that by learning from other people’s experiences, you’re amortizing the time they had to spend learning the same thing.
You Don’t Know Where You Stand
New initiative from the latest all-hands that could derail yours? Missing on the list of the organization’s important projects? Sponsor checking in less often?
Clarify organizational support. Explain what you’ve heard to your project sponsor and ask whether your project is intended to continue.
Clarify roles. Running a project as an “unofficial lead” is an invitation to fail – if you’re the lead and nobody else knows you are, you’re not the lead.
Ask for what you need. Mention of the project at an all-hands meeting? Being listed on the organization’s goals?
Refuel. Setting new deadlines; building a new charter; phase 2 of the project.
You Have Arrived… Somewhere?
But It’s Code Complete!
The software being ready isn’t enough. Nobody wants to use software; they want to catch a Pokémon. Deploying and monitoring; getting launch approval; updating docs; making it usable.
Define “done”. Let intended users of a new feature try out the tasks they’ll want to do with it, and agree that those features are working well.
Scale invariant. Even for granular tasks, define the exit criteria for clarity. This is especially useful when others audit the completion without you being present to clarify things.
Be your own user. Take time to share your customers' experience.
Celebrate landings, not launches. Celebrate shipping things to users. If doing a migration, celebrate the old thing being turned off, not the new thing that got launched.
It’s Done But Nobody Is Using It
Tell people. You need to keep telling them. Send emails, do road shows, get a slot at the all-hands, offer white-glove service to strategic customers.
Make it discoverable. A search on any documentation platforms should end up at the right place. Create a memorable short-link.
It’s Built On a Shaky Foundation
In a competitive market, launching something is often more important than that something to be solid. Beware that if you don’t have something in good shape by the end of the project, it’ll take extraordinary effort to clean it up later.
Set a culture of quality. Be the reviewer who always asks for tests, monitoring, and documentation updates.
Make the foundational work a user story. Can frame cleanup work as part of the user experience (e.g., reliability of the feature), or laying the foundation for the next feature. Focus the conversation on customer’s needs.
Negotiate for engineer-led time. Sometimes called “tech debt weeks”. The point is that it’s a dedicated time to do work that everyone in engineering knows is necessary.
The Project Just Stops Here
Declare “done enough”. Further investment is not worth the cost. Watch out for abandoning unhappy customers, bailing once technical work is done, or walking away from a half-migration.
It’s not the right journey to take. Sometimes you can’t discover that a solution won’t work without exploring it. Pushing on anyway would be a failure. Write a retrospective and share as much as you can about what happened.
The project has been cancelled. Try to understand the bigger picture and get as much perspective. Talk to your team, leading with the why – it’s important they hear directly from you. Showcase everyone’s work lest it (unfairly) derails promotions or great performance ratings.
This is the destination! Mark the occasion and make the success feel special, e.g., parties, time off, shout-outs, presentations, etc. Consider a retrospective – you can learn just as much from things that went right. Highlight aspects of your culture that you want to enforce, e.g., communicating well.
References
- The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change. Chapter 6: Why Have We Stopped? Tanya Reilly. 2022. ISBN: 9781098118730 .
- Incubation (psychology) - Wikipedia. en.wikipedia.org . Accessed Nov 24, 2024.
Thinking through both sides of these scenarios can help me reduce the times when I (or my team) is the blocker.