Team Output Is The Smallest Unit Of Productivity
This article was first published in my newsletter, Herding Lions
I’ve been thinking recently about how most of my growth as a manager has come either from
a. Internalizing new ways of looking at the world (Mental Models)
b. Developing new habits
Over the next few months I’m hoping to do a deep dive on a few of the mental models that have been most helpful to me, starting with the idea that “team output is the smallest unit of productivity”.
I’ve found a lot of getting better as a manager is finding the right way to think about things. A few of the mental models that have helped me be more effective: (🧵)— Ben McCormick (@_benmccormick) October 26, 2021
In The Great Mental Models, Shane Parrish defines mental models like this
A mental model is simply a representation of how something works. We cannot keep all of the details of the world in our brains, so we use models to simplify the complex into understandable and organizable chunks. Whether we realize it or not, we then use these models every day to think, decide and understand our world.
In other words – the ways we simplify and talk about the world will guide our decisions on how to act. We all simplify, so it’s important to simplify in ways that are accurate and lead to effective actions. How we think about measuring, improving and planning productivity matters a lot! We all want to have impact at work, move the needle and work on things that matter. But most people come into management with a faulty intuition about what productivity looks like.
Managers often come into their first EM job fresh from the ranks of being an everyday coding engineer. For individual contributor engineers, productivity is commonly judged by personal output. An engineer will be able to say things like “I built that”, I “reviewed that code”, “I tested the project then found and fixed some bugs”. Impact is tangible, demo-able, and obviously tied to some larger objective handed down from above. Even more senior engineers who do more glue work and cross-org communication can usually still point to something that they owned and saw a result from: “I mentored that engineer as he built that”, “I led that project”, “I supported our sales team on that deal”. The life of an IC dev naturally leads to a world where productivity is defined with “I…” statements.
As a manager you are responsible for optimizing the output of your team over time. This may mean identifying opportunities and bottlenecks in your team’s processes and taking action. It may mean coaching a teammate through leading their first project. It may mean taking on interrupt driven grunt work personally to help your team achieve flow. It may mean standing up to other organizational leaders and making the case for a slower shipping schedule to allow your team to recover from a history of tech debt and burnout. It will certainly not stay the same over time.
The tempting thing is that it’s still easy to make “I…” statements as an EM. “I held a 1 on 1”, “I wrote the document”, or even “I wrote the code myself”. And because you probably have years of experience of benchmarking your success on those statements, it is deceptively hard to let go of them as a marker of your own personal productivity and progress. Put another way, your mental model of productivity is tied to the quantity and quality of your “I…” statements, and that is holding you back from having a broader impact.
“I…” sickness in a manager has a lot of common symptoms. I-sick managers don’t delegate as much, or only delegate the tasks they’re not qualified to do and are least able to coach and monitor on. They may confuse trackable busyness with productivity, or burn themselves out trying to keep an IC workload on top of their managerial responsibilities. I could go on for a while; it’s easy for me as this was my personal largest failing as a new manager.
The output of a manager is the output of the organizational units under his or her supervision or influence. - Andy Grove
An important property of teams is that they abstract the complexities of the individuals that compose them. - Will Larson
For me things only started getting better when I fully internalized an idea that I’d heard but not believed at a root level early on in management - the team’s output is the only thing that matters and what I should be optimizing for. I’ve found it most helpful to treat this as a general rule that “team output is the smallest unit of productivity”. That means tracking output at the team level, determining the effectiveness of my own actions based on how it impacts team output, and of course prioritizing work that maximizes “We…” statements, not “I…” statements.
I’m still not 100% consistent in personally applying this, which helpfully has allowed me to observe the impact of my choices over time. I find that when I focus more on optimizing for the team:
- it is easier to manage my time, and limit my hours to a reasonable level, as my work is more aligned with my built in responsibilities, and I don’t feel the need to hit a quota of personal productivity before clocking out
- it is harder to see the short term impact of my actions, which can be discouraging on days when other external factors are not aligned to help me feel my work is valued or useful
- I create a better environment for my team (duh?) and enjoy my relationships with them more
- Its harder to ignore lingering problems – including messy people problems where the next step may be an uncomfortable discussion
- I end up with a lot more variety in my work, as todays bottlenecks to team output are not likely to be the same as yesterdays
This has been a very manager-centric view so far, but tracking output at the team level can also have a very powerful impact on your IC teammates. The cult of “I…” based productivity has negative outcomes for non-managers as well. When your teammates are judging their productivity based on the number of tickets they’ve closed, projects that they took the lead on , or tech specs they’ve closed, it makes it harder to encourage glue work, swarming on critical issues, pairing, or other soft skill / collaborative activities. It’s easy to send messages as a manager that reinforce an “I…”-centric view of productivity: early on in my career as a manager I would track individual dev velocity sprint over sprint and divide up Kanban swimlanes by developer. Strangely my teammates always seemed to work in isolation and never had time for work that wasn’t directly assigned to them. When I switched from talking to people about improving their velocity to talking about helping the team achieve great outcomes, I saw huge improvements here. I’m grateful to some more experienced engineers who called me out on this and helped me see the benefits of focusing on the team over the individual at every level.
If you’re struggling to feel your work as a manager is valuable, feel like you never have enough time to “be productive”, or want to foster more collaboration in your team, start asking yourself: “What can I do today to make my team more effective?” and drop every other metric of productivity until you find that view natural.