From maker to multiplier

Andy Grove, who ran Intel for many years, gave managers a simple definition in High Output Management (1983). A manager's output is the output of the organisation they run, plus the output of the neighbouring organisations they influence. Your own commits, designs and tickets are no longer the measure. If your two teams ship the offline stock counts and the mobile wallet payment on time and stay healthy, you did well. If you wrote brilliant code and the teams stalled, you did badly.

Grove's tool for this is leverage. Before you spend an hour, ask how much that hour changes the output of everyone around you. Three kinds of task have high leverage:

• Tasks that affect many people at once. Clarifying a priority for a whole team, fixing a broken release process, or agreeing an API contract with a vendor changes the work of five or six people.
• Tasks that last a long time. A good hire, a clear team charter or a skill you coach into someone keeps paying back for years.
• Small inputs at the right moment. A decision made on Monday instead of Friday saves four days of waiting. A short piece of feedback before a bad habit sets in saves months.

Some tasks have negative leverage. A decision only you can make, made late, blocks everyone. Reviewing every pull request yourself turns you into a queue. Changing your mind in public about priorities costs the team the work they did on the old ones.

Grove also lists what a manager actually does all day: gathering information, passing it on, making decisions, nudging decisions others make, and being a role model. Notice that writing code is not on the list. You will still read code and sometimes write it, but it stops being the main way you add value.

Your calendar changes too. Paul Graham's essay "Maker's Schedule, Manager's Schedule" (2009) describes the difference. A manager's day is cut into one-hour slots, and a meeting costs one slot. A maker, such as a programmer, needs blocks of at least half a day, so one meeting in the middle of the afternoon can ruin the whole afternoon. Your day now runs on the manager's schedule. Your engineers still run on the maker's schedule, and protecting it is one of your highest-leverage jobs: group meetings together, keep some days free of them, and stop pulling people into meetings they only need the notes from.

What you own, and what moves to the tech leads

In What a tech lead is (and is not) you saw the tech lead's job from the other side. Now you sit above two tech leads, Sam on the Store app team and Dara on the Partner app team. If you don't agree who does what, you get two failures at once: things that both of you think the other one owns fall through the gap, and things you both try to own create two bosses for the team.

A useful split for most teams looks like this. As engineering manager (EM), you own six things:

1. People. 1:1s, feedback, coaching, growth, performance and pay conversations for all 11 engineers (1:1s, feedback and coaching, Performance and growth).
2. Team health. Workload, morale, conflict, whether people feel safe to raise problems, and whether anyone is close to burning out.
3. Hiring. The open senior backend role, the interview loop and onboarding (Hiring well).
4. Delivery. The promises the teams make: what they commit to, the risks to those dates, and telling people early when a date is in danger.
5. Process. How the teams plan, review, release and learn, and whether those habits still earn their time.
6. The link to the business. Bringing context in (strategy, priorities, budget) and taking the teams' needs and risks out to Ken, Imran and the other department heads (Managing up and across).

The tech leads own the technical direction: architecture and design decisions, design reviews, code quality, technical debt, and breaking work into pieces the team can build (Technical vision and design docs, Slicing and planning work). Some things are shared: sprint planning, estimates, incident response and the technical side of interviews.

Write the split down and agree it with each tech lead in your first two weeks. The method is a short table with three columns, "decides", "is consulted" and "is told", and one row per recurring decision: who picks the state library for offline counts, who approves a release during the festival freeze, who agrees scope changes with Imran, who decides a promotion. When a new kind of decision comes up, add a row. The table protects the tech leads' authority, because when an engineer brings you a design question you can point to the row that says Sam decides.

Where the manager's time goes

New managers often feel busy all day and still unsure what they did. The cure is a time budget: decide in advance roughly how many hours a week each part of the job gets, then check your calendar against it every two weeks.

Start from the fixed parts. With 11 engineers, 1:1s alone are a real block of time. You meet the two tech leads every week and everyone else every two weeks. That is about four to five hours a week, including short notes after each one. Then add stakeholders (Ken, Imran, Lagoon Digital, the heads of store operations and partner sales), the team rituals of two teams on two-week sprints, and hiring for the open role, which can take five hours a week while interviews are running.

Three rules make the budget work:

