Team management: methods, tools and useful context

Most of what a manager actually does is allocate two scarce things: attention and decisions. Everything else (the meetings, the tools, the documents), is machinery for moving those two around. This page is organized around the questions that come up week to week when you are doing that badly and want to do it better.

How many people can one person manage?

There is no correct number, but there is arithmetic you can do yourself.

Assume each direct report gets a proper conversation every week or fortnight. Add the time you spend on their work rather than with them: reviewing, unblocking, answering, representing them elsewhere. Add the recruitment, the performance conversations, the disagreements between them. Now compare the total with the hours you have left after your own non-management responsibilities.

Two things fall out of that arithmetic. First, a manager who also carries a full delivery workload can support far fewer people than one who does not, and pretending otherwise means someone gets neglected: usually the quiet, competent one who does not escalate. Second, the number depends heavily on how much of the work is novel. A team doing well-understood work with clear standards needs less of you than a team doing something for the first time.

If you are over capacity, the honest options are to reduce the number of people, reduce your own delivery work, or explicitly reduce the depth of management some people get and tell them so. The dishonest option is to keep the org chart and quietly stop doing one-to-ones.

The one-to-one that is worth having

The common failure is that the meeting becomes a status update. You already have status somewhere else; if you do not, fix that separately rather than spending your only private conversation on it.

A few things that make the difference:

They set the agenda, you keep a running list. If they bring nothing, you bring something from your list, but the default owner of the time is them. A meeting where the manager talks for most of it is a briefing.

Ask about the work, not about feelings, and the feelings will come. "What's slowing you down?" and "What did you spend most of last week on?" get further than "How are you finding things?" People will tell you about frustration when it is attached to a concrete thing.

Write down what you committed to. The fastest way to make these meetings pointless is to agree to unblock something and then not do it. Two cycles of that and the person stops raising things.

Do not cancel them. Canceling a one-to-one to attend something more urgent teaches, accurately, where they sit in your priorities. Move it instead.

The cadence matters less than the reliability. Every two weeks, always, beats every week, usually.

Delegation means transferring the decision

Most delegation that fails was not delegation. It was task assignment with the decision retained: the person does the work, brings it back, and you decide. That leaves you as the bottleneck and them as a pair of hands, and it is why "I delegated it and it came back wrong" is such a common complaint.

Be explicit about which of these you are doing:

• Do this thing. You have decided; they execute. Fine for well-defined work, corrosive as a default.
• Look into this and recommend. They do the analysis, you decide. Useful while you are calibrating whether their judgment matches yours.
• Decide this, tell me what you decided. They own it. You find out afterward.
• Decide this. I do not need to know. Full ownership, and you have to actually mean it.

Naming the level at the start prevents the most common friction: they thought they owned it, you thought you did, and the disagreement surfaces after the work is done.

Moving someone up a level is the main mechanism you have for developing them, and it is also the main way you get your own time back. The cost is that some decisions will be made differently from how you would have made them. If every one of those differences is a problem, you have not delegated, you have set a trap.

The person who is a bottleneck

Every team develops one: the individual who knows the system nobody else knows, whose queue everything passes through, who is genuinely excellent and genuinely a single point of failure.

This is usually treated as a person problem. It is a design problem, and treating it as a person problem makes it worse: the person hears that their expertise is an inconvenience.

What tends to work is narrowing the dependency rather than eliminating it. Find out which specific requests only they can handle, and split those from the ones that reach them out of habit. Pair someone with them on the second category first, because it is the easier transfer and it builds the habit of routing elsewhere. Give them explicit time for the handover, since it will not happen in the gaps of a full queue.

What does not work is announcing that knowledge must be shared and expecting documentation to appear. Nobody writes documentation for a system they are still firefighting.

Meetings as a budget

A recurring meeting is a standing withdrawal from every attendee's week, and unlike a project it never finishes. Treating meetings as a budget rather than a calendar changes what you notice.

Take your team's recurring meetings and multiply duration by attendees by frequency. The number is usually startling. Then ask, for each one, what decision it produces. Not what information it shares: information can be written. What decision.

Meetings that produce no decision are not automatically waste; some exist for coordination or for the relationship, and those are real. But they should be defended on that basis rather than drifting on because they are in the calendar. A meeting with no decision and no relationship purpose should be a written update.

Two practical habits: give every recurring meeting an end date, so continuing it is a choice rather than an omission; and let people decline the ones where they are only listening, without it being a political act.

Disagreements between people who both work for you

You will spend more time on this than you expect, and the instinct to resolve it quickly is usually the wrong one.

Most workplace conflict that reaches a manager is either a resource conflict wearing an interpersonal costume, or a genuine disagreement about priorities that neither party has the authority to settle. Both have the same tell: the complaint is about the other person's attitude, but the substance is about who gets to decide something.

Ask what the actual decision is. If there is one, make it, say why, and be clear that it is a decision rather than a compromise. Unresolved priority conflicts do not stay dormant; they resurface as friction between the people caught in them.

Where the conflict is genuinely interpersonal (behavior, conduct, anything approaching harassment or discrimination), that is a different category. Employment obligations vary considerably by country and by employer, and there are usually internal procedures and legal duties that apply. Involve your HR function or your organization's own advisers early rather than handling it informally.

Distributed and hybrid teams

The specific cost of working across locations and time zones is that everything asynchronous adds a round trip. A question that takes ten seconds in a room takes a day when the answer arrives while you are asleep.

That single fact explains most of what makes distributed teams work.

