Building software is precise, imaginative work. That’s why developers are most productive in interruption-free environments. In fact, eliminating distractions will do more to optimize engineers’ efforts than most changes you could make to tooling. A team of exceptionally productive engineers can increase a tech company’s output tenfold and reduce labor costs. When every engineer is capable of delivering their best work on a consistent basis, a team of five can produce the output of a team of 50. Given that engineering expenditures are a massive portion of a tech company’s cost structure, that’s a big deal.
The measure of a developer’s productivity also has significant implications on the company’s product and pace of innovation. In many ways, it’s a core business metric. In a typical tech environment, there are several impediments to productivity: Meetings, occasional pings on Slack a lack of clarity on what developers are supposed to be building. These distractions may seem innocuous and unavoidable, but they add up.
“Creative work requires some degree of isolation.”
Each time they sit down to code, developers build up context for what they’re doing in their head; they play a game with their imagination where they’re slotting their next line of code into the larger picture of their project so everything fits together. Imagine you’re holding all this context in your head — and then someone pings you on Slack with a small request. All the context you’ve built up collapses in that instant. It takes time to reorient yourself. It’s like trying to sleep and getting woken up every hour.
“We reduce distractions across the board primarily through a high-documentation, low-meeting work culture. Few meetings means more uninterrupted coding time.”
My cofounder and I reduce distractions across the board primarily through a high-documentation, low-meeting work culture. Few meetings means more uninterrupted coding time. The few meetings we do have serve a purpose: They ensure alignment across teams, and they’re an effective means of sharing information. But when possible, we avoid meetings with thorough documentation. In addition to traditional developer docs in GitHub, we also create documentation outlining our various philosophies for how we run tests or the ways we use certain tools. This documentation provides clarity and guidance even more effectively than meetings, because it’s always available, continually updated and can be referenced asynchronously.
In addition to reducing meetings, this documentation also cuts down on Slack pings and emails. Developers know where to find the information they need and don’t have to interrupt each other’s flow for it.
“Another factor that gets in the way of developer productivity is a lack of clarity on what engineers are supposed to be doing.”
If developers have to spend time trying to figure out the requirements of what they’re building while they’re building it, they’re ultimately doing two types of work: Prioritization and coding. These disparate types of work don’t mesh. Figuring out what to build requires conversations with users, extensive research, talks with stakeholders across the organization and other tasks well outside the scope of software development. This sort of work requires very different skills and training from what software engineers are hired to do.
“The solution is assembling highly skilled product managers, design engineers and engineering managers that developers can trust to steer the ship.”
The solution is assembling highly skilled product managers, design engineers, and engineering managers that developers can trust to steer the ship. For us, that means we think of hiring and maintaining a team of exceptional product managers as an extension of our strategy for maximizing developer productivity.
“Happiness seems difficult to measure, but there are really good proxies for determining whether your team is satisfied. Low output and high attrition means your developers aren’t happy. Happy developers are more productive, and they’re less likely to leave.”
Happiness seems difficult to measure, but there are really good proxies for determining whether your team is satisfied. Low output and high attrition means your developers aren’t happy. Happy developers are more productive, and they’re less likely to leave.
“To keep developers happy, it’s important to understand why they got into software engineering in the first place.”
To keep developers happy, it’s important to understand why they got into software engineering in the first place. Exceptional engineers code because they love building things. That means companies need to prioritize clearing a path for developers to focus as much of their time on coding as possible.
“Another way we reduce distractions is by having a support rotation. Rather than expecting all developers to address urgent bugs or issues, we assign a single developer to address support issues for each week.”
Another way we reduce distractions is by having a support rotation. Rather than expecting all developers to address urgent bugs or issues, we assign a single developer to address support issues for each week. That way, the rest of the team is free to focus fully on their current projects, rather than bracing for interruptions due to something breaking.
“We largely frame tooling as a way to optimize developer happiness.”
We largely frame tooling as a way to optimize developer happiness. It introduces certain quality of life benefits and expedites rote tasks. We encourage our engineers to pay for and use GitHub Copilot, for example, because we’ve found that pairing programming with AI results in a 30% to 40% boost in developer productivity. That’s a tool that’s worth the investment.
“But even the best tooling can’t compete with exceptionally productive engineers. The cost of a suboptimal environment for developers is high.”
But even the best tooling can’t compete with exceptionally productive engineers. The cost of a suboptimal environment for developers is high. It limits your ability to innovate, slows product iteration, and degrades your competitive advantage.
“Ultimately, optimizing developer productivity comes down to eliminating distractions wherever possible.”
Ultimately, optimizing developer productivity comes down to eliminating distractions wherever possible. When engineers have the time, support, information, and tools to get into a flow state, they’re capable of doing more than a team 10 times the size. If an extra tool can help, even better. Kapil Kale is cofounder and COO of payouts platform Tremendous.
