Reject Performative Busyness
Optimize for progress, not theater.
We live in exciting times. Gone are the days of hunting, gathering, and struggling for survival. Thanks to technology, many of us earn a living by applying our creativity toward solving problems we find interesting. And as we keep innovating and creating, more problems arise and more people have a chance to find their problem-market fit.
Yet despite all the new tools and possibilities, many knowledge organizations stagnate. So much potential remains untapped.
One culprit is a pervasive culture of performative busyness: using visible activity as a proxy for productive work1.
A lot of time at work is spent doing theater.
Communication Theater. Being always online and replying to messages and emails as soon as they are received to signal presence.
Meeting Theater. Daily stand-ups and other ritualistic meetings where people take turns talking about the work they plan to do instead of actually doing the work.
Reporting Theater. Status updates and progress reports rich in detail, screenshots, and graphs that take as long to compile as the work they describe.
Task Theater. Bloated project management software with hyper-granular, multi-dimensional, interconnected tickets to curate like gardeners.
Cultural Theater. Joining every culture event and strategically interacting on highly visible projects to show engagement and alignment.
None of these activities are inherently bad or completely wasteful. Teams need a way to track work in progress and spread workload, internal seminars are great learning opportunities, and asynchronous communication channels ought to be monitored. These tasks often look and feel like “real” work, but notice the difference in customer-facing progress between a day spent pruning the backlog and one spent writing code2.
For a knowledge organization to operate at its full potential, we need to minimize performative busyness in favor of actual problem solving.
Cal Newport* has a proposal to move in this direction: Let your best people cook.
Cal starts from a Brandon Sanderson interview where the prolific author described how his company is organized around the principle “let Brandon cook.” Creating stories is the most valuable thing Sanderson can do for his business, so the whole organization is optimized for it.
Most knowledge organizations have their own Brandon Sandersons: people with high-return creative skills. When these people apply their craft, they disproportionately bring the product forward. It’s in a business’s best interest to let its high-impact people apply their skills for as long and with as few distractions as possible.
Obviously, not everyone in a company has a role that directly and disproportionately advances the product. But it seems reasonable to expect that, as we optimize for real-world progress (shipping) over performative busyness, the workflow changes involved will also benefit those with supporting roles. Alternatively, a knowledge organization with a more focused creative workforce might need far fewer auxiliary roles, and the people in those roles will have more ownership and opportunities to use their creativity.
There are so many problems waiting to be solved and we have never been in a better position to take them on. It’s truly tragic to think how much progress we are forfeiting because we’re projecting busyness instead of actually applying our creativity.
As Cal urges, “let the Brandon Sandersons of your company cook!”
The notion of performative busyness is a redressing of what Cal Newport calls pseudo-productivity in his 2024 Slow Productivity book, defined as “the use of visible activity as the primary means of approximating actual productive effort.” The concept of using “busyness as a proxy for productivity” from Cal’s 2016 seminal book Deep Work was also influential. Still, I find the “performative” in performative busyness better conveys how far removed from genuinely productive work those activities are.
Some nuance is required. I’ll admit that the comparison is not always favorable to coding. A day spent identifying the most useful projects to work on could set the direction for a very productive work cycle. Conversely, a day of aimless coding might build unnecessary functionality or, worse, introduce dangerous bugs. But given a project already identified as worthy and a developer who knows what they’re doing, I’ll always bet on actually doing the coding as the surest way to make progress.