← Head back to the Starter Manager Guide
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 was 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).
This principle of management comes from Andy Grove’s book, High Output Management. I believe so many best practices lie downstream from the implications of this principle that we should begin our journey by exploring this idea.
I want to suggest to that you should adopt this idea as the organising principle for your personal practice of management. Here’s why it works.
Why Does Management Get Such a Bad Rep?
First, let’s pause to consider: why does management get such a bad reputation?
The reason, I suspect, lies in a deep-seated confusion about what the manager’s job really is.
If you were an individual contributor — be it a programmer, designer or marketer in the startup context — it would be very clear to you what your job was. 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 our task tracking system.
- Assign tasks, via chat, to specific engineers.
- Sit down for a meeting with the designer on 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.
Very few 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 text boxes and chat windows, and conclude “MAN, WHAT A USELESS JOB!”.
This is a common misconception. An inexperienced junior would not appreciate the difference between activity and value, and concludes that all management activities are evil. A bad manager conflates the work for the output, and spends her time on yet more meetings, emails, and presentations.
This fundamental misunderstanding is how we get bromides about how “managers are a waste of oxygen” and “all meetings are a waste of time”.
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 can sometimes be very confusing for new managers. When you were an individual contributor, you could measure your performance by looking at the breakdown of time you’ve spent on your work. For instance, a programmer could look at the number of hours she spent 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 value that you’ve created. You’ll need a different model for evaluating your performance.
Managerial Leverage
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.
The Manager’s Job as Your North Star
Here’s the first major implication of this idea: if the manager’s job is to increase the output of the team, then every management technique may be evaluated by how it helps you achieve this goal.
It does not matter what management technique we’re talking about. We could be discussing process improvement, or learning to give better feedback; conducting meetings, or doing better one-on-ones; learning to delegate effectively, or being able to build trust; moulding culture, or hiring well — the truth is that all of these techniques and more are merely different ways of increasing the output of your team.
From now onwards, when you come across a new management technique, ask yourself the following three questions:
- How has this helped the author improve the output of their team?
- How may I adapt this technique for my organisation?
- Once I’ve applied it, how will I know if it has successfully increased the output of my team?
I should remark that the third question may be answered either quantitatively or qualitatively; “decrease the number of overtime hours” is just as legitimate a metric as “asking my team over the next two one-on-ones if they feel better about the team’s culture.”
The second implication of the “manager’s job”, however, is that it should change the way you look at your growth.
It feels scary when you think of management as a completely new skill tree, one where there’s no clear syllabus, and where the branches at the highest levels are hidden from view. But if you merely treat your management career as an optimisation problem, things will seem a lot easier than they are.
This allows me to introduce the first exercise of The Starter Manager Guide:
Once every week, sit down with pen and paper and ask yourself: have I increased or decreased the output of my team this past week? What may I do differently next week, that may increase the output of my team just a little more?
And then follow where the answers lead you.
(Go on, do this now. I’ll wait.)
Repeat this for a few months, and you’re likely to become a competent manager. Repeat this for a few years, and you’ll become a good one.
This method is how you may learn to become a good manager in a startup, even though you have no access to formal management training yourself.
In our next chapter, we’ll cover the most basic management skill, and the first one you're likely to struggle with: delegation.
Chapter 2: How to Delegate Without Micro-Management →
If you're a Commoncog member, download the ebook copy of this guide here. If you're not a member, fill this out to get an ebook copy:
Originally published , last updated .