Engineering Leadership

Engineering Leadership

How Shutterstock Builds AI-Native Engineering Teams

Insights from my conversation with Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock.

Gregor Ojstersek's avatar
Gregor Ojstersek
Aug 20, 2026
∙ Paid

This newsletter is sponsored by Sonar.

Cut AI coding token costs by up to 36% with Sonar Vortex

Sonar Vortex operates directly within your AI coding agent’s reasoning loop to supply architectural context before any code is written.

By verifying output in real time, it empowers you to build safer, higher-quality software while significantly reducing your LLM spend.

  • Slash Token Costs: Testing showed reduced LLM token consumption by up to 36% on coding tasks.

  • Reduce Bugs: Lowered software defects by 92%.

  • Smarter AI Context: Equip your AI agents with deep architectural context before they generate code.

Make your agents more effective

Thanks to Sonar for sponsoring this newsletter. Let’s get back to today’s thought!


Intro

I’ve been using Shutterstock’s platform for quite some time now. Whenever I needed a stock image, it was usually one of the first places I’d look.

But in recent years, Shutterstock has been adding a lot of new features and capabilities, especially around AI. It seems they went from focusing primarily on the stock content business to a company focusing a lot more on AI/ML.

A similar transformation I’ve seen with Canva as well (just in a different industry).

That was one of the reasons why I was excited to talk with them and learn how they think about building AI-native engineering teams.

I’ve recently had the pleasure of talking to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock.

He shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams, which I am sharing today in this article.

This is an article for paid subscribers, and here is the full index:

- What does AI-native mean at Shutterstock?
- How big is Shutterstock’s engineering org?
- The structure of their AI-native engineering teams
- The process of AI-native engineering teams
🔒 How are their engineers using AI?
🔒 Advice for writing good prompts
🔒 How do they track token spend?
🔒 What makes an elite versus average engineering team?
🔒 Shutterstock’s engineering culture
🔒 Being vocal and having an opinion is a very important trait
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI and Anthropic build AI-native engineering teams, I highly recommend doing so:

How OpenAI Builds AI-Native Engineering Teams

How OpenAI Builds AI-Native Engineering Teams

Gregor Ojstersek
·
Feb 18
Read full story
How Anthropic Builds AI-Native Engineering Teams

How Anthropic Builds AI-Native Engineering Teams

Gregor Ojstersek
·
Jul 1
Read full story

Let’s start!

What does AI-native mean at Shutterstock?

This has now become a standard question that I ask different companies, and the reason is that “AI-native” means different things for everyone. Here is what it means for Jefferson and Shutterstock:

AI-native means that AI is integrated into everything that we do, all the way from coding and architecture to design, and also providing a good experience to our customers.

An interesting thought that he mentioned is that they want to provide the same kind of experience their people have internally using AI tools to Shutterstock’s customers as well. With AI workflows and experiences on their platform.

How big is Shutterstock’s engineering org?

Jefferson mentioned that they have been flattening a bit of their organization over the years, and they want to have an organization that is engineering-heavy.

They have about 350 engineers inside the org, across a lot of different time zones and countries. Their product org is kept purposely small, as they want their product managers to be working across different engineering teams.

And designers work more directly with product managers. The goal is to have the engineering teams autonomous as much as possible, and then bring in additional people when needed.

The structure of their AI-native engineering teams

Their AI-native engineering team structure is 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 utilized when there’s a need for it in parts 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.

Jefferson also mentioned that not every engineer is expected to be full-stack, the goal is to have all different skill sets covered in the team, so the team can be as independent as possible.

In practical terms, that means that some engineers may be a lot better in frontend, some better in backend, and then some better in DevOps, AI/ML, etc.

And one important thing as well is that they encourage their engineers to change teams if that’s their preference, in order to grow and develop various skill sets. To quote from Jefferson:

I can think of at least a dozen folks internally who have spread their wings and moved into different teams, picked up new languages, started working on front-end when they were back-end engineers, etc., and really developed their careers here.

The process of AI-native engineering teams

Their product teams work within 2-week sprints and use Scrum as their way of working, which is the same as traditional teams.

So, they have all the meetings like traditional teams: daily meetings, planning, retrospectives, 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 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.

How are their engineers using AI?

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2026 Gregor Ojstersek · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture