Hacker News Reader

Comment by hkmurakami | Hacker News Reader

I'm a PM, and I consider it my most important responsibility to prevent interruptions from reaching developers. By redirecting inwards-bound interruptions to myself, I've probably reduced developer interruptions by 80% since I started.

What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others. The solution then is to work the other side (sales, marketing, etc) to interrupt someone else (me) instead. Even if it's a relatively simple technical question from sales, I can convert the in-person active interruption to a passive email notice (at the very least).

The typical office environment (and system) is not productive, so at this point it's up to the individuals to reduce the impact of the system on the team's productivity. (which is a sad reality...)

View on HN

> What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others.

The reason for this, by the way, is roughly that it's short-term easier to think about how to solve their problem so that they'll go away rather than "waste time" arguing about priority. People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back.

Also, many thanks for being one of the awesome people who help deal with this. As a developer who has worked under a few great manager-types (and has a ton of trouble saying no to a request), you make all the difference.

Firstly, thanks for the kind words :).

What's kind of funny is that while I'm pretty good at being a shit-umbrella for my team, I've found that I really really hate making urgent requests to other teams (HW, Applications, etc.) precisely because I know that they also have a lot on their plate already. In fact, I think I'm honestly really bad at 'pressuring' people in other teams to do things that our team needs. Everything comes with a cost, I guess.

> People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back.

I've also noticed that a lot of times, an individual sales/mktg/bizdev person actually doesn't know what the overall priorities are, since she is only aware of her customers and her items that need to be addressed. The person rarely has a sense for what the relative importance of her items are compared to those of the person sitting right next to her also asking the dev team for their time.

In a similar vein, I think it's very hard to push back as an engineer since she will rarely know all the projects that are going on concurrently, who the customers are, what the estimated revenues are for each project, etc. This is exactly the kind of information you need to fight against an interruption request: "Sorry but I'm working on item X for customer Y, with deadline Z, which is a higher priority item compared to your item W."

Now, an engineer probably shouldn't even have all this information, since the information is kind of a distraction in itself. So when a rogue customer-facing guy comes up to an engineer with a request, a much easier solution is to answer with, "Sorry I don't have the authority to change what I'm working on. Can you please go talk to my engineering manager A or my project manager B? I'll be happy to change course once I get updated instructions from them. Thanks."

> I've found that I really really hate making urgent requests to other teams

For me what ended up working by far the best is to always and for every request try to:

1) Give an honest summary of the negative consequences of your request being delayed/ignored

2) Ask for an honest summary of the negative consequences of your request being honored.

3) Continue calibrating the relative importance until the higher priority task is obvious for both parties.

At first you might get run over a few times but if you don't accept politics (also not your own!) to enter the equation and consistently do this eventually people will be very accepting and these request can be made very efficiently.

What you're talking about is a great example of good-faith communication. Unfortunately, it relies on both parties dealing in good faith, and I've had too much experience with people who won't do that -- they won't give an honest assessment of what happens if their request isn't met. I wish I knew how to handle that.

In this case you should trust but verify: ask the person to detail his sources (he is making the request on behalf of someone after all) and approach them directly to get a better picture of the situation.

If his sources are outside of the company or also not truthful then I'd also be at a loss :)

Well, there's nothing intrinsically wrong with an engineer having the information if they're interested. It's often useful to have a larger picture. However, for the purposes of dealing with interruption, calling in an ally is basically the most efficient way to make it go away. (The caveat being that sometimes the interruption really is more important.)

I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.

> I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.

Haha, funny you say this, since I also 'educate' others about this on a monthly basis (it's become much better compared to 12 months ago though, so credit to the customer facing teams who are generally reasonable people).

Curiously enough, in my experience, the vast majority of interruption I receive is not from "external sources" but rather from other developers, typically junior members of the team seeking advice or guidance. I wonder how you would address that?

Part of that depends on the type of advice or guidance. Some of it might be a symptom of the project's bus factor being too low (inadequate documentation, ambiguities or holes in processes, etc), which your organization can fix by paying down some of that technical/process debt. Other forms of advice (career-related, higher-level tech stuff, etc) would seem more like a mentor role. For that stuff, you may want to schedule "mentor time" in a slot advantageous for yourself, such as the last hour of the day.

I sit right next to a tester and he is a constant source of distraction.

Did you ever bring it up?

Several times. I was told to allow him to interrupt me. :/

Assigned mentors, perhaps on a rotating schedule. If I know I'm bound to be interrupted (in my case by a pager), I do work that I know won't require more than 5-10 minutes in "the zone".

The downside is that an assigned mentor will not get as much work done during that time.

Perhaps you deal with it by building it into the schedule: Set aside a specific time (or times) during the day where junior members have stand-up meetings with senior members.

Hopefully getting the interruption onto the schedule would have the benefit of allowing everyone to plan for it and try to minimize its cost. And it might also encourage junior members to try and work through problems themselves first (because they have to save questions for scheduled question times), but also make them feel less like an imposition when they do seek advice.

I find intra-organization chat rooms useful. Developers on their down time can answer questions while busy devs can minimize the window and focus.

This is my method if choice as well, it works well if you establish some basic rules of etiquette.

- no flak

- no flamewars

- no jokes

- no off-topic stuff

If everybody sticks to those rules then it will work fantastic, if you don't guide that it will turn into a zoo and become huge distraction.

We use a plain old IRC server + clients for this, nothing fancy.

This. It was a new idea to me when I started at my current place, now I can't imagine living without it. We've also been through a merger with another similar sized company (with a very different culture, in a substantially different timezone) during my tenure, and evangelising the IRC network was a big thing. The difference in communication efficiency between teams who were quickly convinced that group chat was a positive vs those that weren't was pretty noticeable.

The etiquette thing is important, and varies team by team. Our team has several channels to ourselves with varying levels of formality, and company wide channels similarly (#techteam, title line: "No banter" vs. #companyname, title line: <insert latest in-joke>)

Not only does the group element allow anyone who's taking a quick break to offer some help, it often draws in advice from across the organisation, including people you'd never have thought of asking, who just happen to be dipping in to the channel at the time.

Edit: The office wide "banter" channel's primary purpose most days (so like, not Friday afternoon) is the distribution of fresh coffee, prepared in 5 mug cafetieres, announced and claimed here. So many people have IRC bings on the word "coffee" that it's best discussed in some form of leet substitution if you're not offering to make some.

I've tried, and failed, twice, to introduce IRC into organizations. The first organization wanted policy and procedures around logging all chats - ugh ( yes, I know how to set up logging bots.) At the second, I had most of the team balking on the 'ugliness' of (whatever) IRC client they installed and insisted we use campfire.

I'm more than a little jaded at this point, and would love to hear if anyone has faced and solved these sorts of issues.

This is why you would either have a "support" rota in a team or a dedicated resource for such queries. Interruptions are annoying , but they are much easier to bear if it's just a week in a month. Of course it's not perfect due to the lack of telepathy, exchanging knowledge is not immediate but such rota will help facilitate sharing inside the team as well. I've seen teams that did that, been a part of one for some time and it was really good compared to standard workflow (whoever is closest or nicest is being interrupted).

This. When I worked as a PM, preventing distractions and "drive-by management" was also one of main focuses. My favorite quote about this is from Gmail PM Todd Jackson, who said, “You can either be a shit funnel or a shit umbrella”

As a developer, I'd just like to say: thank you for doing this. A good PM is literally worth their weight in silver (at today's price, anyway).

Reply on news.ycombinator.com