Everyone wants higher productivity. Whether it’s because you want to get a high priority project out faster, or because you want to run more experiments, or because your CFO is asking why it takes your cost center team so long to get anything done, or even just because you’ve worked in higher performing environments and you long for the sweet smell of ozone as the CI/CD servers work overtime to deliver the goods.

And you know it’s possible. There are companies out there that are faster than yours, and not just because they have three times the number of engineers. They must all be 10x engineers, you think, and look doubtfully over your team roster. Maybe, you think, you need to up-skill or (that delightful euphemism) “upgrade” your team. You remember when the company was young, when there were only a handful of engineers, and yet somehow you managed to move mountains. Now, even those engineers are struggling. What happened?

The important thing to understand is that productivity isn’t some unknowable, mystical force that just happens in the presence of great people. It’s the interaction between people and their environment, and there’s been a metric ton of research into what works and what doesn’t. All of which has been gleefully ignored and actively opposed in modern “thought work” environments.

Flow

The most important factor in creating a high performance team is creating an environment conducive to flow. To refresh:

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.” There is no consciousness of effort; the work just seems to, well, flow.
– DeMarco and Lister, Peopleware

Flow is the experience of being fully engaged in exercising a skill you’ve mastered, to tackle a challenging but not insurmountable problem. It is the state people are in when they are performing at their peak. If you want a high productivity team, they must be able to get into flow for long stretches of time.[1]

The problem is that flow is extremely fragile. Any distraction will break flow, and it takes 15 minutes[2] for an engineer to get back into this deep state. By distraction, I don’t just mean direct interactions—pretty much anything will break flow, including pop-up notifications, other people talking nearby, sudden loud noises, even eye contact.

You may notice that I just described the modern office environment.

Most people never get into flow. They’re subjected to a constant barrage of sound, visual stimuli, and interruptions. They might not even know what they’re missing, especially if they’ve grown up in a world of constantly beeping devices and a never-ending flow of chat messages and other notifications. No flow means chronic low productivity, and a belief that all of your people are just low performers.

And let’s be fair – the CFO isn’t entirely wrong. The tech team is extremely expensive. How can the company be paying so much money and getting so little in return? It would never occur to them, or to anyone in leadership, that the problem is both solvable, and that given the tools, they will consciously choose not to solve it.

So, let’s first go through things you can do, which are easy because they are entirely under your control.

Support Rotation

One of the first things I do on any team I manage, is to create a support rotation. The idea is that one person per week is the sin eater for the team, handling all incoming requests, monitoring of alerts, answering questions, handling outages, etc. All incoming requests go through one central channel—Slack, email, pagerduty, Jira, whatever—and one person is assigned to handle everything for the week. They might have to pull someone else in if there’s something they don’t know how to do, or if there’s an emergency, but the vast majority of requests are typically non-urgent, and by having one person on the team triage, you free up the rest of the people to tune out.

There are three problems with this. The first is that engineers don’t like to tune out. They feel a sense of ownership (which is good!), which leads them to continue to monitor the channels (which is bad). You need to train them to let go, to trust their team members, and to stop monitoring. You also need to train yourself not to reward constant firefighting.

The second problem is that everyone who’s been at the company for more than a month will have a favorite engineer they like to ask for favors. “Come on, Alice, it’ll just take you five minutes.” You have to train the rest of the company—by training your team—to go through the standard channel. Everyone here has to have discipline, which isn’t easy. And while you can’t stop people on other teams from reaching out, you can get your team to firmly and politely redirect them.

The third problem is that there will be times when there are emergencies, or when the support rotation engineer doesn’t know how to do something. That’s fine! You just need to make sure that there’s a way to get in touch with non-rotation engineers in extremis (PagerDuty, SMS, etc.), and that the support rotation engineer can get support from the rest of the team when they need it.

Notifications

Notifications are the devil. Your team needs to shut off anything that might beep or boop or pop up or otherwise break their concentration. Some people will tell you that they have the magical ability to ignore notifications (“I don’t even notice them anymore”). They might believe this, but they’re wrong[3]. Studies have shown that even if you think you aren’t paying attention to the little pop-ups, part of your brain is. Turn it all off.

Meetings

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

– Paul Graham, Maker’s Schedule, Manager’s Schedule

We managers are the least important people on our teams, and yet we commonly sink everyone’s productivity by scheduling meetings that are convenient to us, not them. This is one of the most straightforward changes you can make. Schedule all of your team meetings so that they’re minimally disruptive (e.g., putting scrum meetings before or after lunch, and scheduling 1:1s next to those meetings so that your team members don’t have fragmented blocks of time). Encourage your team to set up and enforce focus time (Google Calendar will helpfully auto-reject meetings during this time, if set up correctly).

Stop Collaborating

<record scratch>

Yes, you heard me. Stop collaborating. Or rather, stop collaboration theater. The promise of open plan offices, of return to work mandates, of having people constantly interacting is that the next great idea is just one water cooler conversation away. This is a fantasy cooked up by people whose jobs involve talking to other people (c.f. the manager’s schedule above), who have leases they need to justify (sunk cost fallacy), and who think that cramming everyone into a productivity-destroying space is a small price to pay for collaboration.

Interruption is not collaboration, it’s just interruption. And when you’re interrupted, you’re not getting work done.

