When you look at productive output from a software development team, there’s one factor that almost always predicts problems. You can have top talent; an outstanding idea; great agile process. And yet, if you don’t treat interruptions as a significant source of danger, the progress will be slow and painful.
We all know and love the feeling of “flow:” You’re in the zone, coding away or deep in thought on a financial model. There’s plenty of research that suggests that we do our best work in this state. We are also happiest at work when we are in the zone often.
But far too often, this state is broken up by a tap on your shoulder or a phone call. There’s a small, innocent question – and it takes you five minutes to answer it. But when you come back to your original task, the inspiration is gone. The “zone” is gone. You need a half hour to just bring back all the variables back into your mind. Or worse, you may not catch the sense of “flow” again that day at all.
That’s the scary thing about interruptions – they typically only take a few minutes to handle, but then bring a trail of a scattered state of mind. What’s worse, it’s easy to embrace this interruption as a good thing – hey, I just solved a problem, unblocked a customer, made someone’s day better. And yet, for an organization, more often than not, this interruption was a net negative.
Technology startups have a key property: if they stagnate – stay with the status quo, spend too much time on sustained engineering – they die. Time is of the essence; competition is fierce, someone else is going to win that customer, build a better product, hire stronger talent. So only the time that you invest into important AND non-urgent things is bringing you closer to your vision. Troubleshooting is a necessary evil. You must make your current customers happy. And yet, if you spend all of your time on it, you’ll never make it.
So I encourage you to take a systematic approach: actually measure interruptions and create goals to reduce them to a reasonable level.
Create a mailbox connected to your issue tracking system. Every time someone has a question or request outside of the current sprint’s priorities, have them send an email to that mailbox – or do it for them. There are, in fact, two mailboxes: one for emergencies (ex. site’s down) and one for regular issues (ex. data in the analytics DB doesn’t add up). At the end of each week, count the chickens.
Categorize each interruption by component. Draw a graph over time. Discuss it with your senior engineers.
You’ll be amazed. I sure was when we did this at Wetpaint. When we started this practice, we noticed that we had an average of 60 interruptions a week for a product development team of 15.
This, coincidentally, was a time when we were seriously struggling as an organization – we had a hard time moving the product forward. We dug into the root causes and noticed that most of these interruptions were triggered by two systems. We invested time in two sprints to systematically address these issues, and the interruption count dropped to 10-15 a week. Not surprisingly, our productive output shot up.
Morale also improved significantly. Folks felt like they are working on features that move the product forward, instead of constant firefighting.
An important factor in our setup: we established a rotation program to triage interruptions – and only placed managers on this pager duty rotation. Some interruptions are 3am emergencies that must be dealt with immediately; when managers have to be the first line of defense, root causes tend to get a systemic resolution surprisingly quickly.
Another positive side effect of being systematic with interruptions is that nothing falls through the cracks anymore. An internal customer would find an issue and send one of the devs an email, or just chat with them in the kitchen about it. Sometimes, requests like this would be lost – or delayed far enough to get the customer concerned. After we set up this rigorous interruption tracking, every client knew where to look up the status of their issue.
The movie Social Network has a magical moment. A loud house party is going on. And yet there’s a guy in the middle of the room with headphones on, coding away. People walk around him, careful not to disrupt – nobody dare interrupt his flow!!
Do you know how many times a week your product development organization is interrupted today? Can reducing that number take your crew to the next level of productivity?
Alex Weinstein (@alexweinstein) is the head of product development at Wetpaint and the author of the Technology + Entrepreneurship blog where he explores data-driven decision making in the face of uncertainty. Prior to Wetpaint, Weinstein led technology initiatives in Microsoft Live Labs.
