The Art of Interrupting Software Engineers

Photo by Joshua Coleman on Unsplash

As a product manager (PM), I often make assumptions as to when a particular user story will be delivered. This is painful because I don’t believe in time estimates and don’t think I should be involved in estimating the relative complexity of a story since I don’t own its implementation.

I know I shouldn’t but I can’t help doing it anyway…

From time to time, I look at my team’s backlog and see that a particular story is taking longer than I expected. It’s a difficult feeling because I don’t have context as to why the work is not being delivered if I just look at my backlog.

Earlier in my PM career, I was a bit paranoid and would sometimes err on the side of conspiracy theories:

• “Are the engineers being distracted?”

• “Are they focusing too much a technical matter that will not provide value to the customer?”

• “Are they doing work in parallel that is not reflected in the backlog?”

I would let time pass and, on occasion, stories that I imagined would take a few hours would turn into a day or more. After reaching peak paranoia, I would finally ask engineers why the work was taking so long.

I was almost always met with two reactions that turned my paranoia into a vicious circle:

1. The engineers would give me highly technical explanation I couldn’t understand. This would frustrate me because I did not add much value and distracted them.

2. Engineers would start feeling pressure to deliver the work faster. This led to stress on their part and the team potentially shipping unreliable code to production because we rushed getting it out of the door.

Interestingly, the behaviors of more experienced XP engineers were a bit different:

• When asked about their progress on a story, they would make an effort to ensure I understood what was happening under the hood and what tradeoffs they were facing using a vocabulary I was familiar with. 

• In some cases, those engineers would come to me before I even had a chance to enter the paranoid zone and give me a simple explanation of how the team had learned new information since they first estimated the complexity of a story. 

• Some of the very best practitioners would ask me in advance how urgently we should deliver a particular user story and what we were ready to give up in order to ship faster.

As my technical understanding and empathy grew, I learned that while the above mentioned engineers were able to occasionally help me, this behavior was hard to perform reliably when deep in a codebase. We want our engineers to know why they are building a particular product, but it is sometimes hard to step back and think like a product manager as you are trying to reconcile functions and APIs.

This realization pushed me to develop a routine to trigger time-saving conversations on a regular basis with the engineers I work with. 

1. Check-in Regularly And Elegantly

My main initial mistake was to let my anxiety build up and wait for a story to take way longer than I imagined before asking what was going on. In order to avoid this problem, I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with. This was mostly me passing by and asking how things were going without asking about a specific story. This has several benefits:

• It masks the fact that I have expectations as to when something should be delivered and does not communicate urgency to the team.

• I can get a feeling for how the pair is progressing and if they are facing unforeseen challenges. This often makes understanding problems easier because they are chunked into smaller digestible bits as engineers learn more and more about the problem space.

• I don’t have to wonder if it is the right time to ask because it is now a routine.

This technique is meant to complement ceremonies your team is using such as the Iteration Planning Meeting (IPM) or your daily stand-up and will provide a more granular and reactive conversation.

An important caveat to remember is the tragic impact of interruptions can have on an engineer’s ability to concentrate. One of the best articles you can read on the topic is Maker’s Schedule, Manager’s Schedule by Paul Graham. In order to avoid the wrong kind of interruption, I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break. This might be harder to achieve if you are on a remote team. In this case, you can make it explicit that you intend to check in regularly and devise a system with your peers to improve your chances to interrupt at the best time.

2. Look For Struggle

While your opening question “How are things going?” is very casual, you want to be particularly focused on the answer. Most of the time you will hear that everything is fine and may even find yourself in a really nice conversation that has nothing to do with struggling in a codebase. On some occasions however, you will hear a person express frustration like “We are stuck” or “We are really struggling right now”.

Most of the time, your interlocutor will not expect for the conversation to continue as they expect themselves to figure it out without assistance. At first it may not appear to be, but this is actually a unique opportunity for you as a PM to further engage with your engineers to understand what is going on and why the struggle is real. It is important to keep the conversation alive until you understand the problem at a high level.

The problems you will hear about are often a combination of the following:

• Not understanding why something is happening

• Not being able to manage rapidly increasing complexity

• Not feeling confident about how reliable an implementation is

