A project manager is the person on a software team who makes sure the work actually ships. They don't write the code or design the screens; they keep everyone pointed at the same goal, spot problems early and turn 'we'll get there eventually' into a plan with dates.
What a project manager does
A project is a piece of work with a start, an end and a goal, such as launching an app or moving to a new database. Project management is planning that work, keeping it moving and dealing with whatever gets in the way. The project manager (PM) is accountable for delivery: the agreed thing, by the agreed date, within the agreed budget.
That makes it a coordination job. On a team of developers, designers and testers, each person sees their own slice. The PM sees the whole: who is doing what, what depends on what, and whether the pieces will meet in time. In a typical week that means:
- breaking the goal into tasks and putting them in order;
- tracking progress against the plan;
- clearing blockers, the things stopping someone from working;
- spotting risks before they become problems;
- keeping stakeholders, the people with an interest in the outcome, up to date.
A PM has influence over the work rather than authority over how it is done. They rarely tell a developer how to build something. They make sure the developer knows what to build, by when, and who is waiting on it.
The three questions
Developers joke that a PM only knows three questions. Those questions are the core of the job.
- 'What are you working on?' This checks that the team's effort matches the plan. Two people quietly fixing the same bug, or someone polishing a feature that was cut last week, show up here.
- 'When will it be done?' This asks for an estimate, because the rest of the plan depends on it. If the API won't be ready until Thursday, the app team can't connect to it on Tuesday.
- 'Is anything blocking you?' The most useful of the three. A blocker might be a missing password, a decision nobody has made or a code review sitting in someone's queue. A developer who waits three days for an answer loses three days; a PM who hears about it in the morning can often fix it by lunch.
On agile teams these questions usually live in a short daily meeting, the stand-up. Asked every day, they sound repetitive. The repetition is deliberate: a problem caught on day one costs far less than one found the week before launch.
Boards, tickets and timelines
A PM's tools put the state of the work where the whole team can see it.
- Tickets (or issues) are single units of work: 'Add password reset', 'Fix crash on login'. Each has an owner, a description and a status.
- Boards arrange tickets in columns by status, such as To do, In progress, In review and Done. A glance shows what's moving and what's stuck. A Kanban board often limits how many tickets can sit in a column at once, so work gets finished before more is started.
- Timelines, such as roadmaps or Gantt charts, set the bigger pieces against dates and show dependencies: what has to finish before something else can start.
Dependencies are where projects slip. If the designs must be signed off before the front end starts, and the front end must be done before testing, a delay at the top pushes back everything below it. The longest chain of dependent tasks sets the earliest possible finish date. It's called the critical path, and a PM watches it closely.
Meetings, and why developers complain about them
'Too many meetings' is a common complaint about project management, and it's often fair. Programming needs long stretches of uninterrupted focus. A meeting at 11 and another at 2 can cut a whole day into pieces too short for deep work. Paul Graham's essay 'Maker's schedule, manager's schedule', in the useful links, describes the clash: a manager's day is divided into hour-long slots, while someone who makes things needs at least half a day at a time.
A good PM treats the team's time as the scarcest resource on the project:
- every meeting has a purpose and an agenda, and ends when it's done;
- status updates go in the ticket or a written note, not a meeting;
- meetings are grouped together, for example all in the morning, to leave afternoons clear;
- only the people who need to be there are invited.
The stand-up earns its place because it is short: fifteen minutes at the same time each day, focused on blockers rather than a full report.
Removing blockers and duplicate work
Hearing about a blocker is only the start. The PM then chases it: getting the decision from the stakeholder who has been sitting on it, finding the person who can grant access, or reordering the work so nobody is idle while they wait.
Duplicate work is the other quiet cost. In a team of six it's easy for two people to start on overlapping tasks, or for two teams to build slightly different versions of the same component. A single board with clear owners, and someone who reads it, catches that early.
Things still go wrong, but on a schedule
No plan survives intact. A key developer falls ill, an outside service changes its API, or a feature turns out to need twice the estimated effort. Project management makes these problems visible early and gives the team a way to respond.
Most of the options come down to three linked constraints: scope (what gets built), time (when) and cost (people and money). Often called the iron triangle, these can't all stay fixed when something goes wrong. If a feature takes twice as long, the PM's job is to lay out the options and get a decision: cut or simplify the scope, move the date, or add effort. Adding people late is often the weakest of the three, because newcomers need time and help from the existing team before they speed anything up.
A good PM also keeps a short list of risks, things that might go wrong, each with a plan: 'The payment provider's test environment is unreliable, so build against a mock and we won't be blocked by it.'
A worked example: launching a food-ordering app
A team of four developers and a designer is building a simple ordering app for a client, due to launch in six weeks. On the Monday of week three, the PM finds three problems:
- A blocker: at stand-up, a developer says the payments work has stalled. The team still hasn't got live credentials from the payment provider, and the request has been in someone's inbox for a week. The PM finds who owns it and gets it escalated the same day.
- Duplicate work: the board shows two developers both building form validation, one for sign-up and one for checkout, each writing their own. The PM puts them together: one builds a shared version and the other moves on to order history.
- A slipping estimate: the order-tracking screen was estimated at three days and is on day six. Tracking feeds into testing, which feeds into launch, so it's on the critical path. The PM takes two options to the client: launch on time with tracking as a simple status label, or move the date by a week. The client chooses the simpler version.
None of this needed code from the PM. Each problem would have cost days if nobody had noticed it.
How a PM differs from neighbouring roles
The titles overlap, and on a small team one person may do several of these jobs. The difference is the question each one answers.
| Role | Main question |
|---|---|
| Project manager | Will we deliver this on time and on budget? |
| Product manager | What should we build, and why? |
| Scrum Master | Is the team working as well as it could? |
| Engineering manager | Are the developers supported and growing? |
| Business analyst | What problem are we really solving? |
Scrum, a popular agile framework, has no project manager role. Its guide names three accountabilities, the Product Owner, the Scrum Master and the Developers, and the planning and tracking a PM would do is shared between them. Plenty of companies that use Scrum still have PMs, especially for work that spans several teams. For the analyst's side of the table, see Business Analyst; for how Waterfall, Scrum and Kanban shape the way a team plans, see Development Methodologies.
Common mistakes
- Chasing status instead of clearing blockers: asking 'when will it be done?' without acting on the answer is just pressure. The questions only help if the PM does something with what they hear.
- Making meetings the default: if an update could be a comment on a ticket, it should be.
- Treating estimates as promises: an estimate is a best guess. Punishing a missed one teaches people to pad every estimate, and the plan stops meaning anything.
- Hiding bad news: a slip reported in week two leads to a decision. The same slip reported the day before launch is a crisis.
- Managing the board instead of the work: a tidy board with every ticket in the right column can still hide a team that's stuck. Talk to people.
Key takeaways
- A project manager is accountable for delivery: the agreed scope, on time and within budget, without writing the code.
- Their daily questions (what are you working on, when will it be done, is anything blocking you) exist to catch problems early.
- Boards, tickets and timelines make the work and its dependencies visible to the whole team.
- Good PMs protect the team's focus time and treat every meeting as a cost.
- Things still go wrong. A PM makes them visible early and turns them into a decision about scope, time or cost.
