The Key to Better Engineering Interruptions

Jan 10, 2016 | Productivity

“I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon.” —Paul Graham

There seems to be a growing sentiment that interrupting programmers is costly, and that we should all do that less. Various articles — both anecdotal and empirical — have emerged suggesting that a single interruption can cost a half day or more.

So then why do even the best managers, including ones who came up through the ranks of engineering, frequently find themselves being the source of interruptions? So why is this, if they too have viscerally experienced this kind of disruption?

If it were only that simple

The trickiness of this issue lies in the fact that there’s a double-bind when deciding when to check in on an individual’s progress. Even if we grant that the mean cost of an interruption is only a half-day, what is the cost of not interrupting a developer who is stuck and suffering silently? Surely someone working tirelessly on a problem for 2 days without making any real progress is potentially even more costly — both to the individual and to the organization

This is the real issue here: leading a team in an industry where the work is happening in people’s minds, and in which ‘progress’ is thus a rather slippery concept is a properly wicked problem. Think of this in a similar fashion to constructive and destructive interference of waves — properly timed, one wave’s interference with another can either double the size of the original wave or flatten it entirely.

Such is the nature of interfering with developers: it’s not a question of “do interfere” or “don’t interfere” — it’s a question of interfering properly, which is why this is so difficult for team leads.

Interruptions work similarly: it’s maddening to get interrupted when you’re working on a difficult, highly abstract engineering puzzle, but most of us have also experienced the constructive side of being interrupted and leading to an impromptu session of ‘rubber duck debugging.’

Visibility without interruption

Visibility without interruption is one of those things that Scrum sort of struggles with. Sure there’s the daily standup, but that comes with its own set of problems:

  1. The window only opens once every 24 hours, so this doesn’t really help with the ‘burning half a day’ problem
  2. Some people don’t love saying they’re having a tough time in front of all their peers

Organically high visibility helps a lot with this, and not only helps reduce the number of interruptive pings, but also increases the chance that when someone. Unfortunately, this has long been the luxury of more ‘tactile’ creative professions — it’s pretty easy to notice when someone is having a hell of a time with a weld, but a blocked engineer looks an awful lot like someone in the zone.

 


 

Travis Kimmel

Travis Kimmel

Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Learn how engineering leaders are using data to help their team increase productivity and become even more effective. We've analyzed over 40 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This