Hillel Glazer

How I work

Wherever we start—and sometimes we start in the operations, because that's where the fire is and that's what earns the right to the harder conversation—that's not where we finish. The operations are real and we'll work on them. But they're not the diagnosis. They're the path to it.

The work is finding what's upstream of the symptoms. It's almost always in the strategy—in how the company enters its market, what it promises, at what price, to whom. That misalignment cascades into everything: how work gets estimated, how proposals get written, how the first project with a new customer goes. By the time anyone feels the pain, the cause is three decisions back and six months upstream.

I don't leave until you can see it yourself and you're making the decisions that address it. That's the goal—not to become indispensable, but to build your capacity to hold the alignment and recognize when it's drifting before it becomes a crisis again.

How the practice changed — and why.

For more than twenty years I was good at the work. Genuinely good. And in one particular corner of the industry, I was arguably the best in the world. I literally invented how to solve a problem everyone believed was intractable. Continuous improvement, controlling work-in-progress, removing bottlenecks, rigorous process definition—I knew how to find where systems were breaking down and how to fix them. I was often the person who brought discipline to organizations that had none.

The problem was I was adding structure to systems without ever asking whether the systems were pointed at the right thing. I was improving how companies delivered without examining what they were delivering, for whom, and whether the market considered it worth the price. Sophisticated answers to questions nobody in the C-suite was actually asking.

Then the physics hit me.

You can't control time. Full stop. You can't do more than one thing with your brain at any given instant and expect either to get done correctly. You can't be in two places at once. These aren't management principles—they're laws. And the companies I was working with were violating all three, every day, as a matter of institutional policy. We'd even invented elegant fictions to make the violations look like rigor.

I watched a senior person at a large company—someone whose job was to lead delivery—refuse to entertain a simple thought experiment. Not disagree with it. Refuse to imagine it. The thought experiment was: what would we do differently if this one constraint were removed from the system?

That was the moment I knew the engagement was going to fail. Not because the people were bad. Because being a victim of the system had become more important than being effective inside it. I bowed out. My project partners stayed on. They were eventually let go, as predicted.

But the deeper insight came later—and from an unlikely direction.

I was talking with a researcher about why their technically brilliant work wasn't going to find a market. Somewhere in that conversation I said something offhand: the market determines the value of whether or not the problem is worth solving. And I stopped.

Because I realized that everything I'd spent years calling "value stream" was only ever looking at value inside product development. I was never looking at the customer friction that surrounds it. Never asking whether the problem being solved was one the market cared enough about to pay for. I was measuring flow within the loop while ignoring whether the loop was connected to anything real outside it.

That's when the practice changed. Not from the top down—from the outside in. From market to problem, not problem to solution. Every intervention that ignores that relationship is going to produce improvements that are short-lived and situationally dependent. That's not a criticism of the tools. It's physics.

You can't control time. But you can control speed. And speed—real speed, the kind that compounds—only comes from removing what's working against you. Not from adding more of what isn't working.

That's what Entinex is built to do.

Background

I'm an aerospace engineer and a pilot. That's not a metaphor—it's how I think. In systems. In failure modes. In what happens when the thing you trust stops behaving the way you designed it to.

In 2001 I wrote the first full-length, peer-reviewed article on the intersection of Agile and CMM—published in CrossTalk, the Journal of Defense Software Engineering—years before the industry broadly recognized the question existed. In 2007 I led the Software Engineering Institute's white paper "CMMI or Agile: Why Not Both!?" (published in 2008). It provided institutional legitimacy to what practitioners had already established. It confirmed the direction. It didn't originate it.

I chaired the Lean Kanban North America conference three times and guided the creation of Lean-Kanban University's accreditation program. I spent six years as a Visiting Scientist at Carnegie Mellon University. I'm a member of Cutter Consortium, an Arthur D. Little community, and the author of High Performance Operations: Leverage Compliance to Lower Costs, Increase Profits, and Gain Competitive Advantage (FT Press, 2011).