This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

What I’ve seen happen many times in my career:

A new startup builds their services with “modern” architecture, and of course, in the beginning, the costs are “free” due to the startup credits being given for a certain period of time.

But then, once the free credits are gone, they get surprised with a huge bill. Then, they try to ruthlessly optimize the costs, but often it’s too late. The architectural choices have been made, and switching becomes a lot harder.

It’s really important to keep in mind and have control of the cost of your tools and always try to optimize your spend-to-value ratio.

It’s especially important for all the startups that are just starting. The main focus should be on getting to product-market fit, not skyrocketing your bill for cloud costs.

In today’s article, we’ll go through a real-world case study of how John Gallagher, a seasoned engineering professional, optimized observability costs without losing value.

Let’s introduce our guest author and get started!

Introducing John Gallagher

John Gallagher is a principal engineer, consultant, and coach/mentor, focusing on helping engineering teams to improve production stability.

Today, John will share how to spot the potential red flags, reduce signal noise, and lower monthly cloud bill on observability tools.

Over to you, John!

The accidental discovery

I’ve always been interested in how much companies cost to run. I’d worked on introducing observability into our company and knew that observability tooling can be costly.

So one afternoon, out of curiosity, I pulled up our observability bill to see how things were trending. At first glance, everything seemed normal. Month over month, the increase was modest: maybe 8–10% each month.

But then I looked at a six-month view. Our costs had gone from around $1,000 per month to around $2,500 per month.

I thought about what had changed in that time:

• Our team had grown from 10 to 12 engineers.

• Our traffic had reduced.

• We’d only slightly increased usage of the tool.

Something didn’t add up. We weren’t getting 2.5x the value from our observability tool, yet we were paying 2.5x more for it.

This wasn’t a crisis. Nobody was breathing down my neck about costs. But I had a nagging feeling that we were slowly leaking money, so I started digging.

The granularity cliff

The $2,500 on our bill was broken down into traces, metrics, and logs. Beyond that, detail was hard to find.

Most observability tools give high-level billing reports. In the tool we used, I could get costs by service. That wasn’t enough. I needed to answer deeper questions:

• Which signals were eating most of our budget?

• Within each signal type, was there duplicate data?

• Which data was valuable and which pure noise?

The billing report didn’t allow this level of detail. I’d reached the edge of what I call the granularity cliff.

Many engineering leaders stop here. They don’t have time to dig into the details. Even when they do, they often lack the knowledge of the observability tool’s query language or the ability to group, filter, and analyze logs at scale.

Earlier in my career, I fell off this cliff constantly. I’d see that $2,500 number, feel vaguely uncomfortable, and not know what to do next. So I’d ignore it and work on other tasks. There was always something more urgent: a feature to ship, a bug to fix, a meeting to attend.

But this time I wanted to take a different approach. I resolved to tackle the cost issue head on. I went through 6 steps.

Step 1: Understand the cost model

Before I could lower our costs, I needed to understand how our observability vendor charged us. Different vendors have different pricing models:

• Per-event pricing

You pay based on the number of log events ingested. Each signal costs you money, regardless of how much data is in it.

• Per-data-volume pricing

You pay based on the total size of data ingested. A 10KB log costs you more than a 1KB log.

• A hybrid model

You pay based on some combination of events and volume, or you pay tiered pricing based on retention.

We were on per-event pricing with our tool. This meant that the number of log lines mattered much more than the size of each log. A 1KB log and a 10KB log cost us exactly the same.

This directed my optimization strategy. If we’d been on per-data-volume pricing, I would have focused on reducing log size. But since we were per-event, I needed to reduce the number of logs.

Understanding which pricing model is being applied before optimizing is essential. The strategies that work for one model can be completely wrong for another.

Step 2: Choose the signal to optimize

Modern observability tools can include multiple signals:

• Logs: Detailed event records

• Metrics: Time-series numerical data

• Traces: Distributed request flows

• Synthetics: Automated health checks

• Real user monitoring: Front-end performance data

• Profiling: Code-level performance analysis

Each signal has its own cost structure and optimization strategies. I chose to focus on logs for 3 reasons:

1. Most control

We wrote the code that generated the logs. I could change them directly.

2. Good familiarity

I understood logging deeply. I’d written most of our logging myself.

3. Optimized elsewhere

We’d already reduced our tracing sampling to 15% (the minimum we could responsibly manage with head sampling). Metrics had been cleaned up after an earlier incident where high-cardinality dimensions exploded our costs.

But I didn’t try to optimize everything at once. I picked the signal where I had the most leverage and went deep on that first.

Step 3: Group the data to identify potential waste

I needed a simple way of figuring out which logs had the most volume. I started off grouping by the log message. Grouping by message meant that I could see a broad picture of where we were spending the most.

We had structured logs, so I could have started with any other attribute, but message is the one field that all logs tend to have, so it gave me a good overview.

However, there’s a big problem with grouping by message. Messages were often unique because they contained variable data:

User 12345 logged in from 192.168.1.1
User 67890 logged in from 10.0.0.5
User 11111 logged in from 172.16.0.1

These are 3 different messages, but they are probably coming from the same source, because they have the same pattern: “User X logged in from Y.”

Some observability tools can detect these message patterns by figuring out whether certain parts of the message are variable, such as user IDs, IP addresses, and timestamps. Our observability tool supported this, and it was invaluable. Instead of the 3 log messages above, I’d see a pattern of:

User /d+ logged in from /d+\./d+\./d+\./d+

I sorted by the number of logs in these patterns, which allowed me to see the highest-volume patterns.

I then categorized each message pattern from wasteful to valuable. Agonizing over “not sure” message patterns became a distraction and time sink, so if the value wasn’t immediately apparent, I categorized it as “unknown.”

As I went through the top 50 highest-volume message patterns, I found that:

• ~40% were valuable (e.g., request logs, error logs, critical business events).

• ~50% were unknown.

• ~10% were waste (health checks, statistics, debug logs from third parties).

It became clear then that the sky-high costs weren’t caused by one or two wasteful log patterns. They were from 10–15 lower-volume patterns that had accumulated over time.

Each wasteful log seemed insignificant. But added together, they were costing us $1,500 per month, or $18,000 per year. This was death by a thousand paper cuts.

Step 4: Check the value of the data

I needed to be sure that no other team members were using the logs that seemed obviously useless to me. For every log I classified as waste, I checked:

• Dashboards: Is this log field used in any dashboard?

• Alerts: Is this log pattern referenced in any alerting rules?

• Querying: Is this log used regularly to answer questions?

For dashboards and alerts, our observability tool let me trace a log backward to see where it was used.

For tools without that capability, I’d suggest taking the dashboards and alerts that are most used by the team and manually listing out all the logs they use.

I also looked at our incident postmortems and debugging sessions to see which log queries engineers were actually running when there was an outage.

If I wasn’t sure, I erred on the side of caution and kept the log. At this point, I had two lists: log patterns to remove and log patterns to keep.

Step 5: Remove instrumentation generating noise

For each log pattern to remove, I made a separate code change. I wanted to be able to deploy each change independently, monitoring the impact of each change in isolation. That way I could easily roll back if something went wrong.

So I followed 3 steps.

Step 5.1. Change the code to stop logging

I discovered 3 sources of wasteful logging:

• Codebase

• Library

• Third-party vendors

Source 1: Codebase

The easiest logs to remove were in our code. I searched our app codebase for the wasteful log message pattern.

• If I could identify the logging code, the change was easy: Delete the code, update any tests, and deploy.

• If the logging wasn’t coming from our code, I moved on to the next source.

Source 2: Library

Next, I searched for the log pattern within the libraries our app depended on.

Instrumentation in libraries is more difficult to remove. We didn’t have control over these codebases directly. If I wanted to remove all logging from the library, I would often disable logging using configuration the library exposed.

But in other cases, I needed to make more fine-grained adjustments, or the library wouldn’t expose the relevant configuration. In these cases, I resorted to configuring our logger instead of the library.

In one example I’ll go into later, I needed to filter out the log message “OK.” Instead of configuring the offending library, which proved impossible, I configured our logger to block that exact message.

Source 3: Third-party vendors

If the log didn’t come from our code or a library, it was likely coming from a third-party vendor. Vendors such as AWS, Google, Heroku, Segment, Stripe, and Cloudflare allow their logs to be sent to an external observability tool.

I found some instances where this logging integration had been set up years ago and then forgotten.

There are some obvious clues to look out for in these cases. Often the log to remove would have an attribute such as “app,” “service,” or “source” to indicate that the log was coming from an external vendor.

Other times I needed to do deeper detective work. I would look at all the dashboards of our third-party vendors and check for event webhooks or other related settings. This allowed me to see integrations that I could either switch off or tweak to reduce log volumes.

Last resort: Blocking at ingest

Even in our modestly sized codebase, there were times when I couldn’t figure out exactly where a log was coming from.

In those cases, I blocked the logs at the observability tool. This solution is entirely specific to the observability tool, so it’s my least favourite option and a last resort.

Double-check that these blocked signals won’t count toward your cost. Some tools allow you to block, but the data ingest is still billed, which isn’t that useful to cost savings.

Step 5.2. Deploy it to production

Once I updated the code, I deployed it to production through a PR that other team members could review. I generally tagged one other team member who I knew could respond quickly.

Step 5.3. Watch whether the log volume dropped

I searched for the log pattern I’d removed in our observability tool. When the code was deployed, I was looking for the volume to drop to zero.

Previously I’d created log events for when our app was deployed, so I could see the connection between my code being deployed and the logs disappearing.

If the wasteful log patterns didn’t go to zero, it implied I’d made a mistake. In those cases, I’d adjust the code and try again.

In some cases, I kept an additional eye on other dashboards and alerts to make sure everything was still working.

Step 6: Monitor Usage

Cost optimization isn’t a “one and done.” Keeping costs in check requires ongoing attention.

Once the large volume of wasteful log patterns had been removed, I regularly queried for log message patterns once a month. When I saw suspicious patterns with high volumes, I investigated further and kept on top of costs.