Reduce round trips rather than adding communication. A question with three possible answers, sent with the answers enumerated, resolves in one cycle. The same question sent open-ended takes three.

Write decisions down, not discussions. People joining a thread late do not need the debate; they need the outcome and the reason. Long threads are where distributed teams lose the most time.

Be deliberate about who is in the room when some people are not. If half the team is co-located, the co-located half will accumulate context the others lack, and it will look like the remote people are less engaged.

Overlap hours are the scarce resource. Spend them on things that need back-and-forth (disagreements, design, difficult feedback), and never on status.

Setting how far someone can go without asking

Every person on your team needs to know where their discretion ends. Most do not, so they either ask about things you did not need to hear or decide things you needed to know about: usually both, from different people.

Making this explicit is quick and unusually high-value. For each person, name the boundary in the terms their work actually uses: a spend limit, a category of commitment they can make to a customer, a type of change they can make without review, a decision they should always bring to you.

Two things make the boundaries hold.

State the reason, not just the limit. "Anything that changes what we have promised a customer comes to me" is a rule people can apply to a case you did not anticipate. A bare number is not.

Widen them deliberately as trust builds, and say so. If the boundary never moves, capable people conclude that their judgment is not developing in your view, whatever you say in a review.

The corollary is that when someone decides something inside their boundary and you dislike the outcome, you do not get to override it retrospectively without cost. You can change the boundary going forward. Reversing a decision that was theirs to make teaches everyone that the boundaries are decorative.

A new joiner's first three months

Most onboarding effort goes into the first week (accounts, introductions, orientation), and then stops, at exactly the point where the person starts needing help with the actual work.

Some things that matter more than the induction schedule:

Give them something real and small in the first fortnight. Something that ships, that someone uses, that they can see the result of. Long ramp-ups with no output are demoralizing and teach nothing about how work actually gets finished here.

Name the person they can ask stupid questions. Not you: you are the person whose opinion of them matters, which makes basic questions expensive to ask. Someone else, explicitly told that this is part of their job.

Tell them what is not written down. Every team has conventions nobody thinks to mention: who to ask about what, which meetings matter, what the last reorganization changed, which system is authoritative when two disagree. New people spend months discovering these by making mistakes.

Ask them what they find confusing, in the first month, and write it down. This is the only window in which someone can see your team's oddities clearly. After eight weeks they will have normalized everything, and the information is gone.

Say when you will decide whether it is going well, and on what. Vague early months produce anxiety in the joiner and postponed conversations from the manager.

Recognizing work that leaves no trace

Some of the most valuable work in a team is invisible in anything you measure: the person who answers everyone's questions, who notices the problem before it becomes an incident, who does the maintenance that means nothing breaks, who smooths over the friction between two colleagues.

The failure mode is well known and easy to fall into. What gets noticed is what is visible; what is visible is what is new; so the person doing the enabling work is quietly rated below the person whose results they enabled. They usually know it, and they usually stop.

Two practical things. Ask who people go to. The answer identifies your enablers faster than any reporting will. And name the work explicitly when you talk about performance, so the person hears that it registered: including in front of others, where the recognition also signals that this work counts.

If your organization's rating process has no room for it, say so honestly rather than pretending the outcome reflects the contribution.

Hiring into a team you already run

Two things worth deciding before you write a job description.

What is the gap, in terms of work you cannot currently get done? "We need another engineer" is a headcount request. "Nobody owns the release process and it fails every third time" is a role. The second one gets you a better shortlist and a much better first ninety days.

What will this person's first three months look like concretely? If you cannot describe it, you are not ready to hire, and the new person will spend those months finding their own work, which, if you are lucky, is work you wanted done.

Selection processes and employment terms are governed by law that differs by jurisdiction, and by your own organization's policies. Get the process itself reviewed by whoever is responsible for that where you work, rather than improvising it.

What to fix first

If you manage a team and things feel bad, check these in order. They are ordered by how often they turn out to be the actual problem.

1. Is anyone unclear what they are meant to be working on this week? Ask them directly, one at a time. Disagreement between their answer and yours is the most common root cause of everything else.
2. Is there a decision you are sitting on? Held decisions do more damage than wrong ones, because the work stops while everyone waits.
3. Are the one-to-ones happening? Not scheduled: happening.
4. Is one person carrying a disproportionate load? Look at who gets asked questions, not just who has tasks assigned.
5. Is there a conflict everyone is politely working around? These are usually visible in what people avoid discussing when a particular person is present.

Common questions

Should a manager still do hands-on work?

It depends on team size and on whether you are the only person who can do a critical thing, but the risk is predictable. Delivery work has deadlines and management work does not, so under pressure the management work is what gets dropped, silently, until something breaks. If you keep hands-on work, ring-fence the management time in advance rather than fitting it around the delivery.

How do I manage someone more expert than me?

You are not managing their expertise; you are managing their context, priorities, and obstacles. Ask what they need decided and what is in their way. Do not pretend to evaluate technical judgment you cannot evaluate: find someone who can, or accept the judgment and manage the outcome instead.

How much should I tell the team about things I have been told in confidence?

Say what you can, say clearly that there is something you cannot say, and never say there is nothing when there is. Teams tolerate uncertainty far better than they tolerate discovering they were misled, and the discovery always comes.

What is the biggest avoidable mistake?

Being unclear to be kind. Vague feedback, softened expectations, and deferred conversations feel considerate at the time and are the source of most unpleasant surprises later: for the person as much as for you.