Case studies

Planning and resource allocation Getting cost numbers to people in time to act on them

Service operations · method

Unit cost used to arrive from finance late in the year, when the only lever left was people. I turned it into a number three functions signed off on and saw every month.

Problem: Many initiatives under a multi-million-dollar cost-of-revenue target had been sized on someone's say-so, and unit cost reached operators too late in the year to change anything but headcount.
What I owned: The portfolio from the day I took it over: its intake, its operating cadence and the sign-off chain across operations, workforce management and finance.
Mechanism: Operators size each initiative in their own metrics, workforce management converts it to FTE and finance converts FTE to unit cost. Weekly execution pulses, with monthly forecast and workforce-model locks.
Result: Initiatives with a quantified impact went from 54% to 100% in two weeks. Workforce management could turn each one into FTE, and planning cycles closed 25% faster than the year before.

Spot a gap in January and there's time to plan around it. Spot it in October and it usually means cutting headcount.

How it went, and what I got wrong

Before

An $18M cost-of-revenue target, and only about half the initiatives under it had impact anyone had quantified. The rest were sized on someone's say-so. Forecasts drove hiring, hiring drove cost, and the cost reporting arrived from finance late enough in the year that the only lever left was headcount. Engineering and operations barely spoke, even though operators depended on engineering delivery to hit their numbers.

One number everyone signs off on

Operators size their own initiatives in their own metrics. Workforce management turns that into FTE, and finance turns FTE into unit cost against the annual goal. Every handoff gets cross-examined and signed, including by engineering where delivery is a dependency, so every number has an owner.

Coverage of quantified impact went from 54% to 100% inside two weeks, and the cadence holding it up, weekly execution pulses with monthly forecast and workforce-model locks, was running in seven days.

What I got wrong

I built the complete version first and the one-screen summary second, which was backwards. If a decision-maker can't hold a number in their head, it doesn't matter how correct it is, and correctness was the part I found interesting. By the time I got to the summary, people had already decided the whole thing was heavy.

Revenue and commercial execution Giving sellers a number they could pitch

Google · publisher partnerships

Sellers already had the list. They couldn't tell a publisher what it was worth, so it kept losing to pitches that came with a number.

Problem: Sellers had the target list but couldn't tell a publisher what the opportunity was worth, so it kept losing to pitches that came with a number.
What I owned: pGTM asked me to connect product's evidence to the sellers. I built the data layer, wrote the case study with product and designed the competition.
Mechanism: A SQL and Looker layer joining pipeline and CRM data to product adoption, a measured dollar figure per publisher from Impact Experiments in Ad Manager 360, and a Q3 sales competition with a live leaderboard.
Result: 8-figure incremental revenue against target. pGTM adopted the approach globally, and EMEA and APAC were running their own versions within days.

Before this, sellers were arguing over a figure nobody had produced.

How it went, and what I got wrong

Sellers had the list. They couldn't tell a publisher what the opportunity was worth, so it kept losing to pitches that came with a number attached.

Getting a measured number

Impact Experiments, the incrementality framework inside Ad Manager 360, gave us a measured figure for each publisher. Publishers will argue with a projection. They won't argue with their own incrementality result.

Connecting the evidence to the people selling

The measurement sat with product and pGTM. The publisher relationships sat with sales. Neither group was going to build the other's artifact, so pGTM asked me to do it. I ran the publisher meetings, took what came out of them back to product, and built the case study jointly with them, so it carried product's evidence in language a seller could put straight into a pitch. Sales didn't have to translate it anymore, and started opening conversations they'd been skipping.

Putting the number to work

It went into the internal performance view, so sellers could book credit for the work, and into the client conversation as a figure a publisher would accept. I also built the custom CRM and product views that didn't exist yet, and used them for a leaderboard that turned pitching it into a contest.

I timed the launch to the week the case study cleared legal and client review, so sellers got the proof they had been asking for and a reason to use it in the same week. That opportunity hit a peak of 256% quarter-over-quarter pipeline velocity.

What I got wrong

