Slow Productivity for the Software Industry
Can reducing the work volume improve software engineers’ productivity?
Last week I read a very interesting article from Cal Newport of the New Yorker:
I suggest you read the whole thing, but the gist of it is: of course, we are working too much and burning out. Yet knowledge workers aren’t just working too many hours, we’re working on too many things. Here is the key passage:
…Autonomy has allowed modern knowledge work to evolve haphazardly toward an increasingly unsustainable configuration. The issue in this evolution is not how many hours you’re now asked to work but the volume of work you’re assigned at any one time.
By volume, I’m referring to the total number of obligations that you’re committed to complete — from answering a minor question to finishing a major project. As this volume increases past a certain threshold, the weight of these efforts can become unbearably stressful. Humans are uniquely adept at crafting long-term strategic plans for accomplishing objectives. Our facility with planning, however, falters when confronting an in-box stuffed with hundreds of messages and a task list that fills multiple pages. When there’s too much for us to imagine actually completing, we short-circuit our executive functioning mechanisms, resulting in a feeling of anxious unease.
These psychological struggles aren’t the only cost to having too much work to do. Most professional commitments bring with them the need to coördinate with other people. If you agree to create a marketing plan for a new product, in addition to actually writing the plan, you probably need several meetings and a small avalanche of e-mails to pull together the necessary information and keep the project on track. In isolation, this overhead is reasonable. When you’re tackling too many such projects concurrently, however, the combined impact of all of the corresponding meetings and messages can take over most of your schedule, creating an overhead spiral of sorts in which you spend significantly more time talking about work than actually getting it done — a form of wheel-spinning freneticism that amplifies frustration and, ultimately, leads to burnout.
Sound familiar? If working less is called Slow Work (echoing other “Slow” movements like Slow Food ), Newport suggests working on fewer things at once be called Slow Productivity:
The central goal of Slow Productivity is to keep an individual worker’s volume at a sustainable level.
Newport suggests that over a large enough time span, that workers will accomplish more as they can focus more on fewer things at once. Furthermore, reducing the worker’s “volume” will make them happier and less likely to burn out.
The article is about knowledge workers generally, but I think our industry- software engineering, has a lot to offer on the subject¹. For example, I think we’ve learned a lot about the benefits of reducing “volume” by limiting Work In Progress (WIP) — the total number of tasks a team is working on at one time.
In the excellent book Accelerate, the researchers found that reducing WIP and using other Lean Management practices are core capabilities in elite-performing software teams. Lowering WIP has literally been shown to Accelerate teams and lower burnout.
In addition to limiting WIP, which is usually an intra-sprint discipline, I think we need to focus serially in quarters by limiting Projects In Progress (PIP). I recently took on interim engineering manager duties for one of my teams.
When I arrived, the team of 7 software engineers was working on 5 separate projects. There was a lead driving each project, maybe with another engineer's help. Unsurprisingly, in sprint retros and 1 on 1 conversation, these engineers described the stress of taking on a project nearly solo. They also had little awareness of what other team members were working on. With the team’s buy-in, we made some simple changes:
- We limit Projects In Progress to 3. We will not start a new project unless we are only working on 1 or 2 projects.
- No one gets assigned specific work at the start of the sprint. Engineers can only start new work if there are no open tasks they can help with by pairing, reviewing, testing, or deploying.
As we’ve lowered the WIP and PIP, the engineers have unanimously enjoyed the changes. We’ve been hitting our sprint goals and I expect us to hit our quarterly project goals.
This isn’t always easy stuff. Limiting WIP and especially limiting PIP requires agreement and discipline of engineering and product leadership. We’ve all felt the pressure to split an engineer’s time between two projects to demonstrate initial progress.
But in the end, this won’t win you any points as both projects slip. Ultimately, doing this well requires an entire organization’s buy-in. Try to get PIP down in as many places as you can and then demonstrate that quarter over a quarter, more is being delivered.
Overtime hopefully you can train stakeholders to stop asking questions like “when will we get these 5 projects done?” but instead ask:
- “Are we working on the 1–2 best things?”
- “Would we still do this project if it took 50% more time?”
- “How can we deliver something smaller, somewhat sooner?
It’s also worth noting, as Newport does, the many other sources of “volume”. For our software engineers that may be on-call, production monitoring, support requests, and basically, everyone has to use Slack.
As a manager and leader, you should be aware of all these sources, limiting them or accounting for them as best you can. For example, an easy fix is having a Support Captain.
It’s a simple rotation of team members where the current Support Captain is substantially taken out of the sprint to handle all incoming business-hour support, questions, and production monitoring, allowing everyone else to focus on sprint commitments.
Also, if you have to install Slack, at least do yourself the favor of turning off all alerts.
If as leaders we can get good at this, not only will our teams’ velocity go up, so too will our engineer’s and manager’s happiness. I’d love to hear everyone’s thoughts on Slow Productivity. What’s worked for you?
Notes
¹ Case in point, Newport thinks this is a big obstacle for Slow Productivity:
The bigger challenge of Slow Productivity is that it requires systems to manage work that’s not yet assigned….Slow Productivity would require you to log this item into a system where it can be properly prioritized and ultimately assigned when the right person has the needed time available.
Jira, he’s describing Jira.
