‘Some people are Manhattan Project-style leaders and others are more Apollo Project-style. You kind of oscillate between the two but lean more towards Apollo Project.’
This is how one of my weekly, walking 1:1s with our CEO started and it caught me off guard. Was this a compliment, a criticism, or just an observation? It took some time but I eventually realized that he saw we were conflicting in some areas and it was due to our different management styles. Using the Apollo and Manhattan projects as a way to illustrate those differences was quite novel, and I’ve had time to reflect on it as I continue to refine how I communicate and provide feedback to my managers.
The Apollo program, also known as Project Apollo, was the third United States human spaceflight program carried out by the National Aeronautics and Space Administration (NASA), which succeeded in landing the first humans on the Moon from 1969 to 1972. The Manhattan Project was a research and development program during World War II that produced the first nuclear weapons. The Manhattan Project began modestly in 1939 but grew to employ more than 130,000 people and cost nearly US$2 billion, equivalent to about $23 billion in 2019. Apollo is often associated with a small and scrappy approach to tackling a complex endeavor, while the Manhattan Project is often noted for a more bureaucratic (yet equally successful) style.
A study in conflicting styles
One of the most enjoyable times in my career journey was the time I spent helping to build Heptio, which was eventually acquired by VMware. I was one of the first ten employees and had the challenge of trying to build the engineering team while also navigating the product direction with the founders.
The product vision was both broad and deep and is currently being realized in VMware’s Tanzu portfolio of products. At Heptio, we were building the precursor to VMware Tanzu Mission Control, which at that time I unimaginatively called Heptio Cloud. Although we had big ideas around policies, conformance, showback, and providing a single pane of glass for enterprise decision-makers, we also felt that we might be a tad early in the market for that kind of product. Still, we knew that our end state was to be a product company and not a service provider.
My strategy to move the product forward, and keep the fledgling engineering team motivated, was to have us start building an extensible shell with a minimum of functionality. We were already building a core set of open source projects such as Sonobuoy and Velero, and they would most certainly be the core features of Heptio Cloud that we would enhance with enterprise-specific functionality for paying customers. With that understanding, I could establish an initial roadmap while we continued to gather valuable information from our customers that would drive future product functionality.
Our core workflow revolved around a component called Extension Manager. Almost all product functionality would be delivered via modules called extensions. These extensions would be securely installed from a Heptio registry directly into a customer’s Kubernetes cluster. Once installed, administrators would be able to configure which subsets of the extensions capabilities would be enabled within the cluster. While there were plenty of details that would need to be addressed to do this securely, the initial goals were around end-to-end implementation of the workflow with Sonobuoy as the first extension.
Scoping this level of initial development was critical in focusing early engineers’ efforts. It was also crucial in developing a story that could be used when recruiting new engineers. We were in heavy growth mode at that time and most of my week was spent on Zoom calls with potential hires. Most engineers, and especially those in the infrastructure software space, wanted to know what they’d be working on, and what were the hard problems to be solved. Since we were not yet at product-market fit, I had to rely on both the broad strokes ideas for Heptio Cloud as well as the specific Extension Manager workflow for my sales pitch. To be fair, I also had the unique advantage of having two-thirds of the Kubernetes creators being founders of the company. That alone worked well for some candidates, but most specifically wanted to know what they would be working on.
While this purposely incremental approach worked well for what I was trying to achieve, it fell short in some regards with the founders. They were happy that progress was being made and that they could see tangible results. However, it didn’t map to their mental model of product development based on their histories at places like Microsoft and more recently, Google. There was an expectation of more grandiose functionality delivered sooner, even though there already was an acknowledgment that those features were ahead of the market.
These mismatches in expectations extended to growing the team as well. Like many other startups, we publicly expressed our desire to provide a diverse and inclusive environment. As a Black man leading engineering, I took those statements seriously, especially as I was also the recruiter for a period of time. My hiring strategy was to source broadly and not to over-index on specific companies as sources for engineers. While certain companies were definitely going to have engineers that matched our ideal profile, I wanted to avoid us being inundated with the thinking and culture from any one company.
The founders did not disagree with this approach in general, but their preferences tended towards the Google and Red Hat profiles for engineers. This also extended towards engineering managers. I would tend to source and interview startup-scale managers that were scrappy and comfortable in dealing with ambiguity. The founders often sourced engineering managers from larger companies, frequently Microsoft and Google. While there was no issue with respect to where people worked, there was an issue around their expectations. While our founders had incredibly impressive backgrounds, the reality was that Heptio wasn’t Google. We hadn’t built a product yet much less found product-market fit. Yet, many of these candidates had expectations of us that were not in line with where we actually were as a company. And, at times, I felt our founders had a similar impedance mismatch in expectations.
In one specific instance, I wanted to hire an Apollo Project-style engineering manager. At that point, I needed to delegate some first-line management duties so I could focus on hiring, and potential partnerships and acquisitions. The candidate I found could do the job I needed at that time. He may not have grown with us over time, but he certainly would have given me leverage for the next year or two. My Manhattan Project-leaning CEO disagreed and vetoed the hire.
I was frustrated by this primarily due to the fact that I wasn’t going to get the help I needed at that point. As we interviewed more Manhattan Project-style managers with mismatched expectations, that frustration grew. Months later, in a 1:1, my CEO admitted that he now better understood what I was trying to do and that he should have let me hire that manager. He even asked whether the person was still available and if I should try to recruit him. Although that ship had sailed, I appreciated that my manager reflected on the situation and admitted he was wrong. My respect for him grew and we both learned how to adapt to each other.
Conclusion
Leaders in any organization are going to have different, and often conflicting, styles. The key is to recognize this, acknowledge it when conflict arises, and collaborate on mutual goals. Equally important is to map leadership styles to both the projects being undertaken and the stage that your company is in. Early in a company’s existence, you will probably benefit from more Apollo Project-style leaders. Later in a company’s existence, you may need to lean on Manhattan Project-style leaders more. Throughout the company’s lifespan, you’ll need both, so as you identify these leaders and their dominant styles, nurture and use them wisely.
