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

Last month, together with my friends from Augment Code, we hosted an event called: Engineering Leadership LIVE in San Francisco. It was a blast, and there were so many insightful discussions we had!

As part of the event, we also had 4 talks.

- Gregor Ojstersek, CTO & Author, Engineering Leadership newsletter
Talk: AI-Native Engineering Leadership

You can also watch the full recording of my talk here:

And the full overview of my talk in this article:

- Vinay Perneti, VP of Engineering, Augment Code
Talk: We Thought AI Transformation Was About Adopting Agents. We Were Wrong.

- Andrew Churchill, CTO, Weave
Talk: What Actually Works: AI Coding Patterns from the Top 1% of Teams

- Anwar Haneef, GM & Head of Ecosystem, Canva
Talk: Your Product’s Next User Might Be an AI Agent. What Engineering Leaders Need to Know.

Today, I am sharing the overview and the recording of Andrew Churchill’s talk at the event.

Recording of the talk at the event

You can watch/listen to the talk below, or you can keep reading for the full insights.

Let’s start!

The hype of “10 AI agents doing 400x productivity” is not real

There is so much hype on social media about how to be more productive using AI, but the problem is that those are some specific examples, which do not reflect the actual data on what they at Weave are seeing.

At Weave, they are building a platform for understanding how software engineers work. You can also read a full deep dive on how they work in this article:

In today’s article, I am sharing (based on Andrew’s talk) the results regarding what makes the top 1% teams successful, based on the data from Weave’s usage from hundreds of companies and 10k+ engineers.

It’s also important to mention that the 1% teams in this case are being measured based on the Weave’s code output metric, which is an ML-based algorithm built by Weave to check how effective the work that’s being delivered is.

Not tracking purely lines of code or how many commits were delivered, but understanding the output based on the question: “How long would this PR take an expert engineer to complete?”

The result is a standard unit to quantify output, which is comparable across individuals, teams, languages, and organizations.

There's a big difference between the top 1% teams and the rest

When you look at the chart, there’s an exponential difference between the top 1% of engineers and the rest. Especially interesting is how big a difference it is between the top 10% (P90) and top 1% (P99), and then also between P99 and P50, with a really huge difference.

That’s aligned with the:

• Parreto’s 80:20 rule, as we can see, the top 20% of people carry the majority of the productivity.

• The power law of distribution (a tiny fraction of individuals generates the vast majority of the impact, success) makes sense in this case, as the top 1% of engineers may produce 10–100× the impact of the median.

In the next sections, we will go through the 5 specific areas of what top 1% teams, based on the Weave’s code output metric, do:

1. Their engineering organization structure

2. How much are they spending on AI tools (AI tokens) in relation to how much value such code contributes to success

3. How do they review their code

4. They have higher output, does it mean they also have more bugs?

5. The number of deployments they do

For each area, I am sharing (based on the talk) what the top 1% do that works for them, with a specific example. Let’s start with the first one, the structure of the organization.

1. The organizational structure of the top 1% teams

Many of the top teams are going more toward flatter orgs, have smaller teams, and more higher agency ICs. Higher agency meaning that engineers are owning projects end-to-end and are being more product & business-minded as an engineer e.g., product engineers.

In the talk, Andrew also mentioned that they see that the product engineer role is not a common title anymore, as the expectation is merging just to the title “software engineer”. This is something I have also mentioned in the article AI-Native Engineering Leadership.

Examples of the 2 teams:

• Telnyx (extreme example)

Their engineering org consists of 200 engineers, 0 engineering managers, and 1 VP of Engineering. They took the word “flatter org” to the extreme.

Based on the data from Weave, they are doing very well based on their metric, but it’s really important to mention that such an engineering org structure doesn’t work for everyone.

In my opinion, what helps them to have such a structure is the nature of their product, it’s very technical, so it helps a lot for engineers to be more product-oriented as well.

A similar example is what I have recently written about. The company called PortKey has 24 engineers and 0 product managers. Read the full deep dive on how they work in this article:

• PostHog

Teams of 1-3 engineers, with an assigned Team Lead for every team (who is a DRI - directly responsible individual). The Team Lead also reports directly to the VP.

They want to avoid the coordination task, which grows quite a lot more when you have 4 or more people inside a team. That’s why they want to keep their teams to a maximum of 3 people.

PostHog is betting on the AI-native team structure similar to what OpenAI is doing. You can read how OpenAI is building AI-native engineering teams in this article:

It’s also important to mention that both of these companies have explosive headcount growth and are hiring a lot of people. They are not “replacing” people with AI, but they are betting on the premise of:

More people mean more productivity exponentially.

And they are not going in the direction of the trend that somewhat bigger companies go for: similar productivity, with fewer people.

I personally think that in the long run, the companies that bet on more people with more productivity will have a lot more advantages in comparison to companies that just want to stay similarly productive as before.

2. Top 1% teams have a good ratio of spending and delivering value

The top teams, which have the highest output, spend more on AI tools, e.g., AI tokens, than the ones that have a lower output, which is not surprising. More AI tool spending should increase the overall amount of work that you deliver.

This is also what we see from the chart as well:

But the interesting part is that the top teams are effectively still keeping the costs lower for the delivery of their work. Which can be seen in this chart:

Good examples of such companies are:

• Robinhood

They created a custom agent, fine-tuned to their codebase & requirements, which helps them to keep the costs a lot smaller (token efficiency), while increasing productivity, as it provides a lot more accurate responses based on their specific prompts.

• Spott

Every engineer is running 5 (median) agents at the same time. They are spending a lot on AI tools, but based on the data from Weave, they also have significantly more output per dollar than other teams. So, they spend a lot → while they get exponentially more output.

3. Top 1% teams are focusing on AI code reviews and reviewing specs

As we can see from these charts, the top 1% teams have a lot fewer human PR reviews (in percentage) than other teams. But this doesn’t mean that their code gets merged unchecked.

Instead, they are utilizing AI code reviews and optimizing such reviews to give them as much accuracy as possible in order to be confident with the change.

What they see at Weave (and they do the same as well) is that, instead of focusing a lot on reviewing code, after the PR is opened, the focus should be on reviewing specs before the code is even generated. And they believe a lot of the top teams are doing that.

At Weave, they also use 4-5 different AI code reviewers and have a policy that the human code reviews are optional, which helps them move a lot faster.

A good example Andrew has mentioned:

It’s much easier to review 300 lines of markdown (spec) than 3000 lines of code.

4. Top 1% teams have higher output, but the bug rate stays similar

This is an interesting insight, because you would think that with more code and PRs being finished, the rate of bugs would also linearly increase. But based on the data with more output, there is not a lot of increase in the number of bugs being produced. The chart of the data here:

A lot of the teams utilize AI to test their product on a somewhat recurring basis. An interesting example that Andrew mentioned is the company called &AI. They have 5 laptops running 24/7 with Codex 5.5 and doing the QA testing process → testing their app. This helps them to spot the bugs in production before users spot them.

It’s important to mention this is just one example of how you can use AI to help you with finding issues, there are a lot more different ways you can include AI to help you with ensuring your software works correctly, you just need to find what may work for your specific case.

5. Top teams are deploying more to production than others

This hasn’t really changed with AI, as many teams have optimized the way they work based on DORA metrics, and CI/CD has become quite popular in the last 5-10 years.

As we can see from the data, the top teams are deploying more than others:

What’s important to mention here is that the number of deployments can positively affect to a certain extent:

If you deploy 10 times per day (10 PRs being merged), it’s not going to be so much more effective than if you were to just deploy 1 time per day (10 PRs).

So, if you optimize for pure production deployment, you won’t get the increase in the delivery of the additions to the product.

And as we can see from this data, even for larger companies, the amount of deployments that top teams do is higher than the rest of the teams:

Advice on how to improve

So, the question at the end of this article is: How to take this advice in your case so that your teams improve?

Andrew mentioned in the talk that looking to LinkedIn for the latest hype usually isn’t the answer!

Instead, the recommendation is to focus on understanding where you are today and measuring your progress over time. What this means is that you need some data on where you are today, so you can focus on improving it. And then have a consistent way of checking how you are doing in that area over time.

Keep experimenting, identify what’s working, and do more of it, and also stop doing what’s not working.

Last words

Special thanks to Andrew for sharing his insights in his talk at the Engineering Leadership LIVE event in San Francisco. More overviews of talks will be shared in future editions of the newsletter. Stay tuned!

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.

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.

Intro

I recently had the pleasure of visiting OpenAI’s offices in San Francisco, and one of the people I talked to there was Michael Bolin, a former Distinguished Engineer at Meta, now OpenAI Tech Lead for the Codex open source repo (Codex CLI).

Michael is also a fellow O’Reilly author, he wrote a book titled Closure: The Definitive Guide, dating back to 2010. Additionally, he created Buck, an open-source build tool at Meta, and he worked on Google Calendar during his time at Google.

We talked all about how he does AI-assisted engineering and what his workflow looks like. We went through a specific feature that he recently worked on, and what surprised me the most is that his workflow is very simple and straightforward.

Essentially, his workflow is the following: Write the spec → simple prompt → review the code.

No crazy AI workflows. Just clear thinking, good judgment, and fast iteration. I am sharing all the details on how he does it in this article!

This is an article for paid subscribers, and here is the full index:
- Building a permissions system within Codex CLI
- Writing requirements
- Initial implementation
- Handling merge conflicts
- Importance of keeping PR code sizes manageable and providing context with past PRs
- Codex creating PRs versus an engineer creating PRs in collaboration with Codex
🔒 Agentic PRs help doing more than 1 or 2 tasks at the time
🔒 Integration tests give a lot stronger signals than unit tests if the app is working correctly
🔒 Human code review versus AI code review
🔒 Example of how to use Codex to resolve an issue
🔒 Good fundamentals are crucial when doing AI-assisted engineering
🔒 Last words

Let’s start!

Building a permissions system within Codex CLI

We started our discussion with the project they recently finished, the permissions system within Codex CLI. He mentioned that the motivation behind building it within Codex is especially for Enterprise companies. Enterprises love features, but they also need constraints on which features can be used based on certain permissions.

Enterprises also care about keeping AI’s actions contained and secure, so it can only access and modify what it’s allowed to. So, ensuring that this is handled correctly, they also worked on features related to sandboxing.

This was a bigger project that the Codex team has worked on over several months.

Now, let’s go into how the project has started.

Writing requirements

The requirements have been written in a very simple way. Michael created a Notion document, where he described the requirements and functionalities that need to be supported. Basically a tech spec.

Then he asked the team to check and comment on the spec and specific parts of it. The team took a look, and everyone shared their perspective on what’s potentially missing or what could be done differently, which resulted in refining the initial design.

When that process was done, all the comments were addressed, and the team was happy with it, then they started with the implementation phase of the project.

Initial implementation

When it was time to implement the feature, they already had support for a Notion connector in Codex. So, instead of needing to copy and paste requirements in the context, Michael simply pasted the Notion URL into Codex and said, “Now I want to build this”.

Because of the Notion connector, Codex was able to go directly to the source, read the requirements, comments, and discussion history. Michael explicitly mentioned that he really liked this part as it was much nicer than manually recreating all that context.

The first thing he asked Codex to do was create a plan and break the work into a set of right-sized pull requests.

