Tuesday, July 7, 2015

Braxton LS3

Chapter 9: The chapter starts with an example of stuffing envelopes in large vs. small batches.  For what reasons does Ries say the small batches are more efficient?

Ries tells us that smaller batches are more efficient because problems are more quickly detected, and therefore fixed, it allows for faster feedback and validated learning, and it allows you to see if customers even want your product. All of these provide small batches with an advantage over large batches.

Chapter 9: "Hardware becoming software", "Fast production changes", and "Rapid prototyping tools" are all things that could help us build a robot more quickly.  Give an example of each of these 3 that we could do.

For hardware becoming software, our team could automate several common driver functions using code to allow for common maneuvers to be performed at the press of a button, rather than the movement of the joystick. That allows for faster driver reactions in the heat of the moment, and can keep drivers focused on the game at hand. For fast production changes, we could quickly iterate new parts in CAD when we found a defect or a possible improvement, and we could test for these issues early on, to prevent waste. As for rapid prototyping tools, we could have a large amount of old scrap and wood to be lying around for students to adapt into jankbots for quick prototypes to demonstrate concepts and ideas.

Chapter 10: Shift your focus from building robots to growing our team of students, mentors, parents, and sponsors.  What is our team's engine of growth?

Our team's engine of growth is a sticky one, as we do not require one-time payments nor do we virally spread among the town's population. Instead, our team requires interested students, parents, etc. to not only join, but stay with the team throughout the years

Chapter 10: We also lose people (students, mentors, parents, and sponsors).  What things cause this to happen?  Which of these can we control?

Our most common method of losing people is students graduating. We can also lose people by events such as relocation to another town, loss of interest, or more extreme events such as sponsors going out of business. Some of these events are controllable, or at least manageable in some regard. Gradating students can be kept on as mentors, and their parents can stay with the program, either as mentors, or just as volunteers or food vendors. While events like moving and sponsor bankruptcy are rather unavoidable, loss of interest can be slightly mitigated. Now, while sometimes we cannot prevent people from leaving, we can figure out why they left and improve to prevent a further exodus. If they left due to boredom, we can ask ourselves why five times to find out the root of the problem, and attempt to rectify it. 

Chapter 11: Explain the purpose of the "Five Whys" technique for root cause analysis.

The "Five Whys" is a technique for finding the root of problems and issues by asking oneself why five times, basing their next question off of the previous answer. This technique seeks to find systemic or managerial problems that caused a mistake to occur, and how the team can remedy these problems to prevent a similar mistake from happening again.


In this section of the book, I've learned about the efficiency small batches vs. large batches, different engines of growth for startups and established companies, as well as how to ask the "Five Whys" to figure out the root of an issue or problem, which is almost always systemic. However, without guidance, this process can quickly devolve into the "Five Blames", where people in the room blame each other for failures and mistakes. All in all, this section provided information for startups, and by extension, organizations like our robotics team, to be able to roll with the punches and adapt to the situation as it evolves.


  1. Braxton your small batch comments on programming are great. I think there was some effort in that last year but having a library of all the "typical functions" does 2 things. One it helps with velocity. grab or copy the block and test a bit of the bot. I also see great value in the small batches when it comes to making continuous improvement. These small batches become a library for future development always getting better.

    as for rapid prototyping lets remember some basic tools and material can be rapid. A plywood base or cardboard cover can be rapid.

  2. I agree with your thought of the team's engine of growth and how it is fairly tricky due to the interest level required for one to be in robotics

  3. Learning why people left would be a great idea. This would allow our team to grow and create more individuals with the skills needed on our team.