I pointed the queries at AMS, the region I managed, because that was the problem in front of me. Within days of release, EMEA and APAC asked for their own versions. Repointing a query from one region to global is a small change and I made it quickly. I hadn't planned for validation. I had no data access outside my own region, and for data this sensitive the access review is long, so two regions ran on output I couldn't check until it cleared. It held up, but I couldn't confirm that at the time.

Large-scale execution Building a PMO for a deal that hadn't closed yet

Accenture · $26.5B telecom merger · 2018 – 2020

Several hundred people kept building through months of regulatory hold, on a deal that might not have survived review at all.

Problem: More than a dozen vendor teams each tracked milestones their own way. Nobody could see real status without asking each team, and launch deployments kept missing their dates.
What I owned: Governance for 24 workstreams under 16 VPs, none of whom reported to me, and the integrated plan for 60+ projects.
Mechanism: A near real-time Tableau view of every code drop by release, initiative and team, with acceptance gates that needed sign-off from each team a drop affected. The reports went to the CIO.
Result: On-time deployments went from 74% to over 95% in under three months. The architecture review process I designed re-checked 52 projects after a months-long regulatory hold and avoided an estimated $2M of test remediation.

Nobody made a mistake here. The designs were right when they were written, and the months on hold made them out of date.

How it went, and what I got wrong

Nothing was broken here, because nothing existed yet. The client was setting up a PMO ahead of the merger, and my team was there from the start, building the processes the next five years of integration work would run on.

What the deal did to the work

Terms were renegotiated several times with the FCC, the DOJ and the businesses, and the whole program sat on hold for months. Until approval, there was a hard legal limit on what teams could do: design, build and test against synthetic data, never production data from the other party. Once initiatives had gone as far as the law allowed, engineers and PMs were reallocated across the wider Product and Technology org, and the designs sat.

It wasn't a planned pause, either. At several points nobody knew whether the deal would survive review at all. That's a different job from running a program with a known end state: you're building something that might never launch, and several hundred people still have to work on it as if it will.

Why a pause is expensive

Months passed and things changed under the designs. A call to an API that had since been deprecated. A data feed from a vendor team that had been repurposed. So before anyone restarted, the designs went back through a joint architecture review board: 52 projects reassessed over three months, high and low level designs re-checked against what was now true, with more than 150 project managers, senior managers, directors and architects pulled through it.

Those flaws would have turned up anyway in unit testing and BVT, at far higher cost. The review avoided an estimated $2M of remediation.

Sixteen VPs and no authority over any of them

I had data. I built reporting that showed where work was stuck and whose team it was sitting with. Nobody had that view before. The reports went up to the CIO, and that did most of the work: once a VP knows the row with their name on it gets read two levels up, they push each other and nobody needs chasing.

Why deployments kept missing their dates

On-time launch deployments sat around 74%. The causes weren't technical. Teams were miscommunicating, documentation was wrong, and every team tracked milestones its own way. More than a dozen vendor teams were on the program and none of their tracking was standardized, so there was no way to see real status without asking each of them and taking the answer on faith.

That gap is why I learned SQL and built automated reporting in Tableau. With dozens of teams updating constantly, a near real-time view was the only thing that would keep up: code drop status by release, by parent initiative, and by team and function, with links through to where the design and development artifacts lived in Jira.

On top of the view I put a standardized process with defined acceptance gates, each one requiring sign-off from the teams a drop affected, and used the report as the source of truth teams aligned against. On-time deployments went from 74% to over 95% in under three months.

Porting every report to a tool I'd never used

Mid-quarter, the client switched licensing from Tableau to Power BI and asked me to port every report across. I'd never used Power BI, and it's different enough from Tableau that it wasn't a straight translation. I learned it as I went and got the reporting back up.

What I got wrong

I should have standardized intake at the start. By the time I saw that the existing reporting wasn't good enough, and was part of why dates were missed, more than a dozen vendor teams had each built their own ad hoc tracking, and none of it talked to anything else. So I spent the time meeting each team one at a time and building a translation layer from whatever they'd already committed to. If I'd set the format before the teams built their own, none of that would have been needed.