Michael also mentioned that he doesn’t want 2,000-line PRs because a human still has to review them, which would make the experience very painful.

The initially generated code by Codex was around 6 PRs. They started working through them, reviewing the code, testing, handling merge conflicts, and doing refinements along the way.

That’s how their workflow essentially looked for building the project.

Handling merge conflicts

At this point, I asked Michael about handling merge conflicts for AI-generated code, as that can be quite painful, especially if you have many PRs open touching the same parts of the codebase.

He mentioned that Codex is actually a lot more disciplined when dealing with merge conflicts than he is. He created his own skill for dealing with merge conflicts, which is basically a specific set of instructions.

With the skill, as changes happen in parallel and files get modified by other engineers, he can simply let Codex handle a lot of that work consistently.

Importance of keeping PR code sizes manageable and providing context with past PRs

He mentioned that he’s a big advocate of creating right-sized pull requests. He often reminds Codex that a human needs to review the code, so changes should be broken into a size that is still reviewable.

Sometimes he explicitly tells it how he wants the work divided. Other times, he asks:

“Where does it make sense to split this change into smaller PRs?” or “How would you break this change into reviewable pieces?”

He also provides testing expectations when he has a specific validation strategy in mind.

Another practice he relies on heavily is referencing related pull requests. In fact, that’s often one of the most useful sources of context, he mentions.

Related PRs contain code, discussions, comments, and decisions. Giving Codex access to that context can significantly improve its understanding and output.

Additionally, he also mentioned that he occasionally rejects PRs opened by other people with the message of “PR being too large”, and that historically might have caused arguments because splitting work required effort.

Today, it’s much easier with AI coding tools. You can simply ask Codex to do it. That makes it much easier to enforce good review practices. The biggest thing is getting reviews down to the right size so it’s clear what each pull request is actually doing.

Codex creating PRs versus engineer creating PRs in collaboration with Codex

Or we could also call it Agentic PRs versus AI-assisted PRs. I know preference for most engineers these days is the second one, using Claude Code, Cursor, or Codex, while Michael has the preference for the first one (Codex creating PRs), which I asked him for the reasoning.

He mentioned that their CI takes around 15 to 20 minutes to run, and he wants Codex to create the pull request immediately so CI can start running as soon as possible.

They also have skills around what they call “babysitting PRs” or “babysitting CI”. Once the pull request exists, Codex watches for failures and can react to them automatically.

He also often tell Codex not to run most tests locally because CI will run the tests across Mac, Linux, and Windows anyway. He’d rather get the pipeline started immediately.

It also means, that he doesn’t need to have multiple full test suites consuming resources on his machine. Imagine, if you run 5-6 local changes at the same time, and all the tests start to run, the amount of compute it consumes on a local machine, makes it really hard to be productive.

Agentic PRs help doing more than 1 or 2 tasks at the same time

Read more

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

Measure AI’s impact on engineering.

Claude writes code 10x faster than a human. So why is engineering productivity up 20%, not 200%?

Engineers spend only 30–40% of their time coding. The rest goes to planning, deployments, support, reviews, and everything in between.

Most of this work has been invisible and hard to measure. Larridin changes that by showing how engineering work flows across your org, uncovering blockers, and helping teams fix what slows them down.

Larridin gives AI-native teams a full view of developer productivity, from traditional engineering metrics to AI-native insights like Agent Effectiveness.

Unlock AI-native engineering potential

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

Intro

I recently had the pleasure of speaking with Vrushank Vyas, Head of GTM and CS at Portkey. We were planning to meet on-site at their offices in San Francisco, but the timing didn’t work in our favor at this time, so we talked over Zoom regarding how Portkey works and builds its product.

The especially interesting part he mentioned is that every engineer is expected to wear a product hat and have complete ownership of making decisions end-to-end.

It makes a lot of sense since their product is infrastructure and engineering-heavy, so you need to technically understand the product in order to make good decisions.

In today’s article, we are going over in detail how a company, which is planned to be acquired by Palo Alto Networks, builds its product. Their processes, culture, focus, hiring, etc, and much more!

P.S. This article is part of the articles where I speak with a relevant company and go through their engineering culture and processes. I recently spent time in San Francisco talking with different companies, and I am sharing how these companies work.

If you like these kind of articles, you’ll like these as well:

• How OpenAI’s Codex Team Works and Leverages AI

• Inside OpenAI’s Engineering Culture: How the Teams Behind ChatGPT Work

• How an AI-Native Startup From SF Works and Builds Its Product

Let’s start.

How big is Portkey, and what do they do?

The company started a bit more than 3 years ago. And in total, there are around 32 people at this time:

• 24 engineers

• 8 people outside of engineering (0 product managers and 1 product designer)

They have about 4 people in the US, and the rest of the team is in India. The way they work fundamentally differentiates from a company I recently did a deep dive into, where everyone is on-site working together in the offices in SF.

Their main focus is on building what Vrushank called plumbing infrastructure for AI. A platform that equips teams that are building AI products with everything they need: AI gateway, observability, guardrails, governance, and prompt management.

Their tech stack and (AI coding) tools

Vrushank mentioned that they are really heavy on Node.js with TypeScript, where most of the things they build are on this stack. He mentioned examples in particular, such as their Gateway service and their Control Panel.

Regarding the tools for tasks and project management, they use Linear and Notion.

An important thing he mentioned is that they are trying to move away from separate tools as much as possible, and have as many things inside the main repository as markdown files. The reason is that AI agents can much better interpret that and use markdown instead of having the context in many different places.

They made an internal bet that before the end of the year, they’ll move off from some of the tools they use right now, and just use simple .md inside the GitHub repo.

For AI coding tools, they used to work a lot more with Cursor, now they are moving a lot more towards Claude Code, where almost everyone in the company has built custom skills they use daily.

They also built 2 custom AI agents

Vrushank mentioned they are always trying out what may be a fit for them and might do quick proof of concepts, but he mentioned 2 notable, useful AI agents they use daily:

1. Task-tracking agent based on the discussions with customers

An agent that reviews all transcripts and either drafts the needed email automatically or sends them a Slack message for approval. They just click approve, and it sends the next steps to the customer. It’s built on top of Claude Agent SDK.

2. A pricing agent

They call it Dagger. It scans 1600+ LLMs across 80+ AI providers, which include providers like OpenAI, Anthropic, Amazon Bedrock, Microsoft Azure, Google Vertex AI, Fireworks AI, and Together AI.

The challenge is keeping up with constant changes, like new APIs, features, and pricing updates. The gateway has to support all of these changes while also generating accurate metrics for every request, including cost.

To handle that, they’ve built a pricing agent on top of the Claude Agent SDK. It runs continuously, monitors provider websites and API changes, detects pricing or API updates, and automatically opens PRs with the changes.

They are very selective about what they build

Every feature has to justify its place. Prototyping is fast, they can build something in a day or two, but deciding what to build and use in production is where they put in a lot of thought.

Their philosophy is that the core production traffic their customers run through Portkey must always work reliably. They only build new features when they solve a real, broadly relevant production need.

When a customer requests something new, they first look at whether the existing product already solves it. If it does, they guide the customer to that solution. If it doesn’t, and it’s a valid requirement for an infrastructure platform, then they build it.

Vrushank mentioned that the key is that every feature has to scale. They process trillions of tokens every day, and all 100+ enterprise customers run on the exact same product.

They don’t maintain custom builds or separate release branches. So before shipping anything, they make sure it can reliably handle production scale, from hundreds of millions of requests to trillions of tokens per day.

An example of a feature they said no to

They had customers ask them to build AI evals inside their platform so they could track the accuracy of their AI products in the platform. Vrushank mentioned that they could have built it and likely won more customers, but they’ve chosen not to.

They’ve been very deliberate about staying focused on production traffic. Their view is that evals are still primarily part of the development workflow, while their focus is on running production AI traffic reliably at scale.

They know that the moment they’d build evals, it becomes an entirely separate product with its own heavy feature demands and roadmap. Rather than spreading themselves too thin, they’ve stayed disciplined and focused on solving the production infrastructure layer really well.

They have a strong sense of direction, but not a detailed roadmap

They focus more on direction, instead of planning out the entire roadmap for the year. Instead, they like to operate around strategic themes.

Vrushank mentioned that in AI, things move too quickly for a fixed long-term roadmap, so they focus on identifying important shifts and building infrastructure products around them.

For example, they started with the AI gateway, then built the MCP gateway, and are now building the agent gateway. They’ve even considered a sandbox gateway. Their focus is less about committing to a detailed roadmap and more about following the broader theme of becoming the infrastructure layer for AI systems.

Customer demand plays a role as well. They evaluate whether something fits their long-term direction and whether it strengthens their position as the AI gateway company. This has helped them avoid distractions their competitors have pursued, like RAG libraries and RAG agents. Their focus is on building the best AI gateway possible.

Beyond that, they see opportunities to add value on top of the data they already generate, like helping customers decrease the token spend by optimizing model selection with recommendations on when a smaller model could handle a request just as effectively as a larger one.

But these are still near-term explorations, not fixed roadmap commitments.

Their engineering culture is highly cross-functional

Everyone wears multiple hats. Engineers can be forward-deployed, product-focused, and directly involved in customer support. The same person who builds a feature might also handle the UI, write the documentation, support customers using it, and jump on a call to debug issues directly.

They also put a big focus on creating great documentation, and the engineers building the product are also responsible for documenting and supporting it.

At the same time, they’re not trying to create a “hustle” environment or push extreme work hours. People go home at a normal time and maintain balance outside of work.

The expectation is simply that engineers take ownership end-to-end.

Vrushank also mentioned that it’s a culture built for people who thrive on variety, whether that’s building features, debugging customer issues, writing docs, or jumping into product discussions. It’s not for everyone, but for people who enjoy broad ownership and wearing many hats, it’s a very strong fit.

They are intentionally building what they describe as a “barbell” engineering organization

On one end are engineers deeply focused on reliability, making sure the infrastructure is stable, scalable, and continues to perform well.

On the other end are engineers who move fast and turn ideas into reality quickly. If they spot an opportunity, they can prototype and ship it immediately.

Vrushank mentioned a good example: Their rankings page. It started as a simple idea to make use of the data Portkey already had, but building it required real engineering work, from anonymizing enterprise data and masking sensitive information to ensuring that the data updates reliably every day.

What made this a great example is the ownership behind it. The engineer who built it went above and beyond to realize it. On his own initiative, he bought an LED display, connected it with an Arduino, and turned it into a live leaderboard running 24/7 in the office, showing real-time model usage trends to anyone walking by.

That’s what they mean by the barbell approach. One side is deeply technical infrastructure engineers focused on reliability, and the other is builders who can quickly create bold, visible new products and experiences.

We’ve already mentioned in one of the previous articles that being a great generalist or extreme specialist is the best way to get more opportunities. Being in the middle, not so much.

About 40% of their code is AI-generated

So, this number might be something that a lot of companies have higher, but it definitely makes a lot of sense. And the reason why it makes sense for me is that they are building a product that is infrastructure-heavy.

Which means that the changes are more complicated and one mistake can be very costly for the business. That’s where AI doesn’t help as much.

A similar thing was also mentioned to me by Emma Tang, who is leading the data platform team at OpenAI. I recently spoke with her while visiting OpenAI’s offices in San Francisco.

