Intro

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

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

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

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

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

Let’s start!

Why is AI-generated writing problematic?

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

Here is a good example:

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

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

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

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

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

Another example, the problem with AI-generated code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Brevity is more important than ever

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

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

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

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

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

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

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

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

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

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

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

How to write clearly?

Read more

This week’s newsletter is sponsored by Faros.

Most engineering teams have adopted AI. Fewer can say what it’s producing. Token consumption is exploding.

Engineering leaders must know if spend goes to productive work or on agent retry loops on trivial tasks. The flow shifted from token to shipped outcome.

Faros’s Engineering World Model connects your teams, tools, repos, and workflows.

• It observes where every token went and what shipped

• It diagnoses the root cause behind every efficiency leak

• It optimizes by routing models, skills, & context proven on your own code

Learn more

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

Intro

Interestingly, almost every company I talk to these days has a different engineering org & team structure.

2 years ago, the org structure was fairly standardized, with 2-pizza cross-functional teams and an engineering manager leading the team. Then a Director managing 2-4 engineering managers, and reporting to a VP, which reported to the CTO.

These days, everyone is figuring it out as they go, making adjustments and seeing what may work and what not.

I’ve seen both very traditional and some extremely unique engineering org structures this year.

In today’s article, I am sharing the differences between Anthropic, OpenAI, Shutterstock, and also additional honorable mentions (some are very unique setups).

Let’s start!

How OpenAI builds AI-native engineering teams

I talked to Thibault Sottiaux, who is heading both ChatGPT and Codex, earlier this year, about how they are building AI-native engineering teams.

Interestingly, they mostly hire Software Engineers, who can build projects end-to-end, and also own projects from an idea all the way to when the project is launched and then also maintained.

Teams are separated based on specific projects, and mostly consist of 2-4 engineers. The ratio between manager-to-engineer is very similar to PM-to-engineer, which is around 1:30.

Thibault also mentioned that in the Codex department, there is even a 1: 40 PM-to-engineer ratio.

Engineers are expected to wear many different hats, and they work with a PM or a designer when there’s a need for it. Every project also has a DRI (directly responsible individual), who owns the project. Basically, being the Tech Lead making decisions on the project and doing stakeholder comms.

Additionally, the teams have as few meetings as possible, they only meet when they need to align on a certain thing. No Scrum, Kanban, or daily meetings, just teams focusing on executing their project and collaborating on it.

That’s also the reason why a lot of them prefer to work on-site, as they work on that project similarly to a hackathon-style, instead, it’s not a “throwaway” version, it’s an actual product they are working on.

To learn more about how OpenAI builds AI-native engineering teams, read the full article:

Let’s go to the next one.

How Anthropic builds AI-native engineering teams

I’ve recently had the pleasure of speaking with Katelyn Lesse, Head of Platform Engineering at Anthropic, and it’s been very interesting to learn how they are building AI-native engineering teams.

What’s particularly interesting is that they have a completely different mindset when it comes to building engineering teams than OpenAI.

OpenAI works with small teams of 2-4 engineers, while Anthropic still advocates for a traditional 2-pizza cross-functional team with 5-8 engineers, a PM, a Product Designer as part of the team, and an Engineering Manager leading the team.

The main difference between a traditional team and Anthropic’s AI-native team is that there is no dedicated QA engineer. The QA work is expected to be done by anyone inside the team.

Also, the biggest difference is that any Software Engineer can be a tech lead, while in a traditional team, you mostly have 1 tech lead.

That’s how they can run up to 5 projects simultaneously in the team, instead of traditionally 1-2 projects, as the Tech Lead doesn’t have the capacity to lead many different projects simultaneously.

Additionally, they are big advocates for Product Managers, especially TPMs, product managers who really understand the underlying tech as well. Their reasoning is that with many projects happening simultaneously in the team, there’s a bigger need for PMs.

And they are even thinking of having more than 1 PM in every cross-functional team. It’s a completely different mindset than OpenAI, where they have 1 PM for about 30 engineers, while Anthropic has 1 PM for about 5-8 engineers and potentially the ratio getting lower as well.

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

Another interesting thing is that ALL of their code is AI-generated. Instead of manually changing the output of AI-generated code based on the prompt, they provide feedback and guide the AI agent to the correct outcome (required standard).

They see this as a much better workflow than continuously changing the code themselves manually. That’s also the reason why Katelyn believes reviewing AI-generated work has become one of the most valuable engineering skills.

To learn more about how Anthropic builds AI-native engineering teams, read the full article:

