The BBQ, the Rats, and Tactics to Unblock Software Engineering Projects

Jad Santos
7 min readSep 30, 2021

--

Photo by iulian aghei on Unsplash

Indulge me for a brief story about a bbq and rats. If you’re wondering whether you should read further, let me warn you that it’s not a pleasant anecdote. But if you’re wondering how this relates to software blockers, then you’ll have to continue to find out.

I was having dinner with some friends the other day when one of them asked, “Do you want to hear a gross story? Is it ok? I know we’re eating.” I said, “Sure, why not?” Her husband proceeded with telling me the story.

We ordered a brisket last night and decided to use the BBQ grill to heat it. We haven’t used the grill in months. I went outside and turned it on to warm it up. I kept the lid down so it could warm up faster. A few minutes later, I opened the lid to discover to my horror, a family of rats living on the grill, dying from the heat. I closed it immediately, calmly walked into the house, and asked my wife what we should do.

My friend’s wife continued the story.

I went into panic mode and told him to kill them. So he returned to the backyard and turned the knob to the highest setting, hoping that it’ll be a quick death for the rats. He walked back inside to distract me from the image of burning rats. A few minutes later, our eldest son walked into the kitchen and asked very matter-of-factly, “Should the grill be on fire?”

Her husband picked it up from here.

I ran outside and saw the grill glowing red and engulfed with flames. But calmly, I grabbed the fire extinguisher, which we had never used and was about as old as our teenage son. It still worked. It took a while, but I was able to get the fire out. Although, the grill continued to glow red for hours afterward. After the whole ordeal, I turned to my son and said, “See, son, that’s how you handle a crisis.”

To which his wife replied, “I never saw you as a manly man before until yesterday.” And we all had a laugh-out-loud moment — the end.

— -

As software engineers and managers, we face the technical equivalent of “BBQ grills on fire with rats in them” frequently. We call them blockers for short. If we had a valuable piece of equipment like a fire extinguisher to remove our blockers, software engineering would be easy. Right?

Since we don’t have fire extinguishers, here is a list of tactics I’ve used to get unblocked. It would be best if you use these judiciously. Some of them have significant drawbacks, which I will point out. Also, these tactics are for difficult blockers, which seem impossible to solve at their onset.

1. The War Room

What is it? The War Room is where you and the rest of the engineers congregate to think through solutions, implement them, share results, and make the next decision. It can be a physical room, a virtual one, or a conference call.

Why is it helpful? The War Room facilitates synchronous, real-time communication. It eliminates barriers to information, which can be the difference in getting unblocked now or later.

When should it be used? You should use The War Room when you value resolution speed, which is why it’s for high-severity production issues or development blockers.

Why should you not use it? You should not use The War Room for every situation because it is an intense, high-stress, mentally-draining tactic for getting unblocked. It may have lingering low-morale effects if used in the wrong case or if its duration is too long.

2. Specialist Team

What is it? The specialist team is a small team of two to four people who have the singular mission of removing the blocker.

Why is it helpful? A specialist team is valuable because it is a focused, undistracted team. Its size is small to minimize complicated communication and to encourage collaboration. The team will get to a resolution faster with these qualities.

When should it be used? You use a specialist team when you have a motivated few that want to take on a difficult assignment. These select few engineers can use that source of motivation to get past the blocker.

Why should you not use it? You should not use this tactic if you cannot afford to carve out a subset of your team for a non-trivial amount of time. You will lose the capacity of the individuals assigned to this team, which may be worth it considering the alternative of being blocked for an extended period. The specialist team also has the drawback of isolating a group. It would be best if you did not use it for an extended period. As a final caution, you must avoid elevating the specialists to hero status if they succeed. Doing so could cause resentment in your other team members.

3. Hub and Spoke

What is it? A hub and spoke is an arrangement where your team members attempt to resolve the blocker individually or as small groups (spoke) then periodically meet (hub) to discuss findings or a solution.

Why is it helpful? Hub and spoke is useful because it gives the team concurrent but independent attempts at solving the blocker. You have a higher probability of getting unblocked with multiple parallel streams of problem solvers.

When should it be used? The hub and spoke arrangement is practical when the blocker is challenging but does not have a time constraint or significant impact.

Why should you not use it? It is a tactic with a high probability of finding a solution and an increased likelihood of taking longer because of less frequent information dissemination. If you assume the worst case, then you should not use it if you have a hard deadline to meet.

4. Buying time

What is it? The “Buying time” tactic is when you develop a temporary solution to remediate the blocker to provide you more time to find the best solution.

Why is it helpful? This tactic is beneficial because it removes the constraint of time on your team, which eliminates an additional stress factor for them. The team can find a better solution because they are operating under better circumstances.

When should it be used? You use this tactic when you have a clear temporary solution to pursue. It would be best to try this tactic first because removing the time constraint will provide a better environment for your team.

Why should you not use it? You should not use this tactic when the effort for the temporary solution is unknown or has a higher risk. This tactic also comes with the potential of reducing the urgency of removing the blocker. You do not want your team to “take their foot off the gas” and end up in another time-constrained situation later.

5. People Exchange

What is it? People exchange is a tactic where you solicit help from another team who has the expertise to get you unblocked. In exchange, you provide an equal or more significant number of people to allow the other team to continue with their work. For example, you might ask for one expert on performance optimization in exchange for three people who can help fix bugs.

Why is it helpful? Exchanging people is beneficial because you get a higher probability of resolving the blocker with the experts.

When should it be used? You will want to employ this tactic when there are experts available for negotiation. You may need to exchange more people than the expert team, which means you use this tactic when you can afford to do that.

Why should you not use it? It is a morale hit for your team. You are bringing in “ringers” to do something they cannot, which is a perception they may assume. It is also a morale hit because your team members have to leave to work on something they may not find enjoyable.

6. Quid Pro Quo

What is it? Quid pro quo is an arrangement with another team where you offer to do something later for them to help with your blocker now. For example, you can negotiate to have that other team implement a fix in their API now in exchange for you helping them meet a deadline later.

Why is it helpful? This tactic helps you get unblocked because the team that can provide the best solution is helping you. Instead of building a work-around or taking a long time to fix the problem, the proper team is working on it.

When should it be used? You use this tactic when your cost of unblocking yourself is significantly higher than having the other team fix it.

Why should you not use it? You should not use this tactic because it will cost you later, often at a higher price than necessary. If the other team is a better negotiator than you, it will be a significant hit to meeting your commitments later.

— -

Whichever tactic or combination of tactics above that you use, the best thing you can do for your team is to remain calm, just like my “manly” friend did when putting out the fire. A panicked person is an irrational person, which leads to mistakes and potentially making the blocker worse. A calm person will prevail more often.

I hope this list is helpful for you. If you know more tactics, please share them as a comment. Good luck on putting out those fire rats, err blockers.

--

--

Jad Santos

I'm a software engineer, software manager, and a programming enthusiast. I write about software craftsmanship, engineering management, and programming topics.