Why I Built Stream Methodology

Stream Methodology grew out of nearly a decade of quiet frustration. For years the ideas existed mostly in my head — observations accumulated across firms, projects, and teams. Over the winter of 2025-2026 I finally committed to documenting it properly: the structure, the terminology, the rules and processes. The white paper is the result. It has enough detail for you to understand what Stream is and decide whether it’s worth trying in your own firm.

Throughout my career I watched the same problem repeat itself so consistently that it stopped feeling like a coincidence.

Talented teams, genuinely skilled at their work, were forced to operate within systems that made it almost impossible to do that work well. Constant context-switching. Reactive scheduling. Projects driven more by what was urgent than what actually mattered.

What frustrated me most was the lack of effective management solutions, and a work culture that actively added to the problem.

Standard Gantt charts and waterfall schedules required constant maintenance in an environment that is often very fluid.

Most of the people managing projects in AEC firms aren’t trained project managers. They’re experienced engineers and architects who carry that responsibility as they progress in their careers.

The last two decades of accelerating digital communication have only compounded the focus challenges. Reducing the friction of communication means more messages, across more channels, at higher volume, with diminishing value attached to each one.

When I began to read about the principles of Agile and Scrum, the underlying logic was compelling. However, the direct application to AEC design work left some key aspects missing. Software development assumes a focused team working sequentially on a single product. AEC firms run multiple concurrent projects with long external dependency chains, where a task can sit idle for weeks waiting on a client decision or a permit that hasn’t arrived.

Design work requires sustained concentration. The modern communication environment is structurally hostile to it. The burden on design staff has grown steadily, and no amount of individual effort fully compensates for a system that was never designed to support them.

Stream Methodology was my attempt to build one that was.

About Eric:

I’m a licensed Professional Engineer with over 23 years in mechanical engineering consulting. I’ve built firms, managed engineering teams, and carried project management responsibility across more organizations than I ever expected. The problems Stream Methodology addresses aren’t theoretical. They’re the ones I lived through, repeatedly, at every stage of my career. My hope is that you’ll find at least a few ideas here that make your own operation a little easier to run.