What is Leverage Engineering?

I recently saw a tweet from Astasia Myers mentioning Leverage Engineering, describing it as a new term that would go mainstream in 2025. So, I thought it would be fun to dig into what this is and see if it is anything new and exciting or if it’s a new name for an existing engineering role.

Leverage Engineering at OpenAI

Based on my research, it seems that OpenAI only currently uses this term to describe one of its teams. A quick job search on LinkedIn doesn’t bring back any roles with this title; I can only see open roles directly on the OpenAI careers page. 

It’s not a new team – a LinkedIn post from June 2024 mentions roles on this team. So what might this team be? Let’s dig into the job description to see if I can work it out.

Leverage engineers fix internal bottlenecks

Based on a description of this team by Brock Whittaker:

OK, so this team looks at internal processes and helps fix them. Clarified by this post from Dylan Vassallo:

This role is not new. Plenty of large companies have such teams whose goal is to look across the organization, find bottlenecks, blockers, and other things that are limiting productivity, and fix them.

I first saw this back in 2001 when a friend of mine was tasked with optimizing productivity at the scientific software house we worked at. We had a massive C++/MFC app, with some files that when changed caused you to need to rebuild the entire application, taking over an hour! 

During that hour there was nothing you could do – your machine was almost locked up compiling. He made it so that you rarely needed a rebuild, saving countless hours of developer time. For those C++ nerds in the room, he did it mainly using the Pimpl, or Cheshire Cat idiom!

More recently, another friend was working on a dedicated team at Google also looking at improving developer productivity by reducing downtime and bottlenecks. 

This team was a developer experience engineering team, focused on improving the internal experience for developers. Think optimizing the build time of sites like YouTube to again save thousands of hours of developer time.

This role is not new. Plenty of large companies have such teams whose goal is to look across the organization, find bottlenecks, blockers, and other things that are limiting productivity, and fix them.

I first saw this back in 2001 when a friend of mine was tasked with optimizing productivity at the scientific software house we worked at. We had a massive C++/MFC app, with some files that when changed caused you to need to rebuild the entire application, taking over an hour! 

During that hour there was nothing you could do – your machine was almost locked up compiling. He made it so that you rarely needed a rebuild, saving countless hours of developer time. For those C++ nerds in the room, he did it mainly using the Pimpl, or Cheshire Cat idiom!

More recently, another friend was working on a dedicated team at Google also looking at improving developer productivity by reducing downtime and bottlenecks. 

This team was a developer experience engineering team, focused on improving the internal experience for developers. Think optimizing the build time of sites like YouTube to again save thousands of hours of developer time.

Leverage Engineers use the product and give product feedback

Looking again at the description from Dylan:

Leverage Engineering's mission is to apply OpenAI's latest technologies across a wide variety of business use cases (think support, sales, workplace operations, etc.) and to continuously reincorporate our learnings back into the company's R&D. We've built an automation system that's used thousands of times per day across a dozen teams and we have ambitious plans to scale it up.

This is product feedback, also known as dogfooding, from eating your own dogfood (also referred to as drinking your own Champagne). This is something all tech companies should do – you should always be customer number one. 

At Pieces, we use Pieces to help us build Pieces. This allows us to try out the new builds before they go public, and really dive deep into how Pieces can be used so we can create the best experience for our users.

This is reiterated in the OpenAI job description:

The Leverage team is scaling OpenAI with OpenAI. We apply our latest models to real-world problems in order to assist with or automate work across the company—then share what we learn back to the broader product and research teams. We’ve built an ecosystem of automation products that’s applied everywhere from customer operations to workplace to engineering.

Again, this concept has been around for years. 

At Microsoft for example, they build systems, that run on top of Azure, so they are constantly using their own cloud platform to build out internal and external applications, feeding their learnings back to the Azure platform team. 

AWS was built literally to help the rise of Amazon, so they are using their own cloud platform first and providing guidance back to the engineering teams when they hit problems. Linux engineers use Linux, the C# compiler is written in C#, and so on.

So what actually is Leverage Engineering?

Based on this research – Leverage Engineering is just a new name for an old role. Looking for ways to improve the internal engineering by dogfooding your own tools and giving relevant feedback based on this dogfooding.

Are you on this team, and if so are the results of my research correct? Are you on a team called Leverage Engineering at another company? Let me know on X, Bluesky, LinkedIn, or our Discord. And don’t forget to try Pieces, where we all spend part of our time as Leverage Engineers!