Many of the biggest sources of waste arose from my ignorance, so checking the logs every month allowed me to keep an eye on what was being logged and nip any other cost problems in the bud.

Examples of common waste

I was surprised at some of the low-hanging fruit that was wasting our precious operational budget. If you audit your observability costs, you might be surprised, too.

I uncovered 3 eye-opening examples of waste.

1. The “OK” log message

When going through the top 10 log patterns, one pattern stuck out, appearing over 100 million times per month:

OK.

What?! Clearly this was a useless message.

Investigating further, I discovered that this message was from a third-party library we’d added a few months ago. Buried deep in the library was a health check that ran every few seconds. When the health check passed, it logged a single word: “OK.”

This health check was completely invisible to us. It was built into the library, and we’d never noticed that it was costing us hundreds of dollars per month.

2. The statistics spam

When I looked at the next highest-volume pattern, I saw logs containing IP addresses and seemingly random numbers:

Stats: 192.168.1.45 | requests: 1247 | latency: 123ms | errors: 2
Stats: 10.0.0.12 | requests: 891 | latency: 145ms | errors: 0

Another library annoyance. This time, the library was logging performance statistics in plain text. These logs were:

• Unstructured. We couldn’t query them easily.

• High in volume. There were thousands per minute.

• Useless. We’d never once looked at them during an incident.

We were paying hundreds of dollars a month to store statistics that we couldn’t analyze and never used.

3. The metrics mistake

Before I even started this logging optimization, I had had an expensive lesson with metrics. I’d added a metric to track the p95 response time for each endpoint in our Ruby on Rails app. I had tagged the metric with the controller and action of the request.

What I didn’t realize was that we had more than 200 unique combinations of controller and action. Each combination created a separate time series. And in our observability tool, we paid per time series.

This one metric was on track to costing us $800 within three weeks.

I’d fundamentally misunderstood how metric costs work. The larger the number of unique tags for a metric, the more it costs, and it scales linearly.

Thankfully, my manager caught it early and notified me by Slack message.

The solution? Derive this metric from our logs on demand. We didn’t need to store it as a metric at all. We removed the metric immediately.

My lesson: High-cardinality dimensions on metrics can destroy a budget.

The Results

From this purely self-directed project that I worked on during slack time, I discovered that we were wasting precious operational budget on observability because we were too busy shipping features to review our costs.

I had invested just two days of engineering time, spread over 2–3 weeks and interspersed with regular project work, to find those savings.

Removing the logs caused zero production incidents, and we didn’t need any rollbacks. In fact, the team didn’t even notice the changes.

Observability cost optimization is all about optimizing value versus cost. The key is asking: “Are we getting value proportional to what we’re spending?”

Last words

Many thanks to John for sharing these insights with us! Learn more about him on his Linktr.ee page. Additionally, you can also go through John’s observability spend assessment to gain a better understanding of how you can lower your costs.

We are not over yet!

Why Engineers Must Become Multipliers in the AI Era (6 Important Trends)

The recording of my recent talk at the TechLead conference in Amsterdam in June 2026 is now available. I’ve talked about how the role of engineers is evolving in the AI era.

As development tools become more powerful and accessible, the expectations for engineers are shifting from simply writing code to creating meaningful impact across teams and organizations.

The 6 important trends in software engineers points exactly in this direction.

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!

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.

Intro

Back in December, 2022, based on your feedback, I wrote an article that has been very useful: How to have great 1:1 meetings. Also, the template included has been the most downloaded out of all.

And because the article has been helpful, I decided to do a 2026 extended version of it. So, in today’s article, I am sharing how to have great 1:1 meetings in 2026 and beyond.

This article is written from the perspective of a manager who is organizing and having 1:1 meetings with their direct reports.

It’s also important to mention that in many companies in 2026, a team lead or a tech lead may have 1:1 meetings with their team members, but they are not directly reporting to them. It works from this perspective as well.

This is an article for paid subscribers, and here is the full index:
- What has changed for 1:1 meetings in 2026?
- Make sure to schedule all your 1:1 meetings in advance
- Be on time
- Get your own 1:1 Notion template that I use
🔒 Meeting agenda
🔒 Focus on objectives, goals, and career development
🔒 Meeting notes
🔒 Last words

Let’s start!

Ready, Spec, Ship Hackathon with Kiro

I am happy to share that I will be a judge at the Ready, Spec, Ship Hackathon with Kiro.

There is a $9,600 prize pool available for the top 3 submissions. You can enter solo or form a team of up to three people. Build something ambitious, creative, useful, or completely unexpected with Kiro.

Excited to see all the great stuff being built alongside my fellow judges John Crickett and Angie Jones. Check out the details and enter here:

Check the details

Looking forward to seeing what you’ll build!

What has changed for 1:1 meetings in 2026?

Well, interestingly, not that much. I still use the same template for all the 1:1 meetings I have, and that’s also what I recommend. I’ve been a big fan of Notion for a while now (dating back to 2020), so I’ve been using the same Notion template for more than 6 years now.

Additionally, what I would say has changed the most is that while I keep all the 1:1 meetings very personal and human, I’d occasionally use AI to help me generate ideas for discussion points, brainstorm action items, and help frame certain feedback better.

While I find this helpful, I wouldn’t say AI has been remotely close to an important part of the 1:1 preparation. My goal with every 1:1 meeting is that I build a better working relationship, and that we can openly talk about things. Not try to AI-generate feedback, and sound like a robot.

Additionally, an important shift I notice in comparison to having 1:1 meetings today versus in 2022 is that it’s really important to acknowledge the shift that is happening in the industry with AI.

And it’s even more important to be a good manager and a leader at this time. That’s also one of the biggest differences about how people feel at work these days, in my opinion. The team they are a part of, and the manager they have.

So, with a lot more uncertainty about the future, it’s important to really be there for your team, have great 1:1 meetings, acknowledge the uncertainties, and do your best to support everyone.

Now that we understand some of the differences, let’s start with the basics.

Make sure to schedule all your 1:1 meetings in advance

So, that’s the first thing you should do, it’s important that you have a regular cadence of 1:1 meetings, and that you don’t just schedule them sporadically.

The reason is that if a meeting just shows up in the middle of the week, your report might feel like something bad would happen in a meeting, and they would be unnecessarily worried about it, which can cause a lot of stress.

As a full-time CTO, I heavily stuck to separating my time into manager time and maker time, with the manager time used for meetings, alignments, and slack/emails, while the maker time was for head-down time for deep work.

I organized all my 1:1 meetings on the same day, one after another, with a bit of a break in between. I usually prepared the day before for the 1:1 meetings the next day. A 30-minute meeting is also a standard for a 1:1 meeting.

You can read a full overview of how I organized my time as a full-time CTO in this article:

Checking in with your reports to see if that specific time works for them is also my suggestion, so it doesn’t feel like the time is forced. And in general, this meeting is for your report, not for you, so finding the right time that works for them is important.

Be on time

I’ve had a lot of 1:1s with the managers, who just showed up late to the 1:1 meeting. Sometimes, they would send a message that they’d be late, another time, they would just show up late, with just 15 minutes left in the meeting.

Experiencing that, I focus a lot on being on time as much as I can. Of course I am not always perfect, and it happened to me as well. But at least if I’m late, I send a message. But I do my very best to be on time for the meeting.

Everyone’s time is important, not only yours. And if you treat people like their time is not important, it’s not a good look, and it’s an awful way of building a good professional relationship.

Don’t try to justify that you are a “manager” and that you’re very busy. How you treat your people on a daily basis tells me everything about what kind of manager you are.

Always keep this in mind.

Get your own 1:1 Notion template that I use

This is the exact template that I have been using for the past 6 years, and it works great!

If you want to always be prepared for your 1:1 meetings and need a system to organize all of your notes, make sure to use this template.

Paid subscribers, you can get it here: 🎁 Premium products for paid subscribers.

Meeting agenda

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

AI has definitely changed what it means to be a great engineer. Some time ago, you could be considered a great engineer just by being good at a certain programming language and/or specific framework.

Today, a lot of the expected work of software engineers is actually more aligned with being a Tech Lead and a multiplier for others (making everyone around you better). You can read all about this specific shift in this article:

In today’s article, we’re focusing on how you can utilize AI to be more efficient and productive in your day-to-day work, while providing more impact and making everyone around you more effective.

This is an article for paid subscribers, and here is the full index:
- What is an engineering multiplier?
- How to be an effective engineering multiplier?
- There are 3 camps of engineers and engineering leaders when it comes to using AI
- Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment
🔒 This is how you can utilize AI to be a multiplier
🔒 Learn faster using AI
🔒 Think through difficult problems
🔒 Write better code
🔒 Communicate more effectively
🔒 Find relevant information quickly
🔒 Coaching and leading your team
🔒 Make better decisions overall (especially data-driven)
🔒 Automate repetitive work
🔒 Last words

Let’s start!

My Upcoming Book “The Multiplier Mindset” Published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published later this year!

Learn more about the book

What is an engineering multiplier?

As tools for development got better, the desired skills for engineers have moved from just pure knowing programming languages and frameworks (expected) to problem-solving abilities and people skills.

It's less about the tasks, but how big an impact you can create. And engineers who can create the biggest impact have the multiplier mindset.

It's the mindset where you focus less on just your pure individual tasks, but you focus on how you can make things better for your whole team, organization, and, of course, the customers (users).

I like the term “Engineering Multiplier” because it’s a mix of “Engineering” and “Force Multiplier”, which fundamentally connects the two together.

Being an engineering multiplier means being someone who amplifies the productivity and effectiveness of the engineers around them, not just focusing on their own output, but elevating the entire team.

An engineering multiplier doesn’t just ask, “What can I build?”, they ask, “How can I make everyone around me more effective?”.

How to be an effective engineering multiplier?

As you can see from the picture above, the 2 main focus areas that are important in the AI era to become an engineering multiplier are:

• Human-related skills and

• Problem-solving abilities

And here is the visual of the most important areas:

In this article, we’ll particularly focus on how to utilize AI to help you in all of these specific skills. Before we get into the details, it’s important to have the proper mindset for utilizing AI.

There are 3 camps of engineers and engineering leaders when it comes to using AI

1. The first camp → everyone who avoids using AI in their day-to-day work

Those are normally more experienced people who have been in the engineering industry for a while and have also seen a lot of shifts in the industry. They are more reluctant to change, and rather stick to what they know and what they are good at.

The problematic part is that the mindset of “It has worked well for me for 15 years, why would I change?” can be really harmful for learning new things and improving your craft.

2. The second camp → everyone who overuses AI in their day-to-day work

Those are normally less experienced engineers, either coming to the industry or they’ve been in the industry for a short while.

Such people normally have a good grasp of AI tools and what’s available out there, but they overly rely on them, resulting in the work being mediocre or, even worse, they don’t even check if the output from the AI tools is aligned with the standards.

Such work can be quite a problem for teams, as it puts a lot of work on reviewers to find out all the problems, which can end up taking a lot more time than it would take if they just do it right from the start.

3. The third camp → everyone who takes a balanced approach with curiosity

This is where you want to be. You don’t just blindly trust the “fancy new tool”, and at the same time, you are very curious to find out how you can improve your own and your team’s workflow with new tools.

You are keen on trying new things out, and at the same time you understand how important good engineering fundamentals and understanding of good engineering practices are.

You like to learn new things all the time, and you look at software development as one of the most fun things to do, because there’s always something new to learn.

Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment

Using different tools that are available to make your day-to-day easier and more productive is what great engineers and engineering leaders do.

This hasn’t changed with AI, it has always been like that. We’ve always looked to automate aspects of our work. AI is a tool like any other, just the difference is that it’s a lot more ambiguous to use.

You get a tool that has so many capabilities, but no real manual on how to use it for your specific case. You need to figure out what works best for you and your work specifically.

At the same time, you shouldn’t just blindly trust these tools, you should verify and ensure they actually make you more productive.

This is how you can utilize AI to be a multiplier

Read more

Intro

With the skyrocketing growth of Codex and ChatGPT Work to roughly 10M users, there’s a huge need for optimizations in order to support that kind of scale.

As you know, building the infrastructure behind efficient AI Agents is a lot more complex than building an infrastructure for a chatbot-like interface.

The reason is that AI agents can take many different paths to complete a task, and because LLMs are non-deterministic, the same prompt can produce different responses. This makes their behavior much harder to predict, debug, and test.

I’ve recently had the pleasure of talking to:

• Joe Gershenson, who is leading the Core Agent team at OpenAI

• Ahmed Ibrahim, who is working on Agent Harness

• Steve Coffey, who is working on the API powering Codex and ChatGPT Work

They shared a lot of interesting insights with me on the call, and also in writing as well.

And in today’s article, I’m sharing the main performance improvements OpenAI has recently made in order to support the scale and growth of their user base.

Let’s start!

Beyond picking the right model for a specific job

With the recent release of the GPT‑5.6 series: Sol, Terra, and Luna, each model is designed for a different use case.

• Sol, being the flagship model, has the highest intelligence and strongest reasoning, but it’s also more costly.

• Terra is made for everyday work and is a good balance of quality, speed, and cost

• And Luna has the fastest responses and lowest cost, but is not as good at reasoning.

So, choosing the right model alone can definitely help both at the infrastructure level and also for the users to get faster responses that potentially cost fewer tokens as well.

But in this article, we’re going beyond just the model selection, we’re going into actual infrastructure optimizations that make AI agents both token-efficient and performant.

The 3 layers of efficiency behind AI Agents

Whenever we’re talking about how to make AI Agents more efficient, the 3 main layers that we need to look at are:

1. The agent harness

It’s the infrastructure that runs the AI Agent. Think of the harness as the layer that decides HOW an agent performs a certain action, while the LLM decides WHAT an agent needs to do.

Without the harness, an AI agent can only answer questions, but with the harness it can search the web, read files, write and run code, call APIs, recover from errors, etc.

2. API

The API is the communication layer between the Agent Harness and the LLM. Every time the agent needs the model to reason, plan, or generate a response, it makes an API request.

The more efficiently the API can send requests and receive responses, the faster and cheaper the entire agent becomes.

To complete a certain task, an agent usually sends a lot of different requests, so even small improvements in API efficiency can have a huge impact.

3. Model inference

Inference is the process of the LLM generating a response from the input it receives. This is where the actual reasoning, planning, and text generation happen.

Inference is usually the most computationally expensive part. It runs on GPUs, and GPUs are always a bottleneck, so making this part more efficient is crucial.

In this article, we’ll go through the performance improvements made in each layer. Let’s first start with inference.

1. Inference optimizations

As mentioned, computational power is always a constraint, so being able to utilize GPUs as efficiently as possible is crucial.

The performance optimization improvements made on inference have been shared with me by OpenAI’s team in writing, but the interpretation of them are adapted for this article.

The most recent important efficiency improvements on inference that the team at OpenAI has recently done are the following.

• Load balancing the requests

The team has shared that they distribute work across model instances within 2 criteria. The first one is a global distribution, based on geography, available capacity, and also accelerator type (the type of GPU or specialized chip running the model). The accelerator type varies based on the specific model.

And the second load balancing happens within the cluster of GPUs, they distribute work across model instances based on the load, context length, cache availability, and some other request properties.

They’ve seen improvements, especially with the use of GPT-5.6 Sol in Codex, they can better analyze the traffic and correctly route the requests to the right model instance.

• Optimization to the model’s forward pass

A forward pass is the process of getting an output based on the specific input. The process is as follows: Prompt → model calculations → probability for the next token.

For example, if your prompt is: “The capital of France is”. During a forward pass, the model processes the text and calculates that “Paris” is a likely next token. Each new token usually requires another forward pass. So, a 100-token response likely needs 100 forward passes.

An interesting thing that the team has shared with me is that with Codex and their latest model (GPT-5.6 Sol), an AI agent was able to autonomously optimize their production kernels, which is the core code that executes the mathematical operations of the model.

The reason that the new model was able to provide effective improvements to the production kernels is because it was trained on Triton and Gluon, two open-source GPU programming languages maintained by OpenAI.

They’ve mentioned that these optimizations reduced end-to-end serving costs by 20%.

• Speculative decoding

This is another lever they have worked on, and it’s a technique where you run a smaller model alongside the primary model.

The smaller model proposes several tokens for the primary model to verify in parallel, and when those proposals are accepted, the system can produce multiple output tokens from a single primary-model pass. This heavily reduces the overall computation needed.

And interestingly, similar to improvements to the production kernel, they utilized their latest model (GPT-5.6 Sol) to make improvements on speculator training autonomously.

The team has shared that these improvements increased token-generation efficiency by more than 15%.

They also mentioned that the inference optimization is a continuous feedback loop, and it’s important to measure production behavior and identify the gaps and implement the changes needed, while making sure they actually improve the whole system.

2. API optimizations

In our conversation with Steve Coffey, who is working on the API for both Codex and ChatGPT Work, he mentioned that the 3 core metrics they track in their API are the following:

• Time to first token (TTFT): The amount of time between getting the input, sending the request to an AI model, and receiving the very first generated token.

• Time between tokens (TBT): Tokens arrive one-by-one, so this metric is related to how quickly each token arrives.

• End-to-end time (E2E): how long it takes to receive a complete response

Steve also mentioned that the most important metric is the first one (TTFT), it gives a good insight into the performance of their API both in receiving the input, doing a certain logic, and then sending the request to the AI model and receiving the response.

At this point, I’ve asked about what they prefer more, the overall speed of their API or its availability. And Steve mentioned that availability is the most important, and they aim for 99.99% availability on their requests.

The reasoning is that it’s much better that the user gets the desired output (even if slower) than not at all.

Now, let’s go to the 3 core improvements they made in their API in order to support the high usage. The first one is definitely the biggest one.

From REST API to WebSocket integration

They’ve seen one of the biggest performance improvements by moving a lot of the communication between the AI Agent communicating via REST API to WebSockets.

The reason is that when sending a request to a REST API, for every request you need to go through the initial connection, which can add up to a significant amount of time, especially with a large number of requests being sent. Which, of course, as we mentioned, an AI agent does send, even for a simple task.

The big benefit of using a WebSocket API is that the handshake happens only once (to establish the connection), and then the data gets sent over that connection in a lot more efficient way.

Steve mentioned that they are supporting both the REST API and the WebSocket at the same time, as some of the specific parts still go through that API, and also if the network connection of a user is very bad, they will fall back to the REST API communication.

I’ve asked Steve if supporting both is a problematic part, but he mentioned that not at all.

There are some specific nuances to both parts, like for the WebSocket API, they need to support many long-lived connections, and if they do another deployment, they need to ensure that the users get reconnected after.

The reasoning for not being as problematic is that the core logic behind both APIs is the same, just the way these parts receive and send data is different. But the core logic of security, analyzing, and talking with AI models is the same.

Sending only new things to the API, not the full context of the conversation

Think about the full Codex session and the back-and-forth conversations that you have. Before the optimization, they used to send the full context of the conversation in every request, which, especially in larger conversations, could take a long time to process.

With the WebSocket integration, they are now sending only the data that is new, and they keep the state of the context on the server. The first call of the session starts the context, and it builds up on every piece of data being sent.

The data that’s being sent contains only what’s new + the reference to the conversation, so that the backend knows where to store that data.

With this change, they’ve seen roughly 40% faster end-to-end execution. And imagine if you have a really long conversation, I imagine the speed is substantially faster than it used to be.

Optimizing the CPU efficiency

All of their infrastructure at OpenAI is deployed using Kubernetes. What they’ve found out is that Kubernetes nodes with the same instance type don’t always have the same CPU processors. In their fleet, they’ve found that many of the nodes were using outdated CPUs.

When they measured the resources being used, they saw that older processors used roughly 2x as much CPU resources for the same work. And switching to the new ones improved the TTFT (Time to first token) by 20%.

They have reweighted traffic toward more efficient processors and are now being a lot more diligent in testing and optimizing the CPU resources.

This is a good reminder, especially if you want to optimize the CPU resources, that you continuously test and check for outdated CPUs. Especially if you have a service that has been running now for some time, it’s good to check if you can do any optimizations, which can have a lot of upside.

3. Agent harness optimizations

In my conversation with Joe Gershenson, who is leading the Core Agent team at OpenAI, and Ahmed Ibrahim, who is working on the Agent Harness, we talked all about the optimizations they did on the harness.

The first interesting thing about our conversation is my question about what kind of metrics are on their performance dashboard.

And interestingly, they responded that while they have specific dashboards, like Grafana or similar, most of their dashboards are built when there’s a need for it.

As mentioned in one of the recent articles about how OpenAI builds infrastructure teams, one of their project, that they built is an in-house data agent.

They created an internal-only tool where everyone inside OpenAI can ask data-related questions and get the insights needed in order to make data-driven decisions.

No need to go to data engineers to “generate another dashboard”, they can simply ask the data agent to get the desired insights they are looking for. Read the full article:

So, this is what they use inside the harness team for tracking and to get performance-related data.

And a cool thing that Ahmed and Joe mentioned is that they can share the context of a Slack channel or a Slack thread, or a specific screenshot of a certain ask, and the data agent will automatically look up all the data that is needed and create the correct dashboards for them to properly assess what’s happening.

Now, let’s go into 2 specific performance improvements they did on the harness.

Avoiding the unnecessary context

As we talked about already in the API section, they use the WebSocket integration to just append the new data to the existing context, which is stored on the server.

On the harness level, they optimized the context window history with the approach called deferred discovery.

This makes integrations, custom MCP tools, skills, and any kind of additional things only surfaceable when it’s needed.

At the same time, the harness also prevents individual tools and MCP integrations from unexpectedly consuming the context window. They’ve also set up a default cap output at 10k tokens, unless the model requests a different limit.

Prompt caching

As you know, correctly caching plays a significant role in performance optimizations, in this case, they utilized a technique called caching the prompt prefix.

Here is a good example of how this works. Imagine this prompt:

You are a senior software engineer.

Follow these rules:
- Write secure code.
- Explain your reasoning briefly.
- Use the available tools when necessary.

Conversation history:
...

Current task:

When you assign a certain task to an AI agent, it will break it down into a number of smaller tasks, but it will keep the same or similar prompt prefix.

So, everything before “Current task:” is the prompt prefix. The only thing that changes between requests is the current task.

And as you know, processing long prompts is expensive. So, if the prefix is identical across many requests, the harness will cache the prefix and only share the rest of what’s really needed. Which helps to improve the speed and efficiency of how an agent works.

So, this is a great insight for you, as a user as well. If you are sending a prompt either via API or directly in Codex, you can send the prefix as part of the prompt anytime, and it won’t contribute to higher token usage because of the prefix caching.

Last words

Special thanks to Joe, Ahmed, Steve, and the rest of the OpenAI team for sharing all these interesting insights with me.

Many of these insights haven’t been shared publicly before, making this the first time they’re being shared in this level of detail.

It will be interesting to see how the infrastructure evolves as Codex and ChatGPT Work continue to grow. The saying, “What got you here won’t get you there,” feels especially relevant in this case.

The optimizations that support 10M users likely won’t be enough for 20M or 30M. As AI agents become more capable and get even better capabilities, every performance optimization will matter even more.

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!

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.

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

Earlier this year, I was in San Francisco talking with different companies, and one of them was Larridin. Funnily, I came right in the middle of their team meeting (sorry guys).

They are building a platform for what many companies are wondering these days → how to measure AI adoption and AI fluency.

Things that especially stood out from our conversations:

• They are a true definition of an AI-native team, with AI being at the core of everything they do.

• They are big advocates of spec-driven development. The spec needs to be almost perfect before they start with the implementation.

• Every engineer owns the feature end-to-end → from creating the spec to implementing it, to ensuring it’s working correctly.

• Ameya Kanitkar, CTO, Larridin, mentioned they also like to work with more junior-level engineers, but they need to leave and breathe AI and always look to improve and get better in this area.

• A great analogy about using AI → You have a fast-driving car right in front of you, why not use it?

I’ve talked with the devs, and also with Ameya, whose insights I am sharing today. In today’s article, we’ll dive into how they are doing spec-driven development at Larridin.

Let’s start!

What is spec-driven development?

There are many different definitions out there, but here is what it means for me:

Spec-driven development is a way of building software where you focus on building a good specification first, and then use AI to implement the project.

There are many ways you can write the spec, for example, Michael Bolin, Codex Tech Lead, uses Notion to create a spec and then asks all the other engineers on the team to take a look and provide comments.

This helps spot any issues beforehand and improves the overall implementation done by the LLMs. To learn Michael’s full process for AI-assisted engineering, read this article:

The popularity behind spec-driven development is increasing

I am seeing spec-driven development as the way to build software used by more and more companies, and it definitely makes sense.

Especially with the cost of tokens just keep increasing, you don’t have the luxury of just infinitely prompting in order to get the desired output (unless you work with unlimited tokens).

With a great spec, you can usually use a lower-tier model and get a very similar output, the reason for that is that the instructions in a great spec are very clear.

So, this is also the workflow that I see many companies use:

• Write a spec (with the help of higher-tier LLMs)

• Build the spec (with the lower-tier LLMs)

Now, let’s get into more details on how Larridin does spec-driven development!

1. Start with a spike first

Ameya mentioned that before they start writing the spec, they prove that the “risky” things work.

In software development, there are a lot of unknowns when you are building things, and it’s impossible to write a complete spec if you are dealing with unknowns.

So, what they do is, they create a spike task to resolve these unknowns of a specific project first.

The goal is not to build a full MVP, it can be a small, ugly, throwaway-quality work. Just enough to answer the question “does this actually work”?

The purpose is not to extend it afterward, as you would normally do with the MVP, but the goal is to remove any technical uncertainty, which, alternatively, would just contaminate the spec with various different options.

Some examples:

• If the API that you’re going to build has 3 edge cases, spike those.

• If your whole system depends on how fast your API is, spike the hot path and measure it.

• If you’re building a new view that has a lot of records in it, prove that the API can return the results fast enough.

And another example that Ameya shared from their work:

We wanted to create a model to measure “AI Fluency”. So we wrote a spike to ensure our core logic works. Once we were happy with the results, the rest of the design followed (queue, monitoring, database, etc.). Spec was simply for ensuring core logic works and is token efficient.

The goal is to stop when you have an answer, not when the code is pretty. If you’re worried about naming variables, functions, and file structure, stop, that’s a sign you’re putting too much thought into implementation details.

2. Promote the spike to reference implementation

Once the spike works, don’t throw it away. It’s now your reference implementation.

This is now a reference that you can point the LLM to and say “I know this pattern works, because here it’s working!”

Ameya believes that this is one of the most underrated things when you’re doing spec-driven development. A working example is worth a lot more than a full page in the spec. That’s how the model stops hallucinating and stops “guessing” the behavior as well.

The reason is that the model can now check the reference and see the approach that has been taken to implement that specific part.

The reference implementation belongs in the repo in a known location. All of the references are in a location: spec/spikes/reference/referenceName.

And also another tip here is to comment on the specific parts that prove the approach, and also add comments to the parts where things are hardcoded, maybe the error handling is missing, or the implementation is not on point.

The more info you give in the codebase, the more accurate the overall implementation by the LLM is going to be.

Ameya believes that a spike without comments can be similarly dangerous as not doing it at all, because the model can just reproduce the wrong parts alongside the right ones.

3. Write the spec

Now that you have the reference implementation with comments, it’s time to write the spec! The spec should be detailed enough to hand to a junior engineer or a small model.

You can and should, of course, use AI to help you write the spec. When you use AI to write the spec, Ameya suggests forcing the model to restate what needs to be done, list any assumptions, and also flag any kind of ambiguity.

So, in case there are any non-handled assumptions and ambiguity left, you can either create a new spike or update the existing one.

Here is also a desired spec structure that they use at Larridin:

• Problem statement at the top

What you’re solving and for whom. One paragraph.

• Non-goals

What this system explicitly will not do. This is where you head off half the overengineering before it starts.

• Assumptions

The details that you have already decided, so the model doesn’t “silently” pick them. Cursor or offset pagination? Lazy loading of components? You need to write all of these down.

• Reference implementation

Link to the spike. Call out (if not already in the comments) which parts are shortcuts, and which parts prove the implementation.

• Architecture

Data model, module boundaries, interfaces, error handling, etc.

• Test plan

What unit, integration, and/or e2e tests are needed and how they need to be done. More on this in the next phase.

Example of a good spec shared by Ameya: Full example of the spec.

And a recommendation he shared:

My recommendation is to write the smallest spec that unambiguously specifies the system. If a section feels like fluff, cut it. If a decision feels obvious, write it down anyway. “Obvious to you” is not the same as “obvious to the model”.

4. Write/adjust the test plan before the implementation plan

Test-driven development and spec-driven development are made for each other. Once you know what the system does, you can write the test plan before the implementation plan, not after.

The test plan is part of the spec, and you should go over it and adjust if something is not right or something is missing.

It’s important that your test plan uses either bullet points or that the separation between tests is clear. And also you need to watch out for any “ambiguous tests”.

Here are 2 examples:

• Instead of “Handles large inputs gracefully” it should be “processes 10k rows in under 2 seconds with memory under 500MB.”

• Instead of “Fails safely on bad input” it becomes “returns a 400 with a specific error code when the payload is missing the customer_id field.”

There’s no need to implement the tests yet, it’s important that you list them, name each one, and specify inputs and expected outputs.

That list should be a clear definition of done, which the implementation plan will be measured against.

We are going through the implementation plan in the next step!

5. Create the implementation plan

We now have the reference implementation ready, the spec is ready, and the test plan is on point. Now, it’s time to go to the last step, which is creating the implementation plan.

