First Principles

The Information Technology industry spent decades relearning a production discipline that had already been solved.

We can trace the roots of modern DevOps and project planning back to the mid-1900s when a manufacturing industry in a war-recovery state was struggling to compete against a much larger, better resourced country. It was project planning that elevated them from obscurity to world leader, and those lessons have transmuted directly into the modern CI/CD DevOps Agile Scrum Kanban philosophies you are familiar with today.

Seven Deadly Wastes

It's 1954, and you are Taiichi Ohno, having risen from machine shop manager to Toyota company director in only 5 years. The business is suffering. The country is still recovering from war, resources are scarce and your main competition, America, had converted its wartime manufacturing and logistics experience to commercial output with great commercial success. How can you possibly compete.

Ohno visited America, looking for inspiration. The concept of Supermarkets and how they operated were of keen interest to him. How they managed inventory and logistics, restocking on demand rather than in scheduled tranches, clashed with his own experiences, where unused resources could pile up at slow stations and leave others downstream idle.

When he returned to Japan, he developed a card-based system of organizing tasks into a logical flow. It would start as Idle, move to Doing, and then to Done, with sub-stages as needed. You know it by its Japanese name, Kanban. He also formalized the concept of Kaizen, or "continuous improvement", and Muda, the 7 wastes.

Inside the Circle

Another thing Ohno is known for was standing for hours on the manufacturing floor, observing. He turned this into a tool for training his managers, drawing a circle on the bare concrete and "inviting" his managers to stand within it and watch the assembly line until they understood the processes and could identify the potential problems and bottlenecks. A somewhat harsh tool in modern eyes, but the metaphor is clear: never stop examining what you think is already working for you. If you look carefully enough, you might even see that circle now.

The Toyota Production System, or TPS, laid the foundation for the lean architecture in modern manufacturing ... and eventually IT. It is still taught today, and many of his concepts form the connective tissue we find in project management today.

Constraints

A few decades later, it was Eliyahu Goldratt who provided the next significant contributions to productivity. He was a physicist by training and profession, but he also had a mind for order and productivity. His inspiration began with chickens and eggs.

The kibbutz he had worked on in his youth had a very focused, organized process for their poultry. Feed, exercise and age were mapped carefully to egg production. Goldratt noticed that none of their attention went to costs of production, efficiency, or the market value of their product. Their attention was fixed upon only a single aspect of production. Was it the right one?

Based on these and other observations, he wrote scheduling software called OTP in the late 1970s. His clients were frustrated by it, the program's recommendations seeming counter-intuitive. Goldratt decided it wasn't so much a software problem as a human problem. Their mental model of efficiency was broken, focused in the wrong place. So he wrote a guide in the form of a novel. The Goal was his attempt to illustrate his ideas about productivity in a way that was easily understood.

The publishers didn't think it would go anywhere, with flat characters and a terse, fairly predictable storyline. They were spectacularly wrong, looking for forest and seeing only trees. This book has essentially been strip-mined of ideas for half a century, but still holds up as a seminal, required read for anybody in the project management industry.

The Bottleneck

The core of Goldratt's philosophy was "identifying the constraint". That attention to any other part of the manufacturing process was wasted because the constraint was what slowed "the goal", i.e. a manufactured product.

Generation Noop

Then came the mainframe, the personal computer and the internet, in relatively rapid progression. While manufacturing had a long tail understanding of producing goods (humankind-long), the IT industry didn't quite seem to understand it was just another version of manufacturing. Software written with goals but not plans, features rammed in like cards on wheel spokes, no thought or care to UX or UI or testing. Things migrated, mutated, philosophies formed loosely around a quest for clean delivery and organized progress, when all the time the fundamentals were sitting right there, waiting to be applied.

Frameworks and workflows like waterfall, Scrum, Kanban-as-workflow, Agile, XP and others began to emerge, re-discovering or reinventing bits of what was already known, solving the same problems by accident or necessity. Dev and Ops glowered at each other over the beige cubicle partitions. "Chucking it over the wall" was the accepted term for code handoff.

It is a pretty pessimistic read of the room, but as someone who lived a lot of it, my memories are more of chaos and mismanagement than clean execution. Sitting in a windowless room at 2AM, hoping that the new column being grafting onto a 32-million record "live" MSSQL table wouldn't blow up the database. Pushing code onto the "seed" production server, cursing through gritted teeth as the FTP replication onto sixteen other boxes turned green lights red, one by one.

4 Types of Work

It's 2013 and the term DevOps is a few years old, but still not widely known or understood. Gene Kim, Kevin Behr and George Spafford are about to change that. They take a page ... well, all the pages ... from Goldratt and create a business parable of their own, The Phoenix Project. It essentially synthesizes Goldratt's "Constraint" arguments (aka Brent) and employs Ohno's techniques to tell the story of an IT protagonist who must unwind the organization's FUBAR (their words) IT infrastructure into something that is modern, performant and reliable.

The 4 types of work ... and 1 more

The book revolves around what they identify as the 4 types of work:

• Business Projects: where the work produces the product or service the organization provides

• Internal Projects: work on projects that support the business, like IT infrastructure

• Maintenance: preventative work that maintains the existing infrastructure, like software upgrades or failure simulations

• Unplanned: such as server failures or critical product bugs

One thing I found notable, even distracting is that throughout the novel, as Bill is led by his mentor Erik through the work-type discoveries, Kim and co. neglected one fundamental classification of work. Bill spends almost the entire novel in meetings, travelling, planning and organizing, but that category of work, Overhead, is never codified. I kept expecting Bill to pull the big reveal on this at the end, show his mentor that he'd been paying attention, but it never came. Maybe in the movie...

Overhead

I mention it here because it has always been a sort of quiet secret in the IT world, that Overhead is often and pervasive, but sort of never discussed. I'll definitely talk about it more (in next week's blog, in fact) because it is one of the two black holes of entropy that can pull hours from work capacity, and it rarely gets a name or the proper attention.

The lessons illustrated by Kim, Behr and Spafford are sharp and relevant. They are all known entities in the DevOps world, and have produced many seminal works on the subject, so it's fair to say the processes in this book are both well-informed and core to modern IT infrastructure. They touch upon the ideas of Continuous Integration, Continuous Deployment, testing-as-process, and the fundamentals of project planning.

The Goal

These names are of course only a small slice of what we see in modern project management and productivity theory, but they were significant and especially so in the IT industry. I read The Goal fairly early in my career. No idea who handed it to me, only that they were unusually earnest about me reading it. Later came The Phoenix Project.

It took decades for IT to formalize and integrate the lessons learned in manufacturing. The two industries are not a 1:1 match, but the similarities and hard-won lessons have helped mature or influence many current frameworks and workflows, from Scrum and Agile to CI/CD.

Did the lessons of Ohno, Goldratt and the rest apply uniformly across my career and work? Not always. Plans collide with environment, budget, politics, deadlines and ownership. Often you are implementing somebody else's strategy with little control over the actual constraints or flow of work.

The goal is to be as efficient as possible within the limits of the situation. Sometimes you can't optimize the bottleneck and have to absorb it as friction. Other times deadline pressure and resource scarcity compress your ability to test safely. There is the ideal, and then there's reality.

Every business was already a technology business before LLMs and AI. Now it is unavoidable. The next generation of thought leaders will be dealing with compressed timelines, collapsed execution windows, and the erosion of ideation that follows from automated synthesis. We may need to borrow even more heavily from these older lessons, or invent entirely new ones.