Four engagements, measured the way leadership measures them.

A senior engineering director at a large enterprise SaaS company (details anonymized to protect the relationship — name and reference available on request) brought me in to work with five of his teams, who had just started using Cursor. He'd seen a different kind of process work I'd done elsewhere in the org — this ask was narrower: look specifically at how code was actually moving through the system.

Everyone had a theory about where time was going. Nobody had data. PR queues were backing up, and there was no shared, factual picture of where the friction actually lived.

I ran value-stream mapping sessions with most of the developers, then combined what came out of those with their Jira history and raw Git metadata — pulled into Tableau to essentially hand-build the kind of code-flow visibility that a tool like LinearB now offers as a product. That surfaced specific, fixable choke points, so we reworked their Kanban boards and Jira statuses to make code flow visible in a way it hadn't been. We put new team working agreements in place — a cap on PR size, WIP limits — aimed directly at the review queue. We also walked through their last three major releases together as a team, mapping exactly where each one lost time, and ran experiments off what we found. One that stuck: “pair-prompting” — the old pair-programming habit, applied to AI prompting instead. In retro, engineers consistently said it made review feel lighter. We didn't isolate that on its own — it's folded into the velocity number below.

The work above got me thinking about something I hadn't seen written up anywhere yet: vague requirements don't just slow human engineers down — they get worse once an AI agent is the one turning them into code. I started forming a clear opinion on it, and a peer who heard it hired me to test the theory directly. A senior director of product management at a large enterprise software company (details anonymized to protect the relationship — name and reference available on request) brought me into his org to work on exactly this.

The handoff from product to engineering had the usual issues — vague language, incomplete business rules — the kind of ambiguity a human engineer used to just resolve with a hallway conversation or an educated guess. That workaround doesn't really exist with an AI coding agent. It either builds the wrong thing fast, or someone has to stop and clarify anyway — either way, you've burned time and tokens on something that shouldn't have needed a second pass.

We didn't touch how the product org did its own strategic work — the scope was narrow and specific: fix the handoff itself, nothing upstream of it. We built working agreements for how requirements got written — no vague language, complete business rules — and started pairing sessions between PMs and engineers to build Jira tickets together, instead of writing them separately and iterating through rounds of clarification afterward.

I worked with a VP of Engineering at a large enterprise software company (details anonymized to protect the relationship — name and reference available on request) across 27 teams, moving them off Scrum and onto Lean and Kanban.

Teams were consistently missing what they committed to, at both the sprint level and the quarterly level — the kind of gap that quietly erodes trust between engineering and the rest of the business, no matter how good the underlying work actually is.

We moved all 27 teams from Scrum to Lean and Kanban — not a light retooling of ceremony names, but a real change in how work was sized, tracked, and committed to. Getting delivery reliability to where it needed to be took about two years, with results reported formally every quarter — I personally defended those numbers to the full VP group each cycle. Once individual teams were performing consistently, I spent a third year building and delivering a workshop — “Best Practices for Delivering Cross-Team Projects in an Agile Organization” — which she made mandatory attendance across her entire org, then spent several quarters shadowing individual project leads directly, helping them apply it to their own cross-team work.

I was the senior program manager on the complete redesign of a national outdoor retailer's e-commerce site and its three mobile apps (details anonymized to protect the relationship — name and reference available on request) — the largest project in the company's history, touching roughly 750 stakeholders.

By the time I was asked to take over, the project was three months behind schedule, and stakeholders — including the CEO — were openly frustrated.

I introduced an enterprise-level Kanban model across 12 teams and 2 external vendors, running it for 18 months. I set up recurring executive updates — roughly every two months — specifically to keep leadership informed rather than surprised, and ran regular retrospectives that included stakeholders directly, not just the delivery teams.