The implementation plan is the boring part. A sequence of steps that turns the spec into code. File by file, function by function, each step is clearly defined, so there is no chance for an LLM to go a different direction.

This is much more detailed than a spec. If the spec is around 800 lines, then the implementation plan would be around 3k lines.

So, all you need to do here is ask an LLM to create an implementation plan based on the spec, and output it in a separate folder. You can have a separate folder in your repo called plans.

Once the plan is created, it’s important that you do a detailed review. If you find that the implementation plan is making a new architectural call mid-implementation, that’s a signal the spec wasn’t complete.

Make sure to go back and update it, don’t just manually update the implementation plan with architecture details and leave the spec unchanged.

The whole point of this workflow is that you stop making decisions in phase 3, where you wrote the spec. Making new ones in the last phase can silently introduce problems.

Here is also an example of a good implementation plan: Full example of the implementation plan. And you can find many other examples in the same folder.

6. Implement

So once you are happy with the implementation plan, now comes the easy part. You can use any of the small LLMs to do that. Even Haiku works great.

All you need to do is tell the LLM to create the code based on the implementation plan. It’s your choice if you want to create the PR yourself, or you want to split the project into separate PRs, or tell an LLM to create the PRs, based on a specific convention, etc.

Once you have the implementation plan, the implementation is the easy part.

When to use spec-driven development (and when not to)

Spec-driven development is definitely an overhead for smaller changes. If you are doing a small change, like refactoring a specific file or a small adjustment of a feature, it’s definitely not the right way to do it.

Prompt → review the code is the right way to go for these small changes.

But when you are working on a bigger project, and especially if you don’t know if it’s even feasible in the first place, it can save you a LOT of time rewriting and reviewing bad AI-generated code.

And also making “decisions on the fly” is usually a lot worse than making decisions beforehand. Especially if you are making important architecture decisions. Creating the spec forces you to really think if this is the right approach.

If you just prompt and adjust as you go, then you don’t really think through whether the approach is correct or not.

Last words

Let’s end this article with the following:

As you can see from the process they use at Larridin, clear thinking and good judgment are the most important parts. Once you’ve done that, writing the code is the easy part. Always keep this in mind.

Special thanks to the Larridin team for the hospitality and Ameya for sharing all these interesting insights on how they work!

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!

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.

Intro

If you go on any social media these days, you can quite quickly spot AI-generated posts or comments, and it’s really becoming frustrating. As soon as I see that, I immediately go to something else, and I lose a bit of credibility for that person.

And it’s the same with AI-generated emails, messages, articles, or even ADRs and tech specs. While there is certainly a time and place where AI-generated writing makes sense, the problem comes when people expect to read human, thoughtful writing, but instead they get AI-generated text, with no substance.

Imagine asking a question to your colleague, and they just copy & paste an AI-generated response, without even taking the time to edit it. It’s very similar to just submitting a PR full of AI code slop, without taking the time to edit, and putting all the work on reviewers to try finding the issues.

In today’s article, we’ll go through why AI-generated writing is problematic, its use cases + how you can write clearly, develop your own style, and communicate in a way that gets the response you’re looking for.

This is an article for paid subscribers, and here is the full index:
- Why is AI-generated writing problematic?
- Another example, the problem with AI-generated code
- AI is not the issue, the issue is doing “half-done” work
- AI-generated writing is fine if the expectation is aligned with that
- Brevity is more important than ever
🔒 How to write clearly?
🔒 Develop your style of writing
🔒 Know your audience
🔒 Different tips and tools that can help you
🔒 Last words

Let’s start!

Why is AI-generated writing problematic?

As mentioned a bit in the intro, it’s not that AI-generated text is problematic by default, the problematic part is the misalignment between expectations.

Here is a good example:

You go to the cinema to watch a new movie that has been advertised as the “next must-see movie”, and you have high expectations of it. Great story, thoughtful scripts, great cast, etc. You are excited.

But then the movie starts, and things go sideways quickly. Generic story, generic graphics, generic cast, etc. The movie was actually AI-generated. What are your thoughts?

You are not happy about it because your expectations were different.

And it’s very similar with AI-generated emails, messages, blog posts, etc. You get a bad taste in your mouth if you expected to read thoughtful writing, while in reality you read AI-generated writing.

Let’s go to another example that I regularly see being problematic, especially for engineers who are reviewing code.

Another example, the problem with AI-generated code

What I am seeing and also hearing happening regularly, especially with less experienced engineers, is the following:

They are assigned a task, and they use a certain AI coding tool, use their agent mode to finish the task, and then they don’t go the extra mile to actually understand what has been changed and ensure the changes are made within the guidelines of the codebase.

They open the PR, and because they didn’t actually take the time to read and edit the code, this puts a lot of pressure on reviewers to find all the mistakes and completely shifts the work on them.

There may be a lot of comments on PRs, and it takes a lot of time to review correctly. And even in some cases, engineers give up and just approve the PR, which makes things a lot worse in the long run.

For me, personally, if I see a PR opened full of AI-generated slop, that particular engineer would lose a lot of credibility in my eyes. Or even worse, if they mention that the mistake is there “because of AI”.

Every good engineer should know and realize that overall accountability is on them to ensure that good-quality code is delivered and not look to shift the accountability elsewhere.

Of course, I get it, we all make mistakes, but at the end of the day, submitting a full PR of AI-generated slop or blaming AI for a mistake is not a good look.

AI is not the issue, the issue is doing “half-done” work

This is the core message that I want to get across in this article.

As soon as you send a message or open a PR where you just copy & paste the first AI-generated output and didn’t actually take the time to ensure it’s done to the correct quality, you lose credibility.

Even if you don’t receive the feedback directly, you are going to be perceived differently, and if you do this for a longer amount of time, you’ll end up having a bad reputation, which can be quite problematic, especially these days with a lot of layoffs happening across the industry.

So, always ask yourself, am I doing the work that is perceived to be good quality? Or am I just doing the minimal effort work?

If you’re doing the second, it’s time to really reconsider your priorities. Your reputation is one of the most important things, and how people perceive you really goes a long way.

Now, let’s get to an important point, where AI generated writing is totally fine.

AI-generated writing is fine if the expectation is aligned with that

There are definitely use cases where AI-generated text is fine, like, for example, if everyone is aligned that the tech spec or ADR will be fully AI-generated, and you keep improving it with prompts.

Additionally, if there is a clear PR template prepared, where everyone generates the description with AI, that’s totally fine as well.

But the problem comes when you’re trying to share AI-generated writing masked as your own. Like responding to PR review comments with AI, or responding to Slack messages with purely AI-generated text.

Or even writing full blog posts, articles with AI, that’s fully unacceptable from my perspective. Maybe some people would read it, but me, I won’t.

That’s also the reason why all the articles on this newsletter are going to be written in my style, which I developed in close to 4 years of writing online.

Now that we understand where AI-generated text is fine versus not, let’s go through the importance of clear writing and brevity.

Brevity is more important than ever

What brevity means is to use the right amount of words (no fluff) to communicate an idea clearly. It’s being concise and clear with your written communication.

It means that you can put yourself in the shoes of your reader(s) and write it in a way that resonates with them.

Brevity is a sign of respect for the reader’s time.

This is the post that I posted on LinkedIn earlier this week, which shares an example of brevity (from 2014):

In this situation, it worked. Niraj got the response from Evan, which resulted in a positive one.

What’s important to mention here is that I wouldn’t bet on sending a cold email like that in 2026 and expect to get a similar response.

A lot of people, especially recruiters or hiring managers, have already seen this before (as it’s been quite a popular picture shared across social media in recent years). And it’s a bit of a cliché.

But what’s important is that it worked for Niraj back in 2014. And that’s how you need to think about writing.

Ask yourself: How can I write in a way that would get me the desired response?

This is the art of brevity. Knowing who your audience is and how to frame it in a way that would resonate with them the most.

Let me share some examples and tips for clear written communication next.

How to write clearly?

Read more

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

Learn more

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!

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.

Intro

Over the course of my 13+ year career, both as an engineer and engineering leader, I had the pleasure of being a mentor/coach for many different people.

It started already when I was a Software Engineer, onboarding new engineers, and then it became a standard for me when I became a manager.

I always viewed a part of my role as a manager to be a coach for everyone who was directly reporting to me, and I always enjoyed seeing my people grow.

Interestingly, this was also one of the reasons why I started writing online, a bit less than 4 years ago.

In today’s article, I’ll be going through some of the most important lessons I learned from coaching over 300 engineers and engineering leaders both in my full-time roles, group coaching, or individual coaching.

This is an article for paid subscribers, and here is the full index:
- My experience with coaching
- What’s interesting about coaching is the following
- Those are the reasons why I highly recommend that everyone become a mentor/coach
- Lesson #1: A lot of people already know what they need to do
🔒 Lesson #2: Believing they are not ready or that they don’t deserve it
🔒 Lesson #3: Accountability is crucial
🔒 Putting it all together
🔒 Last words

Let’s start!

My experience with coaching

As mentioned at the beginning of the article, I consider being a coach for everyone who has ever directly reported to me. I’m not counting indirect reports, where I was a skip-level manager, I am counting everyone with whom I had 1:1s with.

The reason for this is that I always looked at 1:1s very similarly to doing a 30-minute coaching session.

Additionally, I did 8 cohorts of the live course called Senior Engineer to Lead: Grow and thrive in the role, where I taught close to 250 engineers and engineering leaders.

And I also had the pleasure of having a lot of individual coaching sessions with many different great individuals throughout my career.

What’s interesting about coaching is the following

You learn a lot as a coach, not only does the person who is receiving coaching.

The biggest benefits of being a coach are:

• If you can teach it, you understand it

It forces you to clarify your thoughts on certain topics, as if you don’t understand a certain topic clearly, you won’t be able to teach it to someone else.

It also shows where you might have blindspots and which particular parts you don’t understand that well.

• You get exposure to a number of different problems people are dealing with

Which helps you to do future coaching a lot better, especially if you see repeating patterns from 1 person to another. Or maybe you come across a similar issue, just disguised a bit differently, and you spot that pattern and re-use a similar solution.

