Understand that diagnosis is foundational to both progress and quality relationships. If you and others are open-minded and engage in a quality back-and-forth, not only will you find better solutions, you will also get to know each other better. It is an opportunity for you to assess your people and to help them grow, and vice versa.
Design Improvements to Your Machine to Get Around Your Problems Once you’ve successfully diagnosed the problems standing in the way of your achieving your goals, you need to design paths for solving them. Designs need to be based on deep and accurate understandings (which is why diagnosis is so important); for me, it’s an almost visceral process of staring at problems and using the pain they cause me to stimulate my creative thinking. This is exactly how it was for the team responsible for client service analytics, and especially for Bridgewater’s co-CEO David McCormick, who was then head of the Client Service Department. Coming out of the diagnosis, he moved quickly to design and implement changes. He fired the team members who had allowed standards to slip and reflected deeply on what new designs he could implement to get the right people into the right roles. In selecting his new Responsible Parties for client service analytics, he picked one of our top investment thinkers who also had extremely high standards (and was very outspoken about cases where he saw them slipping) and paired him with one of our most experienced managers, who knew how to build the right process flows and make sure everything that needed to happen would go precisely as planned. But that wasn’t all. When coming up with a design, it’s impor-tant to take time to reflect and make sure you’re looking at the problems from the highest level. David knew it would be a mistake to look only at this one part of the department, because the same slip in quality that had happened there was likely to have occurred in other places too. He needed to think creatively to come up with a design that would build a durable culture of pervasive excellence throughout the entire department. This led to his invention of “Quality Day,” biannual meetings in which members of the Client Service Department would review each other’s mock presentations and memos and give direct feedback on what was good and what wasn’t. More importantly, the meetings were a chance to step back and assess whether the ways of ensuring quality were working as expected, by bringing in a bunch of tough, independent thinkers to offer criticism and get the process realigned on what good looks like. Of course, there were many more details to all of David’s plans for transforming the department. But the important thing is how all the details and plans extended from a high-level visualization of what was required. Only when you have such a sketch can you begin to fill it in with specifics. Those specifics will be your tasks; write them down so you don’t forget them. While the best designs are drawn from a rich understanding of actual problems, when you’re just starting out on something, you often have to design based on anticipated problems as opposed to actual ones. That’s why having systematic ways of tracking issues (the Issue Log) and what people are like (the Dot Collector) is so useful: Instead of just relying on your best guesses of what might go wrong, you can look at data from prior “at bats” for yourself and others and come to the design process with understanding rather than having to start from scratch. The most talented designers I know are people who can visualize over time, running through different collections of people from the scale of small teams to entire organizations, accurately anticipating the kinds of results they’ll produce. They excel at design and systemization. Hence the overriding principle: Design and systemize your machine. Creativity is also important to this process, as is character, because the most important problems to design around are often the hardest, and you need to come up with original ways of addressing them and be willing to make hard choices (especially when it comes to people and who should do what). The following principles delve into designing and how to do it well.
Build your machine. Focus on each task or case at hand and you will be stuck dealing with them one by one. Instead, build a machine by observing what you’re doing and why, extrapolating the relevant principles from the cases at hand, and systemizing that process. It typically takes about twice as long to build a machine as it does to resolve the task at hand, but it pays off many times over because the learning and efficiency compound into the future.