A Technical Project Manager for Startups Who Reads the Code

I run delivery across a team, not a single project — the scope, the dates, and the tradeoff between them, and I am the one who says which of the three moves when something slips.

Sprint scope is set against milestone dates before work starts, with acceptance criteria specific enough that a ticket cannot be reinterpreted at review. Standups run async so a distributed team pays no meeting tax, and a weekly milestone review asks two questions: what moved, and what is now at risk.

When team output dropped 40% mid-sprint with a hard deadline, I ran rapid one-on-ones to surface the actual blockers, redistributed the workload to cut cross-team dependencies, and moved standups to daily and async. Velocity recovered and held for more than six months afterward.

Every engagement starts with a conversation I run myself, in English — what the client is trying to build, who the stakeholders are, and what already exists. That conversation is not handed to someone else and relayed back to me.

I have run more than 50 of these at Exprovia: first call to signed scope, with the ambiguity resolved before a sprint starts rather than discovered by a developer mid-build.

I turn what a client describes into scope a team can build against — what is in, what is explicitly out, and where the ambiguity sits until it is resolved. Vague requirements are a risk I hold before a sprint starts, not one a developer discovers mid-build.

When a client asked for three weeks of new features during the final delivery week, I documented the original agreement against the new requests with the delivery cost of each item attached, and negotiated a phased plan with revised milestones — the contracted work shipped on date, and the rest moved to a defined second phase.

I surface risk while it is still a choice, not a report, and I have that conversation directly with the client, in English, without a layer between us.

For an account that had escalated over repeated delays and a communication breakdown, the repair was structural, not apologetic: transparent milestone tracking, a weekly executive sync, shared dashboards for scope and risk, and a written ownership matrix across teams. The escalation resolved, and the account expanded to new project scope.

When a service goes down, I run the response myself — owners assigned, a communication cadence set with the client, and the change that stops the repeat written up afterward rather than promised.

When an ECS deployment failed silently in production, I rolled back to the last stable task revision before diagnosing anything, because an open-ended diagnosis window is worse than a known-cost rollback during a customer-facing outage. Service was restored in 35 minutes; the task definition and IAM permissions were corrected afterward, behind health-check validation and a new deployment checklist.