A note for the reader of this fine book: It is less a single cohesive narrative as a collection of thoughts and anecdotes. There are many good comments and thoughts in the book, and the two that stuck with me the most (I think they were both three-page chapters in the book) were on the “one and two” metaphor and peacetime/wartime CEO dichotomy.
Ones like spending most of their time gathering information from a broad variety of sources, from employees to customers to competitors. Ones love making decisions. Twos, on the other hand, thoroughly enjoys the process of making the company run well. They insist upon super clear goals and strongly prefer not to change goals or direction unless absolutely necessary. Functional Ones are people who act as Ones for their functions, but Twos as members of the executive team. In peacetime, leaders must maximize and broaden the current opportunity. As a result, peacetime leaders employ techniques to encourage broad-based creativity and contribution across a diverse set of possible objectives. In wartime, by contrast, the company typically has a single bullet in the chamber and must, at all costs, hit the target. The company’s survival in wartime depends on strict adherence and alignment to the mission.
I thought these two chapters helped me put to rest an issue that I have struggled with for years. During interviews, I have often gotten the question, “what will you do in your first 90 days” or “what is your management style.” It felt like people were looking for some cookie-cutter answer. My intuitional answer was always: I will learn what is systemically wrong and choose the best management style to begin fixing the issues. Not exactly the best answer, so I would instead weave a story that best fits the job description. Historically, I have never taken a job where my day-to-day after six months at the company matched the official job description. The assumption that this would not be the case when interviewing, that a job is often a dialogue between the needs of the company and the capabilities of the employee, has always felt like a false narrative.
In the first referenced section, I could easily place myself in the Functional One category. Another reference, one of my favourite from West Wing, Bartlett’s comment to Josh: “I want to be the man, you want to be the man the man counts on.” That always resonated with me. I love managing and leading engineering, product and design organizations. I am building a space for everyone to be successful and deliver results. However, my focus has always been on the people and seeing the team be successful. I’ve never had an idea or product that I was so invested in that I wanted to take it and launch a company around it.
In the second section, I realized that my experiences had led me to naturally ping-pong between peacetime and wartime CEO management models. I spent 17 years in the video game industry, starting in 2001. When you start a video game project, the desire is to be open to new ideas and explore what will be fun for the player. There are multiple types of exploration: design innovates on the gameplay and the environment (levels), engineering explores new capabilities that can be done on the hardware platform, and the art team tries out new techniques to push the visuals of the game. For most of my time in the industry, the final product had to go out on physical media with no ability for updates or changes. Everything rides on the bits on the disc that ship out to the customers.
As you leave pre-production (the early phase of development) and transition into the later stages of production, there is a shrinking amount of time and resources to absorb a new idea or process change. For example, the decision by the Rage team at ID to adopt the new mega-texture capability pushed the delivery date for that game by (a reported estimate) of at least a year. The notorious Duke Nukem project ran into this issue in a serial and repeated fashion. In the early days of a project, you look for a broad set of ideas to find a maximum value for the player (fun). Later in the project, as you get closer to the physical manufacturing dates, this process is ratcheted down to a single-threaded “single bullet” thought model. Decisions are made to cut scope, and cut content, until you arrive at the set of things that will ship to the customer. Then these things need to be completed, tested, and the final builds sent out for manufacturing.
With an average development cycle of two years and 17 years in the industry, I had gone through this transition multiple times. In my largest project, Call of Duty: Ghost, we began with an exploration model. The team wanted to move off the Modern Warfare moniker (apparently, there is a huge amount of bad juju around the fourth edition of a product). We had two new consoles launching, which required developing entirely new art targets and pipelines. Historically, most franchises also fail to transition over a generation, bringing a lot of focused eyes on the failure or success of the title. Thus, we began in a peacetime model - discovery and exploration across all three core disciplines. Some helpful scope, at the time, a production run of Call of Duty would use up the worldwide manufacturing of the approved facilities for making physical copies for Sony and MSFT. Any delays would result in fewer copies made as EA would be right behind us in the schedule. Thus, as we shifted gears toward the end of production, we also shifted management modalities. We had one bullet. There was no guarantee that any copy of the single-player game could or would be updated from the version that was on the disc. PS3 Master had a last-minute change on it that may cause the game to crash if the DVCR functionality was triggered (popular function in Japan) - recall it now for X million, recall it later for XX million, replace all copies at a later date XXX million, or roll the dice that the issue would be benign (not show up in real-life cases)? PC game needs a change to allow for shader updates and prevent the need for gamers to re-download the entire game when that occurs - delay the production run for the PC at the cost of X million, skip the change, or ship the change without any QA? These and many (many) more are all examples of the decisions that I needed to make, always in under 24 hours and often in less than an hour. It was absolutely a wartime CEO footing. This happened for me across many projects. So the question of “what is your management style” or other similar questions is very contextual for me. My style is what is needed by the organization, in its current context and to deliver for the company. Based on interview feedback, I always felt that not only was this a weak answer, but it was not a “right” answer. Reading this book, I feel more confident that it is “my” answer.