Team management: recurring problems and practical fixes

Most of what team management actually involves is allocating two scarce things: attention and decisions. Everything else (the meetings, the tools, the documents) is machinery for moving those two around. What follows is organized around the questions that come up week to week when you are doing that badly and want to do it better.

What to take away

How many people can one person manage?

There is no correct number, but there is arithmetic you can do yourself. The question has been argued over for a century under the heading span of control, and the argument has never produced a figure that transfers, which is itself informative.

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 follow from that arithmetic: first, a manager with a full delivery workload supports far fewer people than one without. Pretending otherwise means someone gets neglected, usually the quiet, competent person who does not escalate.

Second, the number depends heavily on how much work is novel. A team doing well-understood work with clear standards needs less of you than one doing something for the first time.

Over capacity? The honest options: cut headcount, cut your own delivery work, or cut management depth for some people and say so. The dishonest option: keep the org chart and quietly stop one-to-ones.

The same arithmetic applies to what the team as a whole can commit to, covered in strategic planning.

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, case by case, about who decides and when you find out.

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 your main way to develop them and get your own time back. The cost is that some decisions will be made differently than you would make them.

If every difference 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. A single place that everything has to pass through sets the pace of the whole team. That is the argument of the theory of constraints, and it applies to people as much as to machines.

What works is narrowing the dependency, not eliminating it. Find the requests only they can handle, then split those from requests that reach them out of habit.

Pair someone with them on the second group first. That transfer is easier and builds the habit of routing elsewhere. Give explicit time for the handover, since a full queue leaves no gaps.

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. What a document can and cannot carry, and when writing one is the wrong move, is in operating processes.

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. The obligations that sit with you personally, and cannot be delegated to a calendar policy, are set out in management foundations.

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. In the United States, complaints of harassment or discrimination run through the Equal Employment Opportunity Commission or a state fair employment practices agency, and leave and accommodation obligations run through the FMLA and the ADA. Your employer will also have its own internal procedures. 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.

Make this explicit. It takes little time and pays off.

For each person, name the boundary in the terms their work uses: a spend limit, a commitment they can make to a customer, a change they can make without review, a decision they 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 on a team shows up in nothing you measure. One person answers everyone's questions and notices problems before they become incidents.

Another does the maintenance that keeps things from breaking, or smooths 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.

Selection processes and employment terms are governed by law that differs by jurisdiction — in the United States, federal anti-discrimination rules enforced by the EEOC, plus state and local law — 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.

Common questions

Should a manager still do hands-on work?

It depends on team size and whether you are the only person who can do a critical task, but the risk is predictable.

Delivery work has deadlines; management work does not. Under pressure, management gets dropped silently until something breaks. If you keep hands-on work, protect management time in advance instead of fitting it around 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.