Additionally, you are able to solve various different problems better, as the more problems you are exposed to and solve them, the easier future problems can be solved.

• Communication skills, active listening, asking good questions, and not just handing the “solution”.

This is crucial, and if you want to grow in your career, it’s more important than ever to improve in these skills, as there is a limited amount of impact you can have just with your own contribution.

Being a multiplier for others is how you can have so much bigger impact, especially in the AI era, where pure building has become much more accessible.

That’s also the reason why I am putting a LOT of effort into writing the book The Multiplier Mindset, which will be published later this year. So, everyone develops the right mindset that’s crucial to be successful in current times, both as an engineer and an engineering leader.

Those are the reasons why I highly recommend that everyone become a mentor/coach

As mentioned, you don’t only help the other person, but YOU learn and grow this way as well. It has tremendously helped me throughout my career, and I couldn’t recommend it more.

Try to find opportunities where you can help others grow, even if you are not a manager. Being a mentor is very valuable, and you’ll quickly find out what specific things you know and where you need to improve.

Now that we better understand how important coaching is, let me share my top 3 lessons from coaching many different people throughout my career.

Lesson #1: A lot of people already know what they need to do

I see this all the time, and I’ve seen it in many individuals in tech. Very similar to eating healthy food and exercising to get in shape. Many people know exactly what they need to do, but the problem is starting to do it, being consistent, and sticking with it.

The same is for growing in their careers as engineers/engineering leaders. A lot of people know they need to be more visible, share their work better, be more vocal in meetings, share their opinions, ask their manager for the next step, follow up on the ask, etc.

But the problem comes when you need to actively put this into practice and stick with it. Being more visible means you need to actively find opportunities internally and/or externally to share your knowledge, either via learning sessions, blog posts, speaking at meetups/events/conferences, etc.

Having an opinion in a meeting starts with doing research on the topic before the meeting starts, asking the manager for the next step starts with preparing the full script on what you’re going to say + rehearse it, and before that, doing a good amount of research on what next step you actually want to take.

The problem is mostly the need to put in the work every day consistently, and that’s where a lot of the things stop. Especially if they don’t have a person holding them accountable. I’ll talk a lot more about accountability in the 3rd lesson!

Now, let’s go to the second one, which is closely connected with the first one.

Lesson #2: Believing they are not ready or that they don’t deserve it

Read more

Proud to announce my book “The Multiplier Mindset” published by O’Reilly!

The main premise of the book:

In today’s AI era, being a great engineer is no longer defined by individual contribution alone.

Being a great engineer is defined by the ability to make others around you better, to deliver projects successfully, and to create impact that moves the whole organization forward.

And engineers with the biggest impact have the multiplier mindset.

In the book, I cover:

• Exact mindset you need to thrive today and in years to come, both as an engineer and engineering leader

• Important traits and skills to develop

• 8 case studies from successful multipliers from companies like Pinterest, Adobe, Microsoft, to name a few

I already shared 2 case studies (adapted for the newsletter) as articles, and you can read them here:

The book will be published later this year! 2 chapters left to be written, and the tech review process finalized.

Early release of the book available here: Early release of the book.

Get also a 1-month free access to all the O’Reilly books: Free access to O’Reilly platform.

Wish you a great rest of the week!

Gregor

Read more

Intro

I recently had the pleasure of visiting OpenAI’s offices in San Francisco. Had a great time there, and it was a pleasure getting to know and talk to different engineers and engineering leaders.

Here is also the article, based on my conversation with Michael Bolin, Tech Lead for the Codex open-source repo. We talked all about how he does AI-assisted engineering:

In today’s article, I am sharing the insights from my conversation with Venkat Venkataramani, VP of Applied Infrastructure, OpenAI, and Emma Tang, who is leading Data Infrastructure at OpenAI.

We talked all about how infrastructure teams work.

This is an article for paid subscribers, and here is the full index:
- 5 Core Pillars of Infrastructure at OpenAI
- Infrastructure teams are critical to the success at OpenAI
- The amount of AI-generated code is lower than with product teams
- How they prioritize work?
- Unblocking teams is a crucial part of prioritization
🔒 Their primary challenge with infrastructure at OpenAI has always been the pace of growth
🔒 Another challenge is the unpredictability
🔒 AI-generated PRs have also shown to be another infrastructure challenge
🔒 What makes a great engineer for an infrastructure team?
🔒 How they measure the success of the infrastructure teams?
🔒 Last words

Let’s start!

5 Core Pillars of Infrastructure at OpenAI

At OpenAI, they organize their infrastructure around 5 main pillars, each focusing on a specific part.

1. Developer Productivity

Focusing on improving the software development process + research, giving everyone the tools and capabilities to do the best work possible.

Think of it as everything that helps teams build, test, deploy, and move faster, so that everyone can move as fast as they can.

2. Compute Infrastructure

This is the specific hardware and/or software needed for all the computing behind OpenAI’s products. This includes the infrastructure powering: ChatGPT, API, Codex, and any future products.

Venkat also mentions that this specific pillar could be referred to as Fleet Infra, as it’s specifically focusing on GPU infrastructure.

3. Networking and Storage

With this infrastructure, AI workloads can communicate while storing data generated by models and apps.

This pillar goes hand-in-hand with the compute infrastructure, as their work is closely related.

4. Observability

Monitoring, telemetry, metrics needed to keep the systems reliable. That’s the focus of this specific pillar. The goal is to detect issues quickly, understand what’s happening across the infrastructure, and ensure that the services are reliable.

5. Data Infrastructure

The last but definitely not least. Venkat describes it as one of the most important infrastructure organizations because basically every application continuously generates data.

This is the infrastructure that enables OpenAI’s feedback loop, helping improve future models and products.

Emma shared a great example of their work, which is an in-house data agent. They created an internal-only tool where everyone inside OpenAI can ask data-related questions and get the insights needed in order to make data-driven decisions.

No need to go to data engineers to “generate another dashboard”, they can simply ask the data agent to get the desired insights they are looking for.

Infrastructure teams are critical to the success at OpenAI

Everyone’s productivity is determined by how well the infrastructure enables them.

With bad infrastructure, you are limiting how fast people can move and make things happen. You want to enable everyone instead to do the best work possible.

It’s crucial to enable both:

• teams and people internally at OpenAI, and

• the customers/users

to be able to do what they want to do.

A good example is the following: Good infra plays a huge role in user experience, like how fast ChatGPT responds to the questions being asked, and also how reliable it is.

And there’s another important factor as well, which is cost, and balancing cost with speed and reliability. How to find the right balance between them, so that they don’t burn the full budget just on compute.

And then also specifically for data infrastructure, it’s important to have a good infrastructure in place so that every team inside OpenAI is able to make data-driven decisions.

It’s important to view infrastructure as the backbone of many other essential functions a business can’t operate without.

The amount of AI-generated code is lower than with product teams

This is a very important insight, mentioned by Emma, as many people may believe that you can just use AI and generate thousands of lines of code without consequences. That’s completely not the case when you are building infrastructure.

The infrastructure work is a lot more critical to the business, and with one simple mistake, there can be huge consequences. You can block other teams from being able to progress with their work, and even worse, the users might not be able to achieve what they want to do using their products.

They focus a lot more on understanding every single line of code and making sure that everything works correctly. Therefore, they don’t see as much higher productivity boost using LLMs than some other more product-facing teams.

How they prioritize work?

As you may know, working in any kind of platform/infrastrucure team, there’s always a big issue with how to effectively prioritize the work, as there are often many competing priorities. I’ve asked Venkat about how they think about prioritization.

The really important message and how they think about infrastructure is the following.

They think about infrastructure as a product.

So, the main thing they keep in mind is that any kind of infrastructure you are building, e.g., CI/CD pipelines, data infrastructure, analytics, cloud infra for compute, etc., think of that as a product that you are building.

And everyone using your infrastructure (product) is the customer. Very similar to having an actual product and offering it to real customers.

And an example that Venkat mentioned:

If you are a startup, and you have a lot of competing customers, and you want to say “yes” to all of them, you find a way to make it work.

That’s very similar to what they try to do at the infrastructure organization as well. They try to say “yes” as much as they can, but oftentimes there has to be a certain negotiation.

They might not be able to do everything that a certain team asks for, but maybe they can do 4 out of 5 things, and that can be delivered in the following week.

Unblocking teams is a crucial part of prioritization

And the second important thing regarding prioritization is that if a certain ask is far away from their focus, they’ll ask how they can unblock that specific team as quickly as possible, so that at least they can move forward.

And they’ll focus on building a quick solution (even if that might not be the best possible solution), just to unblock that specific team. What’s important here is that the solution is built in a way that can be easily replaced with the proper solution down the line.

And what they’ll do after is launch a project where they would find the best solution to that specific ask, and build it in the next 1-3 months.

Think of it as building an MVP → unblocking the team with it → building an actual long-term solution and replacing the MVP.

Their primary challenge with infrastructure at OpenAI has always been the pace of growth

Venkat mentioned that building infrastructure that scales to these heights is a hard but not impossible task.

Read more

Read more

Intro

With AI-assisted engineering being the standard way of building software these days, every company is trying to answer the same question:

What does an AI-native engineering team actually look like?

To help us with this, I recently had the pleasure of talking with Katelyn Lesse, Head of Platform Engineering at Anthropic.

We talked about a LOT of different topics regarding Anthropic’s engineering culture, how they work, and how they build their products. She shared a lot of interesting insights, some of which will be shared today, and some in future articles.

In today’s article, I’ll share, based on our conversation, how Anthropic builds AI-native engineering teams.

This is an article for paid subscribers, and here is the full index:
- What does AI-native actually mean at Anthropic?
- The structure of AI-native teams
- Similar structure with an important difference
- With many projects happening simultaneously in the team, there’s a bigger need for PMs
- They are even looking for more PMs in a cross-functional team?
- No dedicated QAs, automated testing + AI Evals are more important than ever
- All of their code is AI-generated
- Defining the desired outcome is key when working with AI
🔒 Additional use cases for using AI in their work
🔒 Responsibility + accountability should always be on engineers, never on AI
🔒 AI-native engineers are becoming tech-agnostic
🔒 How has the onboarding of new engineers changed from 1-2 years ago?
🔒 Working with AI agents should be the new normal for all companies
🔒 Last words

