This week’s newsletter is sponsored by Larridin, an AI-native developer intelligence platform.

How much should you spend on AI coding tools?

Larridin analyzed data from hundreds of engineering organizations to benchmark AI coding tool costs and find the budgeting approach that maximizes productivity without Tokenmaxxing.

Inside the research paper:

• Understand where AI coding budgets are headed

• What high-performing teams spend

• The formula to determine how much your team should invest

Get the whitepaper

Thanks to Larridin for sponsoring this newsletter, let’s get back to this week’s thought!

Intro

I am currently writing a book, The Multiplier Mindset: How to Move from Senior Engineer to Tech Leader in the AI Era (check out the early release on the O’Reilly website). Get also a 1-month free access to all the O’Reilly books here.

The book will feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:

• How they multiply others

• What makes them successful

• How they use AI

• Their advice to engineers and engineering leaders to thrive in the AI era

Today, I am sharing the case study of Jordan Cutler, Staff Engineer at Pinterest, which will be included in the book. Let’s introduce our guest author and get started.

Introducing Jordan Cutler

Jordan is a good friend of mine, a newsletter author, and a Staff Engineer at Pinterest. We have known each other now for more than 3 years and have done a number of things together, including 2 articles in this newsletter. You can read them here:

How to Use Cursor AI to Build Side Projects Gregor Ojstersek, Jordan Cutler, and Sidwyn Koh · March 30, 2025 Read full story

Perfectionism - One of the Biggest Productivity Killers in the Engineering Industry Gregor Ojstersek and Jordan Cutler · July 28, 2024 Read full story

Today, he is sharing his journey from Senior to Staff Engineer at Pinterest and the 3 important dimensions of staff engineering, each filled with his personal examples at Pinterest. Definitely a must-read if you are looking to have staff-level impact.

Over to you, Jordan!

What stops Senior Engineers from becoming Staff Engineers

The engineers I’ve watched get stuck at Senior are the ones who keep pushing to be better at these:

• deeper technical skills,

• faster execution,

• more complex systems.

All good things. But Staff Engineering operates on dimensions most engineers never think about.

I had to learn this the hard way. I spent too much time heads-down on individual contributions before realizing that my biggest impact came from work that didn’t look like “engineering” at all.

I’m a Staff Engineer on the Web Platform team at Pinterest. Our mission is to create a world-class developer experience for over 200 web engineers. In practice, that means I work across 5-10 teams at any point, owning various developer experience metrics like build times, CI duration, documentation quality, and overall developer satisfaction.

Over the past 2 years, I’ve been figuring out what Staff Engineering actually looks like. Not from a textbook, but from seeing what works and what doesn’t.

The biggest shift most engineers can make is to think about these three dimensions:

1. Expanding your surface area

2. Influencing across teams

3. Building scalable systems

Here’s how each one played out for me.

1. Expanding your surface area

Nobody at Pinterest asked me to become the AI person. There was no “AI initiatives” line item in my job description.

But I could see AI was becoming an industry-wide shift, and there was a natural overlap with my work in developer productivity. So I started experimenting... a lot.

I tried different coding tools, tested workflows, and kept incrementally improving my velocity. Once I found what worked, I wanted to share it. But not only that, I knew other people would feel the same way, wanting to share what they found too.

So I started by checking with a friend who is also invested in AI, “Hey, do you think it’d be a good idea to set up a channel where everyone can share their AI learnings and how they’re using it?” Then, I started a group DM with him, a few managers, and other Staff+ engineers. I got a check from them and just did it!

I created the #how-i-ai Slack channel and said, “Hey everyone, share how you’re using AI here! There’s a big opportunity to learn from one another so everyone can be more productive.”

Before I knew it, there were 200+ people there within a day. I realized I hit on something big. A few months later, it now has 1200+ members, received multiple shout-outs in all-hands presentations, and is being incorporated into company-wide tooling.

This, along with answering questions, sharing what I know, and shipping multiple other impactful AI velocity tools, such as a scheduling tool for Claude, a documentation generator, a slide generator, and MCPs, led to even more opportunities.

One of our execs wanted to run a monthly demo highlighting key use cases to all of EPD orgs (engineering, product, and design). Because I had expanded my surface area, they reached out to me as the first demo opportunity. I put everything I could into that demo to make it excellent, and it paid off.

A few weeks later, the Chief Architect established an “AI Coding Pathfinders” group dedicated to improving velocity across the company. Because he knew me from the demo, I was invited to the group to lead one of our company-wide standards. It was the perfect intersection of what I was passionate about, good at, and making a huge impact.

But none of this was planned. I just started sharing useful things, and the opportunities followed. Now, other people reach out asking how they can build on top of the #how-i-ai channel for company-wide learning platforms. The channel created its own momentum.

Don’t wait for someone to assign you work. Create a space, seed it with value, and let it compound.

2. Influencing across teams

Pinterest had company-wide goals for improving page load times. We’d seen a slow regression over time, and there were noticeable gaps between web and mobile performance. Leadership figured there were optimization opportunities on the web side.

My first project at Pinterest was to audit the Search page, figure out what made it slow, and how much we could improve it. The Performance team, a sister team to ours, didn’t have bandwidth for deep dives into specific surfaces. They could track overall metrics, but nobody was doing the detailed work of figuring out why a particular page was slow.

I started by figuring out what users actually do on the page, then traced what happens under the hood from user action to page render, found where it gets slow, and estimated the improvement.

Then I’d bring those numbers to the team that owns the surface.

Not “you have a problem.” More like “you have a problem, it’s costing you X, and here’s what the fix looks like.”

This part is important and was a hard lesson I learned, because I didn’t start that way. Initially, I didn’t reduce the friction enough to drive action.