How Shutterstock builds AI-native engineering teams

I’ve talked to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock, very recently, and he shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams.

I’ll be sharing a lot more info about it in a future article, but today, I am sharing some of the important points, especially in comparison to how OpenAI and Anthropic build their teams.

Their AI-native engineering team structure is a lot more similar to Anthropic’s. They also work in a 2-pizza team setup with 5-8 engineers as part of the team, and an engineering manager leading the team.

The big difference is that they have about 1 PM for every 2 teams, so the ratio is about 1 PM for 10-15 engineers. Also, product design is not a part of the cross-functional team, and it’s being utilized when there’s a need for it in part of the projects that the teams are working on.

Another big difference is that they have 1 dedicated Tech Lead inside the team, who is responsible for everything technical regarding the projects, but there can also be additional owners of certain projects inside the team, but primarily, one person is the main tech lead of the team.

One important insight that Jefferson mentioned as well is that their product teams work within 2-week sprints and are using Scrum as their way of working, which is the same as traditional teams.

So, they have all the meetings as traditional teams: daily meetings, planning, retrospective, etc. And there’s also a sprint demo meeting at the end of every sprint.

Additionally, at Shutterstock, they also have dedicated ML engineering teams, and they work a lot more differently than product teams.

These teams work within 6-week “bet cycles”, where they focus on achieving a certain goal within the 6 weeks. No Scrum or Kanban.

The reason for quite a different workflow than with product teams is that ML work is a lot more unpredictable, and you can’t really promise certain outcomes in X amount of time. You see what may be possible based on the research that you do.

As mentioned above, stay tuned for the full article on how they are building AI-native engineering teams, which will be published in a future newsletter article.

Other honorable mentions

Let’s also go through some of the structures from other companies.

PortKey

I talked with Vrushank Vyas, Head of GTM and CS, Portkey, earlier this year. Interestingly, they have about 24 engineers, which are all product engineers and no product managers.

Every engineer is expected to wear multiple hats, including being a Forward Deployed Engineer, Customer Support, Product Manager, and, of course, Tech Lead.

Their team structure is a lot closer to what OpenAI does, and their expectation is that every engineer can own a project end-to-end.

And also, very similar to what OpenAI does regarding hiring, they like to hire strong generalists who can build across many different tech stacks, or extreme specialists who are really good in one specific tech.

To learn more about how PortKey works, read the full article:

Weave

I talked with Andrew Churchill, Co-Founder & CTO, and Adam Cohen, Co-Founder & CEO, when I visited their offices in San Francisco.

They have a team of around 10-15 engineers, and all are considered to be product engineers who can wear many different hats and own projects end-to-end.

So, similarly to PortKey, Weave’s AI-native focus resembles what OpenAI is doing.

To learn more about how Weave works, read the full article:

PostHog

Works within teams of 1-3 engineers, with an assigned Team Lead for every team. The Team Lead also reports directly to the VP of Engineering, no middle managers in between.

Telnyx

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

Unfortunately, I don’t have the information on how their teams are structured, but it’s interesting to note how unique their setup is. 1:200 IC to manager ratio.

Last words

Companies seem to have very different engineering org structures and teams these days, and it feels like every company I talk to is doing something differently.

The main takeaway is that there is no perfect engineering org structure at this time. It all depends on what works for a specific organization and team.

So, that’s my advice as well, always look at what’s best for your team and organization, don’t just try to copy some other org blindly.

And doing small changes is the way to go in my opinion. Do a small change and see how it goes, and if it’s for the better, keep it, if not, revert it.

You got this!

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

Intro

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

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

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

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

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

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

Let’s start!

My experience with coaching

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

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

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

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

What’s interesting about coaching is the following

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

The biggest benefits of being a coach are:

• If you can teach it, you understand it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more

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

The main premise of the book:

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

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

And engineers with the biggest impact have the multiplier mindset.

In the book, I cover:

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

• Important traits and skills to develop

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

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

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

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

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

Wish you a great rest of the week!

Gregor

This week’s newsletter is sponsored by Blitzy.

Blitzy is an autonomous software development platform built for enterprise-scale codebases. With deep understanding of your codebase and design standards, it helps teams ship up to 5× faster → from Figma designs to production code.

Some of its core capabilities include:

• Self-improving knowledge graph that understands millions of lines of code and their dependencies.

• Figma integration that turns designs into responsive frontend code connected to your backend.

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

The result? Up to 80% of the work delivered autonomously. If you're working on a large enterprise codebase, Blitzy is definitely worth checking 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

There’s a lot of debate these days regarding what the work of engineering managers should look like. The overall sentiment is pointing a lot more towards being technical, and the trend is pointing in this direction as well.

Especially since the lines between Architect, Staff Engineer, and Engineering Manager are becoming increasingly blurred, and it’s often expected that one person can wear all three hats when needed.

But do I believe that you need to be technical as an EM in all situations? Not at all. I am sharing my reasoning in this article.

Let’s start!

As an engineering manager, your goal is to do what’s best for the team and organization

This is a very important point to always keep in mind as an engineering manager.

Your overall performance is judged by the success of your team, the impact you have on others, and the whole organization, not your individual contribution.

So, that automatically puts you in a position to be an enabler for others → helping everyone do their best work possible, and ensuring that the team is going to be successful.

I always viewed a lot of the EM work as “filling the gaps of the team”. Specific examples:

• If the team lacks good communication and cross-functional collaboration, the EM should be doing a lot of that.

• If the team is lacking technical seniority, the EM should be filling the gap

• If the team needs help contributing with tasks, the EM should be doing that

• If the team needs help with setting clear priorities and boundaries, that’s what the EM should be focusing on, etc.

These are some of the examples. And then there are 2 options you have. Either fill the gaps yourself as an EM or hire someone that would fill them.

Now that we understand the overall focus of an EM role, let’s go through the difference between the people manager and technical manager.

People manager vs technical manager

You can’t be the best at both. There is a limited amount of time every day, and it all depends on how you spend it.

1. People manager

As a people manager, you spend more time growing your team, unblocking them, communicating with stakeholders, aligning with the leadership team, and ensuring your team has everything they need to be successful.

2. Technical manager

As a technical manager, you spend more time reviewing architecture docs and tech specs, as well as reviewing code, while contributing to the codebase as well. You’re also a lot more involved in overall discussions when it comes to making technical decisions.

Over the course of my career, I’ve seen both types work well. I’ve personally been a mix of them, and for some situations I’ve been the first one, especially when I grew to Head of Engineering, VP, and CTO.

And I’ve been the second one as a Team Lead and Engineering Manager. But as an EM, I’ve also changed over time to being more like a people manager, as the teams I led grew to be more autonomous.

So, both types can work well, but it’s important to understand that being best at both is not possible. If you spend more time on technical direction and contributing to the codebase, you’ll spend less time communicating, unblocking, and growing your people.

Now that we understand the differences, let me share my recommendation.

Should you be a people manager or a technical manager?

There’s a time and place where both are very much needed. Especially at this time, when the work is being accelerated with AI, the people work might be worth even more, because you can unblock your team to move faster that way.

The problem these days is that a lot of companies might not understand how important people work is, and are forcing a lot of managers to be more hands-on.

The problem with this approach is that it’s not what every team needs. Every team is different, and if the team is already great technically, they need more help with communicating, aligning, and unblocking, so they can move faster. In this case, you need more of a people manager.

And if the team is new and doesn’t understand the codebase well, and you potentially do, you can help the team by being more technical and help everyone get up to speed that way.

So, that takes us to the beginning of the article, where I mentioned that the goal of engineering managers is to do what’s best for the team and the overall organization.

The role of a manager is to make their team better

I definitely recommend staying technical, with no need to be the best coder, but it’s important that you understand the details. If you do, you can help your team a lot better with both wih people and tech-related issues.

And also, there’s a time and place where the team needs a certain type of a manager, so in order to help the team the most, you need to either change your manager type or hire someone else to fill the gaps.

If you decide to hire to fill the gap, that’ll take more time, but if you can fill the gap yourself, that’ll help the team a lot faster.

But this is very important to understand: the narrative that goes around these days that you need to be highly technical as a manager, is simply not true. This is a good example:

If you can enable your team of 5-8 engineers to be 20-30% more productive, that’s a LOT more valuable than just your own contribution.

If you are doing that, it’s important that you communicate your impact the right way and ensure that everyone understands how important your work is.

Individual contribution is a lot more “visible” and “tangible” by default, but the work where you multiply everyone around you is a LOT more impactful. Make sure to communicate that accordingly.

From people manager to technical manager

If you’ve been a people manager for a while, and you feel that you’ve lost a bit of technical chops, I definitely recommend getting more technical. And especially with AI-assisted engineering being the standard for building software these days, it’s a lot more accessible.