She mentioned that they don’t see as much AI productivity increase inside her team, in comparison to other, more product-focused teams, because of the nature of the work they are doing.

Portkey’s hiring process

Because of the nature of their work (infrastructure-heavy) and expectations of being able to have end-to-end ownership, they mostly hire engineers who are more senior.

Their hiring process is quite thorough, with most engineers going through 5-6 rounds, including an on-site interview.

It typically starts with an initial screening, followed by a lighter technical exercise, then a more challenging exercise. Candidates are then invited for an on-site “super day”, where they work directly with engineering team members on practical problems.

The final stage is usually a conversation with the founder, focused on alignment and culture fit, before moving to an offer.

They’re also fully open to candidates using AI during technical interviews. Since AI is part of how engineers work day to day, they see no reason to restrict it in a realistic technical setting like pair programming or problem solving.

But during behavioral or leadership conversations, that’s not a great look if a candidate uses AI to answer questions.

For technical tasks, though, using AI effectively is seen as a positive signal because it reflects how engineers actually build and solve problems in practice.

Last words

What stood out most about Portkey is their focus on staying in their lane and being good at it, at the same time, their focus on product engineering and end-to-end ownership.

A big thanks to Vrushank Vyas for sharing how they work. Looking forward to meeting the team in person next time.

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.

Intro

Yesterday, together with my friends from Augment Code, we hosted an event called Engineering Leadership LIVE in San Francisco.

We had a full house, with an amazing view of the Bay Bridge, and it was a blast, full of insightful conversations about engineering/engineering leadership.

It was really great to talk in person with everyone. I think such events are just going to be more and more important as things become more robotic around us. Here are also some of the pictures:

I’ll also share the recordings, once we have them, and the overview of the other talks as future newsletter articles. In today’s article, I am sharing an overview of my talk, titled: AI-Native Engineering Leadership.

This is an article for paid subscribers, and here is the full index:
- What does “AI-native” actually mean?
- What has changed in engineering leadership from 1-2 years ago?
- A lot of the engineering is actually becoming engineering leadership
- A lot of engineering managers are sought after to become ICs again
- Important note for all the engineering managers
🔒 How are engineering leadership roles changing?
🔒 What to do to become a great AI-native engineering leader in 2026 and beyond?
🔒 Last words

Recording of my talk at the event

You can watch/listen to the talk below, or you can keep reading for the full insights.

Let’s start!

What does “AI-native” actually mean?

Based on the recent report, The State of AI-Native Engineering in 2026 done by Augment Code, there seems to be no clear definition of what “AI-native” actually means, and for every engineer/engineering leader, it means something different.

Here are some (funny) answers from the report to define the word “AI-native”:

My personal favorites are:

• The greatest thing since sliced bread.

• I wouldn’t, that’s a nonsense marketing term.

• Everything is implemented by AI from scratch.

I think it’s really important that we at least try to define what “AI-native” actually means, because the term keeps appearing in many places, and I am seeing it more and more.

The definition that resonates with me the most is the one that I have already defined in the article, done in collaboration with Thibault Sottiaux, Head of Codex, OpenAI:

Being AI-native goes beyond simply using AI tools. It means continuously identifying and eliminating bottlenecks across the entire software engineering lifecycle.

That means questioning everything: planning, strategy, prioritization of features, bugs, code generation, code review. None of it is sacred, and everything can and should be continuously improved.

Being AI-native means identifying where work slows down and applying AI to remove those bottlenecks.

Now that we know what “AI-native” means, it’s important to take a step further and define what actually changed in engineering leadership today in comparison to 1-2 years ago.

What has changed in engineering leadership from 1-2 years ago?

My answer might surprise you, and might be a bit controversial at first, but I promise it’ll make sense. The main goal of engineering leadership has stayed the same as 1-2 years ago! Let me explain.

The goal of engineering leaders has always been to do what’s best for the team, their people, organization, and the overall business.

This hasn’t changed.

Every engineering leader’s goal is exactly the same. But what has changed is a lot of things around the role, the tools, the focus of the organizations, and there are also a lot more engineering leaders than there were 1-2 years ago. Explaining why next.

A lot of the engineering is actually becoming engineering leadership

We all know that AI-assisted engineering is the standard way of doing engineering these days. And a lot of the skills that you need in order to do AI-assisted engineering well are connected with engineering leadership skills:

• Delegating,

• giving feedback,

• dissecting bigger projects into small tasks

• etc.

All crucial skills. You need to be good at all these skills (and many more), working both with AI agents and humans. I wrote this article last year in October:

And today, I’d say that most of the engineering roles are actually becoming the “tech lead” roles. There’s a lot more end-to-end ownership on projects by individual engineers, especially in smaller companies and startups.

And as mentioned above, you need to know how to manage AI agents effectively in order to be able to do great work, at the same time, human-related skills are more important than ever.

What does this mean for engineering managers?

A lot of engineering managers are sought after to become ICs again

As we have seen in many different companies at this time (starting with Amazon), there is a trend of increasing the ratio of IC <> Manager roles. At the same time, engineering managers are more desired than ever, as ICs.

The main reason is the following:

The skills that you learn as a manager are the same skills needed when you are doing AI-assisted engineering.

In order to do AI-assisted engineering well, 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 without assumptions

• Continuously refine and improve based on the output

• Have patience and perseverance

This is systems thinking, and managers have been doing that for years.

These are the skills that a lot of engineers lack, because many haven’t spent the time improving in these areas. They may be really good in technical details, but then lack the people skills and systems thinking + overall patience to use AI to help them.

It’s a similar mindset to the following: “Why delegate to a colleague, if you can just do it really quickly yourself?”

The problem with such a mindset is that you can quickly become a bottleneck, and managers understand really well how important it is to avoid that at all costs.

So, managers are more likely to go for tools, people, or anything else to help them, whereas engineers with no managerial experience are more likely to rely on their own skills and abilities to get things done.

Important note for all the engineering managers

As mentioned at the beginning of the article:

The goal of engineering leaders has always been to do what’s best for the team, their people, organization, and the overall business.

That’s also my advice for all the engineering managers in case your company decides to increase the ratio of managers to ICs. Don’t look at it as a demotion, always look at it from the perspective of what’s going to be best for the team and everyone involved.

And at the same time, it’s not a demotion! Those are two different paths. Besides, you are actually an engineering leader as an IC, just not having direct (human) reports.

Similarly, like we all adapted going from building sites with HTML and CSS, to using JavaScript frameworks, or going from web developer roles to frontend and backend separation, similarly, we’ll have a lot more IC engineering leaders than before, and fewer managers.

How are engineering leadership roles changing?

Read more

Updated speaker lineup for the Engineering Leadership Live event in San Francisco, that I am hosting together with my friends from Augment Code.

- Gregor Ojstersek, CTO & Author Engineering Leadership newsletter
Talk: AI-Native Engineering Leadership

- Vinay Perneti, VP of Engineering, Augment Code
Talk: We Thought AI Transformation Was About Adopting Agents. We Were Wrong.

- Andrew Churchill, CTO, Weave
Talk: What Actually Works: AI Coding Patterns from the Top 1% of Teams

- Anwar Haneef, GM & Head of Ecosystem, Canva
Talk: Your Product’s Next User Might Be an AI Agent. What Engineering Leaders Need to Know.

Join the event (limited spots available):

Secure your spot at the event

Looking forward to seeing you there tomorrow!

Gregor

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

Measure AI’s impact on engineering.

Claude writes code 10x faster than a human. So why is engineering productivity up 20%, not 200%?

Engineers spend only 30-40% of their time actually coding. The rest goes to deployments, sprint planning, admin overhead, support questions, design reviews, incident response, and everything in between.

Until now, we’ve had no way to map and measure where that invisible work actually goes. Larridin changes that. Mapping how engineering work flows across your org, surfacing the blockers and friction that drag on productivity, and showing you exactly what to fix.

Larridin delivers complete 360° developer intelligence for AI-native engineering teams. From traditional developer productivity metrics to AI-era measures like Agent Effectiveness scores.

Unlock AI-native engineering potential

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

Intro

I like to say that finishing projects in software engineering is more like an art than a clear blueprint. Every team and project is different and what works for one may not for the other.

There are many ways to approach engineering projects. Today, we’ll go through a case study on what worked well for Karol Wójciszko, Senior Engineering Manager, Webinterpret.

It’s a bit of an unconventional approach, and that’s exactly what makes it valuable and interesting to read.

Let’s introduce our guest author and get started!

Introducing Karol Wójciszko

is a senior engineering manager for Webinterpret, running multiple engineering teams. He also writes about engineering leadership topics in his newsletter called Engineering Leader’s Playbook.

Today, Karol will share a case study from a project he ran with an adapted version of critical chain project management. It’s a method from Eliyahu Goldratt’s Critical Chain, originally designed for manufacturing and construction.

Let’s start!

1. What Critical Chain Is and Why It Works So Well in IT

The core mechanic in critical chain project management is almost provocatively simple. You take your team’s estimates, cut them all by 50%, and call these new numbers “aggressive but achievable.”

The time you removed from each task doesn’t disappear. It becomes your project buffer: a shared pool of time that the entire team draws from.

Let’s say an engineer estimated a task to take four days; they now have two days to finish it. If they do it in two days, you just put two days into the project buffer. If they finish in three days, there’s a day in the buffer.

And if they do it in five? They’ve used three days from the buffer, which is also fine. Nobody gets punished. You’re tracking how much total buffer the project is consuming versus how much actual progress has been made.

Why does this work? Because of Parkinson’s Law.

You’ve probably heard of it: Work expands to fill the time available. If you give someone four days for a task that they could realistically finish in less than two, they will almost always use the full four days.

Not because they’re lazy or wasting time; it’s just how human brains work. We fill the available time. We polish things that don’t need polishing. We revisit decisions. We context-switch because “there’s still time.”

The result is a painful asymmetry in every project: Early finishes get absorbed silently, but delays are loud and visible.

Think about it. When was the last time an engineer finished a task a day early and that extra day actually benefited the project timeline? It almost never happens. The saved time evaporates into a longer code review, an extra refactor, a coffee break.

But when a task takes one extra day? That shows up immediately in your burndown chart. Everyone notices.

Critical chain flips this dynamic. By setting aggressive targets, you create conditions in which early finishes are actually captured. Some tasks will run over the aggressive estimate. That’s to be expected. It’s what the buffer is for.

But the tasks that come in early now benefit the whole project instead of disappearing.

The two rules that make critical chain work

There are two rules that are nonnegotiable for this method to work.

• Rule 1: Absolutely do not give penalties for going over the aggressive estimate

I mean “penalties” both formally and informally: no performance notes, no disappointed looks, no passive-aggressive “so, task 7 took a bit longer, huh?” in a standup. The engineer did their best.

The aggressive estimate was designed to be missed sometimes. If you create any kind of penalty, even subtle social pressure, you’ll destroy the entire method. People will start padding estimates again, and you’ll be back to square one.

This is harder than it sounds. As a manager, you need to genuinely not react when someone takes five days on a task estimated at two and a half. Your body language matters. Your tone matters. The team is watching.

• Rule 2: Track the buffer, not individual tasks

