Ask HN: How do you reduce developer interruptions to keep your productivity up? | Hacker News Reader

Ask HN: How do you reduce developer interruptions to keep your productivity up?

3 pointsluka-birsa3 comments

I'm a CTO of a smallish (~30 people) startup and we've been battling with developer interruptions since we started working. The team is small and there are a lot of events that are "urgent" and require developer attention. I do understand that sometimes this is a thing of understanding what is important and what can wait but I'd love to hear what are your thoughts on this.

We've tried: - enforcing Asana/bug tracker tickets for each interruption - having dedicated "interrupt free" time - talking with stakeholders about this - tracking every interruption for 14 day period and addressing those that come up often with the source (person/service) - moving to a more dynamic setup of daily planning to account for these interruptions - enforcing "headphones = quiet time" rule - enforcing that all communication needs to go via Slack.

Most of these worked for a while, but sooner or later - people are people and they converge to what is their operational optimum (ie. they love to go and talk in person with the person that can address their need, right away).

I do not think that our current state is very bad, but I do see room for improvement. I can see that full quiet time would improve both quality and deadlines. I'm just not certain that at this point there is anything else what we could do and that our business might simply need such workflow to provide good customer service.

Do you have any ideas? What worked well for you? Did you find any cool tech for this? Do you have an organizational hack that you use?

1- small offices. 2 or 3 persons in the same team (working on the same stuff). If you have small offices with two teams in (eg. 2x2 persons), calls and discussions of one team will crash the productivity of the other team.

2- remote work. Having teleworkers in the teams is a great way to reduce the motivation of direct communication, since that would put remote workers out of the loop.

3- Instead use IRC, email and newsgroups, or any other good way (is Slack a good way? Can it be used from emacs?) to communicate both synchronously and asynchronously remotely, even if to ask a question to your co-worker two meters away. A lot of advantages are to be obtained by using those on-line communication channels: each programmer can manage how and when he's interrupted, even for synchronous channels like IRC; there are written traces of discussions, which help avoid talking again and again on the same topics.

(And on the topic of irc, I would note also that psychologically, reading questions and answering on irc eg. during compiles, is not as much an interruption as doing the same orally, since you do it in the same man-machine communication mode and even using the same editor (emacs), as for programming, instead of switching to a human-human interaction mode).

4- obviously, no direct access from customers to programmers. Or at least, unregulated direct access. There may be good reasons to have your programmers meet your customers, but this should be in organized meetings.

5- if you have to have meetings: 1- make sure they are short (very difficult! Try standing meetings). 2- gather them on the same time period, so to leave large periods of time uninterrupted by meetings.

6- and in the most dire circumstances, you may organize a absolutely no interrupt, no call, no meeting day each week, so your programmers may work at least one day a week.

I don't think this is a technology or policy problem. I think it is a workplace culture. It would seem that those in position to change the company culture don't see developer interruptions as a problem or that interruptions are the price of something that has more value.

Thirty people is also roughly one of those organizational tipping points where what worked for fewer people starts to not scale. Again, this suggests a workplace culture more than anything else.

I don't think there's a silver bullet.

Good luck.

This is just an idea, but can you introduce some "staitic friction" to the interruption process of interrupting another developer?

Classic example: Suppose developer "A" can turn to his/her right and whisper a question to developer "B" to save themselves 15 seconds instead of looking it up. Perhaps making it necessary for "A" to stand up and walk over to ask "B" would cause "A" to look it up and leave "B" undisturbed?

Reply on news.ycombinator.com