The Goal: A Process of Ongoing Improvement

(link) by Eliyahu M. Goldratt & Jeff Cox

I try to choose books that I see often or hear about from reliable sources. One of the books that I try to read yearly is the Phoenix Project which mentions it as a source. I heard about it in some videos that I watched about Lean Agile for software. It often shows up on lists of “To Read Agile” books.

This book will go on my list of books to re-read yearly. The concepts in it will mean different things each time it is read as things around us change.

We’re a team. And the team does not arrive in camp until all of us arrive in camp.

STEP 1. Identify the system’s bottlenecks. (After all it wasn’t too difficult to identify the oven and the NCX10 as the bottlenecks of the plant.) STEP 2. Decide how to exploit the bottlenecks. (That was fun. Realizing that those machines should not take a lunch break, etc.) STEP 3. Subordinate everything else to the above decision. (Making sure that everything marches to the tune of the constraints. The red and green tags.) STEP 4. Elevate the system’s bottlenecks. (Bringing back the old Zmegma, switching back to old, less “effective” routings. . . .) STEP 5. If, in a previous step, a bottleneck has been broken go back to step 1.

For the ability to answer three simple questions: ‘what to change?’, ‘what to change to?’, and ‘how to cause the change?’

More importantly, our software worked. I don’t just mean that it didn’t bump, or that it performed according to the written specifications, or that it was efficient in producing reports. It really worked.

If the goal is to make money, then (…), an action that moves us toward making money is productive. And an action that takes away from making money is non-productive. For the pat year or more, the plant has been moving away from the goal more than toward it. So to save the plant, I have to make it productive; I have to make the plant make money for UniCo.

A bottleneck is any resource whose capacity is equal to or less than the demand placed upon it. And a non-bottleneck is any resource whose capacity is greater than the demand placed on it.

Balance flow, not capacity.

Don’t give the answers, just ask the questions.

A measurement not clearly defined is worse than useless.

Key Thoughts:

• Making sure there is alignment of the goals of the organization, the goals of the department, and the goals of the team will give us the guide posts needed to know that all decisions move us towards success.
• Having clarity on the questions that we need to answer so that we can make sure that our measurements (KPI’s) are valuable is key. Just measuring data will not tell us if we are moving towards our goals. Finding ways to measure the things that actually matter will give us the information we need to be successful.
• We need to understand the flow of our systems, where bottlenecks (constraints) are and where we can make changes to help things flow better.
• Clearing a constraint allows us to move forward at a steady pace and unblock us for the future. But remember that clearing one constraint will reveal more that were hidden and may even create new ones that didn’t exist before. Looking for them needs to be a constant effort.
• In a manufacturing plant they fulfill orders to make money. In software we keep our systems running and improve them to enable us to sell more to make money. How can we successfully deliver software when the customer orders change. Too often we are asked to do work where the requirements are fuzzy, incomplete, or just not correct. This slows everyone down. How can we clarify our “orders” to make sure they are as accurate as possible before the work begins and will bring us the value that we are looking for.
• How do we determine if our teams have achieved success? When do we consider them to be “efficient”? What would we do then?

• How do we succeed at building software
• The projects need to be valid
• The outcome needs to be clear
• Things need to flow steadily in and out of engineering
• We need to be able to build software at a steady reliable pace
• When emergencies arise we need to solve them quickly and safely
• Communication is critical

Potential Action Items:

• Find concrete key things that we can measure that will help us to understand our constraints (bottlenecks). Make sure that the measurements align with the goals of the organization and department. Design projects that will help us to clear the constraints and measure concrete progress.
• Assume that you are new at the job you are doing. Answer the question “what is the first thing you should do in your new job.” Then take some time to align what you are doing today with the answer to that question.
• Track each step in the flow of work though our system looking for places where bottle necks may occur. Work on those areas to help find ways to clear them out, make them faster, or work within their limitations.
• Make sure that the Teams understand “why” we are doing the project. Not just the product changes but truly understand the business value that it will bring.
• Spend some time learning about the Socratic approach.
• While discussing this book with others in an online Reading group the book “Accelerate” was suggested as a good follow-up.

Book Summary – The Goal: A Process of Ongoing Improvement

The Five Dysfunctions of a Team: A Leadership Fable (link) by Patrick Lencioni

This book has been on my TBR for quite a while. I had it on the list due to the number of times it was recommended to me, or that I found it on a “must read” list. Finally, I picked it up and was glad that I did. I have discovered that if I am going to read a book teaching these types of skills I really do prefer the “Fable” style of learning.

I do wish that I could read a book from the perspective of the people who work for the leadership team in this book and see how the decisions they made changed the day to day lives of the rest of the employees.

“If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.”

It is better to make a decision boldly and be wrong — and then change direction with equal boldness—than it is to waffle.

“… a fractured team is just like a broken arm or leg; fixing it is always painful, and sometimes you have to rebreak it to make it heal correctly. And the rebreaking hurts a lot more than the initial break, because you have to do it on purpose.”

“…Exactly. The point here is that most reasonable people don’t have to get their way in a discussion. They just need to be heard, and to know that their input was considered and responded to.”

Key Thoughts:

1. The first thing that occurred to me is that it is hard to read a book like this when I do not have a clear understanding of who my “team” is. I have coworkers and in some cases it is clear who is not on my team, but it is less clear who is. This is something that I think I have struggled with for a while and it has affected me more that I know.
2. I was extremely glad to read this book as I know that it is one that the FMG C-Team currently uses. It helped me to see more clearly where some of the things that are passed down came from.
3. Katherine has the discipline and mental fortitude needed to lead a group of hard headed, intelligent, executives to become a successful team. How does a person become a leader like that?
4. I really liked the description at the end of the book about cascading messaging. “at the end of the [meeting] the team should explicitly review the key decisions made during the meeting, and agree on what needs to be communicated downstream…” How do we apply this at a lower level within the teams?
5. How can we make our engineering department one that can run at a high rate of success and productivity without burning out our engineers and ourselves. Understanding how to build a department with solid processes and decision making skills will be the key to our success.
6. People management is hard. 🤣

Potential Action Items:

1. Team Survey: Can I do something similar to this for our workflows and processes to see areas for growth?
2. Absence of Trust: Help to define “teams” so that each person has a clear idea who is on their team. This includes guilds like the React and SQL ones.
3. Absence of Trust: Could we do peer reviews within the teams? Each person list skills that the others are good at as well as things they need to work on. Then the results are reviewed by someone outside the team, probably not a manager. Keeping the results outside of the hands of anyone who helps to pay the bills would aid in fostering trust.
4. Fear of Conflict: Have teams struggling take Meyers Briggs or some other personality test to see how the team members compare against each other. If you have too many of one type of personality on a team that could cause unhealthy conflict.
5. Lack of Commitment: Think through the idea of cascading messaging and see how that could apply with the meetings that I am a part of.
6. Lack of Commitment: Find ways to clearly communicate deadlines to the teams. Make sure that they see on a regular basis what the goals are and what is expected.
7. Lack of Commitment: If we are going to find a way to communicate deadlines, we also need to work together to make sure we have clearly set deadlines and expectations. The more handwavy the goal is the less likely it is to be completed.
8. Avoidance of Accountability: Retrospectives, provide an easy way for teams to review reports and data about the previous 2 weeks so that they can review the most important things.
9. Inattention to Results: Help to make sure that the collective goal of the team is clearly laid out in a place that they easily access. Quarterly goals is a start, but what is the micro-goal that the team is currently working towards. In Sprints it would be the Sprint goal, how do we do something similar with where we are at now?

Book Summary – Overcoming the Five Dysfunctions of a Team