Measuring interruptions: How to keep your team in the ‘zone’

This article was originally posted as a guest post on Geekwire; it is republished here for the readers of this blog. 

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.

5368292088_37f5fce714_n[1]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?

Advertisements

Line-Drawing Fallacy and Accountability

There’s a beautiful logical paradox, a line-drawing fallacy:  it’s difficult to tell when quantity transforms into quality. Which of the cuts killed an elephant?.. Which of the thousand-dollar checks made a company go bankrupt?..

It’s so difficult to tell when an incremental, continuous process turns the corner and radically changes its character, and a temptation – a very pragmatic temptation – is to allow for wiggle room and ignore the little deviations. Meh, just another check. Our company’s big and strong, and our success depends on macro efforts – who cares about a thousand dollar check for paper clips?.. Let’s concentrate on something bigger!

I’m typically not a fan of idealistic, black-and-white / cut-and-dry judgment philosophies. I try to look for the trade-off curve – if we give up a little bit here, can we win a lot there? I usually find that an obvious decision is typically not so obvious, that for each radical judgment, there’s a set of counter-arguments that deserve to be explored.

Yet, today, I found an area where a hard-line view – a view that doesn’t allow for a gray area – is extremely important. That area is about managing accountability. I had an amazing conversation with my CEO, Ben Elowitz, and he crafted a very convincing argument – I know that it’s one of those that will be pretty transformative to my leadership style. Here it is.

There are two ways to run an organization.

One is the way of the pragmatic.

Have flexible standards – we ship when software is ready; we are OK slipping a little bit. We value commitment, but we value flexibility as well. We are reasonable – we don’t create a panic around a missed expectation unless it really cost the business.

The other is the way of commitment.

Draw a hard line: EVERY commitment that we make, we keep. Our organization does not tolerate a single hour worth of slippage. Create symbols of accountability: generate gigantic, loud, visible stinks every time a tiny expectation is not met. Don’t do it to be an asshole – do it to prevent the tiny little bit of a creep.

Oh, it’s OK to be a day late. It’s just a day…

And then we’re three days late…

How is five days late bad? It’s almost the same as how we did last time (four days late), and you, our fearless leader, seemed to be perfectly happy with the results?..

And then when you have a deadline that your team must meet, how can you expect them to deliver – with this kind of culture?

Ben argues that there are three elements to high accountability, which he equates with high performance:

  1. High standards: we set difficult goals, and hit them every single time. I don’t care that it’s 5pm on a Friday. You said that it’ll be done by the end of the week. Get to work. 
  2. Symbols of these high standards: as leaders, we celebrate victories and are VERY, very upset when any commitment is missed.
  3. Reinforcement – rewards and punishment – is immediately tied to the performance management / review process.
A couple related materials if you found this topic curious: