Intro

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

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

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

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

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

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

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

Let’s start!

What does AI-native actually mean at Anthropic?

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

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

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

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

The structure of AI-native teams

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

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

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

The reasoning for it is the following:

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

Similar structure with an important difference

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

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

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

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

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

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

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

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

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

Additionally, Anthropic has a specific role inside their company called Prod Ops (product operations), with the role of making systems, processes, and tools more effective so PMs and teams can make better decisions more quickly and achieve better results.

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

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

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

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

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

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

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

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

They value the traditional quality pyramid:

• Most unit tests

• Lesser integration test

• Even fewer e2e tests

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

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

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

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

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

All of their code is AI-generated

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

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

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

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

This is also a very important thing she mentioned:

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

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

Defining the desired outcome is key when working with AI

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

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

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

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

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

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

Additional use cases for using AI in their work

Read more

This week’s newsletter is sponsored by Blitzy.

Blitzy is the first autonomous software development platform with infinite code context, enabling Fortune 500 companies to ship 5x faster from Figma design to production code.

It’s engineered specifically for enterprise-scale codebases due to its deep understanding of your codebase and design standards. This can clear years of tech debt, execute large-scale refactors, or deliver new features quickly.

Some of Blitzy’s core features:

• Self-improving knowledge graph: Maps millions of lines of code and their dependencies to create a live understanding of your codebase.

• Figma integration: Turns Figma designs into responsive, pixel-perfect frontend code that connects to your backend.3

• Agent orchestration: 3,000+ specialized agents plan, build, and validate production-ready code.

Result: 80% of the work delivered autonomously, 5× faster. If you are working on an enterprise-scale codebase, I’d definitely recommend checking them out!

Sign up for free and start building

Thanks to Blitzy 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.

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

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

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

4. 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 Anwar Haneef’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 insights.

Let’s start!

The shift from UI to building for AI agents

Canva has recently made a shift from focusing just on UI (user interface), to focusing on building for AI agents.

They introduced various AI features on their platform, they’ve built an MCP Server so that you can search, create, edit, manage assets, and also publish from your preferred interface.

Additionally, they also created (still creating) different AI connectors, so you can use ChatGPT or Claude to start creating a design from the conversation. I believe that’s been a great decision from their side. Embracing the changes, instead of sticking to what used to work for them.

This is a very similar shift to what Salesforce has made. Just Salesforce made it a lot more sensational, with the question: “Why should you ever log into Salesforce again?”.

I wrote about the shift in this article:

Now, let’s go more into building for AI agents.

3 main questions everyone building products is asking these days

1. Will agents replace my product?

2. How do I build integrations that agents can find?

3. Do I build my own agents or become a tool agents use?

At Canva, they focus a lot more on the second question and ask themselves: “How do we ensure agents reach for us?”. Anwar described the reasoning with 3 important shifts they see happening in the industry.

These shifts are:

• Behavior shift

Humans browse UIs, agents call APIs. If your value is locked behind a graphical interface, agents can’t find it.

• Distribution shift

Agents are the new surface, and you need to treat them as the new first-class citizen.

A similar shift Anwar mentioned was the shift when people started using mobile phones to browse websites and use mobile apps.

The companies that really embraced that change and built their products to have a great experience using mobile phones, won in that era.

• Value shift

People pick your product a lot of times for subjective reasons: a beautiful interface, colors, or a friend recommended the product to them.

Agents are objective. They don’t care about beautiful interfaces or colors. They only care if your product can do what it needs to do, reliably at that moment in time. That’s also why domain expertise is really important these days.

With these shifts, and also that the barrier of entry for creating designs has significantly lowered, they want to make it as easy as possible for everyone to create great designs, even outside of their primary graphical interface. That’s where AI agents come in.

Building for this shift, they made a lot of learnings throughout the process. Here are the top 5 learnings from building for AI agents.

1. Treat your MCP setup as a living system

When they built their MCP integration for the first time, they made a lot of mistakes. And the reason was that they wanted to get it out as soon as possible to get to the market quickly and to see what the feedback would be from everyone. This created problems over time when they needed to scale.

That’s nothing new in terms of how software should be developed: Get out the MVP → see if there is traction → improve. What I’d mention is the important part here is to treat building a MCP setup as a standalone product, not a one-time thing.

Anwar mentioned that, especially the hosting decisions, the hosting provider, and how they hosted, became a bottleneck over time.

2. Just because you are using MCP, it doesn’t mean you should neglect your API

MCP is only the surface, and if the underlying API is poorly scoped or designed, it makes it a LOT harder to debug issues. So, they needed to focus on revamping their API design in order to debug issues correctly.

It’s a lot harder to debug MCP directly, and a lot easier to work with APIs, so that’s how they were able to build MCP reliability over time.

The reason is that APIs are deterministic. You send a request, inspect the request/response, log everything, replay failures, and debug. With it, you are able to replicate issues reliably.

MCP introduces another layer. Instead of your application calling an API directly, an LLM decides when and how to use tools. When something goes wrong, it's harder to tell where the issue is: the LLM making a wrong choice, or the issue was with the MCP client, the MCP server, or the underlying API.

3. Agents can be quite picky

The way agents call your service can be quite different from what you originally anticipated. The reason is that the LLMs are the ones that decide the order of calls and how they are going to approach solving your particular request.

And also, as you know, LLMs are nondeterministic, which means that there might be a different output to the same input. You can’t fully anticipate the response.

Anwar’s advice is to treat the Agent Experience as a first-class citizen, and focus on making it as good as possible. Similarly to how User Experience (UX) has been a big focus point for many companies in the past, now Agent Experience is the one that needs the biggest attention.

4. Treat authentication and identification as a first-class product feature

As Anwar mentioned, authentication was a constant friction with every integration across multiple platforms for them. They didn’t treat it entirely as a first-class product feature, and because of that, it was slowing them down.

As a result, they needed to invest more time in their auth setup afterward, and it slowed them down when integrating with other platforms, which would not be an issue if they invested more time into it right from the start.

5. Your product should be a domain expert, not jack of all trades

Agents will look for tools and products that are considered to be “leading experts” in certain areas. If you try to be best at everything, you will likely be best at nothing, and agents won’t even know you exist.

In Canva’s case, they focused on being one of the leading products for design and also optimized the use of their tools for AI agents.

So, the question for you, building a certain product, and want to get recommended either in AI’s output or by AI agents’ default choice:

What is that one thing that your product does really well, which distinguishes it from others, so that AI agents would recommend your product?

The agentic era is the biggest growth opportunity of the decade

Similar to the shift that we’ve seen with mobile and even before, with desktops and personal computers becoming a new norm, the AI era is the next big shift in our industry and can be a huge growth opportunity.

These are the 3 areas that Anwar suggests for anyone to focus on, building a certain product, to be successful at this time:

1. Make Agent Experience a first-class experience

Don’t try to match the user experience and agent experience, instead, build your product in a way that can be easy to consume and easy to discover by agents.

2. Anchor bets to observed shifts

Don’t just build for where the market is today, make sure to focus also on where it might be going. Watch how users are adopting AI, how agents are improving, and what new behaviors are emerging.

The biggest opportunities come from identifying these shifts early and building products that align with how people and AI agents will work in the future, rather than simply improving existing workflows.

3. Invest in your domain expertise

Focus on your differentiation, and ensure that you are focusing on trying to be the best at what you do, not trying to be the best at various different things. Agents always look for specific tools and products which can solve 1 problem really well.

Last words

Let’s end this article with the following:

AI agents are becoming a new distribution channel, and the question is no longer just whether people can find and use your product, but whether AI agents can too.

Special thanks to Anwar for sharing his insights in his talk at the Engineering Leadership LIVE event in San Francisco.

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

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

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

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

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

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

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

Let’s start!

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

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

There are 2 options on what happens next.

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

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

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

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

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

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

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

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

Another situation that happens on a team level

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

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

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

There are 3 options on what happens next.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to build credibility and become trustworthy?

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] 8 levels of context maturity in AI-native engineering

AI shows up in 60% of engineering work. But only about a fifth of it can be handed off without someone babysitting the output. That’s because agents are missing context.

This 8-stage context maturity model gives a real answer on why you haven’t seen meaningful productivity gains for all the tokens burned.

Join live June 24 (FREE) to learn:

• Why more MCPs provides agents access but not understanding

• What it takes to deploy agents you can trust without supervision

• How a context layer solves for quality, efficiency and cost

Register now

Thanks to Unblocked 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

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

Full overview of Andrew’s talk in this article:

- 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 Vinay Perneti’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 insights.

Let’s start!

The November 2025 moment

You might remember the release of Claude Opus 4.5 and the big shift it had on the industry. This is what Vinay mentioned in his talk:

