One of the most profound things I learnt near the start of my management journey was the idea that “the manager’s job is to increase the output of the team.”
This single principle has come to dominate everything I know about management. In my previous company, this principle is how we managed to build our revenue to S$4.5 million dollars in two years — straight from a pivot — without ridiculous team scaling costs. It was how I increased retention and employee satisfaction in my engineering organisation, and how I eventually got overtime work down to one crunch period a year (that is, down from a customer emergency every few weeks).
I also did this in Vietnam, with an old, demoralised team that I inherited as the result of my company’s history as a consulting company. I owe a huge amount to their ability, and their willingness to put up with the many speed bumps we’d experienced together over the course of three years. I came in without prior knowledge of the country, culture, and language, and struggled in the first year because of it.
I wouldn’t trade that experience for anything else in the world.
This principle of management that I want to talk about today comes from Andy Grove’s book, High Output Management. I believe so many best practices lie downstream from the implications of this principle that it’s probably worth it to write a blog post explaining why this principle works, and how it’s useful to the practicing manager.
Why ‘Increasing Output’?
Let’s pause for a moment and ask ourselves: what, exactly, is the manager’s job?
If you are an individual contributor — be it a programmer, designer or marketer in the startup context — it is very clear what your job is. A programmer’s job is to write code, adding business value to the software product that the company sells (or perhaps adding efficiency to internal software that the company uses in the process of doing business). Ditto for designing and marketing — there is a direct mapping between the activities done by the individual contributor and the value created by the individual.
If you look at the activities of a manager, however, this relationship between activity and business value does not appear to be clear at all. Take me, for example. On any given day, my job as a manager might require me to:
- Write story cards for upcoming features in Phabricator.
- Assign tasks, via chat, to specific engineers.
- Sit down for a meeting with the designer on the proposed mockups for an upcoming client customisation case.
- Hop onto a conference call between my boss and a potential client.
- Spend 30 minutes over the course of the day in chat, with sales, who demand quotations and advice for certain client customisations.
- Do or assign blocking code reviews.
- Help a software engineer with a tricky bug.
- Triage a dozen or so customer service complaints.
- Talk to customer service, especially when deployments go wrong.
Not all of these activities map directly to business value. It’s difficult for a junior software engineer, newly hired at our company, to look at these activities and conclude that I’m useful. What they’ll see superficially is that the manager gets to tell people to do things, and then spends the rest of the day typing into textboxes and chat windows, and conclude “MAN, WHAT A USELESS JOB!”
This is a common misconception. A bad manager conflates the work for the output, and spends her time on yet more emails and meetings and presentations. An inexperienced junior does not appreciate the difference between activity and value, and sees management as evil. These are both wrong views. The truth is that managerial activity is separate from business value, and so managers cannot evaluate their value merely by the activities they’re doing.
This fact is incredibly confusing for new managers. When you were an individual contributor, you could measure your output by looking at the breakdown of time you’ve spent on your work. For instance, a programmer can look at the number of hours she spends in a code editor and conclude a (rough!) correlation between that and the business value she has delivered.
But when you are a manager, you cannot look at the breakdown of activities you’ve done for the day and understand the amount of business value that you’ve created. You’ll need a different model for evaluating your performance.
The answer that Grove proposes is that managers are supposed to increase the output of the team.
This is their real job. Nothing else matters.
In this view, a manager’s activities don’t determine value. Instead, managerial activities are good or bad depending on the degree with which they’ve increased (or decreased!) the output of their team.
As an example, say that a programmer is unable to work until a program specification has been written. If a manager doesn’t ensure that a spec is ready for the programmer to work on, then she has just decreased the output of her team, because the programmer is now sitting idle. (In practice, the programmer might start working on something of less importance — which is just as bad.)
Worse, say that a manager rushes through and has a spec that is badly written. Now the programmers that are working according to the spec have built the wrong thing, and all other units in the company that depend on this feature is affected.
In this situation, the manager has screwed up royally! Not only has she lowered the output of her team, she has negatively affected the output of the other units that depend on her team within the company.
The reverse is also true. If a manager always has a spec ready when a programmer is freed up and waiting for his next task, and if the manager always ensures that problems are caught at the lowest value stage possible (i.e. the spec is properly vetted before work begins), then the output of the team is maximised, and the manager has done a good job.
Grove calls this idea ‘managerial leverage’. Positive managerial leverage occurs when an activity increases the output of the team. Negative managerial leverage does the reverse.
This idea — that the manager’s job is to increase the output of the team — leads to a large number of powerful implications. I remember learning this idea and being momentarily stunned at the downstream impacts of the idea on my day-to-day work.
Consider this: if your job is to increase the output of your team, then you may evaluate yourself by looking back and continually asking: “Have I increased the output of my team this week, or decreased it? What did I do well? What can I do better? How do I improve?”
It implies that you should pause multiple times a day to ask yourself “Is this the highest leverage activity that I can be doing? If this activity is low leverage, can I stop doing it, or delegate it out?”
It implies that you should look at processes in your team, asking “Can I redesign some of these processes? Is there anything we can change to increase efficiency?”
It implies that doing performance review and one-on-ones are hugely important, as they affect the motivation and output of individuals in the team.
It implies finding creative new ways to learn about problems before they happen to your team, and learning the techniques for doing so, because preventing problems before they happen is the ultimate form of protecting the output of your team.
It implies preventing politics from growing in your startup, because politics saps team output.
It (sadly) implies playing politics if your team works in an existing, political culture.
And it implies that it is necessary(!) to fire bad performers, because keeping bad performers on your team takes up open slots that could have gone to someone else. In other words, not firing bad people means that a manager is no longer doing their job.
It is, in fact, very difficult to find a management technique or recommendation that isn’t somehow related to the core idea that ‘managers are supposed to increase the output of their team’.
Once you learn this idea, however, it becomes easier to evaluate other managers around you. It helps you pick the right mentors to learn from.
Good managers internalise this idea and continually look for ways to increase the output of their teams. Their actions map consistently to their understanding of the manager’s job. Bad managers, on the other hand, don’t even notice when they exercise negative managerial leverage, because they don’t understand the core metric of their role.
You can make this idea work for you today. Make increasing the output of your team your top priority, and let all your practices follow logically from there. This is your north star, and the path that leads to managerial competence. Understanding the manager’s job is the first step of the path to becoming a good manager.