The question is never “Did Sarah finish task 7 on time?” The question is always “How much total buffer has the project consumed versus how much total progress have we made?” This is a team-level metric.

Individual task overruns don’t matter as long as the overall project buffer is healthy.

This also builds team spirit. Now it’s not about individual performance. It’s about the collective mission. Some tasks will finish early, and some will finish late. The team wins together.

Adapting it for story points (yes, I know)

I need to address the elephant in the room: story points.

Classic critical chain uses time estimates. But most software teams estimate in story points (SPs), which is a measure of complexity rather than time. Purists will tell you that you can’t convert story points to time. And technically they’re right.

But you can calculate how long your team historically takes to finish tasks of each size. That’s not a theoretical conversion; it’s empirical data. And it’s good enough for critical chain to work.

Here’s what I do: I pull all completed tasks from the previous quarter and calculate the median completion time for each SP value. Whether a task had 2 SPs or 5 or 8 or any other amount, I still take the median completion time, which scales with the points.

Why median and not average? Because the median filters out outliers. That one task that took 14 days because an engineer went on vacation mid-project? The median ignores it; the average doesn’t. The median gives you a naturally tighter, more aggressive baseline, which is exactly what we want.

A critical point: This entire calculation happens outside of the team. I pull the data, I compute the medians, I set up the buffer. Engineers don’t need to think about any of this. They just do their normal work. This is homework for the manager, not an extra burden on the team.

Once you have the median times, you cut them by 50%. That’s your aggressive estimate for each task. The sum of everything you cut becomes your project buffer.

I use 50% in this case study, but you can start gentler, such as 30% or even 20%. The principle is the same. You can adjust the aggressiveness as you and the team get comfortable with the method.

2. Case Study: From Red Zone to Early Finish in 4 Weeks

Let me walk you through an actual project week by week, so you can see how this plays out in practice.

Our starting conditions:

• 17 tasks, estimated at 70 SPs total

• A team of three: two senior engineers, one midlevel

• A clearly defined scope (fixed epic)

• Buffer after 50% cut: 35 SPs

The math behind buffer tracking

In the case study below, I track two numbers week by week:

• buffer consumption and

• project progress.

Here’s how I calculate each one.

Buffer consumption is based on the difference between the aggressive estimate and the actual cycle time for each completed task.

When a task is closed, I know how long it actually took. I compare that against the aggressive estimate I assigned during planning. The difference tells me how much buffer that task consumed or saved.

A quick example: If the aggressive estimate for a task was 2 days, but the task actually took 3 days to complete, that task consumed 1 day of buffer. If it took only 1.5 days, it saved half a day of buffer.

At the end of each week, I add up the total buffer consumed across all completed tasks and express it as a percentage of the total project buffer. So if used 2 days out of a buffer of 10 days, we used 20% of the buffer.

Project progress is simpler. It’s the percentage of delivered story points relative to the total scope. If the project has 70 story points in total and the team delivered 7 this week, progress is 10%.

Are we on track? I compare the two numbers. If buffer consumption is 26% but project progress is only 16%, we’re 10 percentage points, or 62.5%, behind.

The project is consuming buffer faster than it’s producing results. If progress is ahead of buffer consumption, we’re in good shape.

One thing I want to call out here: I deliberately keep the math simple.

You might notice there’s no weighted scoring, no statistical modeling, no confidence intervals. That’s intentional. The foundation of this entire method is a median for cycle time, which is already an approximation.

We’re working with uncertainty from the start. There’s no point in building sophisticated calculations on top of an uncertain baseline. That’s just stacking assumptions on assumptions.

I treat these numbers as a guideline, not a guarantee, and the method works precisely because it embraces that simplicity instead of pretending to be more precise than it is.

Week 1: Red alert

Buffer consumed: 26% | Progress: 16%

Buffer consumption was 10 percentage points ahead of project progress (26%-16%). The gauge chart went straight to red.

Here’s the interesting part: By traditional velocity/throughput metrics, this was a completely normal first week. If I’d been running this project with a standard burndown chart, nobody would have raised an eyebrow. The team was delivering at a typical pace for Week 1.

But the critical chain gauge doesn’t care about typical. It cares about the ratio of buffer consumed to progress made. And that ratio was bad. We were burning through the buffer faster than we were completing work.

So I called a quick retro, just a 30-minute conversation about what was slowing us down. The answer was clear: Several key tasks lacked clarity. Requirements were ambiguous, a few diagrams were missing, and engineers were spending time figuring out what to build instead of building it.

We spent an afternoon with the project manager clarifying requirements, updating diagrams, and resolving open questions. This wasn’t anything dramatic; it was the kind of thing that happens in every project. The difference is that we caught it in Week 1, not Week 3.

And here’s what’s worth emphasizing: No other methodology would have raised an alarm at this point.

By velocity/throughput standards, we were on track. This looked like a perfectly normal first week. No burndown chart would have flagged anything. We would have cruised along for another two to three weeks before realizing that unclear scope was silently eating our time.

Before the retro, nobody on the team thought scope clarity was the bottleneck. It wasn’t obvious. But when we sat down and asked ourselves what was constraining us the most right then, that was the answer.

And because the critical chain gauge is so sensitive to the buffer-to-progress ratio, we got that signal in Week 1. We fixed it at the earliest possible moment.

Without this early alarm, we would have learned about the problem much later, when the damage was already done and much harder to recover from.

Week 2: Recovery

Buffer consumed: 46% | Progress: 41%

The gap narrowed to 5 percentage points, buffer consumption at 46%, progress at 41%. The clarity fix from Week 1 was paying off.

The gauge chart was sitting around the yellow-red boundary - still not great, but the trend was clearly moving in the right direction. We were slowly clawing our way back.

At this point, my job was simple: observe, don’t interfere. The team was doing their thing, the fixes were working, and adding more management overhead would only slow them down.

This is one of the things I like about the method: It tells you when to act and when to leave the team alone. Yellow zone? Watch. Green zone? Forget about it. Red zone? Intervene. There’s no ambiguity about it.

Week 3: First win

Buffer consumed: 63% | Progress: 70%

For the first time, progress was ahead of buffer consumption, by 7 percentage points. We were ahead of the historical median.

This was a milestone worth celebrating!

I shared the numbers with the team and we acknowledged the progress. Not every task had been finished within the aggressive estimate. Several went over. But that was fine. The overall project was ahead because enough tasks came in early to more than compensate.

This is the moment the team starts to really get the method. They see that individual task overruns don’t matter. What matters is the collective result. It shifts the mindset from “I need to finish my task on time” to “we need to finish the project on time.”

Week 4: Done early

Buffer consumed: 83% | Progress: 100%

Project completed. We used 83% of the buffer to deliver 100% of the scope. That 17 percentage point gap was pure time savings.

I don’t have a parallel universe in which we ran this same project with a different methodology, so I can’t tell you definitively that we would have been 17% slower without critical chain.

But looking at the data, one thing is clear: The Week 1 red alert alone probably saved us at least a week of delay. And the overall pace of work was noticeably tighter than what I typically see from the same team on standard projects.

3. Track Project Progress in 10 Minutes a Week

You saw the gauge chart in action during the case study: red in Week 1, yellow–red in Week 2, green in Week 3, and yellow in Week 4.

Here’s how I actually define those zones and what I do with them.

Defining the zones

The thresholds are based on two reference points you already have: your aggressive estimates (median cut by 50%) and the raw historical median. The gauge tracks the difference between buffer consumption and project progress, measured in percentage points.

• 🟢 Green = Progress is ahead of buffer consumption, tracking at or below the aggressive estimates. You’re on track to finish early. Close the spreadsheet, go do something else.

• 🟡 Yellow = Buffer consumption is roughly in line with progress, somewhere between your aggressive estimates and the historical median. You’ll probably finish on time, but not early. Keep an eye on the trend - is it improving or worsening?

• 🔴 Red = buffer consumption exceeds progress by more than 5 percentage points above the historical median. At this pace, you’ll blow through the buffer before completing the scope. Time to act - call a retro, find the constraint, fix it..

You can adjust these thresholds to your own risk tolerance. Mine are calibrated to my teams. The exact numbers aren’t sacred. What matters is having clear, visual triggers that remove ambiguity about when to intervene.

The weekly ritual

My entire engagement with this method during a project looked like this:

1. Refresh the data (I pulled the completed tasks from Jira into the spreadsheet).

2. Look at the gauge chart:

   1. Green: I’m done for the week.

   2. Yellow: I note the trend, and then I’m done for the week.

   3. Red: I schedule a 30-minute retro.

That’s it. No daily tracking, no manual data entry, no complex dashboards. One chart, one look once a week for about 10 minutes total.

When this method doesn’t work

I don’t apply the critical chain to every project. Here are some team compositions where it consistently fails:

• Junior-heavy teams

I’ve tried this, and it backfired. Juniors take the aggressive estimates personally. Even when I explicitly say “no penalties,” even when I demonstrate it with my behavior, they stress about missing the target.

It creates anxiety instead of motivation. The method requires a certain level of professional maturity to work. People need to understand, both emotionally and intellectually, that missing the aggressive estimate is fine.

• Burned-out teams

If your team is already stretched, adding aggressive estimates, even with a buffer, even with no penalties, will feel like more pressure. Read the room. If people are exhausted, this isn’t the time for productivity experiments.

• Very senior teams on familiar codebases

I’ve also struggled with teams where everyone is senior and has been working on the same domain for years. Their estimates are already tight.

There’s not enough slack in their estimates for the method to create leverage. They’re already working close to their actual pace, so cutting estimates doesn’t produce meaningful buffer.

• Undefined or shifting scope

This is the fundamental prerequisite. You need to know the full list of tasks upfront to calculate the buffer. If you’re dealing with an epic where new tasks keep getting added mid-sprint or where the PM is still figuring out requirements as you go, stop.

Fix the scope first, then consider critical chain. It works for defined-scope projects, like epics, milestones, and clearly scoped features. It doesn’t work for ongoing maintenance or discovery work.

I run this method maybe once a quarter, sometimes once every six months. I pick projects for which the deadline matters and the scope is locked. It’s a precision tool, not a daily driver.

The compound effect

There’s a bonus that becomes visible over time.

If you apply this method periodically, say, once a quarter, you’ll notice something interesting: Your team’s median completion times actually shrink. The feedback loop tightens.

Engineers internalize the habit of working with focus instead of letting tasks naturally expand. Not because you’re pushing them but because they’ve experienced what it feels like to finish tasks faster, and they liked it.

After about six months of periodic use, you’ll probably need to recalculate your medians. Your historical data will show shorter completion times, which means your aggressive estimates become even more aggressive. And the cycle continues.

That’s the real win. Not finishing one project early, but building a team that habitually works with intensity and focus without the stress.

One more thing: I know the orthodox critical chain community might push back on my adaptations of using story points instead of pure time estimates, using medians instead of single-point estimates, and modifying the buffer thresholds. I get it.

But these modifications are what make the method practical for modern software teams. The original theory is brilliant. Implementation must meet your team where they are.

It took me several iterations across multiple projects to get this setup right. I needed to figure out which Jira automations would work, how to structure the spreadsheet so it wouldn’t need manual input, and how to make the gauge chart update itself.

Below, I walk through the exact configuration step by step: how to compute your median completion times, set up automatic due dates in Jira (with the automation code), and connect a self-updating spreadsheet for buffer tracking.