As mentioned, there’s an increase in expectation of roles such as EM, Architect, and Staff Engineer to be close together.

And that’ll only help, as when you understand the issues that your team is dealing with, you are able to much more easily help everyone to be successful.

Therefore, let me share some of the ways you can stay more technical as a manager next.

First, separate your schedule into manager and maker time

This is the prerequisite, because if you don’t do that, you won’t be able to dedicate any of your time to staying technical. You’ll end up in meetings for a whole day and being “busy”, but not really productive.

If you haven’t already, make sure to schedule focus blocks inside your calendar. I highly recommend you split your time as a manager to:

• Maker time

This is your “head-down” time. Time where you focus on strategy, learning, building, reviewing, etc. There should be no interruptions, no emails, no Slack messages at that time. You, focusing on doing → that’s what this time is all about.

This time is crucial in order to stay technical as an engineering manager.

• Manager time

This is the rest of the available time that you have. That’s where you have meetings, 1:1s with your team, your manager, and peers, and that’s when you are responding to Slack messages and emails.

It’s a lot harder to focus at this time, so you mostly do things where you don’t need a bigger time block in order to finish them.

Those are 2 very different ways of working, and if you try to have them together, you’ll end up context-switching constantly and draining your energy quickly.

This is how I separated the manager and maker time as a full-time CTO:

How to stay technical as an engineering manager?

Now that we have specific time blocks available for focus, let me share specific strategies to utilize the focus time as best as you can.

• Building proof-of-concepts

This is what I did the most as a full-time CTO. Everytime, there was a business idea, that either I had or someone else from the leadership team, I quickly started prototyping on how feasible that would be inside our system.

That helped me to ensure I have a good view of what’s possible and what’s not, how hard it would be to develop that idea, and if it even makes sense, based on the certain tradeoffs we took in our system.

That helped me a lot to stay technical while primarily being an enabler of the team. Additionally, if I didn’t do that, I’d need to assign the PoC to someone else from the team, which would take the time away from building, and then also I’d lose out on understanding the whole system.

I highly recommend you include this as part of your process, and now it’s easier than ever with AI-assisted engineering. You can really quickly build solid prototypes, get explanations of certain parts of the codebase, and get a good idea of how feasible a certain project might be, before it even comes as a priority to the team.

• Reviewing tech specs, architecture docs, PRs

And also attend the architecture/tech spec discussion meetings. It’s a great way to stay up-to-date via discussions, understand the trade-offs, and get to hear how people think about different problems.

Additionally, using LLMs to get explanations on certain topics and decisions will help you as well.

If you are a part of a smaller company, then most probably such discussions happen ad-hoc or before/after the daily meeting, which is great. But if you are a part of a mid+ size company, such meetings are organized separately, and you might need to be asked to be added.

Also, reviewing PRs is another great way to stay up-to-date. That’s also where AI can help you a lot. If you don’t understand a certain line of code, you can simply ask the LLM for an explanation.

But please, make sure you don’t generate any comments with AI. That’s a big NO from my perspective, and if I see that, the person loses a bit of credibility in my eyes. If you do a review, use AI to get the understanding and to learn, but make sure to write the comment yourself.

• Contribute to the codebase on a certain project

But importantly, DON’T take the hardest tasks, as you’re going to be a bottleneck. If you try to take on the hardest and most important tasks for a specific project, you won’t have the time to properly finish them or continue to support them, which can be quite problematic.

Instead, I recommend taking on bugs, issues, small improvements, UX-related improvements, etc. Something that’s not going to be crucial for the success of the project.

As an engineering manager, what I did was take on tasks where there was something that needed to be fixed in our legacy system, while our team was working on the new system to replace it.

• Build a side project

And last, but not least, now with AI-assisted engineering, you can build a quick MVP pretty quickly (of course, it depends on what you are building), but you can get something out a lot faster than it used to take.

So, that’s a great way to stay technical, especially if you build something that you are passionate about. Maybe you like basketball, football, or volleyball? Maybe you like video games, or maybe you have a certain hobby and would like to share your work online?

If you build something that you are passionate about, you have fun building it, and at the same time, you are also staying technical!

Last words

Let’s end this article with the following:

The question isn’t whether engineering managers should stay technical. The real question is: What does your team need from you right now?

Stay technical, that’s important, but at the same time, make sure to do what’s best for your team and the overall organization + communicate your impact the right way.

You got this.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• 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. Had a great time there, and it was a pleasure getting to know and talk to different engineers and engineering leaders.

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

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

We talked all about how infrastructure teams work.

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