Additionally, earlier this year, I talked with Thibault Sottiaux, Head of Codex at OpenAI, on how OpenAI is building AI-native engineering teams. If you haven’t read the article, I highly recommend doing so here:

Let’s start!

What does AI-native actually mean at Anthropic?

As mentioned in the article AI-Native Engineering Leadership, there are many definitions of being “AI-native” across different companies. I’ve asked Katelyn about what it means at Anthropic. She mentioned the following.

Being truly AI-native means that AI is built into the workflow so that it doesn’t feel like an extra tool.

Whether you’re writing code with AI in collaboration or running autonomous AI systems in the background, AI should become a part of the process rather than something separate.

When it works seamlessly and feels natural, that’s when you are AI-native.

The structure of AI-native teams

Throughout our conversation with Katelyn, one point she mentioned many times is the following:

Many aspects of software development haven’t changed, and likely don’t need to change, even as AI becomes deeply integrated into engineering teams.

Therefore, that’s exactly the case in the Anthropics team structure. They still use the traditional 2-pizza cross-functional team structure, with 5-8 engineers in the team, an engineering manager leading the team, a PM, and a designer as part of the team.

The reasoning for it is the following:

Teams still need enough people to build, operate, and maintain systems over time. Ownership, reliability, and shared knowledge are crucial, regardless of how much AI is involved. The difference is just that AI gives everyone significantly more leverage.

Similar structure with an important difference

In a traditional team, you had 1 tech lead, who would lead the project from the tech perspective and coordinate with other teams, while other engineers on the team focused more on implementing features and completing tasks.

Today, almost every engineer is expected to take on a tech lead role if needed. The reason are AI tools, which can enable individuals to accomplish a lot more than before.

As a result, the team size is unchanged, but the work changes.

A team of 8 engineers that previously focused on 1 or 2 projects at a time can now potentially run 4 or 5 projects in parallel.

The team still owns and maintains the same systems, but AI enables everyone to execute far more work in parallel.

With many projects happening simultaneously in the team, there’s a bigger need for PMs

Interestingly, Katelyn mentioned that AI has not reduced the need for PMs, especially TPMs, product managers who really understand the underlying tech as well. She sees the role as even more important.

That’s pretty different from what some other companies are doing, where they actually have fewer PMs. Like OpenAI with a 30:1 engineers per PM ratio, and companies like Telnyx or Portkey, where they work with 0 or a few PMs.

This is her reasoning: With engineers being able to build and ship software much faster with AI, the bottleneck shifts from implementation to decision-making. And the challenge is no longer whether a team can build something, but whether it is building the right thing. So, that’s where PMs come in.

Additionally, Anthropic has 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.

She sees that in an AI-native environment, strong product management becomes even more valuable because it ensures that increased engineering capacity is focused on the highest-impact problems.

They are even looking for more PMs in a cross-functional team?

Traditional teams had 1 product manager supporting a team of engineers. They have the same setup → 1 PM per team, but she believes this will change soon in their teams.

There are simply more decisions to make, more customer needs to understand, and more projects to coordinate. Because of this, her team is finding that they need more PMs than before.

She believes every team needs someone who deeply understands what customers need, what the team is trying to achieve, and what should be built next.

No dedicated QAs, automated testing + AI Evals are more important than ever

They don’t have a dedicated QA engineer inside the team. Testing is a shared responsibility across the team.

They also rely heavily on automated testing. And because AI allows engineers to generate code much faster, they have to be careful about how tests are written.

They value the traditional quality pyramid:

• Most unit tests

• Lesser integration test

• Even fewer e2e tests

And specifically, they focus on creating quality unit tests and a smaller number of slower end-to-end tests. This helps keep development moving quickly and prevents the CI pipeline from becoming a bottleneck (long time for tests to pass).

Another important part of testing is evaluating their AI models and products (AI Evals). They invest a lot of time in building and maintaining evaluation systems that help them measure quality and ensure new models, products, and platform updates perform as expected before reaching customers.

This work is not owned by a single team. Engineers spend a lot of time on testing and evals, and PMs are also heavily involved as well. Everyone contributes to making sure products meet a high standard before they are released.

She also mentioned that roles inside the team have become a lot more flexible and that there is no clear separation of responsibilities.

Like everyone these days, they are also learning as they go, they don’t believe they have found a perfect formula, they are adjusting based on what they see works for them and what doesn’t.

All of their code is AI-generated

I asked Katelyn if her teams have a similar sentiment to what Boris Cherny (Head of Claude Code) has mentioned, which is that all of his code is AI-generated these days.

And she mentioned that it’s what their teams do as well. However, the important thing that she added is that this doesn’t mean AI is building software on its own.

She mentioned that engineers play the most important role in designing systems and making architectural decisions. AI is an excellent collaborator during this process, but engineers are responsible for deciding how large and complex systems should be built.

Once the design is clear, the implementation is largely handled by AI agents. Rather than switching back and forth between AI agents generating code and manually writing code, it’s better to guide the agents until they produce the desired result.

This is also a very important thing she mentioned:

The effective use of AI is not about asking an LLM to generate code and accepting the first answer. You should continuously steer the agent, provide feedback, and let it test and improve its own work until it meets the required standard.

Because of this, she believes reviewing AI-generated work has become one of the most valuable engineering skills.

Defining the desired outcome is key when working with AI

Additionally, her top tip for working with agents is to define the desired outcome instead of simply assigning a task.

Rather than saying, “Build me a dashboard,” you should clearly describe what the finished dashboard should accomplish, what success looks like, and any important requirements or examples.

To support this workflow, her team built a feature called Outcomes in Claude Managed Agents.

You provide a simple description of the desired result, and a second AI agent evaluates whether the generated solution meets those expectations. If it doesn’t, the coding agent automatically iterates and tries again before presenting the final result.

The clearer you define the outcome, the better the AI performs.

Good prompts are less about telling the AI what to do step by step and more about clearly describing what success looks like.

Additional use cases for using AI in their work

Read more

Read more

Intro

We hear the word “moat” a lot these days, especially in the context of AI.

“Good judgment is the new moat for engineers”. “Harness is the new moat for AI products”. “Loop engineering is the new moat”.

So, in the spirit of a trending word, I’ll be sharing what I believe is the new moat (competitive advantage) for engineering leaders in this article.

The insights are based on what I am hearing and seeing regularly from talking with different engineers and engineering leaders across the industry, and what I recommend they do in order to become valuable at their company and grow in their careers.

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

- This is the situation that I’ve seen happening now quite a few times
- Another situation that happens on a team level
- Being able to manage expectations well is becoming THE job of engineering leaders
🔒 How to build credibility and become trustworthy?
🔒 Building up your skills
🔒 Improve the way people perceive you
🔒 A really good flow that I suggest these days to everyone
🔒 External vs internal credibility
🔒 Becoming trustworthy
🔒 Last words

Let’s start!

This is the situation that I’ve seen happening now quite a few times

This is a fictional example, but imagine you are a CTO or a VP of Engineering of a mid-size company. The CEO, or some other C-suite leader, happens to hear about a new AI tool or reads a certain blog post about a specific approach that would 10x the engineering productivity.

There are 2 options on what happens next.

1. Sends the link to the tool/blog post to the engineering leader e.g., CTO, VP of Engineering.

2. Starts planning the adoption process of the tool or that specific approach.

Option 1 is totally fine, and I definitely recommend that CEOs and other C-suite members be curious and look for what may be a good opportunity for the organization.

But the problem comes with option 2. They don’t consult with the engineering leader to determine whether that tool is actually worth it, they just start with the adoption process.

They set up all the meetings and start the initiative. After it’s already in progress, and everyone is talking about it, they call the engineering leader in the room to just align on the details of the execution.

That’s unfortunately where it’s too late for the engineering leader to have a say, whether it’s actually worth it or not. They are just expected to own the implementation with the expectation of engineering productivity to increase drastically. And that’s the problem.

As an engineering leader, you shouldn’t be “looped in” to a new AI initiative, you should be the one who is owning that initiative.

And the reason why you are not owning it is the lack of trust and credibility. You haven’t made yourself trustworthy enough to have a say in whether the tool is even needed or not, which is a huge issue and can hurt you a lot in your role.

Another situation that happens on a team level

You are either a Tech Lead (Staff), Team Lead, or an EM leading the team. Your Director of Engineering comes back from a conference and is hyped by all the engineering productivity gains they hear that other companies have accomplished.

They might also be pressured by the leadership team to show a higher productivity increase in their teams.

You’ve been telling them that you and the team are trying everything they can to find productivity improvements with AI tools, but because of the complexity of the codebase and the nature of the work (infrastructure), the productivity increases are not that high, and you can’t just blindly trust AI-generated code, as the work is very critical to ensure the stability of the services.

There are 3 options on what happens next.

1. They believe you and just ask a few more questions about what the steps to higher productivity would be.

2. They don’t believe you, and start asking other leads about why your team doesn’t have so much productivity improvements.

3. Starts planning the adoption process of a new tool without telling your team, or worse, looks to disrupt the team, and change the members or the lead of the team.

The first option is where you want to be, and where your word has weight. But with options 2 and 3, you might have quite an issue, and the main reason, again, is credibility and trust.

They don’t trust you enough that your word has weight and that you mean to do the right things for the organization. This can be quite an issue if you don’t improve in this area.

Being able to manage expectations well is becoming THE job of engineering leaders

As both examples above have illustrated, there’s a lot of pressure on people to showcase “magical results” with AI, since many people are experiencing FOMO regarding AI, because they hear from other people how well they are doing using AI.

And the problem comes if you, as an engineering leader, don’t have that trust and credibility. If that’s the case, your input might not be taken seriously, which can cause a lot of issues for you and your team.

