I call myself a plumber. Not the profitable post-AGI career move — the actual instinct. In the Israeli Air
Force in the nineties, then leading engineering teams, then close to twenty years helping leaders improve
flow — first inside engineering, later across marketing, sales, the whole organization — it's been the same
kind of work. Something's stuck, there's a bottleneck, sometimes there's a genuinely ugly mess on the floor
that somebody has to clean up. I go find it and clear it.
That curiosity about how people coordinate around complex work led me deep into Scrum, then Kanban (I
co-authored the Kanban Guide for Scrum Teams and co-created Professional Scrum with Kanban), then SAFe (one
of fewer than 50 SAFe Fellows globally). Along the way the Kanban community recognized that work with a
Brickell Key Award in 2013, and I wrote up a lot of it in Holy Land Kanban. I also contributed to ICAgile's
Agility in Marketing learning outcomes — the curriculum standard behind the ICP-MKG certification.
Most advisors plant a flag in one framework and defend it. I went the other direction — because working
across all of them revealed something more useful: every framework is solving a real problem, and every
framework creates new problems if applied dogmatically. What actually helps organizations is understanding
which constraint they're facing and choosing the right tool for it.
That's also why Dave West and I wrote the Scrum Guide Companion for Leaders for Scrum.org. The Scrum Guide tells you what the Scrum Team is accountable for, but it stays quiet on the
leaders around that team — the ones who set the conditions the team has to work inside. The companion is our
attempt to answer the questions those leaders actually ask.
A good example is my work around invitation-based SAFe implementation: the emphasis is not rollout theater,
but creating pull-based engagement so change sticks and performance improves.
Across global exchanges, consumer goods, enterprise software, and product-led scaleups, the same pattern
kept appearing: teams asked to move faster while the system around them slowed them down. The constraint was
almost never execution. It was how decisions were made, how work was prioritized, how funding flowed, and
how many things were in flight at once.
AI didn't change that pattern — it raised the stakes and moved the bottleneck. When code, content, and
analysis get radically faster, the same operating gaps that used to just slow teams down now pile up fast:
production outruns review, validation, and adoption. That's why I pivoted my business from Scaling with
Agility to Scaling AI from Activity to Impact. Not jumping on a bandwagon — agility isn't going anywhere for
me. It's the "Powered by Intel" inside the AI-Native organization, and the lessons from years of helping
organizations scale it are exactly what it takes to turn AI ambition into impact.
That's what I work on — not which framework to use, but whether the operating system around your teams is
capable of turning AI activity into the outcomes you actually need.
Are you serious about turning AI activity into real business impact? Let's talk.