Project Leadership

Teams rarely stall for lack of talent. They stall because the person held accountable for a result has no authority over it, so they stop trying. Or a leader who knows the answer keeps stepping in, and the team learns that the fastest way past a hard problem is to wait. Or someone newly promoted keeps doing their old job, so the people under them never get to do theirs. Or pressure from above gets passed down unchanged, and the team learns to protect itself first.

None of those failures look dramatic. A stalled ticket and a ticket in the middle of a hard search read the same in a status update. This practice covers the leadership moves that keep ownership where the work is: defining what you delegate, telling a blocked person from one who has stopped, helping without rescuing, absorbing pressure, handing over authority when roles change, and building teams that don't depend on any one person.

When to use this

• Use it when forming a team or delegating an area of work.
• Use it when work has stalled and you can't tell whether the person is blocked or has stopped looking for a way through.
• Use it when a stakeholder with more authority pushes for a decision the team believes is wrong.
• Use it when someone is promoted, or when a role or a project changes hands.
• Use it when a team mixes internal staff with external consultants.

Principles

Keep authority and accountability in the same hands. Holding someone accountable for a result they have no authority over teaches them to stop acting. Authority without accountability is the more dangerous form, because it lets someone shape a decision while somebody else answers for it.

An obstacle doesn't transfer ownership. The person responsible for an outcome still owns finding the next reasonable move when a dependency stalls, a requirement is ambiguous or an attempt fails. Ownership ends when the outcome is reached or the responsibility is deliberately handed to someone else.

Help without rescuing. Stepping in once is help. Stepping in every time teaches the team that waiting works. The aim is to give people something to push against, not to make the move for them.

Treat failed attempts as information. Punishing a miss, ignoring it or escalating it into a review nobody wants all teach the same lesson: stop trying after the first attempt.

You can't delegate what you can't define. Before handing over an area, say what success looks like, where the decision boundaries sit and when to escalate. That definition is what makes autonomy possible.

Absorb pressure; don't relay it. A leader who passes pressure from above down unchanged hasn't used their authority. They've handed the team the accountability without the authority.

Build so you can be replaced. Knowledge that lives only in someone's head disappears the day they leave. Work that someone competent could pick up from the code, tests and documentation compounds for everyone who inherits it.

The practice

Delegate by defining

1. Name the outcome the area serves and how it will be measured.
2. Write the decision rights: which decisions the person makes alone, which they make after consulting someone, and which they escalate. A table works; the one in Who owns what is a starting point.
3. Agree when to escalate and with what evidence.
4. Then leave the decisions inside those boundaries alone, including the ones you'd have made differently. Overriding a delegated decision without explanation is how ownership becomes unsafe.

Tell blocked from stopped

1. Listen to how the work is described. "Nobody told me what to do" and "that's another team's problem" describe a constraint as the end of the investigation. "I wrote down my assumptions and I'm building against them" describes it as the start.
2. Look for evidence of investigation: has anyone tried something, asked someone, proposed an alternative, or set a date to reassess?
3. If the person is blocked and still searching, leave them alone, except to clear what only your authority can clear.
4. If the person has stopped, ask the questions in Decision aids instead of answering them. They hand the next move back.
5. If several people have stopped in the same way, look at the system before the individuals. Overridden recommendations, blame after mistakes and three approvals for every step all train a whole team to wait.

Help without rescuing

1. Ask before answering, even when you know the answer.
2. Hand back the next move instead of making it: "What would you try first?"
3. Let reversible mistakes happen. They teach faster than instructions do.
4. When the situation really is urgent and you step in, say why, so it reads as an exception rather than the process.
5. Watch for the signs that you've become the bottleneck: blockers that clear only when you're in the room, stand-up updates addressed to you, and work that slows down when you're away. I look for these in myself first, because rescuing feels like helping and nobody complains about being rescued.

Absorb pressure from above

1. Don't relay a demand unchanged. "The VP says Tuesday, so figure it out" hands the team a trap.
2. Translate the demand into what it actually means: "We can add it to Tuesday. That compresses QA from two days to one across every feature in the release. Are you signing off on that risk?"
3. Name the alternative and its cost, so the person with more authority is choosing between two concrete options.
4. If they still choose the riskier path, record the risk acceptance with their name on it. Then carry out the decision professionally.
5. Protect the people who can't redirect the pressure. QA shouldn't absorb a late change and then be blamed when it breaks.

Hand over authority when roles change

1. The outgoing leader lets go of their old duties deliberately: the meetings they no longer need, the reviews they should delegate, the problems that now belong to someone else. A promoted leader who keeps doing their old job has duplicated a role at a higher salary.
2. The successor pulls authority forward and asks for explicit decision rights. That's organizational health, not disrespect.
3. Write down which decisions transfer and when. Without it, the team works for two partial leaders and neither is fully accountable.
4. The successor spends the first two weeks working through the six questions in Decision aids.
5. Within the first 90 days, the successor publishes a stop, start and continue list. It tells the team the change is deliberate.

Mix internal and external people deliberately

1. Choose the internal lead first, and let them define what is actually missing before bringing in outside help.
2. Bring external people in for specific gaps, and split ownership from day one. External people can own initial architecture, but the internal team owns integration and long-term support. That boundary makes outsiders design for maintainability.
3. Make collaboration explicit with joint design reviews, a shared decision log, and a way for the internal team to challenge external recommendations before they become commitments.
4. Ask every month whether the internal team is learning from the outside experts or just executing their plans. Executing their plans builds dependency, not capability.

Make yourself replaceable

Check your own work against one question: if you left tomorrow, could someone competent pick it up from what you've left behind? Put knowledge in code, tests and documentation rather than in your memory. Expect the same of the team, and treat a single person who holds a deployment process or a system in their head as a risk on the risk list.

Decision aids

Blocked or stopped?

Questions that hand back the next move

• What are you actually trying to achieve?
• What's really stopping you?
• What have you already tried?
• Which part of this can you control?
• What could you assume, just to keep moving?
• Who has the authority to unblock this, and have you asked them directly?

The successor's first two weeks

Who owns what

Signs it's going wrong

• Blockers clear only when the leader is in the room, and work slows when they're away. The team has learned to wait.
• Stand-up updates are addressed to the leader rather than the team.
• People say "we decided as a team" when nobody can name who decided. Accountability has dissolved.
• A newly promoted leader still reviews every pull request and approves every expense. The old job never got handed over.
• Pressure arrives at the team exactly as it left the executive. Nobody between them absorbed any of it.
• Documentation turns defensive and handoffs turn rigid. People are proving it wasn't their fault rather than solving the problem.
• One person can't take a vacation without getting calls. The team has a single point of failure with a name.
• Consultants leave and the internal team can't support what was built.

Related terms

Accountability, Authority, Responsibility, Decision Rights, Turtling, Risk Acceptance, Delivery Lead, Sponsor, Outcome

Where this came from

• Accountability and Authority: Walking the Tightrope: keeping authority and accountability together, and absorbing pressure instead of relaying it.
• Turtling: When a Team Stops Looking for the Door: blocked versus stopped, the language that gives it away, and how rescuing trains waiting.
• Every Arm Is Still Searching: The Octopus Model of Agency: an obstacle doesn't transfer ownership, and failed attempts as information.
• The Managed Transition Model: Leadership Promotion as Power Exchange: letting go of the old job, pulling authority forward, and defining before delegating.
• The Balanced Equation: Crafting the Perfect Project Team Mix: splitting ownership between internal and external people.
• The Art of Making Yourself Replaceable: A Guide to Career Growth: putting knowledge in the system rather than in one head.