It might be hard to tell which problem is happening, especially if you are bombarded with technical terms. This is a great place to leverage vulnerability since most folks will not expect you to understand the details. Try to repeat in your own words what you think is happening at a high level. Encourage your co-workers to correct you or add nuance. This helps you set the tone for what the appropriate level of abstraction is for you and get to a good level of understanding faster. 

3. Understand the Impact of the Work From A User Perspective To Remedy Product Debt

In countless situations, I have found that product debt leads to technical debt. Features with unclear user outcomes often lead to a knowledge gap between a PM and engineers. Product debt is when you under-specify a user’s context or refuse to prioritize user value. This leads to engineers having to make a lot of functional decisions on-the-fly. As more of those decisions happen, the team is robbed of the ability to prioritize user value. 

A typical example:

• The team aligns around a particular story and estimates its complexity.

• A pair of engineers start working on a piece of code to help users accomplish a particular task.

• Quickly, they realize the existence an edge case that could cause issues for the user.

• They often won’t go back to check if the story covered that error or edge case.

• Sometimes, the pair might fear this will be forgotten if they don’t tackle it now.

• The edge case happens to be more complex to solve than originally envisioned.

• Once finally delivered, the PM is unaware of the existence of a particular fix for the edge case.

In this example, the work ends up taking longer than originally intended because the PM did not anticipate a particular use case and the engineers could not imagine delivering the feature without solving for this edge case. This sometimes gets even worse if the PM is not made aware of the functionality that was shipped.

You obviously can’t plan for every use case and edge case that will be encountered. However, it is possible to prevent unnecessary work and help your team develop Lean Startup instincts when faced with those decisions. 

In your routine check-in, don’t hesitate to ask what the impact to your users would be if the current problem went unsolved. This creates a conversation everyone on the team should be able to understand. You will suddenly hear about use cases or chores that were not initially specified in the original story. This gives you two opportunities:

• Break-up the work into smaller chunks and prioritize appropriately. This will help your engineers tackle smaller problems and simplify the implementation of each feature. Working on too long on a feature might also induce fatigue and be an incentive to cut corners. 

• Reflecting on whether or not implementing the edge case is truly necessary. Your MVP might be able to get away with not providing this value for some period of time. It might be more important for you to ship faster and learn more to include additional functionality that the product could satisfy.

You can refine this approach by acknowledging the maturity of your product. In his 3X model, Kent Beck explains that your team should optimize practices differently depending on where your product is in its lifecycle. If your product is a throw-away experiment, you should optimize on being able to run as many experiments as possible until you find product-market fit. On the other hand, when your product is more mature and you have a lot more to lose, you should find ways to minimize your risks. As a PM this means you need to support and encourage the appropriate level of refactoring if you work on such product. 

4. Be A Sounding Board

If you don’t have a scope problem, it is important to acknowledge at this point that you are probably ill-equipped to actually solve the technical problem that engineers are facing. Your lack of understanding and context can be tremendously valuable because through your simple questions you might offer new angles engineers might not have considered. Of course, you will not know these are new but you will suddenly hear engineers having new questions of their own “What if we tried X?” or “This makes me think we haven’t explored Y yet”. This is really powerful because they figured it out on their own and were not told what to do or try. They will barely notice you were even a part of the conversation that led to solving an issue. This type of technique is a variation of Rubber Duck Debugging.

If you fail to be able to generate this outcome, your last resort could be to ask if your engineers have considered asking for help. It’s important to remember that many engineers have high expectations of themselves in their ability to solve a problem, and that asking for help is not always natural or a skill that was sufficiently developed.

Conclusion

In the past few years, I have been able to better manage my interactions with engineers and often help them find time-saving opportunities to deliver the product faster by:

• Checking-in regularly in the least disruptive way possible.

• Focusing on user value to help the team find the fastest way to ship a product we can learn from.

• Being vulnerable about my lack of understanding to stimulate a conversation I can contribute to.

I am curious about ways you have found to solve for the anxiety of seeing software work taking longer to be delivered than you and your team originally expected. 

Special thanks to Jeanette Head, Derek Boire and Chad Woolley for providing a more realistic software engineering perspective and editing this article.

About the Author

Hadrien Raffalli is a Product Lead at Pivotal. You can read more of his articles on Medium and follow him on Twitter.

Follow on Twitter Visit Website