My initial set of audits was overly difficult for the team to figure out what they should prioritize and invest in and why, and they didn’t prioritize it. It was only after follow-up conversations that made it easier to understand and helping to reduce friction that they ended up prioritizing it.

For example, instead of: “JSON payload is 500KB, which is large,” I would say, “The search items response is 500KB, which is much larger than it needs to be for the user experience. A fix here can result in users seeing search results 100ms faster. We can reduce the payload by reducing the items we fetch in query parameters and normalizing the payload response.”

I focused on saying what was slow, why, and how to fix it. I wanted to inspire confidence that this can be better, and a fix doesn’t need to be overly complicated either.

Toward the end of the Search audit, I understood how to quickly identify the biggest opportunities, so I saw a chance to expand and do something similar across other surfaces.

I went to the managers of Home Feed and Pin Page (Closeup), our other highest-traffic pages, accounting for about 80% of all Pinterest traffic, and made a casual pitch: “I’m already auditing Search. Would you like me to take a quick look at your surface area, too?” It was an easy yes for them. Who wouldn’t want more opportunities to improve their surface?

Once they were bought in, I followed a similar process as before. I thought through the most common user flows, including those that spanned multiple pages.

For example, a common flow was a user clicking a Pin on the Home Feed to view it on a Closeup view. This helped me identify big opportunities, like realizing that when the user clicked Closeup, we could show the same medium-resolution image they were seeing before while the high-resolution one loaded.

Compare that to the current behavior: View medium res on Home Feed → click to Closeup → see background color while waiting for high-res image → see high-res image.

I listed each opportunity and even shared high-level implementation details for fixing them. The managers agreed with the priorities, and I became the advisor for multiple engineers across those teams.

Those improvements led to 30%+ performance improvements on their respective surfaces, and I learned a lot about how to drive impact across teams.

I wasn’t a Staff engineer when I did any of this. It was early in my time at Pinterest, and I was still a Senior Engineer. But this kind of work, influencing teams I didn’t belong to and driving improvements across surfaces I didn’t own, ended up being a big part of what made the case for my promotion.

Don’t just identify problems. Offer to help fix them. “Your page is slow” gets ignored. “Your page is slow, here’s the data, and I’ll help you fix it” gets action.

3. Building scalable systems

My manager and I had a conversation that stuck with me. We couldn’t actually answer the question: “How is our developer experience?”

We had metrics everywhere. Buildkite for CI. GitHub for PR stats. JIRA for velocity. Honeycomb for observability. DX surveys for sentiment. But there was no holistic view. We couldn’t just look at a single place and say, “Here are our most pressing problems. Here’s what we can skip.”

So how we prioritized wasn’t terrible, but it was largely based on vibes. Someone complains in a Slack channel about slow builds, so we’d work on builds. Someone else flags test flakiness, we’d pivot to that.

Or we’d jump on the latest new thing, but we wouldn’t have key overarching metrics to tie it to. Each project had its own metrics specific to the work being done, but we couldn’t connect them higher than that.

I built a framework that connected 3 things:

• metrics teams directly control (build times, test pass rates),

• what developers feel day-to-day (CI pipeline duration, tooling friction), and

• the numbers leadership looks at (Developer Experience Index scores on CTO dashboards).

For each metric, we avoided tracking for the sake of it. Instead, we set red/yellow/green thresholds for every single one. We defined what “good” looked like.

CI pipeline under 12 minutes = Green. 12-18 minutes = Yellow. Over 18 = Red.

The thresholds were based on industry percentile values and feedback from developers. For metrics we didn’t have industry values for, if we knew there were many complaints at the current number, we’d mark it as red.

Once we had these thresholds, vague problems became concrete. “CI is slow” turned into “CI pipeline is red, averaging 19 minutes.” This got prioritization from cross-functional teams through their OKRs. Seeing red on a dashboard creates its own urgency.

Because we have this system, when we enter quarterly planning, the first thing we do is pull up the spreadsheet and review how each metric has been trending month over month.

Which ones are red? Which ones are yellow? We work backwards from there. Instead of whack-a-mole, we start with the data and focus on what’s actually hurting developers most.

After the framework was defined, I set up a reporting system to make it self-sustaining. Teams define a single config object with the metric name, category, and thresholds. That’s it.

A pipeline pulls weekly data, calculates changes, and posts a formatted report to Slack every Monday. Regressions show up at the top and we discuss them in the thread. We also tie the “Improvements” section to recent work that was shipped, too.

Finally, the same data gets sent to Google Sheets so we can track trends over time.

Because of this easy, declarative format, we could onboard other platforms easily. The API Platform team defined their own file within a day and had all the same functionality and our mobile teams are exploring adoption too.

Additionally, the system enabled hooking other alert types into the pipeline. Our Web Modernization team wanted monthly alerts about unused code, and they could add them in a single PR. Now it powers multiple teams’ reporting without me having to touch it.

By becoming the person who defined and maintained the measurement system, I created a position that compounds. Teams work on metrics I developed, the reporting runs without me, and new teams can hook in easily.

As more teams hook in, the impact grows without doing anything new. This shows the power of building scalable systems.

What it added up to

If I could go back and tell myself one thing when I was heads-down writing code and thinking that was the whole job: Staff engineering isn’t about doing more of what you were doing as a Senior.

It’s about building things where other people do more because of what you built. A Slack channel that answers its own questions. A performance audit that gives a team the data to fix their own page. A measurement framework that runs while you’re on vacation.

That’s the work that compounds.

Last words

Special thanks to Jordan for sharing his experience with us! Make sure to check him out on LinkedIn and also the newsletter, High Growth Engineer, there are a lot of great articles there!

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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!

Check the benefits of the paid plan

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.