I’m also including a ready-to-use template with all formulas from the case study above. If you’re planning to try this on your next project, it’ll save you a few hours of trial and error.

4. How to Configure Everything So It Calculates Itself

The whole philosophy behind my setup is the team does nothing extra. No additional tracking, no spreadsheets to fill, no status updates beyond the normal board workflow.

Engineers just move tickets across the board as they normally would. Everything I need calculates itself.

Here’s how.

Step 1: Calculate your median completion times

Export completed tasks from the last quarter (or or last four months) from Jira. You want tasks that are fully done, status “Done” or equivalent.

Group the tasks in the spreadsheet by SP value: Put all 1-point tasks together, all 2-point tasks, all 3-point tasks, all 5-point tasks, and so on.

One of the reasons I like Fibonacci sizing is because you end up with a manageable number of buckets to analyze.

For each group, calculate the median time from when the task moved to “In Progress” to when it was resolved. Remember: not average, median. The average gets skewed by that one task that took 14 days because of a dependency blocker or a vacation. The median gives you a clean, representative number.

You have a few options for doing this practically:

• Spreadsheet export

Export your Jira tasks to a CSV or connect Google Sheets to Jira. Then a pivot table will calculate medians in about 10 minutes. Seriously. This sounds like it should take hours, but if you know your way around a pivot table, it’s fast.

• Jira plugins

There are plugins like Time in Status (free tier available) that can show you these distributions directly. When I started, I used one of these. Now I find the spreadsheet approach faster for my workflow.

• Monte Carlo simulation

Some teams already use Monte Carlo diagrams for forecasting. These show similar distributions that you can use as a baseline for your aggressive estimates.

• A custom tool

We’re in 2026. You can build a simple script using the Atlassian API to pull this data and calculate medians automatically. I have several custom tools like this for team management, written with just a few prompts in Claude Code. (Maybe I’ll show how I build these in a future article.)

Whatever method you choose, by the end of this step you’ll have a table like:

• 1 SP → median completion time: X days

• 2 SP → median completion time: Y days

• 3 SP → median completion time: Z days

• 5 SP → median completion time: W days

Cut these by 50% (or 30%, or 20%, your choice). Those are your aggressive estimates. The sum of everything you cut is your project buffer.

Step 2: Set up automatic due dates in Jira

This is the key automation that makes the method low maintenance.

Create a Jira automation rule so that when a task moves to “In Progress,” Jira automatically sets the due date based on its story point value. The due dates are your aggressive estimates.

For example, with a 50% cut:

• 1 SP → due date = today + 1 day

• 2 SP → due date = today + 2 days

• 3 SP → due date = today + 2.5 days

• 5 SP → due date = today + 4 days

Here’s how to set this up in Jira Automation (Project Settings → Automation → Create Rule):

TRIGGER: Field value changed → Status → to “In Progress”

Then add a series of if/else conditions branching on the Story Points field, each setting the due date accordingly. The rule logic looks like this:

TRIGGER: When status changes to “In Progress”

IF Story Points = 1

  → Set Due Date to {{now.plusBusinessDays(1)}}

ELSE IF Story Points = 2

  → Set Due Date to {{now.plusBusinessDays(2)}}

ELSE IF Story Points = 3

  → Set Due Date to {{now.plusBusinessDays(3)}}

ELSE IF Story Points = 5

  → Set Due Date to {{now.plusBusinessDays(4)}}

ELSE IF Story Points = 8

  → Set Due Date to {{now.plusBusinessDays(6)}}

Note: Jira updates its automation UI frequently. It might look a bit different by the time you’re reading this.

A few more notes on the setup:

• Use plusBusinessDays instead of plusDays so weekends don’t count against the engineer. Nobody wants a due date landing on Saturday.

• Adjust the day values to match your own medians cut by your chosen percentage. The numbers above are examples from my case study.

• You can also handle this with a single Lookup table action if your Jira plan supports it. You’ll map story point values to day offsets in one place, making it easier to maintain.

You hardcode these values once. Update them roughly every six months if your team’s speed improves, which it likely will.

The due date must be visible on the board. This is important.

When an engineer picks up a task, they should immediately see the aggressive target. Not as pressure, as information. You want their mindset to be “This is how long it would take if everything goes perfectly. Let’s see how close I can get.”

And you’ll see something interesting: Many engineers actually enjoy the challenge. There’s genuine satisfaction in hitting an ambitious target. I’ve seen real joy on people’s faces when they finish a task within the aggressive estimate. It’s like a personal best.

But if they don’t hit it? Nothing happens. No consequences. No comments. That’s the deal, and you have to honor it every single time.

Step 3: Connect a spreadsheet for buffer tracking

I connect Google Sheets to Jira using a JQL connector. My query pulls only tasks with status “Done” from the specific epic I’m tracking.

The JQL looks something like:

project = [YOUR_PROJECT] AND status = Done AND “Epic Link” = [YOUR_EPIC]

Once the tasks are imported into the spreadsheet, I calculate:

• Cycle time for each task: The difference between the resolved date and the date it moved to “In Progress”

• Buffer consumed: The sum of time overruns beyond the aggressive estimates

• Progress: Percentage of total scope completed

• Gauge chart zone: Green, yellow, or red based on the buffer-to-progress ratio

Once a week, I refresh the JQL import. The new completed tasks flow in, all calculations update automatically, and the gauge chart tells me whether I need to do anything.

Total weekly time: about 10 minutes. Refresh, look, decide.

It contains all the calculations from the case study, buffer tracking, gauge chart zones, cycle time formulas, everything. You can duplicate it and plug in your own data.

🎁 Spreadsheet template with all the formulas

You can download my spreadsheet template. It contains all the calculations from the case study: buffer tracking, gauge chart zones, cycle time formulas, and so on. Duplicate it and plug in your own data.

Conclusion

Critical chain project management is one of the most underused tools in engineering management. Adapted properly, it gives you three things that are hard to get from any other methodology:

• Early warning

The buffer-to-progress ratio catches problems in Week 1 that burndown charts won’t surface until Week 3. That’s the difference between a fixable issue and a project delay.

• Captured time savings

By setting aggressive estimates, you neutralize Parkinson’s Law. Tasks that would have quietly expanded to fill their allotted time now generate actual savings for the project.

• Low overhead

Once set up, the method runs on 10 minutes of your time per week. The team does nothing extra. No additional tracking, no extra ceremonies, no new tools to learn.

The setup does take some upfront work. You’ll need to calculate medians, configure automations, and build the spreadsheet. But after that? You’re just looking at a gauge chart once a week and deciding whether to act or not.

Pick one defined-scope project. Set it up. Run it for four weeks, and see how it goes. The bar doesn’t have to be “not late.”

Last words

Special thanks to Karol for sharing his insights with us! Make sure to sign up to his newsletter Engineering Leader’s Playbook. To learn more about Karol, check him out on LinkedIn.

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.

Full speaker lineup for the Engineering Leadership Live event in San Francisco, that I am hosting together with my friends from Augment Code.

- Gregor Ojstersek, CTO & Author Engineering Leadership newsletter
Talk: AI-Native Engineering Leadership

- Vinay Perneti, VP of Engineering, Augment Code
Talk: We Thought AI Transformation Was About Adopting Agents. We Were Wrong.

- Andrew Churchill, CTO, Weave
Talk: What Actually Works: AI Coding Patterns from the Top 1% of Teams

Join the event (limited spots available):

Secure your spot at the event

Looking forward to seeing you there!

Gregor

I’ll be giving a talk at the Engineering Leadership Live event in San Francisco

The talk is titled: AI-Native Engineering Leadership, and I’ll be sharing:

• What does it mean to be an AI-native engineering leader

• What has changed from 1-2 years ago

• Important trends and skills to learn to thrive in the role

Join the event live in SF on May 26.

Secure your spot at the event

Looking forward to seeing you there if you’re joining! Let’s get back to this week’s thought.

Intro

“My work speaks for itself”.

This is unfortunately what many engineers and engineering leaders believe, but the sad truth is that it rarely does.

The problem is not that your work is not high-quality enough. And the problem is also not that people are unfair (well, in some cases, that might be true), but mostly the problem is related to attention, and the organization being full of noise.

Especially leaders and decision-makers in the company, they sit in back-to-back meetings, and they get SO much information on a daily basis, it’s impossible for them to be on top of everything.

In such an environment, no matter how exceptional your work is, it can quickly become invisible. This is where narrative matters.

In today’s article, we’ll go through all about how to build a story around your work and how important it is to do that.

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

- The highest-impact engineers and engineering leaders are not only strong operators
- You need to build a narrative about your work in a similar way, just on a smaller scale
🔒 How to build a narrative around your work
🔒 1. You should start building a narrative even before the work begins
🔒 2. Find ways to repeat this message many times
🔒 3. Connect the work to business outcomes
🔒 4. Bonus: Make sure to communicate progress consistently and explain trade-offs
🔒 Being good at building a narrative is one of the highest-leverage leadership skills
🔒 Last words

Let’s start!

The highest-impact engineers and engineering leaders are not only strong operators

As we see the shift in our industry due to AI, strong builders and operators are being praised for their work a lot more than 2-3 years ago. But it’s really important to understand that they don’t just do great work alone, they are also skilled narrators.

Let me share a concrete example next.

Andrej Karpathy is someone that a lot of us know for the great work that he is doing around AI. But, imagine if Andrej were just to stay in the “research mode”, and only focus on doing great work, while not sharing his work online. He wouldn’t be perceived as the way he is today.

He recently announced that he is joining Anthropic as part of the pre-training team, and it was one of the biggest news stories in the tech space that received over 25M views on X.

I have to also give a shoutout to my friends and for the fun comments on the announcement post :)

The reality is that I am sure that Andrej got the job without the interview process. No leetcode, no system design interview, and no behavioral interview as well. And that’s all because of the credibility he built through his work and the narrative.

He is very smart about what he says, how he says it, and when he says it as well. He coined the term “vibe coding”, appears on podcasts to create narratives about what’s happening with AI and shares predictions, and also regularly shares his thoughts on X (almost daily).

He is building a narrative about his work every day, which is why we perceive him as a very credible individual.

The other 2 very good examples are:

• Boris Cherny (the creator of Claude Code), and

• Thibault Scottiaux (Head of Codex).

Thibault was also a guest on one of my most popular articles called: How to Build AI-Native Engineering Teams (highly recommend a read).

They both are great operators and builders, but at the same time, they are both active on X and appear on different events and podcasts. They both have cemented themselves as the go-to people for two of the most popular AI coding tools today: Claude Code and Codex (well, I’d put Cursor in between as well).

But you get the point, both would have an unlimited amount of opportunities if they’d want to work elsewhere or do something on their own. And that’s all because of the narrative they are building every day.

Now, all of these examples are quite extreme, but they paint a good picture about how powerful building a narrative is, and what it can do for you and how your work is perceived.

Let’s go to more realistic examples next.

You need to build a narrative about your work in a similar way, just on a smaller scale

It’s important to mention that there’s no need to appear on podcasts or post on X daily or LinkedIn daily in order to build a narrative about your work (of course, this helps, but it’s not required).

What I mean by building a narrative around your work is all about helping people understand:

• Why your work matters

• What problems it’s solving

