What I Learned from Re-Reading The Goal

There are a few books worth re-reading every few years. The Goal is one of them.

There’s a few IT-centric books I recommend re-reading every few years:

  • The Mythical Man Month by Fred Brooks
    • a short read with timeless, thought-provoking software engineering tips. Example: adding more people to a late-running project will make it even more late.
  • Death March by Edward Yourdon
    • how to survive impossible software projects
  • The Goal by Eliyahu Goldratt.

These books hold timeless insights that are easily forgotten. Let’s review one of them today.

What is The Goal?

If you asked me this after I read it the first time I’d say, “it’s about continuous improvement told from the lens of a factory manager, but it’s applicable to any industry, most notably IT.” Today, I’d simplify this to: “It’s about science and learning.”

Contrary to what you read about in the news in the Covid Era, science is not about truth. There are no absolute truths. Science is simply the method we use to explain why things are the way they are. We are constantly learning and improving upon the hypotheses that we think we know. The scientific method gives us a framework to use for our learning.

The Goal teaches the Theory of Constraints in a Socratic style – it’s a novel that shows business lessons around determining what “the goal” of your business really is (and it’s not what you think). The plot: a plant manager for a contract manufacturer has excellent metrics, from both the shop-floor and cost accounting perspectives, yet his plant faces shutdown and bankruptcy. The book follows the plant manager’s journey as he learns what the goal really is.

Wait, a book about manufacturing efficiency being recommended to software development shops? Yep. You’d be surprised at the parallels that can be drawn.

Throughout the book we reason and learn, together with the main character, about the inefficient processes (that are touted by management as being efficient) in a fictional factory. Just when we think we’ve reasoned through the “whys” we are presented with new data which makes us repeatedly question our assumptions and beliefs (this sounds a lot like the scientific method and data science, no?). Simple postulates almost everyone believes, like “improving worker utilization will improve our throughput”, are shown to be incorrect upon observation and deductive reasoning. Yeah, you read that right…your software developers might actually deliver things ON TIME if they worked less. This isn’t just a platitude for software companies that are run like sweatshops, this can be proven mathematically and is one of the core tenants of Kanban. Just because there is some spare capacity doesn’t mean we have to use it.

All tech books should be written like The Goal. Goldratt uses fast-paced fiction and allegory to teach often boring and dry subjects in a captivating way. Imagine how many DBAs would understand at least some of the internals of the Oracle query engine (vs misunderstanding all of it) if it was taught via storytelling. If you want somebody to remember some arcane fact, tell them a story.

What I learned after the first few reads

I try to re-read The Goal every 5 years, and every time I do, I learn something new and profound. My sincere advice is to get the audiobook so you can listen to it and really soak it in. I’m a software developer at heart and when I first read it 15 years ago I quickly realized that the real reasons why software projects are risky, late-running, and rarely bring the promised business value is because they are run and measured through the lens of cost accounting. We value the utilization rate of our staff and equate that with productivity. Better to have a developer working on something vs being idle, right? I quickly learned that this is wrong.

Fast forward to the 3rd time I re-read the book, around 2013, and DevOps was taking our industry by storm and a little book called The Phoenix Project was written. The Phoenix Project is a rewrite of The Goal but the plot and metrics were updated specifically for the technology industry. This book, more than anything else, made “DevOps” and Kanban ubiquitous. The Goal is still a better book IMO. The Phoenix Project is like watching The Office … sometimes it cuts a little too close to home.

Learnings: automating the mundane gives us more time to solve real business problems. Today CI/CD is table stakes, but it wasn’t back then. In 2013 when I was convincing my staff to automate builds and releases it was viewed as a waste of time. “We only release our software to our customers once a year, why would we waste time on this?” How times have changed. I also learned the true differences between agile/scrum and kanban. If you aren’t sure about the differences consider just learning about (and implementing) kanban. It solves so many problems that traditional scrum just hides.

What I learned this time

For the past 5 years or so I’ve become an advocate of human-centered design thinking as part of my data science work. I’ve incorporated empathetic design into my architectures. Data science really only works if we are sure we are solving the right problem for the right people. But data science work is rarely easy to estimate. It’s a process of learning and adjustment. In traditional programming I can estimate about how long it will take to add a feature to a website because I’ve done similar work before. The fact is, I can rarely tell a customer up-front how much time an ML algorithm will take to develop, let alone if it will actually provide lift. We have to do some deductive reasoning, some experimenting, some evaluating. Well, I realized this time that The Goal really is all about applying science and learning to business processes. The learning process can be systematized, we just might not be able to give a good work effort estimate.

Here’s another example of learning: Hackathons. Most companies are doing hackathons but you can quickly see that most don’t really believe they are valuable. They relegate hackathons to “weekend work” or they schedule them yearly. That’s not really good enough. If you believe in hackathons, then they should be part of your innovation cycles. Here’s a trick that works for me: replace sprint or release planning meetings with a mini-hackathon. Instead of talking about new features and then endlessly scoping them, build a few in real-time. You’ll be surprised how much better your estimates become and how much more agreement you have.

Customers have told me they could never propose frequent (monthly) hackathons because management just doesn’t believe there is value. If that’s the case, try doing hackathons on a more micro-level. Have “innovation weeks” at the team level and stagger them across teams. Then invite the other teams.

Here’s what an “innovation week” looks like:

  • developers get an opportunity to prototype new feature ideas or to test-drive a new open-source library
  • product owners get a chance to recalibrate the backlog and refine requirements
  • designers can sketch out concepts for the next round of work.

Not every Innovation Week produces work that eventually makes its way into production. The Innovation Week becomes part of the “corporate muscle” and we begin to institutionalize new learning processes. This is something right out of The Goal where Alex’s team has informal meetings where they discuss and try new ideas and refine their deductions.

Summary

If you haven’t read the 4 books I recommend in this post, go do it. These are timeless works that will make you a better technologist and business leader. Although The Goal is more of a “business management” book, if you think about the parallels to the IT world, you’ll find new ways to adopt continuous improvement.

Are you convinced your data or cloud project will be a success?

Most companies aren’t. I have lots of experience with these projects. I speak at conferences, host hackathon events, and am a prolific open source contributor. I love helping companies with Data problems. If that sounds like someone you can trust, contact me.

Thanks for reading. If you found this interesting please subscribe to my blog.

CONTENT
Design Thinking Digital Transformation

Archive