Chapter 11: Building an Adaptive Organization

A startup should build an adaptive organization so that work processes should be standardized, and a curriculum of the concepts that new employees should learn should be standardized.

11.0 Is speed important?

Startups are mainly in a life-or-death struggle to learn how to build a sustainable business before they run out of resources and die. However, solely focusing on speed can be destructive. To work, startups need built-in speed regulators that help teams identify their ideal place of work. We explored the example of speed regulation in Chapter 9 of the andon cord in systems like continuous deployment. It’s incorporated in the paradoxical Toyota proverb, “Stop production so that production never has to stop.” The essence of the andon cord is that it immediately brings work to a finish if an uncorrectable quality problem arises that requires it to be investigated. This is one of the essential discoveries of the lean manufacturing movement. If you’re causing quality problems, the defects will eventually slow you down. Defects cause many reworks, low morale and customer complaints which causes slow progress and harms valuable resources.

11.1 The wisdom of the five whys

Lean Startups need a process that issues a natural feedback loop to speed up. When you’re accelerating too fast, you create more problems. Adaptive processes require you to slow down and invest in avoiding the types of issues that you’re currently wasting time on. As those preventive efforts succeed, you speed up again. For example, assume you need a training program for new employees. Without the program, new employees will make mistakes during their learning curve, needing assistance and intervention from other teams, slowing everyone down. Thus, how can you decide if the investment in training is worth the benefit of speed due to reduced interruptions? Discovering this from a top-notch view is difficult as it requires estimating two unknown quantities, like how much it will cost to build an unknown program against an unknown benefit you might gain. What’s worse is that the usual way of making these decisions is large batch thinking. A company either has a training program, or it doesn’t. Most companies cannot do anything until they justify the return on investment from doing an entire program.

The alternative is to adopt a five whys system to make incremental investments and develop a startup’s processes. The main idea behind the five whys is to connect investments directly to preventing the most difficult symptoms. This was developed by Taiichi Ohno, the father of the Toyota Production System, which Eric Ries has adopted to be used in the Lean Startup model with minor changes designed especially for startups. At the essence of every technical problem is a human problem. The five whys provide an opportunity to discover what that human problem may be. Taiichi Ohno stated an example that when you’re facing a problem, have you ever stopped and asked ‘why’ five times for each answer when put forwarding a question? Repeating why five times can help discover the main problem and correct it.

Also, through the five whys, you can discover that what initially appeared to be individual mistakes could be problems in training or the playbook for how the service should be delivered. To understand this, let’s assume that in IMVU, Eric Ries’s team received complaints about their new product version.

1. A new product release disabled a feature for customers. Why? Because a particular server failed.
2. Why did the server fail? As an obscure subsystem was used in the wrong manner.
3. Why was it used in the wrong manner? Because the engineer using it didn’t know how to use it properly.
4. Why didn’t he know how to use it? Because he wasn’t trained.
5. Why wasn’t he trained? Because his manager doesn’t train new engineers as he and his team are swamped.

What started as a technical fault turned out to be a human managerial problem.

11.2 Making a proportional investment

Using the five whys analysis to build an adaptive organization is by continuously making a proportional investment at each of the five levels of the hierarchy. That means the investment should be smaller when the symptoms are minor and larger when the symptoms are more painful. In the example we saw above, the answer is to fix the server, change the subsystem to make it less error-prone, educate the engineer, and talk with the engineer’s manager. Having a conversation with the manager is always challenging in a startup. Therefore, proportional investment is essential.

11.3 Instant speed regulator

The five whys approach behaves like a speed regulator. If you have more problems, you’ll invest more in finding solutions. As the investments in infrastructure or processes are successful, the seriousness and number of crises reduce, and the teams speed up again. Especially with startups, there is a risk for teams to work too fast, which trades quality for time in a manner that causes mistakes. The five whys avoid that, allowing teams to find their ideal pace.

The five whys connect the progress rate to learning, not merely execution. Startups should go through the five whys if they face any failure, including technical errors, failures to achieve business results or unexpected changes in customer behaviour.

11.4 The five blames

When startups first adopt the five whys as a problem-solving tool, they face some issues. When the five whys go wrong, Eric Ries calls it the five blames. Rather than repeatedly asking why to understand what went wrong, employees start blaming each other by trying to decide who is at fault. Rather than using the five whys to discover and fix problems, managers and employees can become victims of using the five blames to vent their anger and scold colleagues for systemic failures.

Although it’s natural that when we see a mistake, we consider it to be a defect in another department, knowledge or skill, the five whys help us to see the actual truth that bad processes and not bad people cause chronic problems. Eric Ries has recommended several ways to escape the five blames. Firstly, ensure that everyone affected by the problem is in one room while analyzing the primary cause. From customer service reps who fielded the calls to the senior management, who were the decision-makers when the problem was escalated, should be present in the same room. Then, when the blame arises, most senior members should repeat this mantra – shame on us for making it easy to make a mistake. In a five whys analysis, we need a systems-level view as much as possible.

11.5 Getting started with the five whys

