The Key to Better Engineering Interruptions
“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:
- The window only opens once every 24 hours, so this doesn’t really help with the ‘burning half a day’ problem
- 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 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.