• Leave slack on purpose. Plan only about 25 of your 40 hours. Incidents, a worried engineer at your desk, and a sudden question from the finance director will fill the rest. A manager with a full calendar has no time to respond, and responding is part of the job.
• Protect thinking time. Plans, charters, risk notes and hiring scorecards need a few quiet hours a week. Block them like meetings.
• Keep coding small and off the critical path. Two or three hours a week of code reviews, small fixes, tooling or reading the code keeps you close to the work. Anything a delivery date depends on belongs to someone whose calendar is not cut into one-hour slots.

Then audit. After two weeks, sort every calendar entry into the budget's categories and compare. If hiring took eight hours and 1:1s took two, people got less of you than you planned, and you can decide whether that was right. A rough audit every month is enough.

Your first 90 days with two teams

In Growing as a PM you met Michael Watkins' idea of learning first, then an early win, then owning the plan. The same shape works for a new EM, with some parts that are special to managing people. The plan below has written milestones at day 30, 60 and 90.

Weeks one and two: a first 1:1 with each of the 11 engineers. Thirty to forty-five minutes each, tech leads first. Ask everyone the same questions, so you can compare answers and see patterns: what slows people down, what they are proud of, what they would hate you to change, where they want to grow, and how they like feedback. Take notes in their words. Say what you will do with what you hear, and then do it. Don't diagnose anyone in a first meeting; a quiet engineer may be shy, overloaded or unsure what the reorganisation changed for them.

Weeks two to four: the listening tour. Meet the people around the teams: Ken, Imran, Leila, Tomás, the head of store operations, the head of partner sales, the HR partner, and Lagoon Digital's lead. Go to a store and watch staff count stock on the scanners; visit a partner shop like Ravi's and watch an order being placed. Meeting the team first means you can test what engineers told you against what stakeholders say. Read the last few incident reviews, the roadmap, the delivery plan and the team's working documents (Your team's engineering playbook).

Listening is not waiting. Some things cannot sit for 30 days. The Partner app's mobile wallet payment is promised for 1 December and is about three weeks behind. Learn the facts in your first week from Dara and Imran, and tell Ken in week two what you know, what you don't yet know, and when you will bring options. Bad news told early is cheaper for everyone (Managing up and across).

Day 30: a written note. One or two pages, shared with both teams and Ken: what you heard (themes, in people's words, never who said what), what you will keep, the early win you picked for each team, and your plan to day 90.

Days 31 to 60: charters and early wins. Each team writes a team charter with its tech lead: its purpose, what it owns, who its users are, how other teams send it work, its working agreements and the few numbers it watches. You guide; the team writes. In the same weeks, each team delivers one early win. A good early win is small enough to finish in two or three weeks, visible, valued by the team and its users, done by the team with you clearing the way, and in line with the priorities. Pick it from the problems that came up most often in the 1:1s.

Days 61 to 90: the next quarter. Agree the ownership split with both tech leads for good, set up a simple team health baseline that the teams use to learn (Team design and delivery health), have a growth conversation with each engineer, and review the 90 days with Ken: what changed, what didn't, and the plan for next quarter.

The three traps, and what to do instead

Most new managers fall into at least one of these. Each one feels like doing a good job while you are in it, which is why it is a trap. For each, learn the signal that you are in it and the move that gets you out.

Trap 1: coding on the critical path. You were a strong engineer, the wallet payment is late, and you know payments. Taking the hardest piece yourself feels responsible. The signal: a delivery date now depends on code that only you are writing, in a calendar cut into one-hour slots, and it is late. The move: give the work to an engineer, take on what only you can do (the conversation with Lagoon, the scope talk with Imran), and keep your own coding to things nobody is waiting for.

Trap 2: the super tech lead. You make the technical calls, rewrite designs in review, and engineers bring design questions to you instead of to Sam or Dara. The signals: the tech leads wait for your approval, design reviews end with your opinion, and the teams slow down when you are on leave. The move: route design questions to the tech lead, ask questions in reviews instead of giving answers, and if you disagree with a design, say so once with your reasons and let the tech lead decide, unless the decision is hard to reverse and carries real business risk. Your job is to make Sam and Dara strong (Delegation and mentoring).

Trap 3: changing things too early. In week two you see a slow release process and know a better one from your last team. The signal: you are changing a habit before you know why it exists, and the team hears that its past work was wrong. The move: keep a "things I notice" list from day one, ask why each thing works the way it does, and decide after your day-30 note which changes to make, with the team.

A quieter fourth trap: giving all your attention to the noisy team. The Partner app team has the late date, so it will pull you in every day. The Store app team is shipping steadily, and Nell rarely asks for anything. Keep every 1:1 on the calendar for both teams. Steady teams and quiet people lose good engineers when nobody notices them.