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 a 4-person team's output dropped 40% mid-sprint with a hard deadline, I did not raise it with the group. Instead, I sat with each developer individually, because the cause turned out to be different for each of them: a cross-team rate-limit mistake slowing every response, and less experienced developers taking complicated paths through problems that had simpler ones. Velocity recovered in about four days.

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 changed an education platform from single-vendor to multi-vendor mid-build, I asked for more time; they declined but increased the budget instead. I split the added work so the developers already on the project handled what needed context, and new developers handled what did not. The original delivery held on date, and Phase 2 shipped after it.

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.

When a large-scale US civic information platform's WordPress build could not carry the interactive features a client brought close to launch, I told them directly rather than forcing the requirements into a platform that could not hold them. That got the project $1,000 in additional budget and one more month, and the architecture split (WordPress for content and commerce, Next.js for everything interactive) is what launched.

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 a missed environment variable crashed a live site mid-migration while a client campaign was already driving traffic, an alert I have on every deployment reached me at two in the morning. I put visitors on a maintenance page first, then fixed the variable directly rather than rolling back, because the cause was already identified by the time I looked. Service was restored in 35 minutes.