“In November 2025, we were working with Anthropic to launch Claude Opus 4.5. At the time, it just felt like another model. The evaluations looked good, but nothing about it seemed extraordinary.

Then, in December, something changed. I had regular 1:1s with the team, and independently, several of our best software engineers told me the same thing: it no longer made sense for them to write code by hand.

That caught me off guard. These engineers had already been using AI agents for a long time. So I asked, “What changed?”

AI agents got a lot more reliable. The team mentioned that AI agents had become much better at following instructions reliably. So, they started trusting them much more.

Hallucinations had also dropped significantly, so they could confidently let agents work on tasks for much longer without constant supervision.

Now, let’s go through a very important message next.

The exponential trend of LLMs becoming better

The chart below shows the difference between models, based on the longest real-world software task it can reliably complete 50% of the time.

Even though the chart looks linear, there’s actually exponential progress, as you can see how big a difference it is between GPT-3.5, which can reliably do a 36-second task, versus Claude Opus 4.6, which can reliably do a 10h+ task.

Some people even call this super-exponential progress.

So what does that mean in practice?

If this trend continues, by the end of the year, we’ll have agents that are roughly 10× more capable than Opus 4.5.

Based on the data, that’s the trajectory we’re on. Now, let’s go more into the AI transformation journey.

Engineering productivity after adopting AI agents

In December 2025, when engineers started to regularly mention that it doesn’t make so much sense to manually write code anymore, the expectation for many of the engineering leaders around the industry (Augment included) was to get a 2-3x productivity increase.

But in reality, what they saw at Augment was the 20-30% increase. The reason? The main reason was the bottlenecks.

AI transformation doesn’t happen with just individuals transforming, you need a whole team to develop the same mindset. You need the whole system to change and go after the bottlenecks.

It was a wake-up call for Augment, and they experimented with a lot of different things in order to become more productive over time.

Let’s go through the 3 myths and 3 learnings from their AI transformation journey.

Myth 1: “Al-Native means everyone is using agents”

Most of the companies these days would say that they are “AI-native”, but in reality, there is a big difference between using ChatGPT to get answers and orchestrating different AI agents to do a certain work in parallel.

At Augment, they had some engineers chatting with an AI agent, and some people orchestrating multiple AI agents.

Here are also the 4 levels of being AI-native:

It’s a totally different way of working if you are on a level 1 than if you are on a level 3 or 4. You need totally different systems in place between these levels.

The message from Vinay is very important here:

Being AI-native is not a destination, it’s a journey, and the journey keeps changing as the capabilities are evolving.

Myth 2: “You can drive the AI transformation top down”

We saw companies trying to do a top-down AI transformation in 2025 everywhere. The most prominent example was the memo from Shopify’s CEO. I’ve also extensively written about this back in 2025:

“Everyone is adopting agents”. “This is our OKR”. “We are going to track adoption”. “I am going to make this a part of the performance evaluation”. These have been some of the common sentences from companies back in 2025.

And what was the outcome?

People did adopt the new way of working, but organizations did not make the full AI transformation.

The AI transformation journey is not just changing 1 behavior, it’s about changing the whole system. And at the same time, it’s human nature to resist change, it’s an even higher urge to resist if something is forced upon you.

If you’re forced upon something, the first time you’re going to run into a problem, you’re going to go to your manager, and say: “I told you this wouldn’t work”.

In order to have a successful AI transformation journey, you need a bottom-up initiative.

And the reason is that when a certain issue comes, or a new bottleneck emerges, people don’t wait for top-down direction. Instead, people look to resolve such things themselves, collaboratively.

This principle is important everywhere, but even more important in the AI transformation journey, because the bottleneck keeps changing over time.

Myth 3: “This is entirely technical problem”

The biggest mistake an engineering leader can make is thinking that AI transformation is entirely a technical problem.

“Let’s bring the new best tool”. While a tool is important, it’s not enough. A tool will just help you with the journey, but it won’t make it successful. You need to get the buy-in from the people.

As part of the recent report done by Augment Code, they asked 219 engineers and engineering leaders the question: “What are you fearing the most right now?”.

89% mentioned that they fear that their skills will no longer be relevant.

Basically, the majority of the people (9/10) are feeling this, and they probably haven’t voiced it enough. And if someone is in that mental state and it’s not acknowledged, their willingness to embrace something new is going to be very low.

