Fifteen years shipping products across healthcare, enterprise, and AI. I've been the engineer, the PM, and the CPO. I know where delivery actually breaks.
Tickets get written. Standups happen. Nobody knows who has final call when priorities conflict or a requirement changes. Work stalls waiting for alignment that never comes.
A PM who can't read the architecture makes coordination decisions that cost engineering weeks. Scope gets cut in the wrong places. Technical debt gets approved because nobody explained the actual cost.
Status updates go out on Friday. Nothing gets unblocked. The difference between project management and status reporting is whether someone is actually solving problems between the updates.
Every addition feels small in isolation. Six of them in a sprint mean the sprint doesn't ship. By the time it shows on a timeline, the damage is already done.
Before a sprint is planned, requirements need to be pressure-tested. I run discovery sessions that surface the real requirements, identify the assumptions that will break later, and produce a scope document that engineering can actually build against.
Backlog grooming, sprint planning, daily standups, and blockers resolved the same day. Velocity tracked, not just reported. Priorities adjusted against reality, not against the original plan.
I speak engineering. When a technical decision requires a tradeoff conversation, I'm not translating between stakeholders and engineers. I'm in the room with context on both sides.
External teams working against your delivery need the same oversight as internal ones. I manage integration points, hold vendors to their SLAs, and keep the critical path visible across every dependency.
Weekly updates that actually reflect what's true. Not filtered for comfort. Risks flagged when they're manageable, not after they've shipped.
Deployment coordination, rollback planning, post-launch monitoring, and documentation that lets the next person pick it up without a knowledge transfer call.
I review the current state of the project: open scope, team structure, known blockers, and what's already been decided. This tells me where the delivery risk actually is before I start touching anything.
First week. No changes made until the picture is clear.
Fix the most urgent coordination breakdowns first. Clarify decision ownership. Close open scope questions. Establish the reporting cadence that people will actually maintain. Most teams see immediate change in the first two weeks.
Fast impact, visible change.
Sprint structure, planning cycles, review cadences, and escalation paths that work for your team's size and velocity. Not process for its own sake. Process because delivery requires rhythm.
Documentation so the system runs without me.
Coordinated launch, post-launch review, and a documented operating model your team can own. The goal is a project that no longer needs external PM oversight because the team has the system.
Exit criteria defined before the engagement starts.
Early-stage companies that have the engineering team but not the delivery infrastructure. Established teams where the PM function is occupied but not working. Founders who are managing delivery themselves and can't do that and run the company at the same time. Technical leaders who know the build is good but can't figure out why it keeps slipping.
PM embedded from discovery through launch for a defined deliverable with a deadline. Right for companies with a specific build that needs to ship on a specific date.
Part-time ongoing engagement for teams that need PM infrastructure but not a full-time hire. Typically two to three days per week. Rolling monthly commitment, no long-term contract.
For projects that are already behind. Situation audit first, then a stabilization plan, then recovery execution. No judgment on what happened. Focus on what ships.
Yes. Dropping into an existing team is the most common scenario. The first week is always about understanding how the team actually works, not how the process document says it works.
That's most of my engagements. The first step is a situation audit, not a blame exercise. Once I understand where the debt is, I can tell you what's recoverable and what needs to be renegotiated.
In a project engagement, very involved: standups, blockers, priority calls. In a fractional engagement, more structured. I'll be explicit about what the engagement includes before we start.
Both. Discovery is part of every engagement. If the requirements are wrong, managing a project against them just gets you to the wrong place faster.
I specialize in software delivery. If your project has a significant technical component, that's the right fit. If it's purely operational or marketing, there are better fits than me.
Book a working session. Tell me what you're building, where it's slipping, and what you've already tried. I'll tell you within 60 minutes what the delivery problem actually is and what would fix it.