Eric Ries has suggested a few tips for getting started with the five whys. There are rules to be followed for the five whys to work correctly. For example, the five whys require an environment of mutual trust and empowerment. If this is lacking, the complexity of the five whys will be overwhelming. In such situations, Eric Ries has used a simple version that yet allows teams to focus on analyzing the leading causes while developing the muscles they’ll eventually need to solve the full-blown method.

He has asked teams to follow these simple rules:

• First, tolerate all the mistakes for the first time.
• Then, don’t repeat the same mistake twice.

The first rule motivates people to get used to being compassionate about mistakes, especially others’ mistakes. The second rule makes the team start making proportional investments in prevention. Although this simplified system is successful, it isn’t successful in the long run. The simplified system invites questions such as what counts as the same problem? What type of mistakes should we focus on? And should we fix this problem or try to avoid a whole category of relevant problems? For a team that is getting started, these questions can be frustrating; however, they need to be answered in the end, which requires a complete adaptive process like the five whys.

11.6 Facing the dirty truths

You need to be ready to face the fact that the five whys will reveal dirty truths about your company at the beginning. Under pressure, teams might feel like they don’t have time to waste on studying the primary causes, although it would give them more time in the long run. As a result, the process will sometimes evolve into the five blames. Due to this reason, it’s essential for someone with authority to insist that the process should continue, its recommendations are implemented, and to behave as a referee if disagreements occur. Thus, building an adaptive organization requires executive leadership to sponsor and help the process succeed.

Always remember that you need the help of your manager or team leader for a five whys inquiry. It might be impossible to get the whole team for the five whys inquiry, but you can always follow the simple two-rule version on your own when something goes wrong. Finally, ask yourself how to prevent yourself from being in this situation again.

11.7 Start small and be specific

Once you’re ready to start, start with a narrowly targeted class of symptoms. For example, when Eric Ries used the five whys for the first time, he used it to diagnose problems with one of his internal testing tools that didn’t directly affect customers. Although it may be tempting to start with something significant and critical, as that’s where most of the time is wasted due to a flawed process, it’s where the pressure will be the greatest. When the chances are high, the five whys can become the five problems quickly. It’s, therefore, better to let the team learn how to do the process first and then expand into higher stakes areas later.

If the symptoms are more specific, it’s easier for everyone to know when to schedule a five whys meeting. For example, suppose you want to use the five whys to address billing complaints from customers. You’ll have to choose a date after which all billing complaints will automatically cause a five whys meeting. Remember that this requires that there will be a small enough number of complaints that having this meeting every time one comes in is reasonable. If there are too many complaints already, choose a subset on which you want to focus. Ensure that the rule that decides which types of complaints trigger a five whys meeting is simple and strong. For example, you might decide that complaints related to a credit card transaction will be investigated. Don’t pick an unclear rule.

Initially, the temptation would be to make radical and profound changes to every billing system and process; however, keeps the meetings short and pick simple changes at each of the five levels of the inquiry. Eventually, as the team gets more used to the process, you can expand it to include more billing complaints and other problems.

11.8 Appointing a five whys master

To facilitate learning, Eric Ries has found it helpful to have a five whys master. This person is responsible for being the moderator for every five whys meeting, deciding which prevention steps to adopt and assigning the follow-up work from that meeting. The master should be a senior member to have the power to ensure that those assignments are complete but shouldn’t be so senior that they won’t be able to present at the meetings due to conflicting responsibilities. In addition, the five whys master can assess how well the meetings are and if the prevention investments are successful.

11.9 The story of QuickBooks

QuickBooks is one of Intuit’s products. It has been the leading product for many years. Therefore, it has a large and committed customer base, and Intuit expects it to contribute significantly to its bottom line. QuickBooks has been launched on an annual cycle in one giant batch. The usual release approach was to spend considerable upfront time to discover the customers’ needs:

Usually, the first three to four months of each annual cycle were spent strategizing and planning without building new features. After a plan and milestones were established, the team spent the next six to nine months building the product. This would lead to a big launch, and the team would get its first feedback if it had successfully delivered on customer needs at the end of the process. The timeline started like this – the process begins in September, the first beta release is in June, and the second beta release is in July. The beta is tested to ensure that it doesn’t crash people’s computers or cause them to lose their data, and by that time in the process, only major bugs could be fixed.

This is the waterfall development methodology that product development teams have adopted for years. An extensive batch system depends on proper forecasting and planning success.

11.9.1 Year one – gaining failure

Greg Wright, the director of product marketing, witnessed failure in his first year joining the QuickBooks team in 2009. In that year, the company shipped a completely new system in QuickBooks for online banking, one of its most essential features. The team explored rounds of usability testing by using mock-ups and nonfunctional prototypes, followed by considerable beta testing using sample customer data. At that moment of the launch, everything seemed to be fine.

The first beta release was in June, and the customer feedback started becoming negative. Although customers were complaining, there wasn’t a good reason to stop the release as it was technically flawless by not crashing computers. However, Greg was stuck at this point as he didn’t know how the feedback would translate to actual customer behaviour in the market. Were these separate complaints or a part of a huge problem? He was particular about one thing – his team couldn’t afford to miss the deadline.