• Why are these problems important now

• What tradeoffs were considered

• What changed because of your work

• What outcomes were created

• What future opportunities exist because of your work

Narrative provides context into the “why”, “what”, and “what were the outcomes”. Which is crucial. And goes well with what I like to regularly say:

You can do the best work in the world, but if it’s not aligned with the expectations, it won’t be perceived that way.

Look how big a change it is when you say.

1. My team has created product X, and customers seem quite happy about it.

2. My team has created product X that has increased the Daily Active Users (DAU) by 50%, and Average Revenue Per User (ARPU) by 25%, while also increasing the Net Promoter Score (NPS) by 20%.

The sad reality is that if you say the first version, the work won’t get the same praise and recognition, but if you say the second version, it doesn’t matter if you do the same work. The story behind the work in many situations matters more than the work itself.

The narrative in the second version is a lot better, and it’s all about the details and the context that you share, connected with what outcomes your work creates.

Especially important to understand as an engineering lead, if you don’t create a great narrative, your team will also not get the desired recognition, no matter how hard everyone works. So, it’s not only about you.

Now, let me share the detailed steps on how to build a narrative around your work.

How to build a narrative around your work

Read more

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

Measure AI’s impact on engineering.

Claude writes code 10x faster than a human. So why is engineering productivity up 20%, not 200%?

Engineers spend only 30-40% of their time actually coding. The rest goes to deployments, sprint planning, admin overhead, support questions, design reviews, incident response, and everything in between.

Until now, we’ve had no way to map and measure where that invisible work actually goes. Larridin changes that. Mapping how engineering work flows across your org, surfacing the blockers and friction that drag on productivity, and showing you exactly what to fix.

Larridin delivers complete 360° developer intelligence for AI-native engineering teams. From traditional developer productivity metrics to AI-era measures like Agent Effectiveness scores.

Unlock AI-native engineering potential

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

Intro

In a previous article, I mentioned that code review is the new bottleneck for engineering teams. The reason is that these days, we are able to generate code faster than ever with AI.

But the problem is that we can’t review the code fast enough, so the review process is the new bottleneck. And for that reason, a lot of teams are trying to find the right balance between these 2 options:

1. Block the progress by doing great human code reviews and ensuring that the quality remains high

2. Rely just on AI code reviews and/or doing shallow human code reviews

The issue here is that there’s no industry-wide agreement on how to scale the code reviews in a way that would support the speed of generation of the newly created code, without generating bad code, e.g. “AI code slop”.

Lucky for us, Ankit Jain, CEO, Aviator, is our guest author for today’s article. He will be sharing his recommended solution.

Let’s introduce our guest author and get started.

Introducing Ankit Jain

Ankit is a cofounder and CEO of Aviator. Previously, he led engineering teams at Sunshine, Homejoy, and Shippo, and was also an engineer at Google and Adobe.

He also leads The Hangar, a community of senior DevOps and senior software engineers focused on developer experience. Today, he is sharing with us his take on how to avoid bad AI-generated code output, e.g., “AI code slop”.

Over to you, Ankit!

Code review process is not made for the AI-era

This article is a follow-up to How to Kill the Code Review, which argued that traditional code review is no longer a viable quality gate in an AI-accelerated software development life cycle.

The natural next question is, if not code review, then what? What should be the alternative?

This article is the practical answer.

Velocity charts look great. PRs are merging faster. If you only look at the code written, the numbers tell a story of AI accelerating output. But behind those metrics, engineering teams are accumulating a new kind of technical debt.

Those PRs are either sitting unreviewed for days or are being rubber-stamped because no engineer has time to carefully review 500-line diffs.

I am not saying engineering teams should go from reviewing every line of code to nothing. I’m advocating for moving the approval gates upstream to prevent what I call the “AI slop” code. Code that compiles, passes basic checks, and looks plausible but is subtly wrong.

Now, let me share in more detail where AI-generated code goes wrong, even without “looking wrong”.

6 ways AI code goes wrong without looking wrong

1. Plausible but incorrect logic

The most dangerous variety. The code reads right and has correct syntax, but the logic is wrong. These bugs are difficult to catch in review because they require understanding what the code was supposed to do, not just what it does.

2. Over-engineering

AI models are trained on vast bodies of code that include enterprise patterns, framework abstractions, and production-hardened architectures.

Asked to solve a problem that genuinely needs 15 lines, a model may produce a 200-line abstraction layer that anticipates a generality nobody asked for.

3. Convention blindness

Models generate good generic code, not code that fits your system. Your repo has conventions around naming, error handling, logging patterns, and module boundaries.

AI frequently ignores them, not because it can’t learn them, but because it hasn’t been told about them in the prompt.

4. Hallucinated APIs and deprecated usage

Models confidently invoke methods that don’t exist, reference config options that were removed two versions ago, or call internal APIs that aren’t accessible in the current service context.

These errors are sometimes caught immediately, and sometimes only in production.

5. Defensive overreach

Excessive try-catch blocks, silent error absorption, redundant logging. The code handles failure gracefully in the sense that it swallows it silently, making debugging substantially harder.

6. Cargo-cult patterns

Copies patterns without understanding why, like retry logic in a context where retries make no sense. Circuit breakers for calls that are always synchronous. Error handling that looks thorough but doesn’t map to actual failure modes. The pattern is there; the reasoning behind it is not.

The common thread is that slop passes the eye test. It looks like real code. That’s precisely what makes it dangerous at scale.

Why existing processes are not enough

Code review was designed for a different world.

AI-generated PRs are different in kind, not just in scale. When a human writes code, intent travels with the author through the review process.

They can explain the tradeoffs they considered, the alternatives they rejected, and the constraints they worked within. Even unwritten, that context is accessible.

When AI writes code, intent may exist in a prompt that was never saved, a ticket that doesn’t capture the decision-making, or only in the engineer’s head. The implementation is preserved; the reasoning behind it is not.

Tests catch less than we assume. Automated testing is necessary but not sufficient. Tests verify behavior within the scope of what the test author thought to test.

AI-generated code introduces failure modes that are, by definition, unanticipated because if the engineer had anticipated them, they would have specified them in the prompt.

You cannot write tests against requirements you didn’t know to articulate.

The missing ingredient: Intent

The concept of formalizing intent before implementation isn’t new. Behavior-Driven Development, Test-Driven Development, and Design by Contract all attempt to define behavior in a structured, human-readable form before any code is written.

These approaches were often perceived as overhead. Under delivery pressure, they got skipped. AI makes them practical in a way they were never before.

AI can help generate structured acceptance criteria, specs, and contract-like descriptions from a brief. It can also verify output against them. The overhead objection disappears when the spec itself is AI-assisted.

We tested intent-driven verification on a real feature

At Aviator, we recently ran an experiment to test the intent-driven verification approach. With the main question we wanted to answer:

What if the review happens before the code is written?

The team implemented a medium-scoped, full-stack feature. A hierarchical, per-repository configuration system, with zero manually written application code.

Everything was guided by a spec reviewed and agreed upon by the team before a single line was generated.

It spanned the full stack, including a database model and migration for config history, a schema/validation layer, a resolution engine that merges repo and global configs, a GraphQL API (types + mutation) for reading and updating configs, integration of the resolved config into all runtime subsystems (sandbox provisioning, CI handling, code generation, chat processing, persona selection), and a frontend settings page with a config editor, change history view, and source indicators showing where each setting originates.

The kind of feature that, done conventionally, would generate dozens of review comments across multiple PRs.

Writing the spec

The spec was generated collaboratively: a scaffolding PRD was fed to Claude Code, which was instructed to ask clarifying questions that were answered synchronously by the team.

The resulting spec was reviewed at two levels.

1. The first was implementation details

Specific UI component choices, input validation requirements, performance strategies like Redis caching for config lookups.

These are the kinds of concerns that normally surface during code review, not spec review.

2. The second was scope and completeness

The team caught a missing UX requirement, questioned whether a persona’s feature was well-defined enough to include, and flagged places where the spec text was out of sync with the actual design (e.g., referencing a table that didn’t exist).

These are decisions that, if deferred to post-implementation review, would require rework. The spec review took about 10 hours of engineering work across multiple engineers.

It produced 14 acceptance criteria with 65 checkable items. It also produced a document that could serve as a document against which the code could be verified.

Implementation and verification

We used Claude Code to implement the spec. The agent decided to split the implementation into four phases:

1. Foundation,

2. Backend core,

3. Integration, and

4. Frontend.

The whole implementation consisted of around 6k lines of code, with 40% app code, 40% tests, and 20% GraphQL auto-generated files.

It’s worth noting that no explicit instruction to write tests was given in the specification, which suggests the agent’s strategy for meeting the acceptance criteria was to write tests.

A second agent then verified the 65 acceptance criteria against the resulting PRs.

This took six minutes and produced a structured report with file references and explanations for each item:

• 60 passed,

• 4 failed, and

• 1 partial.

A human doing the same verification thoroughly would have needed hours.

What the code review caught

Human reviewers left an average of 10 comments per PR. Few bugs were found, with the major one being a stale editor state. Code review caught convention-level issues such as import placement, enum duplication, and naming patterns.

This was an expected outcome. Spec review catches design-level issues like missing requirements, underspecified features, and scope questions.

Code review catches convention-level issues, the things that require familiarity with your specific codebase. Both layers are necessary because they catch different things.

Five guardrails engineering teams can start using now

We’re still learning how to write specs that are precise enough for agents to implement reliably but flexible enough that the team doesn’t spend more time specifying than they would have spent coding.

Engineers tend to stress too much about what a spec should be and the overhead of writing it.

If we think about writing a spec simply as writing a JIRA ticket, that stress can go away. For a simple issue, a single-line intent or what you’d write in a ticket could be a sufficient spec detail, and acceptance criteria can be generated by AI.

Our experiment worked well enough to change how we think about verifying AI code and preventing code slop.

The following practices are not a complete methodology. They’re a set of concrete interventions that teams can adopt incrementally, starting where they have the most pain.

1. Scope AI tasks tightly

Large, open-ended prompts produce the most slop. ‘Build this feature’ hands the AI too much latitude.

Well-scoped tasks with clear boundaries: a specific function, a defined API surface, or a constrained refactor, produce way better output and are significantly easier to verify.

This is counterintuitive for teams that see AI’s value in handling large tasks. The value is there, but it works better when large tasks are decomposed into smaller, well-specified subtasks with explicit checkpoints between them.

It’s no different from how we humans work better.

2. Make intent a first-class artifact

Before any code is generated, the intent should be written down in a form that can be reviewed and approved. This doesn’t require a formal methodology. It requires the habit of documenting the what before generating the how.

Acceptance criteria can also be written by AI. Intent is really hidden in the prompt conversation that the user is having with AI (the decision tree) or the details a user may be adding in the ticket.

At the more rigorous end, it means BDD-style specs or contract-like descriptions that can be used to verify output.

The exact format matters less than the discipline of capturing intent explicitly. Again, I’m not trying to add overhead and invent new documents to write. We already do a pretty good job of expressing intent when prompting LLMs.

In practice, that would most probably look like a lightweight spec template for AI-assisted work.

Two to three sentences on scope, a list of acceptance criteria, and a note on what’s explicitly out of scope. Make it a PR requirement. That, again, can be generated by AI.

