Project managers
A project manager is accountable for a piece of work arriving — sequenced, resourced, unblocked and visible to the people paying for it. The role is often mistaken for administration because its artefacts are documents and meetings, when the substance is judgement about dependencies, risk and where a plan is quietly failing. What follows explains the discipline, the conditions under which it earns its cost, and how to distinguish someone who moves delivery from someone who describes it.
What does a project manager do?
A project manager owns the delivery of a defined body of work: agreeing its scope and sequence, mapping the dependencies between teams and suppliers, tracking timeline and budget against the plan, surfacing risk while it can still be acted on, clearing obstacles that the delivery team cannot clear alone, and keeping stakeholders informed with a picture they can act on. The accountability is for the work reaching completion — not for deciding what the organisation should build, which belongs to product.
The distinction between delivery accountability and product accountability is the one that causes most of the confusion around this role. A project manager can be entirely successful on a project that should never have been commissioned, and entirely unsuccessful on a valuable one. Their question is whether committed work reaches production predictably; someone else’s question is whether that work was worth committing to.
Most of the real difficulty lives in dependencies. Any project of consequence relies on things outside the delivery team — a security review, a vendor contract, a data migration, another team’s API, a legal sign-off, a hardware lead time, one person on annual leave in a fortnight. Each is fine in isolation and each has a latest responsible date. Holding that lattice in view, and acting on it weeks before it becomes urgent, is the part of the job that is hardest to observe and most costly to omit.
The second difficulty is honest reporting under pressure. Projects rarely fail suddenly; they fail through a sequence of small optimistic readings that were individually defensible. A project manager who reports what is actually true — including that a date is no longer credible — gives an organisation the chance to respond. One who reports comfortably removes that chance, and the failure arrives all at once, late.
When teams need this capability
Delivery coordination is usually absorbed by a tech lead or engineering manager until the coordination surface grows faster than their capacity for it. These are the pressures that typically make dedicated project management worth its cost.
The work crosses more than one team or supplier
Once delivery depends on another team’s roadmap, an external vendor, an infrastructure group or a client-side approval, the coordination stops being incidental. Nobody inside a single team can see the whole critical path, and the handoffs between teams become where the weeks disappear.
Engineering leads are spending their week on coordination
A tech lead scheduling meetings, chasing approvals and assembling status updates is doing necessary work at a poor exchange rate. The usual signal is a senior engineer whose calendar is full and whose technical contribution has quietly stopped, which is expensive twice over.
Commitments carry an external consequence
A regulatory deadline, a contractual milestone, a trade event, a partner integration date or a migration with a decommissioning cliff. When missing a date has consequences beyond disappointment, someone needs to be tracking the path to it deliberately rather than hoping the sprint cadence will get there.
Nobody can say what state the work is in
Different people give different answers about what is done, what is blocked and what remains. This is rarely dishonesty; it is the absence of a single maintained view. Its cost shows up as decisions taken on stale information, and as surprises that were visible to somebody weeks earlier.
Scope keeps growing without a corresponding decision
Requests arrive through side channels, get absorbed by whoever hears them first, and never appear against the plan. The date does not move because nobody has connected the additions to it, and the shortfall surfaces only when the date does.
A programme of work needs sequencing rather than a backlog
Migrations, platform replacements, market launches and integrations have an order that matters — steps that cannot start until others finish, and windows that cannot be moved. That structure needs planning outright, and treating it as a prioritised list of tickets loses the constraint that governs it.
Core capabilities
Scope definition and control
Establishing what the project includes, what it explicitly excludes, and what completion means for each part of it. Most scope disputes are not disagreements about work but about a boundary nobody wrote down, and the exclusions turn out to be the more valuable half of the statement.
Sequencing and planning
Decomposing work to a level where estimation is meaningful, ordering it against real constraints, and identifying the path where slippage propagates rather than absorbs. A plan whose value is that it exists is not a plan; the useful output is knowing which items cannot slip without moving the end date.
Dependency management
Tracking every input the team does not control — other teams, vendors, approvals, environments, data, people — with a latest responsible date for each and a standing habit of chasing them before they bite. This is the single most under-appreciated part of the discipline.
Risk identification and response
Naming what could plausibly go wrong, judging likelihood against impact honestly, and — the part frequently skipped — agreeing an owner and a response for the ones that matter. A risk register maintained as a document rather than as a set of decisions is administrative weight with no return.
Removing obstacles
Finding out what is genuinely stopping progress and going and resolving it: the environment nobody owns, the access request in a queue, the decision waiting on someone who does not know it is waiting on them. Whether a project manager does this or merely records it is the clearest divide in the profession.
Stakeholder communication
Knowing who needs what information, at what depth and how often, and giving a sponsor the version they can act on rather than the version that is easiest to assemble. Different audiences need genuinely different reports, and one update circulated to everyone usually serves nobody.
Timeline and budget tracking
Following actual progress and actual spend against the committed baseline, and understanding variance well enough to explain its cause. The value is early warning: a trend identified while there is still room to respond is worth more than a precise figure delivered afterwards.
Change management
Handling requests that arrive after the plan is set — assessing their effect on scope, sequence, cost and date, and putting the trade-off in front of whoever owns the decision. The failure mode is silent absorption, where a series of reasonable additions consumes the buffer without anyone choosing to spend it.
Estimation and forecasting judgement
Working with estimates while remembering what they are. That means using ranges rather than points where uncertainty is real, using observed throughput in preference to optimism, and resisting the reflex to convert a forecast into a commitment because a commitment is what the room wanted to hear.
Governance and decision hygiene
Making sure decisions are actually taken, recorded with their rationale, and communicated to the people they affect. A surprising share of delay is not disagreement but a decision that everyone believes someone else has made.
How the discipline works
Project management is a practice rather than a toolchain. What follows therefore sets out the delivery approaches, planning techniques and artefacts the discipline relies on across the market — a description of how the work is done, not a claim about any particular practitioner’s toolkit. Tooling matters far less here than in an engineering role: the same techniques are applied in almost any tracking system, and a candidate is better judged on how they plan, forecast and escalate than on which product their last employer had licensed.
Delivery approaches
- Scrum
- Kanban
- Hybrid and staged governance
- Incremental delivery
- Programme and portfolio coordination
Planning and sequencing techniques
- Work breakdown
- Dependency mapping
- Critical path analysis
- Milestone planning
- Rolling-wave planning
- Capacity and throughput forecasting
Risk and change practice
- Risk registers
- RAID logs
- Likelihood and impact assessment
- Mitigation and contingency planning
- Change control
- Escalation paths
Reporting and forecasting artefacts
- Status reporting
- Burn-up and burn-down charts
- Cumulative flow diagrams
- Cycle time and throughput measures
- Milestone and variance reporting
- Budget and spend tracking
Stakeholder and governance practice
- Stakeholder mapping
- Responsibility assignment matrices
- Communication planning
- Steering and governance forums
- Decision and action logs
Common tool categories
- Work tracking systems
- Roadmap and timeline planners
- Documentation and knowledge bases
- Spreadsheets and forecasting models
- Asynchronous communication platforms
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Project managers interview well. The vocabulary of the discipline is easy to acquire without the underlying practice, and a candidate can describe a governance structure fluently having only sat inside one. The reliable approach is to ask about specific projects that went badly and listen for what they personally did about it.
Obstacle removal versus status reporting
This is the divide that matters most and the one least visible on a CV. Ask what they did the last time a project was blocked by something outside their authority. Reporting a blocker upward is the beginning of the work rather than the whole of it, and the answer will tell you which understanding they hold.
- Describes going directly to the person or team causing the block
- Can name a blocker they resolved without escalating it
- Treats escalation as a considered step, not a reflex or a last resort
- Talks about what they did, not what the process required
Dependency thinking
Ask how they identify dependencies at the start of a project and how they keep track of them afterwards. Weak candidates list dependencies once and revisit them when something breaks; strong ones treat the list as live, with an owner and a date attached to each entry.
- Distinguishes dependencies they control from those they merely influence
- Attaches a latest responsible date rather than only a description
- Has chased an external party well ahead of the need
- Can describe a dependency they missed and what it cost
Honesty about a slipping date
Ask about a project where the committed date became unachievable, when they knew, and when they said so. The gap between those last two answers is among the most informative things you will learn in the interview.
- Raised the problem while options still existed
- Presented choices — scope, sequence, resourcing — rather than only bad news
- Can explain how the slippage arose without attributing all of it elsewhere
Handling change without becoming an obstacle
Scope changes on every project of consequence. Ask how they respond to a significant late request. You are listening for someone who makes the trade-off explicit and hands the decision to whoever owns it, rather than either blocking on principle or absorbing quietly.
- Frames change as a cost to be decided rather than a rule to be enforced
- Takes the decision to the accountable owner instead of taking it themselves
- Can describe a change they accepted and what it displaced
Working credibly with engineers
A project manager does not need to write code, but they do need enough technical literacy to tell a genuine constraint from a preference, and to avoid asking for something incoherent. Ask how they respond when an engineer says a task will take considerably longer than expected.
- Asks what makes it hard before questioning the estimate
- Understands why some work resists decomposition
- Has adjusted a plan because of a technical constraint they came to accept
- Does not describe engineers as a resource to be levelled
Stakeholder judgement
Ask how they handle a sponsor who wants a date the plan does not support, or two stakeholders who want incompatible things. The role requires holding a position under pressure from someone more senior, and some experienced candidates have never actually done it.
- Separates what a stakeholder asked for from what they need to know
- Has told a sponsor something the sponsor did not want to hear
- Adapts depth and frequency of reporting to the audience
Method held lightly
Certification indicates exposure to a body of knowledge and nothing about judgement. The candidates worth hiring can explain where their preferred method fits badly and what they changed as a result. Rigid adherence to a framework in an environment that does not suit it is a common and expensive failure.
- Can describe a ceremony or artefact they dropped, with reasoning
- Has worked in more than one delivery approach
- Adjusts process to the team rather than the team to the process
Interview questions worth asking
Offered as material for the buyer’s own interview process. The assessment of any candidate belongs to the hiring organisation, which judges them against its own delivery environment and decides for itself who is suitable.
Tell me about a project that finished late. What was the earliest point at which that outcome was visible, and what happened between then and the date?
What a strong answer shows
Whether they read a project honestly and act early. Strong answers identify a specific early signal, describe what they did with it, and account for their own part in the delay rather than assembling a list of external causes.
A team says it is blocked on another department that has not responded for a week. Walk me through what you do next.
What a strong answer shows
Whether the instinct is to resolve or to record. Listen for going to the individual involved, understanding why the request stalled, and using escalation as a deliberate step with a purpose rather than as the first move or one never made.
How do you build a plan for something the team has not done before, where the estimates are genuinely uncertain?
What a strong answer shows
Forecasting maturity. Look for ranges rather than false precision, for sequencing that puts the uncertain work early where it can still inform the plan, and for a candidate who does not present an unknown as a commitment because a commitment was requested.
A sponsor asks for something significant with the date unchanged. What do you say?
What a strong answer shows
Whether they can hold a position under seniority pressure. The strongest answers make the trade-off concrete — what would be displaced, delayed or resourced differently — and return the decision to the sponsor rather than absorbing it silently or refusing outright.
How do you know a project is actually in the state your report says it is in?
What a strong answer shows
Whether their picture is verified or collected. Look for direct contact with the work — attending the team’s own conversations, reading the tracker themselves, asking what is not done rather than whether things are on track.
Describe how you handled a dependency on a team that did not share your priorities.
What a strong answer shows
Influence without authority, which is most of the job. Strong answers involve understanding the other team’s pressures and finding an approach that worked for both, rather than escalating until the other team was instructed.
What did you stop doing on your last project because it was not earning its cost?
What a strong answer shows
Whether process serves the project or the reverse. Candidates who have never removed a meeting, a report or an artefact are usually running a method rather than a project — and the reasoning behind the removal matters more than the item itself.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- An organisation is running a platform migration alongside its normal roadmap. The engineering work is understood, but it depends on an infrastructure team, an external vendor and a security review, and no single person holds the sequence. Dates are being agreed in separate conversations and reconciled late.
- Approach
- Additional delivery coordination capacity works inside the client’s existing governance — their planning cadence, their reporting lines, their escalation routes and their decision forums. The client’s own leadership continues to own the roadmap, the priorities and the decision about what the migration should achieve; the added capacity maintains the dependency picture, tracks the plan against it and brings trade-offs forward while they can still be decided.
- What this adds to the team
- The client gains coordination capacity without transferring accountability for the outcome. What the project is for, what it must include and when it matters remain decisions made by the people who own the business.
Related disciplines
Frequently asked questions
- What is the difference between a project manager and a business analyst?
- A project manager is accountable for the work being delivered; a business analyst is accountable for it being the right work. The project manager owns sequence, dependencies, risk, timeline and communication, and asks whether the team can get there. The business analyst owns the problem definition, the requirements and the acceptance criteria, and asks what precisely needs to exist for the outcome to be achieved. On smaller projects one person sometimes covers both, and the usual result is that whichever half is less comfortable receives less attention.
- What is the difference between a project manager and a product owner or product manager?
- The intended split is that product decides what should be built and why, while project management gets a committed body of work delivered. Product owns value, priority and the roadmap; project management owns sequence, dependency, risk and the path to the date. In practice the boundary is not settled across the industry — some organisations expect a product manager to run delivery, others expect a project manager to shape scope, and job titles are used inconsistently between companies. It is worth agreeing explicitly who decides priority in your own structure before hiring for either, because the ambiguity is where the friction accumulates.
- Do agile teams need project managers?
- Agile practice removes the need for a project manager to allocate tasks and gather status, which is genuinely progress, and this is often read as removing the role entirely. The work that remains is real: cross-team dependencies, external suppliers, contractual and regulatory commitments, budget accountability and communication with stakeholders who sit outside the team. Scrum defines no owner for any of it, because it describes a single team and most organisations are not one. Where that work is unassigned it does not stop — it lands on a tech lead or an engineering manager, usually at the expense of what they were hired to do.
- How is a project manager different from a scrum master or delivery manager?
- A scrum master is oriented towards one team’s practice — facilitating its ceremonies, improving how it works and protecting it from disruption — and carries no accountability for a date or a budget. A project manager’s remit is a body of work that usually spans several teams and includes commitments outside them. Delivery manager is used for both, and for a hybrid of the two, so the title alone will not tell you which set of responsibilities a candidate has actually held. Ask what they were accountable for rather than what they were called.
- Does a project manager need a technical background?
- They need technical literacy rather than technical practice. Enough to follow an architectural discussion, distinguish a real constraint from a preference, understand why some work cannot usefully be split, and ask a question that does not immediately signal they are outside the conversation. Former engineers can be excellent in the role, but the correlation is weaker than expected: a project manager who over-identifies with the technical debate often stops doing the coordination the team needed from them.
- How do you tell whether a project manager is adding value?
- Look at what happens to obstacles. In a team with effective project management, blockers are found earlier than the team would have found them, resolved without a series of escalations, and rarely arrive as a surprise at a steering meeting. Where the role has become administrative, the signal is a well-maintained set of documents alongside a team that still spends its week waiting on the same recurring problems.
- How does a project manager work with an existing engineering team?
- Under a staff augmentation arrangement, a project manager operates within the client’s delivery structure — their planning cadence, reporting lines, governance and escalation routes — and the client directs the work. Accountability for the product, the business priorities and the roadmap stays entirely with the client, and additional coordination capacity does not move it. What Talent.ID carries is the employment side alone — the employment relationship itself, payroll, employee benefits, talent administration, and remaining the employee’s counterpart over time.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.