Ten years in business operations, four of them in Google's global partnerships org. I get Product, Finance, GTM and Engineering onto the same numbers, then build the planning, reporting and tools that keep them there.
I build the plan with the teams instead of handing it to them. At Google that meant annual planning and budget across seven teams; at Included Health, an OKR framework the COO adopted into the next year's plan.
Weekly forums and VP reviews that kept 56 initiatives across four product areas moving. On the merger I ran it for 16 VPs, none of whom reported to me.
The SQL and Looker layer that joined pipeline to product adoption at Google, and the Tableau reporting behind 60+ projects on the merger.
If a plan needs a system that isn't there, I build it. Five so far. The two built for planning are written up below.
The same five steps every time: frame the decision and who owns it, model the constraints, diagnose what's holding everything up, intervene where it pays off soonest, and operationalize it with an owner and a number to track. The simulator runs these steps end to end →
Both tools below are for planning work. One runs a whole year, the other sizes one team. Three more, built for other problems, are under them.
What I got wrongI built a claims-based signal to speed up client launches. It cut conversions in half, and I shut it down two weeks after shipping it.
The briefLaunch a new line of business, and show the cost of running the work early enough in the year to do something about it.
Scope
The briefGet a fragmented regional partnerships org planning, selling and reporting as one business.
Scope
The briefBuild the operating structure a five-year integration would run on, before the deal had even closed.
Scope
Lean Six Sigma Green Belt · Google Project Management Certificate
Problems from my own work, and operating questions that usually get decided on gut feel.
Case studyCost & forecastingUnit cost used to show up from finance late in the year, when the only lever left was headcount. I turned it into a number three teams agreed on and saw every month.
54% → 100% of initiatives with quantified impact, in two weeks
What I got wrong: I built the complete version first and the one-page version second. It should have been the other way around.
Read the case study →Several hundred people kept building through months of regulatory hold, on a deal that might not have made it through review.
74% → 95% on-time deployments, in under three months
What I got wrong: I didn't standardize intake before a dozen vendor teams each built their own tracker.
Read the case study →Sellers already had the list. They couldn't tell a publisher what it was worth, so they kept losing to pitches that came with a number.
8 figures of incremental revenue, and a peak of 256% pipeline velocity
What I got wrong: I scoped the queries to my own region, so I couldn't validate the results in the two regions that adopted it.
Read the case study →A support function can stay central or split into dedicated pods. A shared person would have to be 73% slower on every request before pods come out cheaper, which is much further than most people guess. The break-even also shifts with client size.
Read it →Paste the number you watch, click when you changed something, read one sentence. How the tool decides, the false-alarm rate it was held to, twelve pastes shaped like real exports, and the slope fix I tried that made things worse.
Read it →I designed an intake form around what I needed and didn't think about what anyone would fill in. Then I blamed stakeholders when nobody used it. Forty-two fields, three of them ever read, at a company whose CRM already had most of the answers.
Read it →
If you have a messy cross-functional problem that needs structure, numbers and a way to keep it moving, write to me. Nobody has to own it yet.
