The longer version

I took over a two-workstream modernization program at a Fortune 100 financial services firm, weeks after the client’s own domain review flagged it red. A legacy platform being rebuilt while it stayed in production. Findings in week one: no delivery methodology, no governance plan, no documented commitments, and nobody — on either side — owning requirements. Requirements were being reverse-engineered out of legacy code.

Fourteen engineers across two workstreams, some moving between them. A hard seasonal code freeze I could not move, and a client executive who had already lost confidence. I could not change the team quickly, and I inherited a backlog generated largely by AI from the legacy codebase — tickets that looked complete and carried no business logic.

Led. Primary delivery owner and the client’s main point of contact from delivery lead through executive sponsor. Shared the account with a delivery partner; I owned governance, staffing, reporting and client communication.

Defined milestones with the client rather than inheriting a date, and put one named owner on each. Narrowed three parallel batch jobs to one with a single owner, and reduced front-end scope from five transaction types to one proven end to end, on the reasoning that a repeatable pattern beats five half-finished ones. Rejected: holding the original date and pushing harder — closed volume against work in flight said it would not land, and a missed date after a death march costs more credibility than a renegotiated one.

I moved on governance before requirements ownership, and requirements was the more expensive gap by a wide margin — it has cost more time than engineering capacity ever did. Where a client-side expert owned the specification, the work moved within days. Where nobody would take that seat, it did not. Next time, naming a requirements owner is a condition of the plan in week one, and I escalate the absence of one as a red risk immediately instead of absorbing it.

A major airline’s people-data organization needed more delivery capacity than its onshore budget allowed — employee and workforce data being prepared and published to downstream consumers over streaming topics. Delivery cost was climbing, response times slipping, and no scalable lever existed. NEED: the trigger figure — cost trend, SLA miss, or backlog size

The first nearshore engagement at this client. My firm had delivered nearshore teams elsewhere, but nobody in this organization had worked that way before — so there were bumps, and no internal precedent there to point at. A real communication and working-style adjustment on both sides, equipment to ship across borders, knowledge transfer from client full-time employees to consultants who had never seen the platform, and an expectation of immediate delivery from a team still being onboarded.

Led. Designed the engagement as a fully managed service rather than staff augmentation, and stood up the original team: four nearshore data engineers plus one onshore lead. I owned the operating model, the kickoff, escalation and the client relationship.

Brought our nearshore practice leadership into scoping before the engagement was sold in, so the scope of work and the right people from the practice were settled up front rather than backfilled later. Always placed a team with a lead on it — never an individual — so someone from the practice was accountable for holding junior engineers to the client’s bar. Rejected: staff augmentation, which would have made the client responsible for managing our engineers and put every quality problem on their desk instead of mine.

The whole thing turned on the kickoff. Getting practice leadership involved early is what made the staffing right; putting a lead on every team is what made the quality hold. Those leads went on to carry business-review content, propose solutions, and recommend how to reach value faster with quality code. They also built our practice culture inside the client while genuinely adopting the client’s, which is why the expansion happened at all. If I ran it again I would formalize that lead role from day one instead of discovering how load-bearing it was.

Directly managing 25+ engagements inside an account carrying 45+ — and accountable for the whole account’s delivery, including the engagements I did not own. This is here because it shows what I can carry at once, and because the account grew while I carried it.

A $20M+ portfolio with 90+ consultants deployed. Two direct reports whose growth I was responsible for. Onsite with the client three days a week. Much of the team was already placed mid-engagement, so I could not renegotiate terms or restaff at will — the levers available to me were structure, attention and standards.

Owned delivery on the complex, milestone-based and nearshore engagements, and the client relationship. Oversaw the rest of the account’s delivery, every consultant performing to the client’s bar rather than only mine, and the development of my two direct reports. Made myself the escalation owner rather than the escalation router.

Split the book by complexity and gave my direct reports real ownership of the simpler engagements rather than having them shadow me. Used the three days onsite as a governance instrument rather than a courtesy: risk surfaced in a hallway a week early is cheaper than risk surfaced in a status meeting. Transparent status and business reviews so the client saw risk before it was urgent, and process and compliance controls so the same failure did not recur account to account. Rejected: escalation to leadership as the default path.

Splitting the book by complexity was right. Splitting the relationship would have been better — I held the client-facing side too tightly for too long, which made me the bottleneck on my own account and slowed how fast my direct reports could grow. I would also have built the escalation standard before the reporting layer; reporting told me what had already gone wrong, the standard is what changed behaviour.