Technical Project Management

Requirements usually arrive as outcomes — “customers should be able to invite their team”. Turning that into deliverable scope means asking the questions engineering would otherwise discover mid-sprint: which roles exist, what happens to pending invitations when a seat limit is reached, does this need an API, what are the edge cases?

Assumptions are written down, dependencies identified and acceptance criteria agreed before estimation, so “done” means the same thing to product, engineering and QA.

A realistic sprint is planned against actual capacity — leave, support load, release work, meetings — not ideal days. Dependencies decide sequencing: the API contract before the frontend that consumes it, final design before implementation.

Work that carries over twice is a signal, usually of unclear scope or a hidden dependency, not of a slow team.

Frontend, backend, QA, design, product and external stakeholders each see a different part of the work. Coordination means making the hand-offs explicit — when the API will be ready, when designs are final, when QA can start, who decides when a question comes up — so teams don't wait on each other in silence.

Many delivery delays are dependency problems in disguise: a frontend blocked by an unfinished endpoint, a feature waiting on a third party's sandbox, a release held up by an environment that isn't ready. Agreeing API contracts early lets frontend and backend work in parallel against the same specification, and external dependencies get owners and dates like any other task.

Risk is easiest to handle while it's still early. I track technical risk (unfamiliar technology, performance unknowns, complex migrations), delivery risk (capacity, dependencies, unclear scope), external risk (third parties, client feedback cycles) and production risk (data migrations, irreversible changes). Each gets an owner and a mitigation — a spike, a feature flag, a phased rollout, a fallback plan.

Scope creep is managed by making its cost visible, not by refusing every change.

Product Owners decide priorities; my role is to make sure those decisions are made with full information. That means translating technical implications into product terms — “this option takes two extra weeks but avoids rebuilding billing later” — proposing smaller slices that deliver value sooner, and being explicit about trade-offs rather than quietly absorbing them into the timeline.

Clear ownership and written decisions save more time than extra meetings. Each piece of work has an owner; significant technical decisions are recorded briefly — context, options, decision — where useful; and questions are answered where the next person will look for them. Meetings exist to decide or unblock, not to report status that could have been read.

QA is involved when scope is defined, not when development ends. Testable acceptance criteria, test data and environments ready before the feature lands, and a clear view of regression risk — which existing areas a change touches — make QA a partner in delivery rather than the last bottleneck before release.

A release is ready when the work is tested, dependencies are deployed in the right order, migrations are safe to run, stakeholders know what's changing, and there's a plan if something goes wrong — rollback, feature flag or fix-forward. After the release, a short check confirms the critical flows work in production and monitoring is quiet.

With an engineering background I contribute to technical discussions — architecture options, risk, effort, sequencing — and I can recognise when a decision is being avoided. But ownership stays with the engineers who will build and maintain the solution. My job is to make sure the right people make the decision, with the right information, at the right time, and that it's recorded.

I've been involved in hiring for engineering teams: technical assessments, candidate evaluation and hiring recommendations. Assessments are most useful when they reflect the real work — reading and improving existing code, discussing trade-offs — rather than puzzles unrelated to the job.

Velocity is a planning tool for one team, not a performance score. The signals I find useful: delivery predictability (did we deliver what we planned?), blockers and how long they last, escaped defects found after release, and cycle time where it helps reveal bottlenecks.

The real measure is outcomes — did the release solve the problem it was meant to — not the number of tickets closed.

Stakeholders need clear expectations, honest progress, early warning of risks, and the decisions that need their input — in their language, not in ticket numbers. Bad news delivered early, with options, is almost always better received than a surprise delivered late.

Having built and led development of production systems changes how I manage delivery. I can sanity-check estimates, follow architecture discussions, spot hidden dependencies between backend and frontend work, and help untangle delivery problems — an unstable test environment, an unclear API contract, a migration that needs a maintenance window — before they turn into schedule problems.