3. Review intent before implementation

For any AI-assisted task above a certain complexity threshold, require spec approval before code generation begins.

The most expensive review is the one that happens after the code exists.

When a design decision is caught in a spec review, fixing it is a sentence change. When it’s caught in code review, it may require significant rework.

Teams that shift review earlier, approving specs before generating code, front-load the high-value decisions and leave code review to do what it’s actually good at: catching implementation-level issues.

4. Automate what you can

Tests, linting, and type checks catch surface-level slop, and you should absolutely not skip those. As I said in my piece, trust is layered when it comes to AI code. We stack imperfect filters until nothing comes through.

5. Build and maintain a team slop register

Every codebase has patterns that AI consistently gets wrong. Maybe it’s a specific error-handling convention, a naming pattern, a module boundary that gets violated, or a library the AI prefers that you’ve deprecated. These are knowable and preventable.

A slop register serves two purposes: feeding these patterns back into prompts (to prevent them from occurring) and informing CI checks (to catch them when they do).

You don’t need the full workflow to see results

The most common pushback against spec-first workflows is that they’re slower.

Writing specs takes time. Getting them reviewed and approved takes time. And engineers who are already productive with AI tooling don’t want to slow down.

It may seem that this intent-driven verification adds process, but we are just changing the ways of working that we’re used to. The tools aren’t ready. The organizational structures aren’t ready. We are in transition.

If your team is early in this process, the most valuable first step is usually the simplest one: require capturing the intent from prompts for any AI-assisted task above a defined complexity threshold.

The format doesn’t have to be perfect and rigidly defined at first. A few sentences on scope, a short list of acceptance criteria, and a note on what’s out of scope.

From there, introduce a spec review as a step before code generation. Add the slop register. Build toward automated verification against acceptance criteria.

The full workflow takes time to establish. But each step in that direction improves the signal-to-noise ratio of what ends up in the codebase, and makes the AI investment return what it’s supposed to return.

Last words

Special thanks to Ankit for sharing his insights on this important topic with us! Make sure to check out Aviator, they are building a lot of cool stuff there, highly relevant for building engineering teams in the AI era.

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.

Engineering Leadership Live Event in San Francisco

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership Live is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after.

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there! Let’s get back to this week’s thought.

Intro

As mentioned already in the article Become a Great Engineering Leader in 2026, the entry-level engineering leadership roles (Staff Engineer, Tech Lead, Team Lead, EM, Architect) are just getting closer together as time goes on.

And especially a common scenario that I am hearing frequently is a Tech Lead or a Senior+ Engineer also taking on managerial responsibilities of the team.

Today’s article is especially for these people. People who have recently taken the managerial responsibilities of the team, regardless of their title.

I am sharing all of my knowledge and experience on how to manage your time as a first-time lead. This was also one of the modules in the Senior Engineer to Lead: Grow and thrive in the role course, and now adapted as an article in this newsletter.

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

- Managing my time was one of the biggest struggles I had as a first-time team lead
- Prioritize ruthlessly
- Make sure to block focus time in your calendar
- Use a Pomodoro timer to avoid distractions
- Improve communication to save time for everyone
- Remove pointless meetings
🔒 Separate “maker time” and “manager time”
🔒 Group similar work together
🔒 Say “no” more often
🔒 Take time off
🔒 Bonus: Biggest lessons I learned
🔒 Last words

Let’s start!

Managing my time was one of the biggest struggles I had as a first-time team lead

When you grow to a lead role, everyone wants your help, advice, or your involvement as well. I found myself saying yes to everything (which is NOT the way to go!). I’ve helped solve problems, joined discussions, supported everyone, and gotten involved in a lot of different initiatives.

The result was 10–12+ hour workdays, working as a manager during the week, and working as an engineer during weekends. It wasn’t sustainable.

It’s really important to understand that if you don’t manage your time correctly, your team will struggle, important work won’t get done, and you will eventually burn out.

A big learning for me was the following:

The more senior you become, the more you succeed through others, not through your own output.

As a lead, don’t try to take on all the hardest tasks yourself. That turns you into a bottleneck. It’s much better to delegate, trust your team, and focus on enabling others to succeed.

Now, let me share some of the most important things you need to do in order to manage your time effectively.

Prioritize ruthlessly

You need clarity on what to work on, what to schedule, what to delegate, and what to ignore.

A useful framework is dividing tasks into four categories:

• Do first: Important and urgent tasks.

• Schedule: Important but not urgent tasks.

• Delegate: Urgent but less important tasks.

• Don’t do: Not urgent and not important tasks.

One of the worst things you can do is keep everything in your head, and even worse if you can’t decide on priority.

Indecision often creates so many more problems, in some cases, a lot more problems than making a wrong decision. Because then you know that the decision was wrong, and you can pivot to the right one.

So, make sure to make decisions quickly. Either do it, schedule it, delegate it, or remove it.

Make sure to block focus time in your calendar

Everyone needs time dedicated just to focusing, without being distracted. If you don’t protect focused work time, your calendar gets consumed by meetings and “someone else’s priorities”.

And you might think that you are productive, but at the end of the day, nothing really gets done, therefore, I highly recommend putting dedicated focus blocks into your calendar.

Examples:

• 2–3 hours daily,

• half-days,

• a full day once a week,

• or several long blocks during the week.

Make sure that during the focus time, you disable any notifications, no meetings, no emails, no Slack messages, and other distractions.

Try to keep focused on what you are doing. This was one of the most impactful changes I made as a first-time lead, which has really helped me be able to do good work long-term.

A very important and underrated part is that it also creates healthy boundaries because people see you’re unavailable during those blocks.

Use a Pomodoro timer to avoid distractions

Additionally, if you have problems with focusing, the Pomodoro timer is the way to go. It always puts me in a state of focus because I intentionally avoid distractions, while the clock is telling me to focus.

I typically go for 25 minutes of focused work and a 5-minute break. Sometimes I go for 50 minutes of focused work, and a 10-minute break. Depending on how focused I feel and the overall motivation. I put the timer on full screen on one monitor, and then do the work on a bigger screen.

This helps me to stay in the zone and reminds me that I need to focus. Whenever I feel like my mind wants to do something else, the timer reminds me it’s time to focus.

During the focus time, I don’t check Slack, I don’t check my phone, I don’t look at social media, etc. The focus should only be on one task, and to finish it. Pomodoro helps force you into deep work mode.

Improve communication to save time for everyone

A lot of wasted time comes from poor communication. I like to say that overcommunication is better than undercommunication.

I intentionally overcommunicate specific topics in order to ensure that things are really clear, especially in a remote environment, working with people from all over the world, across different time zones.

It’s a lot better to say things multiple times and ensure they are understood than to assume they are, and you assume wrong. Overcommunication is usually the right amount of communication.

Key habits that will help you with this are:

• explain the “why” behind decisions,

• set clear expectations,

• avoid misunderstandings,

• proactively communicate,

• ask for feedback regularly.

And additionally, if you have something important for the whole team to focus on, say it in a meeting, and then also write it in the team’s Slack channel as well.

Remove pointless meetings

There’s nothing wrong with removing a meeting that is no longer useful. Not every meeting should exist.

The problem actually comes if there’s a meeting that is scheduled in a weekly cadence, and nobody feels comfortable removing it. While there’s no actual outcome from the meeting.

Always keep asking yourself:

Does this meeting help make a decision? Is this meeting necessary? Could this be async instead?

Separate “maker time” and “manager time”

Read more

Read more

Engineering Leadership LIVE Event in San Francisco

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26th!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership LIVE is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after. I’ll be sharing more about the speakers in future newsletters!

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there! Let’s get back to this week’s thought.

Intro

Many companies these days are removing AI completely from tech interviews, not allowing the use of any of the AI tools to solve a coding task.

But that’s wrong.

Not allowing the use of AI is like removing a tool that engineers use daily. Similar to Google, Stack Overflow, or using an IDE. Are you going to remove that as well, and just check how well a candidate memorizes specific functions of a programming language?

Modern engineering is: having good judgment + using AI to move faster. Judgment is the important skill you should be checking.

So, why remove something that engineers use and are expected to use every day?

Especially, it doesn’t make sense when a company is even pushing for more AI adoption.

In today’s article, I am sharing in detail about which parts of the hiring process I recommend allowing the use of AI and which not.

I am also sharing 3 concrete options on how to structure a tech interview, so you allow the use of AI, and get all the info that you need to do a proper assessment of the candidate.

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

- AI-assisted engineering is the best way to build software these days
- Leetcode-style of a tech interview has been a standard for years
- I’d be surprised if, by the end of 2026, companies still use such a type of interview
🔒 This is my recommendation for a tech interview in 2026
🔒 This is how to structure a tech interview
🔒 Option 1
🔒 Option 2
🔒 Option 3
🔒 Putting it all together, the full process for hiring a new engineer
🔒 Last words

Let’s start!

AI-assisted engineering is the best way to build software these days

It has become a standard for the way we build. Most of the engineers these days are using AI in at least some part of the development process, which may be generating code, researching, or something else.

Learn how 15 engineers and engineering leaders use AI in their day-to-day work in this article:

To quote from the recent survey conducted by JetBrains:

The biggest question is not whether developers use AI at work. The answer to that is already obvious: They do. In January 2026, 90% of developers regularly used at least one AI tool at work for coding and development tasks, a clear sign of high AI usage in software development.

We are currently in May, which means that the % of engineers using at least one AI tool has just increased.

So, if using AI as part of the development process is a standard these days, why would companies want to remove AI from the assessment of new candidates?

The goal with the tech interview should be to get as close as possible to the actual work that an engineer is doing on a daily basis, right? That’s how you can assess whether it’s a fit or not.

Well, that’s been a problem for years now as well, even before AI became so popular. Let’s get to that next.

Leetcode-style of a tech interview has been a standard for years

LeetCode (the platform) was founded in 2015, and quite quickly after that, it became the go-to style for tech interviews in many companies. It has become a standard for “objectively” assessing the technical skills of a certain candidate.

Well, I was never a fan of it, and I’ll tell you why.

When I was a Software Engineer, preparing for interviews, I solved 200+ leetcode style type challenges, and while solving them, I kept looking for specific patterns that could be reused across different challenges.

I made sure to create templates, which I could reuse for any problem that I’d be asked to solve in an interview. So, doing that, I was well prepared for interviews, and I also nailed the interview and got the job.

Well, that felt good, that I was able to “grind” leetcode challenges for weeks, and I got the job, but then none of it really helped me in my day-to-day work.

The work that I was doing was completely different than what I had been grinding for weeks.

So, basically, with the leetcode-style type of interview, you don’t really assess the actual skills that a specific engineer needs to be able to do the job well. You assess whether the person has been practicing such types of challenges or not.

I’d be surprised if, by the end of 2026, companies still use such a type of interview

Especially these days, with AI, you can solve any of the leetcode-style challenges in a matter of seconds.

And if the standard in our industry is AI-assisted engineering, then it really makes no sense to “check the tech skills” with problems, which can be easily solved with a prompt.

I’ve talked to many engineers and engineering leaders about this, and many share a similar sentiment, so I’ll be really surprised if, by the end of 2026, we’ll still see such interviews done by any of the companies.

