In knowledge work, productivity isn’t directly correlated with the amount of time spent working. We know this intuitively. If you’re exhausted, it doesn’t help with the problem you’re solving to spend more hours looking at the computer screen.
More often than not, taking a break (or going to sleep) is the only correct solution. You get back to the problem after the break (or the next day), and the problem has ‘solved itself’.
Or as Barbara Oakley puts it in their book A Mind for Numbers:
“Sleep has been shown to make a remarkable difference in people’s ability to figure out difficult problems and to find meaning and understanding in what they are learning.”
- Barbara Oakley: A Mind for Numbers
While Barbara is writing about learning, the same goes for working. Most knowledge work is, after all, learning.
Individual contributor (IC)
How come, then, often the focus at work is on how many hours we spend at work, not on what gets done? The intuitive answer is two-fold:
It’s much more challenging to measure output (or outcomes) than it is to measure how much time we’ve put in. Which is why it’s easy to turn to “busyness as proxy for productivity”, as Cal Newport writes in their book, Deep Work, and continues:
“In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity: doing lots of stuff in a visible manner.”
- Cal Newport: Deep WorkSo the character of work has evolved from the agriculture and factory work of old, but the way we measure productivity hasn’t necessarily evolved to meet the needs of this new kind of work. Or as Cal Newport continues in their latest book, Slow Productivity (which happens to be this month’s book in the Bad-Ass Bookshelf book club):
"It's why we gather in office buildings using the same 40-hour work weeks originally developed for limiting the physical fatigue of factory labor. And why we feel guilty about ignoring our inboxes. [...] It's safer to chime in on email threads and jump on calls than to put your head down and create a bold new strategy."
- Cal Newport: Slow Productivity
Many a manager's knee-jerk reaction is to try to micro-manage the time spent. Often, they don’t see what you do in the day-to-day work. Then it’s the out-of-the-ordinary that gets disproportionate scrutiny. Attending an event on a workday, for instance, might be frowned upon because the return on investment (ROI) isn't easily calculable.
But if your employee still delivers what’s expected of them, should it even matter what that ROI was? When we hear “as long as it doesn’t affect the performance”, the connotation is a negative one. What if we flipped the script? "As long as it has a positive effect on the performance (even if we recognize it's sometimes hard to measure)" has a much nicer ring to it.
Of course, it is tempting to blame the manager for everything. But as Cal’s quote from Deep Work suggests, a lot of this is self-inflicted. As mentioned above, most of us don’t have a manager watching over our shoulders. So it’s up to us to take care of our productivity, as no one else will do it for us.
Team
What about teams, then? Most of those who are not their own bosses (and also many who are) work in some team setting. As you know, in a team setting, you can’t have optimal productivity as individuals if you don’t have optimal productivity as a team.
By the way, optimal productivity doesn’t mean working full out all the time. It’s a marathon, not a sprint, as they say. This is what John Thompson had to say in their book, Building Analytics Teams:
“Over the course of a career, a project, or a period, the pace will need to quicken from time to time. You cannot expect to run at the most comfortable pace all the time; you and the team need to keep up and match the needs of the project and or company. The ebb and flow of the pace of work is to be expected and proactively managed to increase the productivity and well-being of all team members and the team as a whole.”
- John K. Thompson: Building Analytics Teams
What about agile methodologies, then? After all, it’s hard to find a job ad that doesn’t mention you have to be familiar with them. To me, 'agile' feels like one of those words that gets used so frequently and in so many different contexts that it starts to lose its meaning.
I know people have started to make the distinction, then, between agility and Agile with a capital A. Calling for the simplification of the framework and rituals that come with, say, Scrum.
Jon Yablonski's book, Laws of UX, is about UX, but the sentiment of “be careful not to simplify to the point of abstraction” also holds within (agile) teams. You shouldn’t have more rituals than necessary. But knowing where the line should be drawn isn’t always easy. What then is the key to success? In one word, communication.
Most of the rituals were meant to facilitate communication, but they only work if people
are present (in both meanings of the word)
are interested in helping each other be better and do better work
have trust in one another
have a shared focus
And while we need some rituals to make the team work, they aren’t sacred, and we shouldn’t be scared to customize them to fit the team we’re in. Unfortunately, the phenomenon of agile cosplay is a real occurrence. As Andrei Gliga puts it nicely in a LinkedIn post:
“Is Agile dead? No. But Agile cosplay is thriving. The teams that make it work? They care about outcomes, not rituals.”
- Andrei Gliga
I’ve witnessed firsthand how switching from Scrum to Kanban can be beneficial. We didn’t do it because someone told us to. The team decided it would be more conducive to completing actual work and reducing mental overload.
Sprints are great for some work, but can also create unnecessary stress every two weeks and cause you to rush to close a Jira ticket to ‘earn’ enough story points to look good, quality be damned. If this sounds familiar, maybe it’s time to speak up in the next retrospective…
I keep on going back to the book(s) that first got me thinking about agile and ways of working, The Phoenix Project and its ‘sequel’, The Unicorn Project. The field of data was relatively new to me at the time (and, in many ways, still is) when I first read these books.
I will write a separate post about them at some point, but these are the five pillars for productivity from The Unicorn Project that I try to live by:
Locality and simplicity: Focus on these to design effective systems and organizations. Cut internal complexity in our code, processes, and organizational structures.
Focus, flow, and joy: The quality of our daily work hinges on its structure. Engage in small, manageable tasks with quick feedback. Promote focus, learning, and joy.
Improvement of daily work: Focus on enhancing daily work processes rather than the work itself. This fosters a culture of continuous improvement and innovation.
Psychological safety: This is crucial for high-performing teams. Focusing on learning from incidents rather than assigning blame. Leaders must model, coach, and reinforce open communication and a culture of humility.
Customer focus: Focus on actions that improve customer lives and create value. Don't focus as much on internal metrics or siloed objectives. What to develop in-house versus what to outsource? Select options that enhance competitive advantage and meet customer needs.
In conclusion
I keep reminding myself that productivity isn’t just about what gets done today. It's also about how we set ourselves up to do good work again tomorrow.
Sometimes the best way to ‘get more done’ is to work less. Remember that real productivity isn’t measured in hours, but in the outcomes we create together.
The Unicorn Project’s pillars, especially focus, flow, and joy, are ones I try to revisit whenever I feel that old factory mindset creeping back in.
So next time you find yourself stuck in busywork or exhausted but still pushing pixels around your screen, remember: sometimes the bravest thing you can do for your productivity is to step away!
What’s one thing you can change (or stop doing) that would protect your focus, give you more joy, and help you maintain better flow, so you and your team can focus on what matters?
“Chances are, your company’s present time-accounting system is based on a conventional model. It assumes that work accomplished is proportional to the number of paid hours put in. When workers fill out their time sheets in this scheme, they make no distinction between hours spent doing meaningful work and ours of pure frustration. So they’re reporting body time rather than brain time.”
- Tom DeMarco & Tim Lister: Peopleware
Disclaimer: I’m writing this from Finland, where we have reasonable working hours, with the norm being 5 days a week, 7.5 hours per day (that’s 37.5 hours per week), and 5 weeks of paid annual leave. We have it reasonably well here. However, the concern about the balance between hours spent and outcome remains a valid point.
Further reading
Tom DeMarco & Timothy Lister - Peopleware
Gene Kim, Kevin Behr & George Spafford - The Phoenix Project
Gene Kim - The Unicorn Project
Cal Newport - Deep Work
Cal Newport - Slow Productivity
Barbara Oakley - A Mind for Numbers
John Thompson - Building Analytics Teams
Jon Yablonski - Laws of UX
Extra: Joe Reis - The Quality Paradox (Substack post), which is where I discovered Peopleware months ago, and which, in many ways, inspired me to write this.