Let’s start!

5 Core Pillars of Infrastructure at OpenAI

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

1. Developer Productivity

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

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

2. Compute Infrastructure

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

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

3. Networking and Storage

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

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

4. Observability

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

5. Data Infrastructure

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

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

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

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

Infrastructure teams are critical to the success at OpenAI

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

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

It’s crucial to enable both:

• teams and people internally at OpenAI, and

• the customers/users

to be able to do what they want to do.

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

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

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

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

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

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

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

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

How they prioritize work?

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

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

They think about infrastructure as a product.

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

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

And an example that Venkat mentioned:

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

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

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

Unblocking teams is a crucial part of prioritization

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

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

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

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

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

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

Read more

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

The way we build software has been changing now for quite a while, and it’s really important that we acknowledge this shift.

I remember 2 years ago, when I was a full-time CTO, we were talking with the team about whether we should be using GitHub Copilot or not, and if it even helps.

Today, that conversation is totally different, and AI-assisted engineering is the standard in how we build software these days.

In this article, I’ll be sharing the changes happening to the way engineers work, and the most important skills to focus on. The insights are based on my conversations with many engineers and engineering leaders across different companies, both in the EU and the US.

Let’s start!

The engineering process has been quite straightforward for a while

When I started my career as an engineer 13 years ago, we had quite a similar software engineering process to the one we had 2 years ago when I was a full-time CTO.

Here is the process explained in a few simple steps (you are most likely fully familiar with it):

1. Someone creates a (Jira) ticket

That would be either the Tech Lead, PM, Manager, or an engineer themselves.

2. Someone works on the ticket

Engineers pick the ticket based on priority and implement the required changes/additions based on requirements.

3. Code review

Adding at least 2 engineers to review the code, with 1 approval needed in order to unlock the merge button + passing the (unit, integration, and e2e tests).

4. Merge the change

Either the PR author or assignee merges the change and pushes the change to the main or any other relevant branch.

5. Deployment

Deployment was either on specific times, some teams had it daily, some weekly, and some teams did continuous releases based on every change.

Over time, there were certainly optimizations to the process, but fundamentally this is how the process looked likes for a while.

Such process made it easy to just focus on finishing tasks

What felt comfortable in the process is how easy and clear it was to just focus on “doing your job”, which was picking a certain ticket, doing it, and then you got the satisfaction of completing something.

A lot of the hard work has been done before picking that ticket, thinking about design patterns, architecture, creating good practices, etc., by someone else before you.

Much of the work based on these tasks was: build something based on the pattern that was already created.

Additionally, many times someone else also asked all the business-related questions to validate whether that specific thing was the right thing to build.

Not every task was like that, but a lot of the tasks definitely had such a sentiment.

Such work can be very comfortable, as you just needed to focus on the “how”, because you know exactly what needs to be done, and you just need to do it.

And you aren’t taking any risks, as normally the tech lead or a PM took the accountability for whether that work was impactful or not.

This varied based on the size of the companies and the culture

The structured process, with a low amount of ownership, was quite common (still is, to some extent) in bigger companies with a lot more older systems that didn’t have such a huge pressure on delivering.

Smaller-to-mid-size companies always had a lot more ownership and responsibility attached to specific individuals, because when there are fewer people, you are automatically expected to wear more than 1 hat.

And of course, Big Tech has always been known to have a certain pressure and competitiveness among people working there, so there’s always been a structured process, but it had a forcing factor for people to be overachievers and take more ownership and responsibility.

What changes today?

This image is a really good representation of what has changed:

As you can see from the image, there’s a lot more (mobile) apps being built and released, but the apps with significant usage have actually dropped.

This means that pure building is worth less, but WHAT to build and WHY to build it so that people will care is worth so much more.

There’s a huge need for companies and products to stand out from competitors in a certain way, and just pure features and tech is just not going to cut it anymore. That’s already expected.

With this in mind, the work of engineers is shifting a level upwards, as pure building based on requirements is worth less, but great decision-making is worth a lot more.

The work is shifting a level upwards

I like to say that a lot of the engineering work is becoming engineering leadership. The Software Engineer role is becoming more like a Tech Lead role.

Engineers are writing code less, but generating it more with AI, therefore, reviewing code a lot more, which makes decision-making a bottleneck:

• choosing the right problem,

• making good trade-offs,

• collaboration + communication,

• validating assumptions,

• deciding what not to build.

All of these are very crucial things to focus on these days as an engineer at any level.

