Over the next few articles, I’ll talk about my experience becoming the engineering manager of the Go team and leading the team through several important transitions: from a focus on internal Google users to external Cloud users; from an engineering team of ~20 to a cross-functional team of ~50; and from an engineering-led strategy to one informed by product needs, business concerns, and UX research.
2016 was a complicated year. In March, I started managing the full Go team. In April, we moved our family to a new neighborhood in Brooklyn. In November, Donald Trump was elected president of the United States. But my 2016 started with the loss of my little sister, Shama, to suicide. Shortly thereafter, my wife Mandi and I started seeing a therapist together to process our grief and the challenges we were navigating together. Today, I am a much better husband, father, friend, colleague, and manager than I would have been without that therapy.
I share these personal details to highlight that each of us are living and working in a broader context of love and loss and hope and frustration. While most of my professional growth prior to 2016 was technical, most of my growth since then has been in better understanding people, both as individuals and as collectives, and how we can succeed together.
I never wanted to be a manager. I love coding, designing systems, iterating on APIs, coming up with the right names for things, and building useful tools that “just work”. But in 2013, the Go team was low on “management bandwidth”, so I accepted the role of Tech Lead Manager (TLM) of the 6-person team developing Google’s internal integrations for Go. At Google, TLM is a demanding role in which you continue acting as Tech Lead (TL) for the team while also serving as their Engineering Manager (EM). Google generally encourages people to specialize in either the individual contributor or manager tracks, but TLM can be useful as a transitional role to determine the right fit.
By 2016, Russ Cox and I were already working closely together to set goals for the entire Go team. So when our EM at the time decided to move on, I was offered their role. Overnight I went from 6 direct reports in the US to 20 direct reports distributed across North America, Australia, and Switzerland. By November, that number would rise to 25. It would take another 3 years to bring my direct reports back down to 6, though by then my org had grown to over 40 engineers plus a dozen cross-functional partners.
Systems thinking helped me transition from designing computer systems to leading organizations. I’ve always loved systems, particularly those we see in the world around us. As a student, I focused my research on distributed systems. At Google, my technical work was building storage and data processing systems in C++, then creating the tools and libraries to enable developers to build such systems in Go. I loved it all. (I recommend Thinking in Systems by Donella Meadows.)
As a manager, I realized that many of the challenges we designed for in distributed systems also occurred in developer organizations, and even the solutions were somewhat similar. Project planning resembled programming in that we had to decompose large problems into smaller ones that could then be pipelined and parallelized. Unlike programs, projects “execute” only once, and the “execution environment” (the team!) changes dynamically (not unlike a multitenant system with component failures). We could reduce the risk that a project would be stalled by an individual absence by distributing the work over more people (eliminating a “single point of failure”), although this adds coordination overhead (as in replicated systems). Replicating knowledge across people pays off in future projects, provided we assign work to take advantage of that knowledge (locality-aware scheduling).
But there’s a key difference between computer systems and organizations: we’re talking about people, not computers. People have career ambitions, financial needs, and disagreements. People are intelligent and take action to make their work better not only for themselves but for those around them. People cannot and should not be “programmed”—instead, the “system” should establish the common values and practices that enable people to work well together. This is more like “programming through agents”, which is far less deterministic than traditional programming, but much more resilient, provided the system proves sufficient slack for adaptation.
My next realization was that the system of our team operated within the much larger system of Google, the company. As Google adapts to change, so must each organization within the company. In 2013, Google entered the public cloud business with GCP, and by 2016, Go had clear momentum as the language for open source cloud infrastructure projects and cloud native applications. Meanwhile, Go’s growth within Google was slowing. It was time for a change.
When I became Go’s engineering manager, Russ Cox continued to serve as Go’s tech lead, and Steve Francia joined as Go’s product manager. Together we prepared a pitch to Google’s leadership in 2017 to pivot Go from growing internal adoption to growing usage on cloud. The pitch included data we had on Go’s adoption in several companies (based on conversations and public articles) as well as Go usage data on GCP (based on API calls).
The pitch went over well, and the Go team was funded to grow substantially in 2018. When Thomas Kurian joined in 2019, Google moved Cloud to its own organizational unit, and Go moved into Cloud. This began Go’s next chapter as part of a product-driven business focused on serving paying customers, generating revenue, and achieving profitability. As a free open source programming language, this was … interesting.
Sameer Ajmani 