– Rework (2010)

True collaboration happens when multiple people are engaged in a common activity that needs all of their contributions. It doesn’t just happen magically—it is intentional, and purposeful. Collaboration theater is when you dump a bunch of people into an office, create rules based on available space and cost and appearance of furniture instead of desired outcomes, and call interruption “collaboration”. Look at all the interaction! The hallway conversations, the constantly full meeting rooms! Surely we must be drowning in serendipitous interactions that never would have happened if we created an environment that allowed thought workers to get work done!

When one of your engineers tells you that they prefer to work late because “no one’s around and they get so much done”, or that they don’t even try to get work done in the office because they just spend that time in meetings, that’s an indictment of your so-called collaborative environment.

You don’t have to believe me—I refer you instead to the many, many studies on open source offices and on the productivity benefits of giving your engineers a door to close. And as I’ve mentioned before, DeMarco and Lister spend seven chapters going over the performance benefits of having a space optimized for thinking.

Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals: Count on the best people outperforming the worst by about 10:1. Count on the best performer being about 2.5 times better than the median performer. Count on the half that are better-than-median performers outdoing the other half by more than 2:1. … The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The top performers’ space is quieter, more private, better protected from interruption, and there is more of it.

– DeMarco and Lister, Peopleware

This is one of the origins of the infamous myth of the 10x engineer. But it hits a little different when you realize that the source data imputes a fair amount of the performance variance to workspace, not some unknowable, immutable innate ability. It turns out that creating an environment of constant interruptions, Harrison Bergeron-style, has a negative impact on team performance. Who would have guessed?

Rounding it all up

So here we are—easy, right? Everyone on the team has a door they can close, but are able to come out and interact with others when it matches their needs. All notifications have been turned off, and only the support rotation engineer is available for ad hoc requests. No one checks their email or chat client except during well-defined “office hours”. Meetings are minimized, and those that are necessary (scrum rituals, 1:1s, etc.) are scheduled next to each other so that thinking time isn’t fragmented. Everyone is able to get into flow, and suddenly you have an entire team clustered in the top quartile (or better) of the performance normal curve. This should make everyone in your management chain happy, right?

Except you won’t

This is the point at which someone will tell you no. In fact, other than the support rotation and changing your meetings (both of which are under your control), everything else is off the table.

They will tell you that:

• “We’re trying to foster a culture of collaboration.”
• “We don’t have enough office space to give teams their own dedicated areas.”
• “We don’t have enough seats to create areas with ‘library rules’.”
• “People have to come into the office because we think it creates a more engaged culture.”
• “We don’t have enough meeting rooms, so some people have to take meetings from their desks.”
• “If people need quiet to work, they can wear noise-cancelling headphones.”
• “It isn’t fair to the other teams if we give the engineers special privileges.”[4]
• “We have offices in <other time zones>, and we can’t restrict meetings to one time because that will push them into unacceptable times of day.” (this is a real problem, and there isn’t a good general solution—but that doesn’t mean that you should throw up your hands and abandon productivity)
• “It’s important for everyone to always be available, in case there’s an emergency.”
• “We believe in the importance of serendipitous meetings that can only happen when people are together in the office.”

It’s worth considering for a moment what the purpose of the office environment is. It isn’t actually there for collaboration. It isn’t there for serendipitous meetings. It isn’t even there for productivity. All of these are means to an end.

The office exists to contribute to the success of the company. That’s it. If the company is more successful because the office exists, then it has value. If the company is less successful because of the office, then it’s destructive of value. Accepting an office environment that destroys half of your team’s productivity is a choice. If the company got a really great deal on keyboards that typed the wrong character 10% of the time, you’d throw those keyboards away. But somehow we’ve delegated our teams’ productivity to people who have no knowledge or interest in what makes a high-productivity environment, and they typically choose to “utilize the space effectively”, as though the purpose of the office were to warehouse employees, and their jobs were to Tetris different departments into the smallest space, with the least cost.

Sometimes culture can win—I once worked on a team of eleven introverts who worked inside a dedicated space with library rules, and we got a hell of a lot of stuff done on a very tight schedule—but this too is something you have to fight to create. It won’t happen without intentionality and work on your part.

Or, you can give up, and accept. High productivity is for other companies, and other teams. In your company, you have an office, and collaboration. And for a lot of people that’s enough.

---

[1] It’s important to understand that flow isn’t New Age woo, and it isn’t just my opinion. Flow has been studied intensively for decades.

[2] Note: I didn’t make up the 15 minutes thing. That’s based on years of research by psychologists trying to understand flow. If you think that your team is special, and can somehow get back into flow faster, you’re engaging in magical thinking.

[3] There’s probably a whole blog post to be written about all the productivity-related magical thinking engineers engage in (“I have the special ability to get back into flow immediately” “I don’t even notice notifications, which is why it’s ok to leave them on” “I’m more productive in a noisy environment” etc etc). It’s the new machismo (plus ça change), and at some point it isn’t even worth trying to convince them that they’re wrong. I just explain that lesser engineers don’t have their special abilities, and so would they please stop having loud conversations in the middle of the cubicles?

[4] This is always a weird one, since it simultaneously recognizes the problem, pretends it doesn’t exist, and denies relief.