Optimizing for Teams Rather Than Management
Optimizing for Teams Rather Than Management
The Problem with Focusing on Managers Rather Than Making The Jobs of Teams and Users Easier
“We need to standardize our processes.”
“We need to see regular reporting across all our teams.”
“We need to focus on predictability.”
You’ve probably heard the phrases above. I know I definitely have. On the surface, they seem to make sense. Having a standardized process for a company or organization makes sense, right? Having standardized, regular reporting to compare across teams makes sense, right? We all like predictability, right?
The problem is that these sentiments run counter to excellent product development.
want to listen? check out the podcast above
Optimizing for Managers
At their core, the idea of standardization and predictability are about optimizing product development (or any other type of work) for the benefit of management.
If your view is that we need to make managers’ jobs easier, these ideas of make sense. Standardization, regular reporting, and predictability all make the jobs of managers much easier. Like the pyramid below, the teams and processes are in place to support managers.
Standardization and Reporting
The need for standardization centers on the idea that managers need to be able to easily manage many teams, and if all those teams share a similar process, the job of the manager is easier. They don’t need to dive into individual teams to understand the nuances and difficulties. They can keep a safe distance and still do their “managing”.
Standardization often flows into the idea of reporting. If everything is the same for every team, then a manager at any level (from an engineering manager to a private equity owner) can glance at reports and get all the information they need. Again, they can keep their distance while pretending to understand.
But data and reporting, whether from teams or products or anything else, is a first step to understanding. It can point to areas for follow-up, but isn’t the end-all. You can’t truly understand without bringing quantitative and qualitative data together. But that is often the opposite of what standardization and regular team reporting are meant to do.
Predictability
Software and product development is inherently unpredictable. If it is predictable, you aren’t creating anything new or interesting. You aren’t solving problems, you are simply implementing existing solutions that have been done before.
I talked a lot about this several years ago in my article Product Thinking vs. Project Thinking, which was the inspiration for the name of this newsletter and much of the work I’ve done since.
For example, moving your human resources software from one provider to another can and should be predictable. The new software provider has likely helped manage the transition of many customers from a different platform onto their own. And given the size of a company and complexity of the move, they should be able to estimate the time and effort, because it has been done many times before.
But creating that new HR software system was inherently more unpredictable. What will customers need most? Will a feature solve the actual problems, or will we need to go back and create something different? What problems arise as we introduce completely new paradigms to companies? These things hadn’t been done before and are far harder to guess at.
Unless you are simply copying someone else’s software, you will have to deal with unpredictability.
Predictability, regular reporting, and standardization do all make a manager’s job much easier. But should that be the goal?
Optimizing for Teams and Users
Turning the pyramid on its head gives us a different view. We put teams and users in the most important place, with the processes and managers there to support them. It is no longer about making the job of the manager easier, but empowering the team to create the best experience and product for their users.
Product development teams are (and should be) closest to their users. They understand them the best and need to have the flexibility (dare we say “agility”) to create the right solutions for their problems.
Creating the right solutions may mean different needs for different teams. Trying to fit all development teams into the same bucket of process and management runs counter to agility and flexibility.
Just like we want to allow product teams to find the right solution to a customer problem, we should allow them to find the right solutions to their own processes to deliver on those customer and business needs.
Better Standardization
Not all standardization is bad. And some will be inevitable as organizations grow. But we should create frameworks for teams to work in and allow them the ability to adjust and explore the best way for them to achieve their goals and solve our customer problems.
Standardization should solve a problem for teams, not just for managers. If creating a common practice across many teams allows for faster development, faster releases, and better solutions, then we should do it. If it is just about allowing managers and leaders to keep their distance from actual understanding, then we should avoid it.
Managers
Having teams with different ways of working and different processes makes the job of management harder. But that is why managers are in that role and often get paid more. It is not the job of the team to make your job easier as a manager. It is your job to make things easier for your team, even if that means more work for you.
It is the height of laziness for managers to think that the teams they manage exist to make the job of the manager easier. Whether you manage a single team or an entire company of teams, it is not their job to make your job easy. It is their job to solve customer and business problems, and deliver solutions. Your job is to help them make that happen.
As a manager and individual contributor, I’ve dealt with all of these problems through the years. Managing teams working in different ways is harder. But I’ve never seen it as my role to force teams to change to make my life easier. As a manager and leader, it is literally my job to help teams do their best work, and do whatever translation is necessary so other stakeholders and leaders can understand.
Standardization, reporting, and predictability sound great, but should be approached with extreme caution. We need to help our teams deliver better solutions. If it helps our teams, then we should make it happen. But if standardizing processes or focusing on predictability hurts or hinders our teams, we should avoid it.
Other Good Links
Are Screens Robbing Us of Our Capacity for Deep Reading? (article) - I find this to be so incredibly sad. Thinking deeply and reading deeply are two of the most important things IMO. And we keep doing them less and less.
“It’s a spiral—as we began to move from books to screens, we started to lose some of the capacity for the deeper reading that comes from books, and that, in turn, made us less likely to read books. It’s like when you gain weight, and it gets harder and harder to exercise. As a result, Anne told me, she is worried we are now losing “our ability to read long texts anymore,” and we are also losing our “cognitive patience . . . [and] the stamina and the ability to deal with cognitively challenging texts.”
Project Hail Mary (book) - Speaking of books, I just finished this one by Andy Weir (The Martian). It was pretty good, though he falls back to familiar tropes from The Martian, which were fine the first time and, but get a little tired. It reminded me of Children of Ruin by Adrian Tchaikovsky, which is a superb book and handles many of the same themes, only much better. Check it out if you haven’t read it already.
The Discovery of Insulin: A Story of Monstrous Egos and Toxic Rivalries (article) - I love learning about the history of important discoveries. And insulin certainly is up there. I didn’t realize how dramatic it was though.
Station 11 (TV series) - If you haven’t watched this post-apocalyptic series, it is definitely worth your time. It is some of the best television I’ve watched in a long time.