A PM's lesson: get the work to the goal without leaving people behind

A project can start with a sentence as simple as “get this system done by next quarter.”

Everyone nods as if they agree. Then the work begins: the client pictured one thing, the team understood another, the person who can actually decide wasn't in the room, new requests keep arriving — and the delivery date hasn't moved.

Eventually the project manager becomes the person running around asking everybody:

“Where's this at?”
“Who's picking this up?”
“Will we make it?”
“Could you update the board?”

The whole day goes into chasing work, and the project isn't much clearer than it was this morning.

Two courses whose names sound unrelated

I'm still working out what being a good PM actually asks of you. In real work, getting a project to its goal is only part of it — the rest is working alongside people with different roles, different ways of thinking, and different constraints.

So I took two courses that, on paper, have nothing to do with each other. The first is Google's Foundations of Project Management — setting goals, planning, managing scope, coordinating, and getting a project to its destination. The second is Create a High-Performing Team — building a team, setting goals together, and helping people work better.

So this isn't a formula for being a PM. It's a summary of what I've learned and am trying to put into practice — in case it's useful to anyone doing this work, or anyone else curious about running projects and teams.

Putting the two next to each other, I started to see that a manager's job doesn't come in two separate modes — handle “the work” now, handle “the people” later. Every time we set a goal, assign a task, move a timeline or check on progress, we are already doing both at once.

Project management tells us which way the work has to go. People management tells us how to get there together.

Projects usually start going wrong before the team starts working

One of the first things the Google Project Management course teaches is the four phases of a project.

1. InitiateAgree on what problem we're solving
2. PlanSet the scope, time, people and risks
3. ExecuteDo the work, track it, clear the blockers
4. CloseDeliver, take the lessons, carry them forward

It sounds elementary — and yet plenty of projects sprint past the first two. Brief on Monday, board open on Tuesday, work split on Wednesday, and on Friday we find out that everyone understood the brief differently.

So the problem may not be that the team is slow. It may be that we started before answering the questions that matter.

• What problem are we solving?
• What exactly are we delivering?
• What's in scope, and what isn't?
• Who decides?
• How much time, people and budget do we have?
• How will we know this succeeded?

In one exercise, I planned a platform where teachers enter grades and students and parents can look them up. If the goal is written only as “finish the grade management platform,” everyone can read “finish” differently.

Run it through project initiation and it sharpens: the scope is the grading system, not every school system; the deliverable is entering and viewing grades online; 100% of teachers using it within nine months; a budget of $150,000; one IT person supporting it.

Nothing has been designed or coded yet, and the team already decides better — because it knows the goal, the constraints, and what should not be pulled into this project.

Before opening a board or handing out tasks, try writing a few lines: what are we making, to solve what, for whom, by when, and what has to happen for it to count as done. If that can't be answered clearly, no amount of timeline detail will stop the team from running in different directions.

A familiar tool doesn't mean the right one

The course also covers the ways of running a project — Waterfall, Agile, Scrum, Kanban, Lean, Six Sigma. The names make project management sound like a large subject, but the point underneath is fairly plain: no method is best for every project. It depends on the nature of the work in front of us.

So the question isn't “what does everyone else use?” It's: where is our project actually stuck, and which way of working would relieve that?

Some teams have sprints, dailies and a full set of boards, and still nobody knows what matters most this week. That isn't a missing tool. That's missing clarity.

A PM shouldn't just be the person who remembers deadlines best

Once a project is moving, the picture of a PM usually collapses into someone updating statuses, booking meetings and asking whether things are done. But if all we ask is “where's this at,” we get a percentage back and still have no idea what's actually going wrong.

Questions that help the team more:

• What are you trying to get to right now?
• What's in the way?
• Is there anything the team can't decide on its own?
• What information, people or support would help?
• If nothing changes, which part is most likely to slip?

Which shows that a PM's job isn't only to chase work — it's to take what's blocking the team out of the way. Often the blocker isn't technical: an unclear requirement, stakeholders who disagree, nobody to decide, or a team that doesn't feel able to say the timeline no longer works.

Most project managers have to do this without direct authority over everyone involved, which is why the course calls it influence without authority — getting people to see and to decide together, without giving orders.

• We can't force an answer today, but we can make the cost of not deciding visible
• We can't order the team to absorb more, but we can show what has to move if this comes in
• We can't decide for the owner, but we can name who decides, by when, and what it affects if they don't

That's the difference between a PM who forwards messages and a PM who keeps the team moving.

Once you look after a team, success isn't measured by what you do yourself

