Notes on hiring a Foundation Eng leader.

I’ve recently had a few folks reach out for advice on hiring a Foundation Engineering leader based on my supporting that organization at Stripe. The first challenge with the question is defining what “Foundation Engineering” even means!

I joined Stripe to work with the “Sys” engineering group, which was short for “Systems,” and there were about thirty folks in Sys within the larger infrastructure organization that had… maybe sixty folks working across data, developer tools, financial infrastructure, and so on. We adopted the Foundation title about a year later when the engineering organization did a reorg that joined Sys with Data and Developer Experience, and moved away from having an explicit Infrastructure organization. The Developers group, focused on external developers, joined us a bit later, and at the point I left the overall group was about two hundred and fifty folks.

The major takeaway being that while the scope of a small engineering organization is a relatively pure concept, the boundaries of a larger organization are typically defined by circumstances, constraints, and chaos. The Foundation organization I worked with was broad and pragmatic, and it’s dangerous to pattern match hiring leaders before understanding the details of the role you’re hiring.

To focus your search a bit, there are three questions I’d recommend spending time with:

1. Is your business fundamentally enabled or differentiated by the technology you need this team to build? (For example, I occasionally get to chat with Jasmine Tsai who leads engineering at Mux, and streaming technology is their product rather than technology that enables their product.)
2. Is this a one-domain leader or a multi-domain leader? (For example, are you looking for a data engineering leader, an infrastructure engineering leader, a developer experience leader, or someone who spans multiple domains?)
3. If your organization scales rapidly, will you hire under or over this particular hire? (Same example as for multi-domains above.)

If you answer yes to the first question, then good news: you shouldn’t be hiring a Foundation leader, but instead a domain expert with experience in product engineering plus whatever your specific technological need is. I’d even argue that you probably shouldn’t be hiring a people manager here at all, but instead a staff-plus engineer. Even if you are absolutely certain you need a people leader, I’d push you to think through your reasoning once more.

If you’re still convinced you want a Foundation engineering leader, then it comes down to a choice between a:

1. systems operator who is great at operationalizing, scaling, and structuring systems, and brings structure to chaos while working with eight to 30 engineers,
2. organization builder who is a systems thinker, reasonably experienced at the fundamental domain problems but trusts expertise of others (e.g. not a solo architect who also views themselves as a people leader), and an effective hiring manager for 20-plus engineers

If you want a multi-domain leader or someone who will hire underneath themselves, you probably want the (organization) builder. Otherwise you probably want the (systems) operator. If you want a builder for a team below twenty, they’re probably going to either (1) struggle to make an impact or (2) scramble to hire into the size they’re effective in.

A few thoughts on hiring for these roles, as well as selecting which of the roles to hire:

• System thinker who is reality-based. I used to believe that systems thinking was the fundamental skill for the sorts of work that gets bundled into Foundational Engineering roles. I still believe it’s essential, but I’ve worked with too many systems thinkers who prioritize how things should work over how things actually work. When these folks run into trouble, they often focus on rejecting reality rather than refining their model. This doesn’t work! When system thinking and reality conflict, reality is always right, and rejecting that is a sign of poor judgment
• An operator’s job is providing a predictable environment for product engineering to create a business. Young organizations have mundane infrastructure problems and the operator’s job is to deploy mundane solutions to those mundane problems. An extraordinary infrastructure platform in a young organization will be mostly invisible, creating a solid foundation for product engineering to build a product (which in turn allows the wider company to build a business). Prefer folks who are willing to compromise infrastructure purity for medium-term product velocity. I’ll note that “medium-term” is load-bearing in this sentence, and explicitly different from short-term (this month) and long-term (next year)
• Many successful operators have exposure to Site Reliability Engineer practices. The core SRE practices around creating operable systems and software are invaluable for the operator’s work: things like effective on-call rotations, running incident reviews, determining who owns which pagers, and so on. I stop short of strongly recommending SRE experience primarily because some organizations indoctrinate their SRE teams into a fixed mindset about how things “must work” and that mindset fosters idiomatic leaders that struggle to partner with others, typically to the detriment of product engineering velocity (which is generally the most important thing they’re supposed to enable)
• The builder’s job is balancing business goals against developer experience. As the organization gets larger, the challenge shifts to offering the best developer experience you can to internal engineers while also meeting your security, compliance, cost, and stability obligations. The fundamental challenge is maintaining a good developer experience in the presence of these business constraints, and while also scaling your organization
• Prefer builders who’ve been an operator. It’s very hard to operate an effective organization if you haven’t worked within an organization to understand how it feels to be operated upon. A builder who’s been an operator will build more trust with less thrash
• Prefer builders with software engineering experience. I’ve personally found that the empathy and experience from working as a software engineer is very valuable in the builder role. As always, you can absolutely build a team that complements a particular skill gap, but this is so fundamental to the builder role that I think you’d end up implicitly two-in-a-boxed if your candidate lacks this experience (as an aside, I personally think the linked article undersells the challenges of the two-in-a-box model)
• Avoid builders who lean on hiring as their first tool. Hiring is essential, but it’s also the least creative way to solve capacity problems. It’s a sign of inexperience or inflexibility to lean on hiring as the first tool to create capacity. Hiring is absolutely an essential tool to use after you understand your constraints, but it’s a concerning starting place

That’s enough writing fodder for folks thinking about the Foundation leadership profile they want to hire, so I’ll wrap it up with two final thoughts. First, it’s fairly challenging to find folks who do well on all dimensions of the builder profile, and they’re likely already considering quite a few opportunities. Second, even if you feel confident because your team includes an operator who you hope will grow into the builder role, many operators struggle transitioning to builders without active support broadening their skillset.

As is usually the case, there is no free lunch.