As mentioned, a leetcode-style interview just checks whether the person has been practising solving such problems or not. But these problems are not even close to what an engineer does on a daily basis.

Now, let me share what my recommendation is.

This is my recommendation for a tech interview in 2026

Read more

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26th!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership LIVE is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after. I’ll be sharing more about the speakers in future newsletters!

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there!

Gregor

Read more

Read more

Intro

I’ve been interested in writing about the FDE role for a while, as I’ve seen the big increase in popularity in recent years.

And especially after attending the Salesforce TDX in SF and speaking with Nick Johnston, SVP, Global Consulting Partnerships & Partner Sales at Salesforce, it became clear that the role’s popularity is just increasing.

We talked for 30+ minutes just about FDEs and what they do! Here is also the picture:

Today, I am sharing my thoughts on whether I think you should become an FDE or not, what FDEs really do, and who the role is best suited for.

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

- What is a forward deployed engineer?
- Why the role exists
- What a forward deployed engineer at Salesforce does
- What a forward deployed engineer at OpenAI does
- What a forward deployed engineer at Palantir does
🔒 Should you become a forward deployed engineer?
🔒 The pros
🔒 The cons
🔒 Who thrives in this role?
🔒 Is it a good career move?
🔒 Last words

Let’s start!

What is a forward deployed engineer?

Forward deployed engineer (FDE) has gained a lot of popularity in recent years, especially among tech companies that work directly with businesses (B2B).

What my feeling is, talking with different engineers and engineering leaders about the role is that a lot of people have some sort of idea about what FDEs do, but in reality, the roles are quite different from one company to another.

The role varies based on the requirements of a specific company. Which means the skills needed (especially on the tech side) are different, but one thing is clear. Customer empathy is really important, and it’s highly unlikely to be a great FDE without being able to put yourself in the shoes of the customers.

I like to personally view this role as an intersection between software engineering, customer success, and product/business. The reason is that FDE’s primary role is to help customers use their products.

Therefore, they need to be technically savvy and, at the same time, be able to communicate well with the customers and have a good understanding of the product and the overall business, so they can find the right solutions.

Think of the role as a consultant who is also a main developer, integrating the solution directly. In many ways, you’re not just building software, you’re solving business problems in real time.

If you’re considering this path, it’s worth understanding what the job really involves, who it’s best suited for, and the trade-offs you’ll face. Let me share, next, why the role really exists in the first place.

Why the role exists

Especially companies that offer more complex products to their customers, can face issues between what their product can do and what customers actually need. FDE is the person helping to fill this gap.

They help:

• Increasing adoption of the product

• Customize implementations for specific customers (if needed)

• Gather feedback from customers to improve the product itself

Let’s go through, next, what FDEs at Salesforce, OpenAI, and Palantir do.

What a forward deployed engineer at Salesforce does

Nick mentioned that there is no single recipe for the role, and it may vary a lot from customer to customer, but the core responsibility is clear:

Help customers get value from technology faster.

An FDE typically starts by understanding the customer’s needs, pain points, and, of course, their current environment:

• What systems are already in place

• Where customer data lives

• How that data flows across systems

Once that is a lot clearer, they focus on defining use cases that would help the customer.

Example use cases:

• Adjusting the data flow

Not just within Salesforce, but also in external systems in order for the customer to be able to integrate with Salesforce successfully.

• Setting up AI agents in order to automate a certain business process

This is another use case (which seems to be a popular use case, based on my impression from the Salesforce TDX conference).

As we mentioned in the article, 3 Key AI Trends, EGI (Enterprise General Intelligence) is something that should be a clear focus for all enterprise companies. And EGI means using AI, its tools, and systems to perform business-specific tasks with high capability and consistency.

• Implementing the right guardrails for the customer

And a third use case that Nick has mentioned is implementing the guardrails, which may be security, governance, compliance, or something else. Especially important for bigger companies, which need to ensure compliance with specific standards.

These are just examples of use cases that FDEs deal with. To sum up, the core focus of FDEs is to ensure they understand the customer’s needs very clearly and find the optimal solutions to help them get the best results.

There are 2 types of FDEs at Salesforce, internal and partner

1. Salesforce FDEs (internal)

These engineers are closely connected to the product organization. Customer work is secondary unless a client explicitly requests Salesforce involvement. Their main goal is to:

• Gather feedback on product features

• Test new features in live environments

• Help improve the product

2. Partner FDEs

Those are FDEs from companies like Accenture and Deloitte, who work directly with the customers:

• To deliver specific implementations for a customer

• Provide direction or solution design

• Have support from Salesforce FDEs

This partner model helps Salesforce to scale without building a massive internal services organization.

What a forward deployed engineer at OpenAI does

I’ve checked all the different openings of a forward deployed engineer position at OpenAI, and here is what I found out.

FDEs are expected to:

• Design, architect, and develop full-stack solutions

• Build production AI systems and integrations

• Deploy advanced AI models on customer infrastructure

This is a combination of being a solutions architect, software engineer, and AI engineer.

They provide a hybrid work model of 3 days in the office per week, and travel up to 50% is required. Which means that FDEs are consistently traveling to customers and working directly on-site.

A lot of the FDE roles are general, defined as Model Deployment for Business, which means that they can contain any kind of work related to OpenAI. From creating custom GPTs for the customer to helping integrate OpenAI into the logic of the customer’s applications, or something else.

There are also some more specific focused FDE roles like “FDE, Financial Services”, which means that FDE works mostly with Fintech companies.

What a forward deployed engineer at Palantir does

Palantir is the company that first invented the role, and from doing research, the reason was that their software was too complex for customers to just “plug it in”, therefore a dedicated person was needed to get a specific customer up-to-speed.

Here is the definition of an FDE from their official blog:

FDE is a software engineer who embeds directly with our customers to configure Palantir’s existing software platforms to solve their toughest problems.

While a traditional software engineer focuses on creating a single capability that can be used for many customers, FDEs focus on enabling many capabilities for a single customer.

Additionally, they mention that FDEs need to be iterating closely with customers across various industries and require a unique and broad skillset, ranging from software development to data engineering to customer engagement and creative problem-solving.

FDEs need to address questions like:

• What products are we deploying for this use case?

• Why are we deploying them?

• How will we spin up workflows that utilize these products to address the customer’s specific needs?

FDEs need to be able to answer these questions, and at the same time, also implement these solutions.

Now that we better understand the role and what it looks like based on different companies, let me share whether you should actually become an FDE yourself.

Should you become a forward deployed engineer?

Read more

Read more

Intro

My recent trip to San Francisco and meeting with different people and companies got me thinking a lot about the differences between EU and US tech companies.

Especially the conversation we had with the Larridin team, about different markets and how US vs EU tech companies operate. Here are also some pictures from the visit:

I’ll be sharing more about how they work in a future article.

In today’s article, I am sharing my thoughts about the differences between US and EU tech companies, the mindset behind them, and the pros and cons of each.

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

- I’ve worked with a number of EU and US companies over the course of my career
- US companies tend to innovate a lot more than EU companies
- EU companies are a lot less prone to taking risks
🔒 I see a lot less self-confidence in EU companies in comparison to US companies
🔒 Work-life balance is a lot better in EU companies
🔒 US companies tend to let go of people faster
🔒 Sales-oriented & crushing the competition mindset is prominent in US companies
🔒 EU companies are dealing with a lot more regulation
🔒 US companies raise a lot more capital a lot more quickly
🔒 Last Words

Community chat

Before we start with today’s article, a reminder. As a paid subscriber, you are able to ask any questions related to engineering/engineering leadership and get an opinion from like-minded people.

• Share ideas, challenges, or get an opinion on the approach (you can start a new thread)

• Connect with everyone

• Special opportunities

We are just discussing the biggest challenges in our roles. Make sure to share yours as well!

Join the community chat

Let’s start with today’s article!

I’ve worked with a number of EU and US companies over the course of my career

In my full-time roles, I worked for both EU and US companies as a (senior) software engineer, at the same time also as a manager (Team Lead, Engineering Manager, Head of Engineering, Interim CTO).

I was also a VP of Engineering and a CTO for a company based in Singapore, but we had the team in the majority in the EU.

Alongside doing full-time roles, I was also doing freelance projects. I like to say that freelance work has been my secret to the growth of my career. I finished over 100 projects for both the EU and US clients, while most of the clients were from the EU.

At the same time, I did (and still do) advising and consulting for both US and EU companies, and I also do coaching and mentoring, having the pleasure to work with different people across the world.

And of course, I also had the pleasure to attend many different events, speak at conferences, both in the US and the EU, and meet many different people, both in person and online. I also regularly talk with engineers and engineering leaders across the world.

So, my perspective on how tech companies operate comes from a lot of different angles, and I’ll share my view on what I see.

Let’s start with the first difference and the one that I felt the most, especially during my latest visit.

US companies tend to innovate a lot more than EU companies

From my experience and what I am seeing across companies in the US, especially in San Francisco, is that they are all constantly evolving and trying new things. While in the EU, there’s a lot more fear of change, therefore, less innovation.

US companies tend to try new things faster, learning as they go, making mistakes. Change is something they actively look for. There’s a bias to take action, even when no one knows exactly how it’ll turn out.

A good example of that mindset is the company that I recently had the pleasure of getting to know, the company called Weave, and I wrote about how they work in this article.

In the EU, the mindset is often different. There’s a lot more focus on stability, predictability, and getting things “right” before moving forward. While this can be the right move for some companies, it slows down innovation.

There are definitely exceptions on both sides, and SF does not represent the whole US, but that’s the difference I see in the majority of the companies.

Neither approach is inherently wrong. One optimizes for speed and innovation, the other for precision and reliability.

But in a world that’s moving faster than ever (especially because of AI), I think speed and innovation are what’ll make a big difference in the upcoming years.

Let’s go to the next one.

EU companies are a lot less prone to taking risks

From what I’ve seen working with and observing companies across Europe, there’s generally a much stronger urge to minimize risk. Decisions are made more carefully, plans are more detailed, and there’s often a clear desire to avoid unnecessary uncertainty.

Risk-averse is the right phrasing for many of the companies in the EU, and change is something that many people tend to avoid. And from my experience, change is something that a lot of people in the EU are not looking forward to, and it takes a decent amount of time for the change to be accepted.

While in the US, my feeling is that changes get accepted a lot quicker, where it feels like decisions get made overnight.

In the EU, before launching a new product, entering a new market, or making a big strategic decision, there’s usually a lot of validation, alignment, and internal consensus needed. Things need to make sense not just in theory, but also in terms of long-term sustainability.

While working with US companies, I felt many times that some of the decisions were rushed, but people have been comfortable taking them, even though the results have not been guaranteed.

“Go big or go home” mindset is something that I’ve seen in many companies in the US. Especially in SF.

Some of the examples that I saw in US companies, that I haven’t seen in the EU:

• Completely changing the direction overnight through an email, without explanation

• Letting go of half of the engineering department and shutting down access completely

• Setting extremely aggressive, a lot of times unrealistic targets (revenue, growth, product timelines) and committing to them publicly

Of course, there are exceptions in both US and EU companies, and it depends a lot on the industry as well.

Now, the next one is related to both of the points I’ve mentioned before, but it’s extremely important to understand why I believe that is the case.

I see a lot less self-confidence in EU companies in comparison to US companies

Read more

Read more