When the product shipped, the results were terrible. It took customers 4-5 times longer to reconcile their banking transactions than it had with the earlier version. Ultimately, Greg’s team failed to deliver on the customer need they were trying to address, and as the next release had to proceed through the waterfall methodology, it took nine months for the team to fix it.

Intuit uses a tracking survey called the Net Promoter Score to examine customer satisfaction with most of its products. This is an excellent source of actionable metrics about what customers think of a product. NPS eventually becomes stable. As it measures the main customer satisfaction, it’s not subject to minor changes. It only registers significant changes in customer sentiment. QuickBooks’ score dropped 20 points that year, the first time the company had evolved with the NPS. That 20-point drop caused significant losses for Intuit simply because customer feedback came too late, and there was no time for them to iterate.

Thus, something had to be done to get out of this problem, and that’s when Greg Wright had a mission to achieve startup speed for QuickBooks development and deployment.

11.9.2 Year two

Greg tried to change the QuickBooks development process by adopting four principles:

1. Smaller teams. Convert from larger teams with stable roles to smaller, fully engaged teams whose members adopt different roles.

2. Achieve shorter cycle times.

3. Quicker customer feedback, testing if it crashes customers’ computers and the performance of new features or customer experience.

4. Allow and empower teams to make quick and brave decisions.

Fundamentally these principles seem to comply with the methods and principles we saw in the earlier chapters, but Greg’s second year in QuickBooks wasn’t an apparent success. Over the year, the team’s work looked more like it was in the previous years. As Greg stated, “Organizations have muscle memory”, and it’s hard for people to let go of old habits.

11.9.3 Year three

Unhappy with the bit of progress in year two, Greg partnered with Himanshu Baxi, the product development leader. They got rid of all the old processes and made a public announcement that their teams would be creating new processes and were not reverting to the old version.

Rather than focusing on deadlines, both invested in the process, product and technology changes that allowed them to work in small batches. Those technical innovations helped them get the desktop product to customers faster for feedback. Rather than building a comprehensive road map at the start of the year, Greg started the year with his so-called idea/code/solution jams that brought engineers, product managers and customers together to establish a pipeline of ideas.

There were three differences in year three:

1. First, teams were engaged in creating new technologies, processes and systems.
2. Cross-functional teams were created around new ideas.
3. Customers were involved from the origin of each feature concept.

It’s important to remember that the old approach did not lack customer feedback or customer involvement in the planning process. Changing to cross-functional teams wasn’t easy, and some team members were doubtful about it. For example, some product managers felt it was a waste of time for engineers to communicate with customers. The PMs believed it was their job to discover the customer issue and define what was required to be built. The engineers didn’t want to spend time prospecting.

Communication was necessary for this change in process to succeed. All the team leaders were ready for the change they were driving and why they were driving it. Most of the skepticism they faced was because they didn’t have solid examples of where this has worked in the past, and this was a completely new process for Intuit. Originally, QuickBooks was built in large teams and with long cycle times. Each focused on iterating with customers as quickly as possible, running experiments and then using validated learning to make real-time investment decisions about what to work on. Therefore, they used to have five big branches of QuickBooks that merged features at the time of the launch, but now there are twenty to twenty-five branches. This enables for a much larger set of experiments. Each team works on a new feature for six weeks, testing it with customers throughout the process.

Although the primary changes needed in an adaptive organization lie in the employees’ mindset, changing the organizational culture isn’t enough. As we saw in Chapter 9, lean management requires treating work as a system and handling the whole process’s batch size and cycle time. Therefore, to achieve permanent change, the QuickBooks team had to invest in tools and platform changes that would allow the new quicker way of working.

For example, one of the major issues in trying to release an early alpha version the past year was that QuickBooks is a mission-critical product. Most small businesses use it as their main repository for critical financial data. As a result, the team was cautious about releasing an MVP with the potential risk of corrupting customer data. Thus, even if they had worked in smaller teams with a smaller scope, the problem with all that risk would have made it hard to work in small batches.

To reduce the batch size, the QuickBooks team had to invest in new technology by building a virtualization system that allowed them to operate multiple versions of QuickBooks on a customer’s computer. The second version could access the customer’s data but could not permanently change it. Thus, there was no danger of the new version corrupting the customer’s data. This helped them to separate new releases to allow selected real customers to test them and provide feedback.

The results in year three were convincing. The version that year had many customer satisfaction ratings and sold more units.

Conclusion

As Lean Startups develop, they can use adaptive techniques to build more complicated processes without sacrificing their main advantage: speed through the feedback loop. One of the main benefits of using techniques that are taken from the lean manufacturing is that when Lean Startups grow, they are well positioned to develop operational excellence based on lean principles. They know how to work in discipline, create processes that are customized to their solution and use the five whys and small batches.

As a successful startup becomes an established company, it will be careful when developing the kind of culture of disciplined execution that distinguishes the best firms in the world like Toyota. However, even established companies must face difficulties finding new growth sources through disruptive innovation. Therefore, startups and established companies should learn to balance multiple works while pursuing operational excellence and disruptive innovation. This demands a new type of portfolio thinking which will be explored in chapter 12.