This is where the second one picks up. Create a High-Performing Team starts with a shift in thinking: from being responsible for your own work to being responsible for a whole team's.

As an individual contributor, a hard task is one you can just take on yourself, and success is the quality of what you shipped. As a manager, if you keep taking the hard tasks back, the team may hit this deadline — but nobody else learned anything, and you've become the bottleneck for everything.

A manager's success isn't how well we can do everyone's job for them. It's how good an environment we build for the team to work in. The course splits the role into three:

• Build community — make people feel part of a team and able to work together
• Deliver results — help the team produce the outcome it's there for
• Develop people — support each person to learn and grow

All three have to move together. Care only about results and the team may deliver on time but be too worn out to want the next project. Care only about the atmosphere and everyone gets along without knowing what the standard or the target is. Focus on developing people without giving them real responsibility, and the growth stays inside the conversation.

A team that works well needs clarity, meaning and impact: everyone knows what they're doing, understands why it matters, and can see how their part lands on the team, the users or the organisation.

Because it's very hard to work well when all you know is what's due on which day, and not who it helps or what it fixes.

A good goal has to travel from the slide to each person's work

Setting the team's goals is where the two courses meet most clearly.

Project management asks: what is the goal, and how will we measure success?
People management asks next: does everyone on the team understand that goal the same way?

A goal can be beautifully written in a document, and still one person is optimising for speed, another for quality, and a third thinks we're all still experimenting. That team isn't really moving toward one goal.

SMART goals make a target specific, measurable, achievable, relevant and time-bound. But hitting every letter still isn't enough unless it translates into answers for:

• What should the team prioritise right now?
• Who owns which part?
• What quality are we expecting?
• When do we check in on it?
• If the situation changes, who decides to adjust the goal?

So a manager doesn't just announce a goal. They bring it back up at enough moments that the team can decide with it on their own. When new work arrives, the team should be able to tell whether it connects to the goal. When two things compete, the team should know which matters more. When we give feedback, we should tie it back to what's still missing against the outcome we want.

A good goal doesn't only say where we're going. It helps the team know what to say yes and no to on the way there.

Every change of plan hits both the work and the people

Put project management and people management together and the same events start reading differently.

Setting scope isn't only managing a list of tasks — it's managing several groups' expectations. Changing a timeline isn't only moving a date on a plan — it's rearranging how a whole team's working life is ordered.

Tracking progress isn't only collecting statuses — it's checking whether people understand the brief, have enough to work with, and feel able to raise problems. Giving feedback does two things at once: it holds the standard of the work, and it helps one person do better next time.

Closing a project doesn't only leave files behind. It leaves lessons, relationships, and a way of working that the team carries into the next one.

Which is why managing people isn't something to reach for only when the team has a problem. It's already inside every decision the project makes, from the beginning.

If you had to start as a PM tomorrow, start here

You don't have to change the whole process in a day. Better questions at each stage are enough to start changing the work.

Before the project starts

• What problem are we solving?
• What does success look like?
• What's in scope and what isn't?
• Who does the work, who decides, and who needs to know?
• What constraints and risks are there?

While the work is running

• What's the important goal this week?
• Where is the work stuck?
• What decision or help does the team need?
• What changed from the plan, and who does it affect?
• If new work comes in, what has to move out?

When talking with the team

• Does everyone understand why this work matters?
• Is ownership clear enough?
• Am I helping them do it, or quietly taking it back?
• Does this feedback cover both what to fix and how to grow?
• Does the team feel able to raise a problem before it's too late?

At the close

• Did we deliver against the goal?
• What made the team work well?
• What should we stop, change or keep doing?
• What did people learn from this?
• What should the next project start differently?

These questions look ordinary. But being a good PM rarely starts with owning the most tools — it starts with making sure the things that matter get said at the moment they should be said.

Five things I want to carry into every project from now on

1. Don't start so fast that the goal never gets clear

   Work that starts a little later with everyone aligned can arrive sooner than work that opened a board on day one.

2. A PM's job isn't chasing work — it's keeping the team able to move

   Knowing something is late isn't enough. We need to know what's making it late, and who can take that obstacle away.

3. Every time we take on more, we accept what follows

   Scope, time and resources are always tied together. You can't add to one without moving another.

4. A manager doesn't have to be the best at everything

   They have to help the team understand more, own more, decide more, and grow.

5. A good result shouldn't cost the team everything it had

   A project doesn't end on delivery day, because the same people may have to work together again tomorrow.

In the end, project management shows us the structure of the work. People management keeps us from forgetting that all of that work is happening through actual people.