This newsletter is sponsored by Honeycomb.
Live Masterclass + Q&A: The Business Case for Observability
Observability is a significant engineering investment. On September 2, Honeycomb’s Liz Fong-Jones, co-author of Observability Engineering, will break down how engineering leaders can evaluate that investment, connect observability to meaningful outcomes, and build an evidence-based case for what comes next.
In this virtual masterclass session:
Evaluate observability against engineering outcomes
Identify gaps between monitoring and effective observability
Build an evidence-based case for future investment
Thanks to Honeycomb for sponsoring this newsletter. Let’s get back to today’s thought!
Intro
I recently had the pleasure of speaking with Eric Sammer, Distinguished Engineer at Redis (formerly CEO Decodable).
We talked all about how Redis builds AI-native engineering teams, their process, culture, and also how they do hiring.
Interestingly, their engineering culture revolves heavily around performance. Not surprising, though, as performance plays a huge part in Redis’s products, and they work within pods of 3-4 engineers, each with a feature lead.
This is an article for paid subscribers, and here is the full index:
- What does AI-native mean at Redis?
- The size of Redis’s product&engineering org
- Redis’s AI-native teams structure
- Their meetings and process
🔒 How are they using AI to be more productive?
🔒 They are measuring token spend, but how effective the spend is is the hard part
🔒 Redis’s engineering culture
🔒 Hiring process for a new engineer
🔒 Last words
If you haven’t read the articles on how OpenAI, Anthropic, and Shutterstock build AI-native engineering teams, I highly recommend doing so:
Let’s start!
What does AI-native mean at Redis?
As with every article about AI-native teams, I always want to understand what AI-native really means for a particular company, and this is what Eric mentioned:
I think it’s similar to “cloud native”. It’s a term people use to mean almost everything and nothing.
To me, being AI native means treating AI as a default way of working, not as something you simply add on later.
The question I like to ask is: If we were building software engineering from scratch today, and AI already existed, what would it look like? How would we build teams, processes, tools, and technology differently?
That’s what AI native means to me. And I think cloud native is a good parallel.
Especially interesting is the parallel to being cloud native, which resonates, because when companies started to shift from on-prem to cloud, quite some time ago, that term got quite similarly sensationalized as AI-native is today.
The size of Redis’s product&engineering org
I was quite surprised to hear that Redis has about 350-400 people across the product and engineering org. They really came a long way from when Redis was just an open-source project started in 2009.
Engineering makes up the majority of that headcount, and around 20-25 people are in product. That’s about a 1:15 PM-to-engineer ratio. Very similar to what Shutterstock does. While Anthropic has a 1:8 ratio and OpenAI has 1:30.
One of the more interesting changes Eric has mentioned is that, looking from 2 years ago to today, there’s a lot less specialization of engineers, and a lot more engineers who are good generalists.
I wrote about this exact trend in this article: Become a Great Generalist or Extreme Specialist.
And he also mentioned that PMs don’t just work on creating PRDs or designing in Figma, but they actually build working prototypes in React and Claude Code.
Redis’s AI-native teams structure
They work within small pods of 3-4 engineers. Every team has a feature lead, which is basically a tech lead, leading the technical implementation of a certain project that the team is working on.
And these teams work with other teams, and people e.g. PMs, designers, customer support etc. when needed.
This is very similar to how OpenAI builds their AI-native teams, just the difference is that the feature lead is called the DRI (directly responsible individual), for both technical and product/business as well.
Eric also mentioned that the teams have support from higher-level engineers e.g. Staff, Principal and Distinguished engineers when needed.
These higher-level engineers are normally also called service leads, they lead specific larger functionalities and ensure that the teams who are building these related projects are aligned with the standards.
Their meetings and process
These teams can generally decide what the best way is to handle meetings and the overall process. Some of these teams work within 2-week sprints, and every team decides how many meetings they need.
Eric mentioned that this is something they are still figuring out and evaluating what the best way to go is, and he sees that alignment is more important than ever. This is what he mentioned:
I’ll be honest, I don’t think we’ve fully figured this out yet. It’s something we’re constantly evaluating to see if there’s a better way to work.
In the past, the biggest bottleneck was writing code, testing it, and getting it into production. Now, the bigger bottleneck is how quickly teams can align and make decisions. The more people you have, the harder that becomes.
That’s why I think frequent communication, like daily stand-ups, is more important than ever. They help teams spot when something is off, when people aren’t aligned, or when they don’t understand why we’re building something.
These stand-up meetings are also less about the technical details and more about timelines, priorities, and cross-team dependencies these days.
Planning also needs to move much faster. Some teams still use traditional 2-week sprints, but a lot can change within those 2 weeks.
Roadmap and prioritization decisions used to happen every couple of weeks. Now, they can happen every few hours. A team might finish something much faster than expected, and suddenly you need to figure out what they should work on next.
My feeling from talking with many different teams is that nobody really has it figured out, and everyone is learning as they go, even Anthropic and OpenAI, they are constantly evaluating and adjusting how they work.