How Companies Build AI-Native Engineering Teams
Differences between OpenAI, Anthropic, Shutterstock, and other AI-native engineering teams.
This week’s newsletter is sponsored by Faros.
Most engineering teams have adopted AI. Fewer can say what it’s producing. Token consumption is exploding.
Engineering leaders must know if spend goes to productive work or on agent retry loops on trivial tasks. The flow shifted from token to shipped outcome.
Faros’s Engineering World Model connects your teams, tools, repos, and workflows.
It observes where every token went and what shipped
It diagnoses the root cause behind every efficiency leak
It optimizes by routing models, skills, & context proven on your own code
Thanks to Faros for sponsoring this newsletter. Let’s get back to this week’s thought!
Intro
Interestingly, almost every company I talk to these days has a different engineering org & team structure.
2 years ago, the org structure was fairly standardized, with 2-pizza cross-functional teams and an engineering manager leading the team. Then a Director managing 2-4 engineering managers, and reporting to a VP, which reported to the CTO.
These days, everyone is figuring it out as they go, making adjustments and seeing what may work and what not.
I’ve seen both very traditional and some extremely unique engineering org structures this year.
In today’s article, I am sharing the differences between Anthropic, OpenAI, Shutterstock, and also additional honorable mentions (some are very unique setups).
Let’s start!
How OpenAI builds AI-native engineering teams
I talked to Thibault Sottiaux, who is heading both ChatGPT and Codex, earlier this year, about how they are building AI-native engineering teams.
Interestingly, they mostly hire Software Engineers, who can build projects end-to-end, and also own projects from an idea all the way to when the project is launched and then also maintained.
Teams are separated based on specific projects, and mostly consist of 2-4 engineers. The ratio between manager-to-engineer is very similar to PM-to-engineer, which is around 1:30.
Thibault also mentioned that in the Codex department, there is even a 1: 40 PM-to-engineer ratio.
Engineers are expected to wear many different hats, and they work with a PM or a designer when there’s a need for it. Every project also has a DRI (directly responsible individual), who owns the project. Basically, being the Tech Lead making decisions on the project and doing stakeholder comms.
Additionally, the teams have as few meetings as possible, they only meet when they need to align on a certain thing. No Scrum, Kanban, or daily meetings, just teams focusing on executing their project and collaborating on it.
That’s also the reason why a lot of them prefer to work on-site, as they work on that project similarly to a hackathon-style, instead, it’s not a “throwaway” version, it’s an actual product they are working on.
To learn more about how OpenAI builds AI-native engineering teams, read the full article:
Let’s go to the next one.
How Anthropic builds AI-native engineering teams
I’ve recently had the pleasure of speaking with Katelyn Lesse, Head of Platform Engineering at Anthropic, and it’s been very interesting to learn how they are building AI-native engineering teams.
What’s particularly interesting is that they have a completely different mindset when it comes to building engineering teams than OpenAI.
OpenAI works with small teams of 2-4 engineers, while Anthropic still advocates for a traditional 2-pizza cross-functional team with 5-8 engineers, a PM, a Product Designer as part of the team, and an Engineering Manager leading the team.
The main difference between a traditional team and Anthropic’s AI-native team is that there is no dedicated QA engineer. The QA work is expected to be done by anyone inside the team.
Also, the biggest difference is that any Software Engineer can be a tech lead, while in a traditional team, you mostly have 1 tech lead.
That’s how they can run up to 5 projects simultaneously in the team, instead of traditionally 1-2 projects, as the Tech Lead doesn’t have the capacity to lead many different projects simultaneously.
Additionally, they are big advocates for Product Managers, especially TPMs, product managers who really understand the underlying tech as well. Their reasoning is that with many projects happening simultaneously in the team, there’s a bigger need for PMs.
And they are even thinking of having more than 1 PM in every cross-functional team. It’s a completely different mindset than OpenAI, where they have 1 PM for about 30 engineers, while Anthropic has 1 PM for about 5-8 engineers and potentially the ratio getting lower as well.
They also have a specific role inside their company called Prod Ops (product operations), with the role of making systems, processes, and tools more effective so PMs and teams can make better decisions more quickly and achieve better results.
Another interesting thing is that ALL of their code is AI-generated. Instead of manually changing the output of AI-generated code based on the prompt, they provide feedback and guide the AI agent to the correct outcome (required standard).
They see this as a much better workflow than continuously changing the code themselves manually. That’s also the reason why Katelyn believes reviewing AI-generated work has become one of the most valuable engineering skills.
To learn more about how Anthropic builds AI-native engineering teams, read the full article:
How Shutterstock builds AI-native engineering teams
I’ve talked to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock, very recently, and he shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams.
I’ll be sharing a lot more info about it in a future article, but today, I am sharing some of the important points, especially in comparison to how OpenAI and Anthropic build their teams.
Their AI-native engineering team structure is a lot more similar to Anthropic’s. They also work in a 2-pizza team setup with 5-8 engineers as part of the team, and an engineering manager leading the team.
The big difference is that they have about 1 PM for every 2 teams, so the ratio is about 1 PM for 10-15 engineers. Also, product design is not a part of the cross-functional team, and it’s being utilized when there’s a need for it in part of the projects that the teams are working on.
Another big difference is that they have 1 dedicated Tech Lead inside the team, who is responsible for everything technical regarding the projects, but there can also be additional owners of certain projects inside the team, but primarily, one person is the main tech lead of the team.
One important insight that Jefferson mentioned as well is that their product teams work within 2-week sprints and are using Scrum as their way of working, which is the same as traditional teams.
So, they have all the meetings as traditional teams: daily meetings, planning, retrospective, etc. And there’s also a sprint demo meeting at the end of every sprint.
Additionally, at Shutterstock, they also have dedicated ML engineering teams, and they work a lot more differently than product teams.
These teams work within 6-week “bet cycles”, where they focus on achieving a certain goal within the 6 weeks. No Scrum or Kanban.
The reason for quite a different workflow than with product teams is that ML work is a lot more unpredictable, and you can’t really promise certain outcomes in X amount of time. You see what may be possible based on the research that you do.
As mentioned above, stay tuned for the full article on how they are building AI-native engineering teams, which will be published in a future newsletter article.
Other honorable mentions
Let’s also go through some of the structures from other companies.
PortKey
I talked with Vrushank Vyas, Head of GTM and CS, Portkey, earlier this year. Interestingly, they have about 24 engineers, which are all product engineers and no product managers.
Every engineer is expected to wear multiple hats, including being a Forward Deployed Engineer, Customer Support, Product Manager, and, of course, Tech Lead.
Their team structure is a lot closer to what OpenAI does, and their expectation is that every engineer can own a project end-to-end.
And also, very similar to what OpenAI does regarding hiring, they like to hire strong generalists who can build across many different tech stacks, or extreme specialists who are really good in one specific tech.
To learn more about how PortKey works, read the full article:
Weave
I talked with Andrew Churchill, Co-Founder & CTO, and Adam Cohen, Co-Founder & CEO, when I visited their offices in San Francisco.
They have a team of around 10-15 engineers, and all are considered to be product engineers who can wear many different hats and own projects end-to-end.
So, similarly to PortKey, Weave’s AI-native focus resembles what OpenAI is doing.
To learn more about how Weave works, read the full article:
PostHog
Works within teams of 1-3 engineers, with an assigned Team Lead for every team. The Team Lead also reports directly to the VP of Engineering, no middle managers in between.
Telnyx
Telnyx’s engineering org consists of 200 engineers, 0 engineering managers, and 1 VP of Engineering. They took the word “flatter org” to the extreme.
Unfortunately, I don’t have the information on how their teams are structured, but it’s interesting to note how unique their setup is. 1:200 IC to manager ratio.
Last words
Companies seem to have very different engineering org structures and teams these days, and it feels like every company I talk to is doing something differently.
The main takeaway is that there is no perfect engineering org structure at this time. It all depends on what works for a specific organization and team.
So, that’s my advice as well, always look at what’s best for your team and organization, don’t just try to copy some other org blindly.
And doing small changes is the way to go in my opinion. Do a small change and see how it goes, and if it’s for the better, keep it, if not, revert it.
You got this!
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Interested in sponsoring this newsletter? Check the sponsorship options here.
Check out my book “The Multiplier Mindset” coming out later this year, here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
I'm currently part of an AI task force, so we're still learning, experimenting and finding the right balance.
The whole field is completely new, so the playbooks are being written at the moment.
Great cross-section, seeing OpenAI's 2-4 person teams next to Telnyx's 200-engineers-zero-managers is genuinely useful. One thing the sample can't show, and I'd want your read on it: every company here is product- or AI-native, none with a regulator in the room. From the financial-services side, some of what reads as "legacy ceremony", segregation of duties, change approval, audit trails, isn't drag, it's the control. So the question your piece opens for me: which of these AI-native moves are strictly better, and which are only affordable when nobody can subpoena your deploy log? Katelyn's point that reviewing AI-generated work is now the key skill lands even harder there, it's not just productivity, it's the person who has to defend the output when asked. Would make a sharp follow-up.