Dev, Interrupted

How many times have you had this nightmare:

“Hey, something’s broken. We need it fixed.”

“… but I’m working on something already,” you reply.

“Haha, hilarious. Developers are funny people with social influence.”

“Just kidding. Fix this right now.”

Leave Developers, and Britney, Alone

Not Fair

We don’t like to be distracted when we’re working. Switching from one thing to another is not only frustrating, but it breaks our concentration flow. Unfortunately, distractions are inevitable. People will ask you questions, and bugs will come up. Perhaps a customer is seeing a bug right now and it needs to be fixed as soon as humanly possible. And if the problem is big enough, people are going to want status updates quickly and accurately.

Usually bigger companies will have support teams to manage these kinds of requests. But if you don’t have one, you’ll need a structured way to field outside requests while keeping productivity high and communicating effectively.

A few weeks ago, we got to implement a solution.

Enter the Interruptible Dev

Bruce Lee Showdown

The Interruptible Dev is the person whose responsibility is to receive, triage, and if necessary delegate, any requests or questions coming to your team (and your team only). These will usually amount to bug reports, but it could include small feature requests or inquiries about how one of your products works.

To structure this a bit, we set a bunch of parameters:

  1. The team will rotate who will be the ID (Interruptible Dev)
  2. Once the ID gets a request, she has to respond within 5 minutes to confirm the reception
  3. The ID must provide a status update within 30 minutes. The request might not be completed in 30 minutes, but the update should have more details and a plan for moving forward.
  4. The ID has to try to fulfill the request first. If she can’t, she can grab another developer to pair with.

As you can tell, communication is a key aspect of the Interruptible Dev. If you’re hit with something really urgent, you’ll need to keep a tight feedback loop between developers and customers (whoever filed the request). Products like Zendesk will help you do that, but emails & post–its can go a long way.

One thing needs to be clear – being the Interruptible Dev is not the same thing as being “on call.” The ID is simply receiving and responding to requests that come to your team. The ID does not have to wake up at 4am if the server is down. So there’s that.

Still, you might think that being the Interruptible Dev is the worst thing in the world. It’s not. Speaking from personal experience, I can say that I kind of liked it. Here are some pros and cons of being the ID:


  • The rest of the team will love you
  • If you’re a recent hire, you will learn about your codebase. In order to put out the fires, you’ll need to learn the ins and outs of your products.
  • If you’re a junior developer, you will be empowered. Is the Senior Developer busy architecting? Too bad – his code is broken. Time to pair.
  • You fix problems and people know you did it. It is the opposite of a thankless job.
  • You’re always on the go


  • You’re always. on. the. go.
  • If you’re the ID, you won’t get your own work done. Ever.

If Only We Could Do This Ourselves…

You can! Go be the hero you were meant to be.

If you’ve done something similar, or you did it better, let me know!

Email: [email protected]
Twitter: @shakerdev

Ask a question or share this article, we’d love to hear from you!