Spec-driven development is also becoming really popular these days, so focusing on creating good tech specs and ADRs is becoming more and more important.

And more and more engineers are expected to own projects end-to-end, so good planning and stakeholder communication are more important than ever.

This is how it looks like in practice

It’s also important to keep in mind the distinction between the sizes of companies and the culture, because that matters a lot for what the expectation is of your work as a software engineer.

I’ll go through all 3 different cases:

• Bigger companies (outside of Big Tech)

The shift in such companies is a lot slower, and the work + the process might not be that much different than the one that I’ve mentioned above at this time.

A lot of such companies haven’t even adopted AI properly and are still evaluating whether the security is a big risk if they use AI. However, there certainly are companies who have made the shift.

With time, in my opinion, all of the companies will adapt and adjust the way they work as well. So, if not already, I don’t see the future where engineering work will just look like: “Taking the next well-defined task and finishing it, without taking ownership and accountability of the project”.

If you’ve been doing work based on well-defined tasks, now, you need to start defining tasks yourself, that’s going to be more and more expected.

• Small-to-mid-size companies

If you’ve been wearing 2-3 hats as an engineer in such a company, being a backend engineer, frontend, and QA, it’s more and more common to be expected to wear 3-5 different hats, including product, FDE, and/or customer support.

A good example is the company PortKey, which has 24 engineers and 0 product managers, where every engineer is expected to wear many different hats.

And at the same time owning projects end-to-end. Really good examples are both OpenAI, and Anthropic, where most of the engineers are already owning or are expected to own a certain project end-to-end if needed.

• Big Tech companies

As mentioned above, there’s always been pressure to deliver in such companies, but now the pressure has just increased a level. We see a lot of layoffs happening, and people are often expected to deliver miracles these days, especially using AI.

Being able to manage expectations well, building a narrative around your work, and ensuring that your work is visible are key things to do well if you are a Big Tech engineer these days.

My advice for all the engineers is to really focus on building up your people skills

Many people advise engineers to focus on getting as good as possible with AI, getting to know all the latest tools and what’s possible to do with them.

While that’s important, I fully believe that the biggest upside in skills you can have is to focus on developing your leadership skills, communication, empathy, and overall emotional inteligence.

The reason is that you are most probably already good at tech skills, as that’s what you’ve been doing for quite a while now. But in order to make the shift to being more like a tech lead, you need to work on your people skills.

And that’s going to make you a lot more valuable, being able to lead projects end-to-end, while managing expectations correctly and ensuring that your work is impactful.

Last words

Let’s end this article with the following:

Technical skills are very important, but good judgment, being able to communicate well, and being a great leader are becoming THE skills.

My recommendation: really embrace the shift. And the sooner you’ll embrace it, the more valuable you'll become.

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

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

Read more

Intro

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

• acknowledging the good work,

• areas for improvement and

• setting individual goals.

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

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

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

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

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

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

Let’s start!

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

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

Therefore, I always keep in mind the following:

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

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

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

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

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

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

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

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

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

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

Every company has a slightly different process regarding performance reviews

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

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

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

The cadence of performance reviews

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

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

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

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

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

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

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

Understanding different reviews

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

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

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

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

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

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

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

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

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

The tools to use

Read more

Read more

Intro

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

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

Here are also some of the pictures from the event:

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

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

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

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

Let’s start!

How are engineering leadership roles changing?

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

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

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

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

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

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

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

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

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

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

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

Engineering leadership skills are more important than ever

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

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

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

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

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

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

Managers, more desired than ever to become ICs

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

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

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

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

All very important skills to thrive as an IC.

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

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

Read more

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

How much should you spend on AI coding tools?

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

Inside the research paper:

• Understand where AI coding budgets are headed

• What high-performing teams spend

• The formula to determine how much your team should invest

Get the whitepaper

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

Intro

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

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

• How they multiply others

• What makes them successful

• How they use AI

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

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

Introducing Jordan Cutler

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

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

Over to you, Jordan!

What stops Senior Engineers from becoming Staff Engineers

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

• deeper technical skills,

• faster execution,

• more complex systems.

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

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

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

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

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

1. Expanding your surface area

2. Influencing across teams

3. Building scalable systems

Here’s how each one played out for me.

1. Expanding your surface area

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

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

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

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

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

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

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

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

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

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

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

2. Influencing across teams

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Building scalable systems

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

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

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

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

I built a framework that connected 3 things:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What it added up to

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

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

That’s the work that compounds.

Last words

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

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

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

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

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