As an engineering leader, you really need to think about this side as well. You can’t just bring a new tool to the team and expect that there’ll be a successful transformation.

Now that we have gone through the 3 myths, we’ll go through the 3 learnings from Augment’s AI transformation journey.

Learning 1: Slow down to speed up

This is a great analogy that Vinay mentioned:

“Even a Formula 1 car has to slow down when it makes a turn”.

And that is true for all the organizations. If you don’t slow down, you might be going full speed in the wrong direction. This can be very problematic (even more so these days, as the speed of building has increased).

At Augment, they slowed down and took 2 days offsite for the whole engineering team, and did the following:

• Day 1: Hackathon

The theme of the hackathon was: 10x your agent, 10x your team, and 10x yourself. With one additional constraint which was: Whatever you’re building, build it entirely with AI agents.

That’s how the team was able to experiment, share their ideas, and implement them as well.

• Day 2: Human side

Vinay mentioned that day 2 was a LOT more important, and that day 1 was actually preparation for day 2.

They opened day 2 with Mentimeter: Live question being asked and put on the screen: “What feelings are you going through now after yesterday’s hackathon?”.

And then asked everyone to answer it (anonymously), and the answers showed up on the screen. The 2 biggest themes of the answers were:

• Fear, uncertainty

• Curiosity, excitement

And an interesting thing happened after this:

Everybody felt like they were not alone, feeling that way. There’s something very powerful about seeing on the screen what you’re feeling, and seeing that everyone feels the same way.

Secondly, Vinay asked the team another 2 questions:

1. “What do you think we need for AI agents to be more productive?”

2. “What are some of the new behaviors that we need to adopt as a team?”

They created 30-minute breakout groups to think about these 2 questions, and everyone came up with very interesting conclusions like:

• Verification is the biggest bottleneck

• Producing the high-quality spec is the highest leverage work a human can do

• Code review is also a big bottleneck

• Agents amplify both good and the bad

Learning 2: The throughput of a system is governed by its slowest link

There’s a book called The Goal, by Eliyahu Goldratt, which talks about the importance of always finding the slowest link and working to improve it.

If we look at software engineering throughout history, coding has been a bottleneck, until now. And as agents get better and better at coding, the bottleneck shifts to something else. You need to actively be thinking about that.

This is what they found out at Augment regarding the bottleneck shifting over 2025 and today:

Learning 3: You need a system

As we know, smaller AI-native teams are the preferred way of working these days. And these teams usually work with a large number of AI agents.

And in order to have that way of working possible, your system needs to evolve as well. You can’t expect to just create smaller teams and put 1-3 engineers together working on different projects and expect that things will remarkably change for the better.

In order that the change becomes successful, your system needs to evolve as well.

3 main takeaways

1. AI-native is a system redesign problem

Al-Native transformation journey is so much more than adopting AI agents. You can’t just give the team a new tool and expect that things will magically work out for the better.

At this time, it’s really important that you show up as a leader: be supportive, provide space for the team to experiment, and give them the psychological safety, so they can make mistakes and learn from them.

2. Tackle bottlenecks in your system, one at a time

If coding is not a bottleneck anymore, think about where the bottleneck is going. Figure that out and focus on resolving it.

3. AI transformation is a part human and part technical

Everybody in software at this time is going through an identity crisis, so you need a way to acknowledge that and be supportive on this journey. That is very important to keep in mind.

2 questions for reflection

2 very important questions for you to reflect on. Make sure to block some time!

1. 6 months from now, when agents are 10x better, what does your org look like to take full advantage of that shift?

2. Where does human involvement have the highest leverage?

Last words

Let’s end this article with the following:

The teams that succeed in the AI transformation journey are not the teams that have the largest number of AI agents. The teams that succeed are the ones that adapt their systems so that humans and agents can work side-by-side effectively together.

Special thanks to Vinay for sharing his insights in his talk at the Engineering Leadership LIVE event in San Francisco.

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

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

• acknowledging the good work,

• areas for improvement and

• setting individual goals.

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

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

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

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

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

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

Let’s start!

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

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

Therefore, I always keep in mind the following:

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

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

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

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

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

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

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

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

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

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

Every company has a slightly different process regarding performance reviews

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

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

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

The cadence of performance reviews

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

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

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

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

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

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

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

Understanding different reviews

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

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

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

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

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

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

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

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

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

The tools to use

Read more

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

Read more

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

Read more

Read more

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

Read more

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

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 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