Programmers, teach non-geeks the true cost of interruptions (2014)

>Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

Wow. This is exactly what the top comment was talking about with the opening sentence. These people may not need deep concentration to be successful, but that doesn't mean they don't do real work.

I learned to hide at a past company. I would book small meeting rooms for long periods and work in there. Or go work in the cafe. Even that is superior as while there are lots of small distractions, nobody specifically wants your attention. In the summer I would work outside under a tree.

Or as I didn't want a promotion at another company, would come in very early and leave early.

I think pg explains this better: http://www.paulgraham.com/makersschedule.html

I think it's important to make sure you have the infrastructure in place to support your team's productivity. It isn't something that won't happen without work:

1) Have an escalation flow, and have someone dedicated to handle escalations. The example about the order API crashing should never hit anyone except the person who is on call that week, and that person shouldn't have any project work assigned. (They can be doing project work, but your planning should assume they're AFK the entire week. Sometimes on-call weeks are like that, and sometimes nothing comes up. Don't aim for the 50%-ile on that variance, aim for the 99.9%-ile, or your projects will be set-back 50% of the time instead of 0.01% of the time. And you'll burn out the on-call engineer.)

2) Forbid DMs. All questions should be posted to a public channel. (I guess people still use email, but I haven't seen it anywhere I've worked for several years, so it might be one of those things that's dead now.) Many questions that are directed at a specific engineer can easily be answered by the manager or lead who is probably on a "manager's schedule" and not a "maker's schedule". Forcing someone else to investigate also spreads the knowledge around on the team. (If there's only one person who knows how something works, they can't go on vacation, will get burned out, and quit; leaving you with 0 people that know how something works.)

3) Most meetings should be very targeted and be predicated on pre-work, and have an agenda. For example, if you're a product manager, you shouldn't invite 10 random engineers and say "hey can I have X by next Monday?" Write a PRD, solicit comments asynchronously, and then have a 1 hour working session to resolve the comments that require high-bandwidth discussion. Once the PRD is ready, eng leads can prioritize the feature, and assign resources to write a design document, and treat that as normal project work. Assigning people underspecified work just leads to disappointment on both sides -- the PM doesn't get the feature they want, the engineer has to delete the code they spent a month on. (It's also important for product to not change their mind too often: https://apenwarr.ca/log/20171213#slide13)

4) If you can get software to bin-pack meetings, you should. There are very few cases where the exact time of the meeting matters -- what matters is making sure that the global interruption cost is minimized. (This is NP-complete, but there are still services that will do it for you. Great is the enemy of good here, and "Everyone is free on 2pm Thursday" is the worst possible way to schedule meetings.)

5) Don't have status meetings. If you want a daily slot to discuss issues that come up, that's totally fine, but going around the room to ask what you did yesterday is a colossal waste of time. It's always "today I'm working on the same thing that I worked on yesterday", because nothing that is worth paying someone $200,000 a year to do is done in a day. (How do you know if someone is done with their high-impact project? Don't worry, they'll tell you.)

> Instead, aside from the programmers, you have mostly salesdroids and managers, who have absolutely no concept, because they have never done any real work.

Honest question - how many years of professional experience do you have?

Have you ever been on a team that didn’t have enough devs and needed to grow? Have you been on a team that addressed that by hiring more devs? What about funding for software and other tools to do your job?

This obviously varies from company to company, but often, especially at companies that promote from within, the managers around you very likely started doing exactly what you’re doing.

Managers also have their own kinds of deep work, like careful and detailed proposals to increase funding so your team can grow, just to name one.

If you expect the people you work with / who manage you to understand you and the challenges posed by distractions, taking some time yourself to truly understand them is just as important.

I should add a disclaimer: I’m not a people manager.

Sounds like a manager talking. The problem with programmers is, they haven't learn how to multitask! A few youtube videos and maybe a seminar and voila! They'll no longer be derailed by buzzword bingo and backseat driving.

The act of saying "Sorry, ..." is enough to derail a deep debug session. Having a manager hover over your shoulder is enough. And if that's not believable, then clearly one of us hasn't been there, and has a naive view about programming.