So, my main advice these days is: Figure out how you can make yourself as trustworthy as possible.

This can single-handedly solve so many issues for you as an engineering leader, and of course, this is a big competitive advantage that’ll help you grow in your career.

There are many ways you can do that, the important thing is that you showcase yourself as an expert in what you do and have some social proof.

For me, personally, writing online has worked best, and I definitely recommend it to everyone to start doing that.

Now, let me share in detail on what you should do to become trustworthy and build credibility, so your word has weight, which is crucial at this time!

As mentioned, this can be the difference in having a great time in your role and being a candidate for promotion, or you stagnate and be a potential candidate for replacement.

How to build credibility and become trustworthy?

Read more

Read more

Intro

Performance reviews play an important part in any organization, and when done the right way, they help a lot with:

• acknowledging the good work,

• areas for improvement and

• setting individual goals.

It’s important to use them the right way and not have them for the wrong reasons.

There are cases where companies use them for the wrong reasons and track metrics that don’t make sense, like lines of code delivered, AI token consumption (a popular metric these days).

The way I look at performance review meetings and the biggest benefit of them is that everyone sets goals and has clarity on where they want to grow and in which areas they can improve.

In today’s article, I’ll be breaking down what a good performance review process looks like, my advice on how to handle it, and also tips for everyone on how to implement it correctly.

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

- You shouldn’t wait for the performance review to give feedback
- Every company has a slightly different process regarding performance reviews
- The cadence of performance reviews
- Understanding different reviews
🔒 The tools to use
🔒 The process for setting up performance reviews
🔒 Prepare for the meeting
🔒 An important tip for writing an effective self-review: updating your brag list of wins regularly
🔒 Last words

Let’s start!

You shouldn’t wait for the performance review to give feedback

Let’s first start with a very important thought, and that is that I am a big believer in giving early and frequent feedback and especially using 1:1 meetings for that.

Therefore, I always keep in mind the following:

Any feedback for improvement you give on a performance review should not come across as a surprise.

You should already give feedback on 1:1 meetings regularly beforehand.

If you wait for the performance review, it’s overwhelming, and it’s impossible to accurately capture everything, especially if you do performance reviews once a year.

Timely feedback can be crucial for the success of your team and people. In my opinion, this is key if you want to lead a team successfully.

Waiting too long to give feedback is not the way to go, and I learned that the hard way as a first-time manager. Here is my story:

I thought that my timing to give feedback needed to be perfect. And because of my waiting, things got a lot worse.

I said to myself: “Maybe things will get better if I wait for a bit more time”. Well, the reality was that things didn’t. And my waiting for perfect timing made it a lot worse.

Similar to making decisions. “They need to be perfect”, I said to myself. And that got me to the place where I didn’t make the decisions fast enough, which actually blocked my team from progressing.

And I realized over time that not all the decisions will be the absolute right ones, but it’s much better to make a decision and reverse it later if needed, instead of not making it at all.

Now that we understand how important continuous feedback is, let’s focus more on how to do performance reviews.

Every company has a slightly different process regarding performance reviews

In this article, I am sharing my experience on what has worked well for me and what my recommendation is regarding the performance review process.

But it’s very important to understand that companies might have a slightly different process, the tools they use, and also the cadence.

So, make sure to check what the process at your company looks like. I’ll be writing from the perspective of a manager who is setting up the performance review process in the organization for the first time.

The cadence of performance reviews

The cadence that worked best for me is once a year, especially if you are giving regular feedback in 1:1 meetings. The specific timing doesn’t matter that much, some companies do it in the middle of the year, some in December.

I did it on both occasions, and the only important thing is alignment across the full organization.

Every 6-month cadence works as well, but then you need to communicate that on one occasion, there won’t be salary increases and promotions (unless a company makes that possible 2x per year).

I also heard that some companies do quarterly reviews as well, but in my opinion, that’s too frequent. It’s not enough time to accurately capture the goals and work through them, especially if you regularly meet in a 1:1 meeting and talk about them.

Once a year is great, because normally, companies have a policy to do promotions and salary increases once a year, and then it goes well together with the performance review, so everyone’s expectations are aligned.

As an employee, if you know when you can potentially expect your salary to be increased or get promoted, you can plan on achieving the goals that you’ve set for yourself during that time, and share the results at the performance review meeting.

That’s also the reason why keeping a brag list of wins is so important, we’ll go more into that later in the article!

Understanding different reviews

First, it’s important to know what you want to track. These are the 4 main reviews (based on priority) that you can track:

• Self-review: Every individual reflects on their own wins, weaknesses, and their career development (priority 5/5)

It’s really important that this part is included, because that’s how every individual can reflect on how they are doing based on their own perspective, share all the wins, and also share their goals as well.

• Manager review: Managers evaluate progress against objectives and assess the overall role effectiveness of individuals (priority 5/5)

Of course, the performance review is not an actual performance review if a manager doesn’t evaluate and assess how a certain individual is doing in their role. As mentioned in the beginning, the evaluation should not come as a surprise.

• Peer review: Colleagues provide feedback on collaboration and support (priority 3/5)

This is not mandatory, but I recommend doing this because it may give a bit of a signal on how effectively the specific individual is collaborating and supporting others. These reviews should also be anonymous.

• Upward review: Direct reports evaluate their manager’s effectiveness and leadership skills (priority 3/5)

This one is not mandatory as well, but it can be a good signal on how you, as a manager, are doing (or other managers). These reviews should also be anonymous.

The tools to use

Read more

Read more

Intro

A question that came up frequently on the Engineering Leadership LIVE event in San Francisco that I hosted together with my friends from Augment Code was:

Should I go back to being an IC or stay being an Engineering Manager?

Here are also some of the pictures from the event:

It’s a very important question to ask, because there are changes in our industry, and it’s crucial that you understand what’s happening so you can make the best decision for yourself.

There are different trends that many companies are following these days, and there’s also a bit of a change in how I think about moving to Director or VP roles (executive). So, if you are an engineering manager, asking yourself this question, it’s a must-read article for you!

In today’s article, I am sharing my advice on what you should do, what has changed, some of the insights are based on my discussions we had at the event, and of course, what I am seeing and hearing from many other engineers and engineering leaders across the industry.

This is an article for paid subscribers, and here is the full index:
- How are engineering leadership roles changing?
- Engineering leadership skills are more important than ever
- Managers, more desired than ever to become ICs
🔒 Should you go back to being an IC as an EM?
🔒 1. If your company decides to move you from an engineering manager to an equivalent position in the IC path (Staff or Principal Engineer)
🔒 2. If you are an EM right now and are thinking of making a move back to being an IC (Staff or Principal Engineer)
🔒 3. If you are an EM looking for a new role
🔒 Both paths can be a very viable choice
🔒 Last words

Let’s start!

How are engineering leadership roles changing?

This is something I have already mentioned in the article: AI-Native Engineering Leadership, but I believe it’s really important that we go through it here as well, because it’s crucial that you understand what’s happening in the industry.

I’ve always looked at engineering leadership roles as the following:

• IC path: Staff Engineer, Tech Lead, Lead Engineer or higher (Principal, Distinguished)

• Management path: Team Lead, Engineering Manager, or higher (Director, VP, CTO)

• Architect path: (Software) Architect or any kind of other architect (Solutions, Distributed, etc.) or higher (Staff, Principal)

Here is the overview of the engineering leadership roles 2 years ago:

Now, today, there are a lot more tech leads, as a lot of engineers are expected to be one, and also, there are fewer middle managers. Director-level or above roles stay the same as they were.

For middle managers, e.g., (Sr.) Engineering Managers, it’s becoming more and more common to be expected to take on Staff Engineer roles if needed, and Staff+ Engineers taking on manager hats if needed. Most commonly, EMs taking the Staff role.

And the same for Architects as well → taking on a Staff Engineer role or manager role if needed.

This has shown to be very true, especially when Amazon started its initiative of increasing the ratio of managers to individual contributors by 15%, and many of the companies followed the approach. And now we’re seeing this trend in many other companies, as well.

So, that’s why we are seeing a lot of managers taking more of a hands-on work and also Staff Engineers and architects taking, in some cases, also a manager role as well.

Engineering leadership skills are more important than ever

Speaking with engineers and engineering leaders from companies like OpenAI, Anthropic, Big Tech & startups, and many other people across the industry. One thing is clear, and it’s becoming more and more common.

There’s a lot more individual ownership of projects than there used to be.

As an engineer, in the past, you might work on a project as part of the team, but now, where I see the trend is heading, is that a team is working on many different projects simultaneously at the same time.

Therefore, almost everyone is expected to have tech lead-like skills. Good communication, being a leader, working well with cross-functional people and stakeholders, while being able to start and finish projects successfully, either by yourself or by delegating work to others.

If you don’t have such skills, or you don’t wish to develop them (you definitely should, though!), the way to stand out is to be an extreme specialist in a certain area that is rare and valuable. Having a superpower in a specific area that is very valuable to the organization also brings significant value.

Because engineering leadership skills are more important than ever, that’s the reason why many managers are very desired to become ICs again. Let’s get to that next.

Managers, more desired than ever to become ICs

Being a successful manager means that you have developed good human-related skills, which are extremely desired in IC roles these days.

In addition, you also have a good context of the business/product and really understand the challenges and motivations from stakeholders, because you have been a stakeholder for a while as a manager.

With coding becoming a lot more accessible, a lot of managers can be extremely productive and provide a huge impact. The skills that you learn as a manager are the same skills needed when you are doing AI-assisted engineering.

You need to know what and how to delegate correctly, dissect bigger tasks into smaller, manageable pieces, be good at giving feedback and providing instructions, give clear explanations, refine and improve based on the output, and also have patience as well.

All very important skills to thrive as an IC.

And especially if, as a manager, you stayed hands-on and have a good grasp of engineering fundamentals. This is a big plus if you potentially want to target the Staff+ roles as an engineering manager, which I’ll share my thoughts and recommendations next!

Should you go back to being an IC as an EM?

Read more

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:

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.