This newsletter is sponsored by CodeRabbit.

Fewer findings. Only real risks.

AI-generated code can introduce vulnerabilities that are easy to miss in a pull request.

CodeRabbit Security continuously reviews your codebase for complex bugs and security risks, using full-codebase context to follow data flows, dependencies, and patterns beyond the latest diff.

Run CodeRabbit Security on your own repositories today.

Try CodeRabbit

Thanks to CodeRabbit for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

AI is changing engineering faster than any tool before it ever has. In just a few years, we’ve gone from writing every line of code ourselves to seeing AI-assisted engineering as a standard way to build software.

That shift has created a lot of uncertainty. Many people are asking themselves what skills will still be valuable, how the roles will evolve, and if relying on AI will help them grow or make them too dependent on it.

But AI isn’t just a tool for writing code faster. It can also be one of the most powerful tools for learning. The key is knowing how to use it effectively.

In this article, you’ll learn how high-performing engineers and engineering leaders use AI to learn faster. More importantly, you’ll learn the mindset behind these workflows.

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published soon, and is available for pre-order!

Learn more about the book

There are 3 Types of Engineering Professionals Using AI

When it comes to using AI, most engineers and engineering leaders fall into 3 camps:

• Refusers

These are the engineers who refuse to use AI altogether because they don’t trust it. They tend to be more experienced people who have seen a lot of shifts in the industry.

They are reluctant to change, preferring to stick to what they know and are good at. Their mindset is “It has worked well for me for 15 years, so why would I change it?” But this attitude can stop people from learning new things and improving their craft.

• Overreliers

These are the people who rely on AI tools so heavily that they stop thinking critically and become less effective. They are often less-experienced engineers who have a good grasp of the AI tooling landscape. But their overreliance on AI tools often results in mediocre work.

Worse, some don’t even check whether the AI output they’re using is aligned with the team’s standards! This forces reviewers to do the work of finding all the problems, which can take a lot more time than if the engineers had done the task properly right from the start.

• Multipliers

These are the engineers and engineering leaders who see AI as a way to multiply their efforts, not to replace their expertise. They use it to eliminate repetitive work, learn faster, explore more ideas, and spend more of their time on the problems where human judgment matters most. They are also the ones who have the greatest impact.

You want to be in the multiplier camp: approaching the “fancy new tool” with curiosity, not unearned trust. You need to be keen to try out new things and learn but hold tight to good engineering fundamentals and practices. You should delegate your busywork, not your judgment calls.

You should use AI to help you think at a higher level, because that’s what becoming an engineering multiplier is all about. The following sections look at how to multiply your impact on important tasks using AI.

How Multipliers Use AI to Learn Faster

To learn new things significantly faster, you need a good understanding of engineering practices and the resourcefulness to leverage different resources to get what you need.

Great engineers don’t spend hours trying to understand a codebase by going through it file by file or reading every word of the documentation. They use AI to help them quickly understand the unfamiliar parts of the codebase and get an overview of its architecture, APIs, and any other relevant things. Here are some examples.

Onboarding to New Codebases

Using AI can help you understand a codebase in hours. , a senior software engineer working in the healthcare industry, wrote a guest article on the Engineering Leadership newsletter about how he uses AI when he needs to work with a new codebase.

He laid out a four-step process, which I summarize in this section.

Step 1: Use /init to get the big picture

If the codebase already has a CLAUDE.md and/or an AGENTS.md file, read through them. If not, run Claude Code’s /init command. It will skim through the codebase and document its understanding of the most important features in CLAUDE.md.

Use a higher-tier model when you run /init, even though it will cost you more tokens. Tokens spent on reasoning up front are tokens well spent.

Using Plan Mode with a cheaper model like Sonnet, makes the plan more likely to overlook critical architecture or contain consequential mistakes. More reasoning-heavy models, by contrast, often come up with things you wouldn’t have thought of on your own.

Step 2: Map the architecture

It’s wise to produce a map of the repository early on to help you understand the system’s major components, responsibility boundaries, and dependencies.

Here’s a prompt you can use to do this:

You are onboarding me to this repository.

Tasks:
- Identify the top-level architecture (apps/services/libraries) and what each does.
- Produce a directory map: top 10 directories with responsibilities.
- Identify key runtime boundaries: API layer, domain layer, persistence, async jobs, config.
- Show a dependency diagram (Mermaid) using the repo’s actual module/package boundaries.
- Cite exact files for each claim (paths + brief evidence).

Constraints:
- Do not edit files.
- Prefer reading docs first (README, AGENTS.md, CLAUDE.md, docs/, CONTRIBUTING, ADRs) and then code.
- If the repo is a monorepo, explain the workspace/tooling setup.

Diagram:
Create a Mermaid diagram with your findings.

Step 3: Identify the testing strategy

If you want to understand the test pyramid in your app and build confidence quickly, you should identify your app’s testing patterns right away. Here’s a prompt you can use for that:

Identify the testing strategy in this repo.

Output:
- Where tests live and how they're organized (unit/integration/e2e).
- The fastest local confidence loop: which commands to run before a PR.
- How fixtures/mocks/test containers are handled.
- Common failure modes in this repo's tests (if visible from config/docs).

If there is no testing strategy, propose a plan for one that follows the
testing pyramid (lots of unit tests, less e2e tests).

Step 4: Run the app

If you don’t already have the app up and running by now, you’ll want instructions. Ask for setup steps with this prompt:

Produce a repo-specific local setup checklist with commands.

Rules:
- Only include steps you can justify from files in the repo (README, Makefile, package/build files, scripts, devcontainer config).
- Include: required runtimes, dependency install, env vars, database setup,
migrations/seeds, and “run server / run worker / run UI”.
- End with a smoke test of one key flow.

This should give you a single “happy path” setup that ends with a running service and a verification step.

Learning a New Framework or Programming Language

More and more of the engineers I speak with are becoming tech-agnostic these days. The separation between frontend and backend continues to blur.

The same holds true for different programming languages. If you are good at working with a certain technology, you likely have a good understanding of its engineering fundamentals and specific patterns.

You can much more easily learn new tech using AI because the concepts are quite similar, while the syntax is different. If you are an expert in Python, you can apply your knowledge in combination with AI to be productive in Java and PHP, and the same goes for a lot of other programming languages and frameworks.

Once you have a good understanding of one specific tech, you can utilize AI to become good at others if you need to.

For example, imagine you’re an experienced Python engineer who needs to work on a Java project. You start by giving AI the context about yourself. You can use a prompt like this:

I'm an experienced Python engineer and need to become productive in Java.
Explain the most important differences, using Python concepts I already
understand. Focus on the things most likely to surprise me or cause
mistakes.

As your next step, you can be more specific about the actual work that you do. If you’re joining a new project that uses Spring Boot, you might use this prompt:

I know how to build REST APIs with FastAPI. Show me how the same concepts
work in Spring Boot, including routing, dependency injection, validation,
database access, and error handling.

From there on out, use AI while working to get explanations of unfamiliar code and review your code for potential mistakes.

Building Hands-On Projects

For the past decade or so, watching a tutorial video has been the standard way to learn a new technology. Instead, try using AI to help you understand certain parts when you are building.

Make sure to ask why certain things are the way they are. You can start much like you would if you were learning a new framework, except this time your goal is to learn by building. Let’s say you are an experienced React engineer and you want to get up to speed with Angular. You can start with this prompt:

I'm an experienced React developer learning Angular. I want to build a
simple TODO app with CRUD functionality. Create a plan that will help me
learn Angular while building it. Don't write the code yet.

This is where the plan mode of your favorite AI coding tool can come in handy. Review proposed plan and architecture, then start asking questions like this:

Why would you structure the application this way? How is this different
from how I would typically structure a React application?

Then, I strongly suggest that you build the project one part at a time. Don’t just try to “one-shot” it and hope for the best. Use AI as a learning partner.

If you see a pattern you don’t recognize, that’s when you should ask why that pattern is there, what the possible alternatives might be, and, of course, how that pattern relates to the concepts you already understand.

Additionally, you can use AI to review your code. A prompt for this might look like the following:

Review this code as an experienced Angular engineer. What am I doing that
works but isn't a good practice in Angular? Explain why and show me how
an experienced Angular developer would approach it.

The goal is for you to understand and learn, so don’t try to optimize for having AI write as much code as possible. Focus on the decisions about WHY certain code should exist and HOW it affects the whole system.

How to Use AI as a Thinking Partner

Conway’s law tells us that the structure of a software system mirrors the communication structure of the organization that builds it.

Perhaps that’s why people in the software industry have to solve so many difficult problems that involve both tech and human beings.

You can use AI as a thinking partner by prompting it to challenge your assumptions, provide alternatives, and identify what you’ve missed. Here are some ways to do that:

• Share a tech spec or architecture decision record with a large language model (LLM). Ask it to stress-test the idea.

• Prepare for a difficult conversation with stakeholders or your manager by drafting a script of what you want to say and then asking the LLM to give you feedback and help you refine it. After you refine the script, rehearse it out loud until it comes naturally!

• Share a specific problem, explaining it as clearly as possible, and ask the LLM to share ideas for solutions. Striving to explain the problem to an LLM clearly not only yields better solutions but also refines your understanding.

• Ask AI to review your writing. Apply its proposed changes manually so that you can think them through and adjust them to fit your own voice and style.

Last words

Let’s end this article with the following:

The goal of engineering has never been to do everything yourself. Engineers have always used tools to free up their time for higher-leverage work, and LLMs are just more powerful tools whose outcomes are much less predictable.

So, use them to your advantage, especially to learn something new faster! 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.

This newsletter is sponsored by DX.

Download the CAFE(S) framework for evaluating AI agent context quality

AI agents are only as effective as the context they operate on. The new CAFE(S) framework gives engineering teams a practical method for diagnosing and improving the five core dimensions of context quality before issues reach production.

What you’ll learn:

• A shared vocabulary for evaluating AI agent context across your systems

• Actionable patterns to identify and fix context failures early

• How to scale AI workflows safely without compromising performance

Download the framework from DX

Thanks to DX for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Building a technically perfect solution doesn’t mean you’re building the right solution.

I’ve seen many engineers (including myself) spending weeks (and even months!) building something technically amazing, only to realize that a much simpler solution would have delivered the same or even better results.

The best engineers don’t just know HOW to build great solutions. They know and understand whether it’s worth building in the first place.

This is becoming even more important in the AI era. As writing code gets easier and faster, the ability to make good decisions, understand trade-offs, and focus on what actually matters becomes much more valuable.

And that’s where having a pragmatic mindset makes all the difference.

In this article, I’ll share a mistake I made earlier in my career and practical ways you can develop a pragmatic mindset as an engineer.

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

- What Does it Mean to Have a Pragmatic Mindset?
- My mistake of building a theoretically correct solution rathet than a pragmatic one
- First, Build the Right Things; Second, Build Things Right
🔒 Prioritize Simple Solutions Over Complex Ones
🔒 Think in Terms of Trade-Offs
🔒 Use Boring Tech to Build Great Products
🔒 Get Used to Building Proofs of Concepts (PoCs)
🔒 Become a Salesperson, Too
🔒 Focus on the Product and the Business
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published soon, and you can already pre-order it!

Learn more about the book

What Does it Mean to Have a Pragmatic Mindset?

Pragmatism is one of the most important concepts in software engineering.

Being pragmatic as an engineer means focusing on what actually works in each specific case, not just what is theoretically correct.

There are endless variables and trade-offs we need to consider when building software, and many of them are people focused.

And while AI can predict the next best token, it doesn’t have the real-world experience or the perceptiveness to pick up on many different signals and make the decision that best fits a certain moment.

A pragmatic engineer finds the best solution that’s possible within the constraints of the real world, not the ideal world.

There are many potential solutions to every engineering problem. Some are theoretically correct but don’t work in reality because of the set of specific constraints involved.

Engineering is not performed in a vacuum. The constraints on real production software include the following:

• Budgets

• Product requirements (which may change)

• Team members’ knowledge and expertise

• Team members’ and stakeholders’ personalities, relationships, and motivations

• Legacy code

• Existing hardware and infrastructure

• Regulatory frameworks

• Project schedules

And so on. Being pragmatic means we build useful, reliable, and achievable solutions within the existing constraints.

My mistake of building a theoretically correct solution rathet than a pragmatic one

Back when I was a senior software engineer, I made the mistake of building a theoretically correct solution rather than a pragmatic one.

We were building a new feature for an application that used Angular on the frontend and ASP.NET Core on the backend. We were adding functionality to let users upload, view, edit, and set metadata for images.

I was excited to work on this. We spent a lot of time and effort on it, and I was personally very proud of it. But our users were already accustomed to cropping images themselves before uploading them, so they never really used the cropping and resizing functionalities we built.

It was a technically correct solution that worked amazingly well, but pragmatically, it was a bad call.

To come to the best and most pragmatic decision, ask yourself, “What’s the simplest solution we could deliver?” Then deliver exactly that. You can optimize it further if you need to, but only after delivering it.

The legendary computer scientist Donald Knuth famously wrote that “Premature optimization is the root of all evil.” Too often, engineers try to optimize prematurely and get excited about building a “complex solution” that isn’t even needed, so they waste both time and effort.

In the next sections, we’ll look at how you can develop a pragmatic mindset as an engineer.

First, Build the Right Things; Second, Build Things Right

You can build the best solution that’s technically possible, but if the users don’t need it, they won’t perceive it that way.

Ruthlessly prioritize what you should focus on; only after that should you look to optimize it.

This is more important than ever at this time in the AI era. As you can see from the image below, 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.

Prioritize Simple Solutions Over Complex Ones

Read more

This newsletter is sponsored by CodeRabbit.

Review the PR that matters most. CodeRabbit Triage ranks work across repositories, tells you what to review next and what needs your action. It also flags low-risk PRs that may be ready to close, so your queue shrinks effectively.

Try CodeRabbit

Thanks to CodeRabbit for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

2 days ago was 4 years since I first started writing this newsletter! On October 3, 2022, I published my first article, which was an announcement that I was starting a newsletter.

And as every year, it’s now a practice to create an “anniversary” newsletter. So, this year, it’s no different :)

If you want to read the 2-year and 3-year anniversary editions, you can do so here:

• It’s been amazing 2 years of writing the Engineering Leadership newsletter 🥳 🎉

• Amazing 3 Years of Writing the Engineering Leadership Newsletter 🥳 🎉

For today’s article, I’ll be sharing a bit about my beginnings, the most important lessons I learned from 4 years of writing, and what I would tell myself 4 years ago.

Let’s start!

If you haven’t built your own blog, are you really an engineer?

Joke aside, I remember when I first started writing 4 years ago and published my first article, or, more accurately, blog post. Back then, it really was a blog that I built myself with no AI tools, of course :)

It looked like this:

It was built with React + Gatsby, and I had it hosted on Netlify.

At the same time, I also created this newsletter, as you know it today, but it was more just for sending emails, and the blog was used as a primary source.

Back then, there were, of course, no AI tools, as we know them today, so maintaining and building your own blog took away some of the precious free time that I could spend writing. I also worked full-time as Head of Engineering at that time.

So, after about 6 months to a year, I decided to stop supporting the blog that I coded myself, and focused on continuously improving my writing as much as I can.

What started as me sharing my experience and what I have learned throughout my career has now become one of the biggest and most-read platforms for engineers and managers.

With over 10M views in the past year, this newsletter is the #1 recommended newsletter for engineering leaders based on various sources and, of course, different AI tools.

I am honored and thankful to everyone who is reading! And I can’t thank you enough for the continuous support over the course of 4 years of writing.

To show just a bit of my gratitude, I’ve mentioned the great Engineering Leadership newsletter community in the acknowledgments section of my upcoming book, which is coming out soon!

I shared the following:

Special thanks to the Engineering Leadership newsletter community. What started as me sharing what I had learned throughout my career grew into a community of 200k+ engineers and leaders from around the world.

Your replies, questions, disagreements, stories, and feedback have helped me tremendously to think more deeply about engineering leadership. Many ideas in this book became a lot clearer because I had the opportunity to explore and discuss them with you.

Let me share, next, my most important lessons I learned through 4 years of writing this newsletter.

My most important lessons from 4 years of writing

• Consistency beats almost everything

I’ve created over 250 articles in the span of 4 years, and never missed a week. For the first 2.5 years, I was doing 1 article per week, and for the last 1.5 years, 2 articles.

Even though not every week I was happy with the article (still not), it went out, I’ve kept publishing, and if you’d asked me 4 years ago that this newsletter would become the go-to resource for engineering leaders, I wouldn’t believe it.

And of course, other things have always come up, like life, or especially for the last year, writing the book and managing all the other things, you find yourself having less time, but it’s really important to have some non-negotiable things you want to do no matter what else happens. It keeps you focused on your goal.

As I mentioned in one of the past articles, I like to have daily and weekly goals. Daily goals are specific to the day and may be like: publish a post on LinkedIn, exercise, or attend a certain event.

And for weekly goals, it may be publishing 2 articles, publishing X amount of LI posts, etc. This keeps you focused on what are the important things you need to do, without feeling the pressure from having a lot of things on your mind. That has worked really well for me over the last 4 years.

• Writing is thinking and learning

Now, this is especially important to understand today, with so much AI-generated text everywhere. I look at writing as thinking and learning. When I write about something, I need to understand it first, only after I can write well around that topic.

So, if you just generate text with AI, you are missing out on the important learning.

Even with all the interviews I do, for example with Tibo, Head of ChatGPT & Codex, OpenAI, or with Katelyn Lesse, Head of Platform Engineering, Anthropic, I focus on understanding what they have said, and then write about that specific part in the style that I normally write.

That enables me to learn and really understand things, and whenever I need them, I can quickly remember where something was mentioned and can re-read it.

It’s also the reason that whenever I talk about a certain topic, either give a talk at a conference or have a conversation with someone, I can quickly connect my learnings to something that I am talking about.

And especially when I give a talk and I get “in the zone”, I can talk about engineering leadership topics forever, without needing to prepare a lot beforehand.

So, if you try to “shortcut” your way to the end result, unfortunately, you are cheating yourself with that, and you are losing out on important learnings, which has actually been your goal in the first place with writing. To learn, understand, and share your knowledge with others.

• The newsletter became bigger than the newsletter

As mentioned, 4 years ago, I wouldn’t have believed all the opportunities that would come if I started sharing my thoughts online. I had the pleasure of giving a talk or hosting a workshop at 12+ conferences over the course of a bit more than 2 years. I was also a part of 30+ podcasts, webinars, or similar.

Earlier this year, I also hosted my first event called Engineering Leadership LIVE in San Francisco. There were close to 200 people attending, and it was a blast. Looking forward to doing more such events in the future!

And then, writing the book The Multiplier Mindset, which I started in December, 2025, has been a big goal of mine that I wanted to do for quite a while. I was thinking of doing self-publishing at first, but after speaking with O’Reilly, I knew I made the right choice going with them.

The book is much better, the core message is so much clearer, and I couldn’t be happier with the outcome. I’ll write about the whole process of writing the book in one of the future articles, so stay tuned for that!

And not to mention all the other opportunities like consulting, coaching, and full-time role opportunities. They all came because I started sharing my thoughts publicly.

• The biggest lesson is the impact of creating something useful for a long enough time

My main goal is and always will be to make everyone to be a better engineering leader. With every article I write, every template I create, or every talk I give, that’s always the focus.

And I believe that has been one of the key things for the success of this newsletter in the past 4 years. A lot of people are telling me that they really like the actionable advice that they can use immediately, and that has been my goal.

And the same goal is with the book The Multiplier Mindset. I focused on making every page to be as actionable and useful as possible, something that can help you be successful.

And I fully believe that if you read the book or my articles and apply them in your own case, your success is inevitable.

When I asked people for feedback and reviews of the book, I was surprised they mentioned the newsletter as well. Here are 2 pieces of feedback that connect to the newsletter:

“I've read Gregor's newsletter for nearly two years, and his advice is always practical and battle-tested. As AI writes more of the code, this book is his playbook for what matters more than ever: multiplying the people around you.”

“I've been reading Gregor's teachings since his newsletter first started out. They are valuable because they're rooted in practice and always hands-on. This book distills the best of them into one playbook for engineers growing into leadership.”

So, what I want to mention here is the importance of creating something useful (or being useful) and sticking to it for a long enough time.

This can be anything, it doesn’t need to be a newsletter, it can be anything else.

The same exact mentality you can use for growing in your career as an engineer and engineering leader. Being useful, and doing great work + making sure that your work is visible for a long enough time and stick to it. That’s how you grow and progress.

What I would tell myself 4 years ago

The biggest regret I have regarding the newsletter is not starting it sooner. So, if I could go back in time even 2 or 3 years before I started, this would be my go-to advice: Start writing asap.

And this would be my exact words:

Start before you feel ready. Don’t worry too much about the platform, subscriber count, or whether every article is perfect.

Focus on creating something genuinely useful, keep improving, and give it enough time to compound.

Additionally, I’d mention a really important thought that I know is holding back many people from trying something new:

Stop worrying about what others would think. Everyone has their own problems to worry about, so they are not too concerned with what you are doing.

I spent too much time thinking about “what would everyone think if I post this article or this LinkedIn post”, my colleagues, friends, family, etc.

But then only good things have happened when I openly started sharing things.

I’ve broken this down fully in this LinkedIn post:

And you can read more about the Spotlight effect in this article:

Last words

Thanks again for your continuous support. I’ve got a lot of great things coming up for the newsletter, including an upcoming book launch! I am really excited for that, and I’ll let you know once the book is published!

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

Feedback or addition? Make sure to 💬 comment.

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

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

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

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

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

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

Get in touch

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

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

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

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

Check the benefits of the paid plan

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

This newsletter is sponsored by Archera.

De-risk your multi-cloud spend with Archera

Archera is an automated cloud cost management solution designed to maximize savings across AWS, Azure, and GCP, without forcing you to predict your architecture three years out. If your stack shifts and usage drops, they’ll cover whatever goes unused.

• Refactor without fear: Secure aggressive RI, SP, and CUD discount rates with native risk protection. You aren’t trapped paying for abandoned instance types or old nodes.

• Skip the “percent savings” Tax: Most vendors take a 25% cut of your savings. Archera uses a $0 platform fee model with transparent, flat coverage premiums.

• Live in your native cloud: Executes commitments directly inside your existing AWS, Azure, or GCP organization so you keep total ownership of your billing and setup.

Get started now with $0 platform fees:

Get started now

Thanks to Archera for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

The more you grow in your career as an engineer, the more important skills, outside of pure tech become.

Engineers who create the biggest impact are not only technically capable of building great things, but are also trusted to make things happen, make good decisions, and also be a multiplier, to make others around them better.

A big part of that comes down to being proactive.

Proactive engineers don’t wait for others to tell them what to do. They look at the big picture, see problems before they happen, take the initiative, communicate early and often, and look for ways to improve things.

This becomes increasingly important as you grow in seniority. The problems become less defined, the path forward becomes less obvious, and there are fewer people telling you exactly what the right next step is.

That’s why developing a proactive mindset can be one of the biggest shifts you make in your career.

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

- What Does it Mean to Have a Proactive Mindset?
- Understand the Big Picture
- Get Better at Anticipating Problems
- Take Initiative to Make Improvements
- Be Curious
🔒 Communicate Well
🔒 Support Others
🔒 Simplify as Much as Possible
🔒 Avoid Perfectionism
🔒 Last words

In this article, we’ll look at practical ways to become more proactive, and develop the right mindset, let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published soon, in mid-to-late October this year.

Learn more about the book

What Does it Mean to Have a Proactive Mindset?

Being proactive means taking initiative, anticipating challenges, and driving solutions without receiving instructions or waiting for problems to arise.

A lot of engineering and business challenges are ambiguous, so you need to find out exactly what is needed and why specific problems exist.

Proactivity is a forward-thinking mindset, where you aren’t just reacting to tasks or issues as they come up but actively seeking ways to improve processes, the team, and overall outcomes.

I fully believe that proactive engineers are the best kind of engineers. They don’t need excessive instructions; they don’t need every piece of the outcome defined for them completely.

I can rely on them to ask questions, find out exactly what needs to be done, and do it the right way and on time. Such a mindset is valuable in any organization.

The more you grow in any career path, the more ambiguous the problems become. Proactive engineers thrive on such challenges, while people who are used to performing well-defined tasks have a harder time.

As a manager, I’m looking to promote people who make my role easier, reliable people who can solve problems well and inspire others to do the same. Proactivity is a key part of that.

In the next sections, we’ll look at how to develop a proactive mindset.

Understand the Big Picture

You need to know how your work fits into the big picture.

• What kind of organizational goals is your work a part of?

• What are the main business problems you are solving?

For example, are you building a feature to improve the user experience? What potential risks and challenges are involved with the work you’re currently doing?

Ask as many questions as you can about the product, the business, and the overall organization. Start thinking like a product manager.

Notion template: List of questions to ask before making a technical decision

Use this list of 35+ product-oriented and technical questions when making your next decision. This will help you to make an informed decision and build the RIGHT things.

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

Once you’ve asked your questions, your immediate next step should be to look to reduce the scope while delivering a similar value to users.

With a simpler solution, you can deliver value faster and test it earlier to see if it’s really what the users need.

The goal is to remove any overhead that might not bring value (or as much value). These are the “must haves,” not the “nice to haves”.

Get Better at Anticipating Problems

You want to get better at anticipating problems before they even happen, and you do that by thinking a few steps ahead. Some questions you can ask yourself to get you started in any given situation are follows:

• How will this feature scale as the user base grows?

• Could this implementation introduce security vulnerabilities?

• What edge cases or unexpected inputs might cause this system to fail?

This will help you to think about alternatives and cases that may not be covered in the current implementation.

Don’t just jump on the next problem you think would be interesting to solve. Not every problem is worth solving.

Use the “You ain’t gonna need it” (YAGNI) principle: first, decide if the problem is worth solving, and then, if it is, propose your solution.

Take Initiative to Make Improvements

You don’t (usually) need permission to make things better. If you see a process improvement that could be made, a need for some documentation, or an issue in the codebase, take the initiative to improve it. Here are some examples:

Refactor code that could be better

Use meaningful variable and function names. Make a piece of code simpler and easier to understand. Find something that’s inconsistent with the rest of the codebase and bring it into alignment.

Automate a repetitive task

There might be a way to automate the start of your local environment or the creation of initial test data. The opportunities are endless here.

Keep documentation updated

If something changes inside the codebase, take the initiative to adjust the documentation.

Be Curious

With technology evolving faster than ever, it’s really important to be curious and proactively learn new things.

Don’t wait for your manager to suggest what you should learn; seek out knowledge that will help you and your team. Here are some ways to do this:

Actively read, watch, listen to, and follow the right people

Subscribe to newsletters and blogs, read books, and follow people on LinkedIn. Here is a list of 200+ resources that I curate and regularly update.

Try new tools

Especially with AI, it’s important to try new tools and see how they can help you. People who can use AI well are thriving right now.

Get better at writing prompts and comparing different AI models by getting in as much practice with them as you can.

Ask questions and build a network of experts around you

Always look to dig one level deeper. When you’re working with someone, ask questions and try to understand why the particular approach they use is the best one.

Communicate Well

Read more

This newsletter is sponsored by CodeRabbit.

Fewer findings. Only real risks.

AI-generated code can introduce vulnerabilities that are easy to miss in a pull request.

CodeRabbit Security continuously reviews your codebase for complex bugs and security risks, using full-codebase context to follow data flows, dependencies, and patterns beyond the latest diff.

Run CodeRabbit Security on your own repositories today.

Try CodeRabbit

Thanks to CodeRabbit for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Most engineers put a LOT of effort into preparing for tech interviews, they practice solving many of the leetcode-type problems (yes, still in 2026), prepare for system design interviews, and other similar types.

I focused a lot on that part as well when I was interviewing for Senior+ engineer roles in the past.

But what many people forget (me included in the past!) is that the tech interview is there to check the box of whether the person has the right knowledge and necessary technical skills.

But companies still need to answer these questions:

• Will you be effective in this role?

• Will you work well in this environment?

• And at what level should we hire you?

All of these are determined in the behavioral interview. And it’s crucial that you do well on it.

To help us know exactly what companies look for to assess the fit and level of a potential hire, luckily, Steve Huynh will share with us today his insights from conducting nearly 1,000 interviews at Amazon.

Let’s introduce our guest author and get started.

Introducing Steve Huynh

Steve spent almost 20 years at Amazon as an engineer, growing all the way to becoming a Principal Engineer. During that time, he was an Amazon Bar Raiser, conducting a lot of interviews with potential hires while also training other interviewers.

Today, Steve is kindly sharing an excerpt of the chapter adapted for this newsletter, from his book Technical Behavioral Interview: An Insider’s Guide.

I also got a copy of the book and can attest to both the quality and depth of information. If you are looking to improve your behavioral interviews, this should be your go-to book.

Let’s start!

Technical skills alone don’t determine your offer

The primary consideration for any tech role is whether you have the technical skills to do the job.

Companies will assess this mostly through tech interviews, like, coding challenges, system design, or whatever technical evaluation matches the specific role. If the candidate can’t demonstrate the core technical capability, nothing else matters.

But technical skills alone are not enough.

Companies learned this the hard way by hiring smart people who couldn’t work effectively in their environment. That’s why behavioral interviews focus on 2 additional types of fit:

• Role fit

Can you handle the specific challenges and working conditions of this position? A backend role at a fast-growing startup requires different capabilities than a backend role at an established enterprise. The technical skills might be similar, but the role demands will be different.

• Company fit

Will you do well in the environment in which this organization operates? They want to see if your working style, decision making style and values align with how the company operates.

And companies use behavioral interviews to answer 2 critical questions:

1. Do you fit with both the role and the company?

2. And if you do fit, at what level will you be most effective?

Here is how it works:

• You get both of them right, you get an offer at the right level.

• If you get the fit wrong, you will be rejected no matter how skilled you are.

• Get the level wrong and you will be down-leveled or rejected for being underqualified.

Signals to detect fit

Companies can’t just directly ask: “Would you fit here”? Because, I don’t believe any candidate would answer the question with “No”.

Instead, what companies do, is look for signals in your stories that show either you are a fit or not.

Let’s go through both specific role and company fit signals, next.

Specific role fit signals:

• If the role requires you to work with ambiguous requirements, do your stories demonstrate that your comfortable working when uncertainty is high?

• If the position involves cross-team coordination, do your stories demonstrate an ability to do well working with mutliple teams?

• If the job needs fast iteration, do your examples show shipping quickly and adjusting based on feedback?

Specific company fit signals:

• A company that values “bias for action” looks for stories that show you moving quickly despite incomplete information.

• An organization that values “customer obsession” wants to hear you share examples of you going deep to understand user needs.

• A place that has a culture of “radical transparency” is looking for stories that show you sharing information openly, even when you’re uncomfortable.

The same story can send different signals to different companies.

This is very important to keep in mind:

You spending 3 weeks perfecting a solution might demonstrate attention to quality at one company but analysis paralysis at another.

Moving fast and fixing issues later demonstrates good judgment at a growth startup but recklessness at an established healthcare company.

A lot of it comes down to what the company culture is, so always look at it backwards from the company perspective, and put your focus on demonstrating the qualities that a specific company values.

Let’s go through some specific examples of what you need to watch out, based on what kind of a company and the role you are interviewing for.

Common “mis-fits”

Even a talented candidate will get rejected if they are not a good fit. It’s important to understand that the same behaviors that are positive at one company can be a poor fit at another. Let’s go through some examples.

Example 1: Being independent versus work collaboratively

This covers both how you work and how you make decisions. Some companies need people to take a problem, own it, and return with a solution. Some expect you to bring the team along with you at every step.

Companies asking you to do work on your own also want you to make calls on your own, and companies asking for collaborative work want buy-in from the group on decisions.

If all your stories are about going off and building something by yourself, consensus-driven companies will worry that you’ll steamroll people or make decisions without informing anyone.

And if every story needs group agreement before you act, companies that value individual ownership will ask if you can make a decision without a meeting.

Example 2: Shipping fast versus being thorough

Startups need to experiment fast, ship MVPs and iterate based on feedback, while companies in healthcare or finance need to validate carefully before any release.

This tension also shows up in how teams think about code quality. Some organizations will happily spend extra weeks to perfect the architecture, while others want a working solution as soon as possible, even if the code needs cleanup later.

A startup might be bored by methodical testing stories and a medical device company might be scared off by your “ship it and fix it” stories.

Example 3: Being a technical expert versus focusing on pragmatism

There are organizations that value technical expertise and clean architecture above all else. Others need practical solutions on time, even if imperfect.

If you try to focus on perfect code, you will fail in a deadline-driven company. If you accept technical debt everyplace, you will fail in a company that maintains critical infrastructure.

Example 4: Innovation versus stability

Some roles are about innovating and challenging the status quo, others are about maintaining and optimizing existing systems.

If you say you are constantly reinventing established processes, teams that value stability won’t think you’re a good fit.

Alternatively, stories that demonstrate you follow only established patterns will fall flat with teams seeking creative problem solving.

Example 5: Being direct versus diplomatic

Some cultures value radical candor and want you to say exactly what you think. Others value harmony and communication in an effort to not burn any bridges.

If you are too blunt, you will not fit in well at a relationship-focused company. If you are not direct enough, you will not like working at a company that values “disagree and commit.”

Example 6: Do you make data-driven decisions or focus on intuition?

Some companies need data to justify each decision (“data-driven” cultures) whereas others trust their judgment and go more on gut feel.

Showing that you make decisions based on instinct does not impress analytical companies, and telling a company that values experienced judgment that you conduct 3 A/B tests to choose a button color will get you struck off their list.

Example 7: Are you a specialist or generalist?

Big companies often look for deep experts who master 1 domain, while smaller companies need people who like to wear multiple hats. This is crucial to understand when you are showcasing your experince through stories.

Important: Understanding the fit is crucial. That’s how you can pick stories that match the company and the role.

Now that we understand how the “fit” works, let’s go through 4 dimensions that determine your level.

The 4 dimensions that determine your level

Companies measure your level across 4 dimensions that are present across every story you tell. Each dimension represents a different part of your ability. Together, they show the company where you operate most effectively.

We’ll go through each, next, and also define what’s expected for a specific level.

Scope

Scope provides a measure of the number of people on your team and, extending outward as you advance, whose work was affected by your actions. The greater the number affected, the higher your level for this dimension.

Entry Level:

• Your work affects your own productivity and starts to help other team members. For example, you might improve how you handle assigned tasks or fix issues that were slowing down a few teammates.

Mid Level:

• Your work affects aspects of the team and shapes how it operates.

• You might redesign a process that changes a significant part of how your team works or solve problems that affect most of the team’s effectiveness.

Senior Level:

• Your work directly impacts your entire team and is beginning to influence at least one other team.

• You create solutions that change how your whole team operates and affect workflows in adjacent teams, or you solve problems that require coordination with other groups.

• You may also start collaborating more closely with product or design partners on your immediate team’s work.

Staff Level:

• Your work directly impacts at least two teams and is beginning to have an influence on the broader division or organization. Examples of this include developing technical strategies that change how multiple teams make decisions and solving problems that require buy-in across several parts of engineering.

• Your influence extends beyond engineering into product, design, and program management as you shape solutions that affect how cross-functional partners work.

Principal Level:

• Your work affects many teams or changes how large parts of the organization operate.

• You have created technical strategies that have influenced how dozens of teams make decisions.

• You have solved problems that cut across a large engineering organization.

• At this level, your influence regularly extends into business strategy, shaping decisions alongside product, design, program, and business leadership.

Contribution

Contribution captures what you did, not what happened around you. It is important to be precise about the line between “I” and “we.” Companies will expect to see evidence of increasing leadership and ownership as you advance in your career.

Entry Level:

• You execute assigned work and are beginning to take ownership of small pieces. Examples: implementing solutions designed by others; fixing bugs in existing systems; taking full responsibility for well-defined features within larger projects.

Mid Level:

• You own complete solutions from problem to implementation while also guiding others.

• You have identified issues, designed the approaches, implemented them, and you have verified that they work, and you have helped your teammates understand the reasons for your decisions.

Senior Level:

• You lead initiatives requiring coordination.

• You’re expected to make progress even when the requirements are unclear or the path forward is uncertain. Examples of this include driving technical decisions for your team; mentoring others through complex problems; architecting solutions to be implemented by others; and ensuring quality work outcomes for many people.

Staff Level:

• You lead cross-team initiatives and establish technical direction, often in situations where the right approach isn’t obvious and stakeholders have competing priorities.

• You are defining technical approaches that are adopted by multiple teams, creating systems that enable other teams to solve problems on their own, or driving agreement on complex technical decisions across several teams.

Principal Level:

• You create organizational capabilities and establish new ways of working.

• You’re frequently operating in highly ambiguous environments where you must define the problem before you can solve it.

• You define technical standards that guide dozens of teams, build systems that enable others to solve entire classes of problems, or transform how the organization approaches its hardest challenges.

Impact

Impact shows what changed for the better as a result of your work. Companies want to see that your work produced results worth the investment. Strong stories put numbers on the impact and connect technical wins to business or user outcomes.

Entry Level:

• You improve your personal productivity and are starting to help the team work better. Examples include reducing the time you spend on repetitive tasks, fixing issues that were slowing down teammates, or improving the quality of code in the areas you touch.

• Even simple measures matter at this level: time saved or bugs prevented.

Mid Level:

• You improve team effectiveness in specific areas and influence team-wide practices.

• You reduce deployment times for specific workflows, eliminate categories of bugs in your domain, and/or you create tools that have made the team more productive in particular areas.

• You can quantify these improvements and connect them to broader outcomes like feature velocity or reliability.

Senior Level:

• You transform how your entire team works and are starting to have an impact beyond your team. For example, you might have introduced new workflows that changed your team’s capabilities. Or perhaps you eliminated major sources of operational problems, or the improvements that you have created have been adopted by adjacent teams.

• Your impact extends beyond just engineering metrics to product outcomes, user experience, or operational costs.

Staff Level:

• You improve how multiple teams operate and drive organizational improvements.

• Your impact comes from achievements such as establishing practices that several teams adopt, solving infrastructure problems that were impeding multiple teams, or creating new capabilities that open up new types of work across teams.

• Your measurable impact can be tied to business metrics like revenue, customer retention, or time-to-market.

Principal Level:

• You create organizational capabilities and drive strategic changes.

• Impact at this level could come from establishing technical foundations that dozens of teams use to build upon, solving problems that were blocking major business initiatives, or creating leverage that compounds benefits across the company.

• Your impact is measured in business outcomes and strategic capability, not just technical improvements.

Difficulty

Difficulty reflects the complexity of problems you’ve tackled, the constraints you have faced, and the trade-offs you have managed.

Under this category, solving easy problems with big impacts is less impressive than hard problems solved well.

Entry Level:

• You work on straightforward problems within established patterns. For example, you might face challenges learning new technologies or debugging unfamiliar code, but the path forward becomes clearer once you understand the problem or ask for help.

Mid Level:

• You work through challenges and obstacles in your work. The problems you tackle have more moving parts and less obvious solutions. These could be competing requirements or having to work through technical complexity you haven’t seen before. Or perhaps you have had to manage dependencies within your team that affected your timeline or figure out solutions when the approach wasn’t immediately obvious.

Senior Level:

• You manage constraints and make technical decisions with team-level architectural implications.

• The problems you solve involve multiple interacting systems and competing concerns.

• You might have to balance needs across multiple stakeholders with different priorities. Maybe you make architectural decisions that affect how your whole team works, or you have to work around technical limitations that require creative solutions, or solve problems that require you to address both technical and business factors.

Staff Level:

• You manage competing trade-offs across multiple teams while handling problems with significant technical and organizational complexity.

• You balance different technical approaches when teams have genuinely conflicting needs.

• You create solutions that affect how several teams work together.

• You make architectural decisions that have to work across diverse contexts.

• You get teams to agree when the technically optimal solution differs for each team.

Principal Level:

• You handle fundamental trade-offs between competing organizational needs or solve problems where no clear solution exists.

• The complexity at this level often involves novel problems that lack established patterns or precedents.

• You balance technical excellence against delivery speed at organizational scale; work within organizational constraints while maintaining technical integrity; create approaches for entire classes of problems the company hasn’t solved before; or make decisions that affect company strategy and require executive buy-in.

Putting it all together

Companies aren’t just evaluating whether you can do the job. They’re also assessing whether you’ll thrive in their specific environment and at what level you’ll be most effective.

Both role fit and company fit determine not just whether you will get an offer, but also whether that offer will position you for success.

Understanding fit helps you know which of your experiences will connect most with what the company values.

Small companies need someone who ships fast and figures things out alone. And enterprises need someone who navigates processes and builds consensus.

Neither is inherently better than the other. They’re simply different environments that reward different approaches.

Last words

Special thanks to Steve for sharing all these important insights! Make sure to check him out on LinkedIn, and also check out his book Technical Behavioral Interview: An Insider’s Guide for more info on how to do well on behavioral interviews.

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

Feedback or addition? Make sure to 💬 comment.

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

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

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

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

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

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

Get in touch

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

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

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

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

Check the benefits of the paid plan

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

This newsletter is sponsored by Hygraph.

[Webinar] AI content workflows that actually save you time

Connecting your CMS to Claude via MCP sounds simple. Scaling it into workflows that actually increase your content output without adding headcount is the hard part.

More prompts and larger context windows give AI access to your content, but not the structure to use it well. Teams pulling ahead fix that through their content model, so output comes back accurate and publish-ready.

Join live on Sep 30 (FREE) to learn from the content workflows that:

• Generate 750+ pieces of GEO content without slowing the editorial calendar

• Save 20-30 minutes per blog post, no new hires needed

• Split one workflow into 5 pipelines instead of one blowing up the context window

If you’re trying to get more from AI without adding headcount, this one is worth your time.

Register now

Thanks to Hygraph for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I used to believe that as a leader, I needed to know everything. When I first grew from a senior software engineer to a team lead, leading a team of 5 people, I tried to take on the hardest tasks, finish the most tasks, have everything under control, and also work on weekends.

The team felt like I was trying to do everything myself and didn’t trust anyone around me. Well, that got me quite close to burning out, and I was forced to make a change.

I made a deliberate change to start delegating more and empowering and trusting my team. Things turned out a lot better after that.

As a leader, you are not judged by your individual contributions but by the success of your team and projects. So, remember that making others around you better is your number-one goal.

Now that we understand what’s really important, we’ll go over 6 actions you can take to become an engineering leader everyone wants to work with.

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

- Be a Team Player
- Take a step back from individual work and look at the big picture
- Regularly check in with your teammates
- Learn and grow together as a team
- Manage Up, Down, and Sideways
🔒 Create a Positive Work Environment
🔒 Don’t Blame
🔒 Coach and Mentor
🔒 Empower and Uplift Your Team
🔒 Last words

Let’s start with the first one!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published in mid-to-late October this year.

Learn more about the book

Be a Team Player

It’s really important to make the mindset shift as an engineering leader and transform the way you think. It should be a lot less “I” (“I did this.”) and a lot more “we” (“We as a team did this.”).

In software development, it’s really all about the team, the projects we’re working on, and the goals we’re trying to achieve. And one of the best ways you can be a team player is to put your team’s success first.

Here are some actionable tips that will make you a team player as a leader.

Take a step back from individual work and look at the big picture

Ask yourself the following questions every day to determine what you can do to help your team:

• Is there someone who’s stuck and needs help?

• Does the team have everything they need to be successful?

• Is a senior leader asking for something important?

Regularly check in with your teammates

You can check in with them through 1:1 meetings or quick chats at the start of team meetings. See how they’re doing, both in their work and personally.

Did someone just come back from a trip? Ask about it. On Monday mornings, ask how their weekend was. These small moments of connection go a long way toward building trust and supporting your team.

And when your teammates feel supported, the whole team performs better.

Learn and grow together as a team

You want to avoid creating or perpetuating knowledge silos, in which only one person knows how to do something. As a leader, create opportunities for knowledge sharing.

Use meetings, Slack, or other channels to encourage people to share what they’ve learned. If someone discovers something new, have them explain it briefly and share what new they have learned.

That way, everyone will benefit and the whole team will get stronger together.

Work on your own teamwork skills

If you’re not already a team-oriented person by nature, it’s a good idea to consciously develop teamwork as a skill.

If you’re not sure how to do this, I recommend finding a hobby or activity outside work in which you collaborate or work with a group to achieve a goal.

This could be playing sports (or video games or board games), working on a side project, taking part in a community, or something else.

Manage Up, Down, and Sideways

To be considered a great engineering leader to work with, you need to manage up well (to your manager, leadership, and stakeholders), down (to your team) and sideways (to your peers).

If you mishandle one part and don’t build a decent working relationship, the other parts may suffer.

A mistake I made as a new team lead and later as an engineering manager was shielding my team too much and trying to sugarcoat things when we were having major issues.

Instead, I should have involved the team earlier, looked to collectively address things, and not tried to solve the major issues on my own.

I also made a lot of other mistakes, like the ones I mentioned in the article: How to Manage Up as an Engineer or a Manager: sending an email about potential improvements to my skip-level manager while not trusting my direct manager to handle those improvements, plus expected my new manager to change their working style because I was used to the working style of my previous manager.

All of that really doesn’t work, and I just ended up making our working relationship worse. So how can you manage successfully in all directions?

My top 3 tips are as follows:

• Build good relationships and good communication practices.

• Try to proactively find out the problems that people around you are facing and put in the effort to resolve them.

• Be transparent, give feedback, and ask for help when you need it.

Create a Positive Work Environment

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 23 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

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

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

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

Intro

It’s important to realize that a lot of the problems teams face today are not new. We’ve been struggling with coordination, missing deadlines, bad metrics, adopting “shiny new technologies” for quite a while now.

That’s why understanding the laws like Conway’s Law, Brooks’s Law, Goodhart’s Law, Hofstadter’s Law, Amdahl’s Law, and Amara’s Law are so important and truly timeless.

And what’s important to mention is that in today’s AI era, many of them are becoming even more relevant. With the speed of building increasing, the bigger bottleneck becomes coordination, communication, and good leadership.

In today’s article, Dr Milan Milanovic will be sharing the most important laws you need to know for leading engineering teams. He’ll also be sharing examples of these laws from his personal experience.

Let’s introduce our guest author and get started.

Introducing Dr Milan Milanovic

Milan is a CTO, Microsoft MVP, and also an author of the book Laws of Software Engineering. He has more than 20 years of experience both as an engineer and engineering leader, working across many different industries.

I know Milan for quite a while now, and we chat occasionally on various topics. Today, he’s been kind enough to share some of the important insights from the book adapted for this article.

Over to you, Milan!

Understanding the specific software engineering laws is crucial for leading engineering teams

Throughout my 20-year career in tech, especially working at big companies and on large projects and teams, I noticed some specific patterns. Back then, still a young engineer, I couldn’t define them well.

Later, when I worked on some other projects and in new companies, I noticed the same patterns again. It became obvious to me that the same mistakes happen in almost every company.

This was the first time I researched a bit more about them, and it was immediately obvious that they are not new and some are old, like 20 or 30 years or more (Brooks 1975 and Conway 1967).

What also surprised me was that most of my colleagues back then didn’t know about them.

The second time I came across them was when I was writing an article on why engineering teams’ estimations and plans fail. It became obvious that a lot of these laws play a big role and are crucial for success of engineering teams.

So, my recommendation if you want to lead a high-performing engineering team, is that it’s really important that you know and understand the laws I am going to share today.

What’s also important to mention is that, with the emergence of AI in the last few years, a lot of these laws are even more important than before because we have shorter cycles, smaller teams, and a lot of these laws can be violated much faster.

Let me start with the first law!

1. Conway’s Law

This one is probably the most well-known of all laws, and it can be harder to grasp and understand, especially if you’re just starting in the industry.

It says that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Let me share an example.

If we have small distributed teams of a few engineers working in different places, the architecture of the system will probably be Microservices. Why? Because it reflects the organizational and communication structure of the team. On the other hand, if we create one large team, we will probably have one big monolith.

I remember once working on a big banking project with a large team; the system was one big monolith, and it was really hard to maintain.

Then we sat down and created a new organizational structure with subteams, and split our monolith into modules, so it became a modular monolith.

Each subteam became the owner of one module. It was not possible to split the architecture into modules before reorganizing teams first.

It’s important to note that we should not copy someone else’s structure, e.g., the Spotify model, because this model solved their coordination problem, not ours.

2. Brooks’s Law

This one is also very important for leading engineering teams, and the reason is that we are often in a situation where our projects are late.

There are a few things we can do in this situation, and I’m sure that every leader has tried to solve this problem by adding more people to the team (or teams).

This is exactly what Brooks’s Law warns us about which states that adding more people to a late project only makes it later.

It looks a bit contradictory at first glance, but if we think a bit more about it, it is not. When we add more people to the late project, we do 2 things:

1. We increase the number of communication and coordination channels in the team.

2. And we take time from the existing team members to do their job, because they need to take part of their time to work and onboard new people.

The math is simple, e.g., with 8 people in the team, we have 28 communication paths, while if we have 6 people in the team, we have 15.

Let me share an example from my experience next.

In one of our projects, we had 8 team members, and we were always late for our deadlines. We tried different things, such as making estimations with buffers, hiring new people, etc. But we always ended up being late on our commitments.

What happened after was that 2 people left our team, and all of a sudden things became more efficient, and we managed to deliver on our commitments.

This was surprising, but as communication paths dropped from 28 to 15, obviously this had an impact.

What I found is that there is also a way to measure this, and is called Little’s Law, which comes from queuing theory.

Little’s Law (L = λ * W) refers to work in progress, throughput and lead time. For example, If your team completes 5 tasks per week and you have 20 in progress, the average lead time is 4 weeks. Increase WIP to 40 with same throughput, lead time is 2x now.

So when you add people to a late project WIP goes up and throughput stays flat. The outcome? Longer lead times, not shorter. Reduce work in progress (WIP) before adding people if you want to get things done faster.

3. Goodhart’s Law

This one is probably the most relevant for managers and leaders. And it’s becoming even more important due to AI.

This law states that when a measure becomes a target, it stops being a good measure.

Many companies make a mistake where they measure certain metrics and treat their direct outputs as goals.

Some examples of this are:

• lines of code written,

• test coverage percentage,

• tickets closed, etc.

The main problem with this approach is that when we attach our goals to outputs, people will find a way to gamify these metrics and become good at increasing them, while not actually increasing business value.

I remember when, in my early days, our manager considered better engineers those who produced more code, although we knew this was not true.

Once, one of our best colleagues decided to remove 1,500 lines of code and simplify one of our modules in payroll. The system became simpler and faster, yet our manager rated that as an example of a not-good job.

Now, with AI, we see similar trends with spending AI tokens (tokenmaxxing). Engineers who spend more tokens are considered more valuable, and some companies even created leaderboards for that.

So, how to solve this problem? Focus on outcomes, not outputs. Define metrics, but use them only as proxies, not targets or rewards.

The focus should be on producing meaningful results. Here is an example:

The metric “Cycle time” alone just tells us that something is moving, but cycle time + what we shipped this month, and whether it provided value for the users, tell us a more complete story.

In our team, we saw a good example of this when we decided to move from Scrum to Kanban and completely remove story points and estimations.

Before, we always tried to achieve our velocity and measured everything by it, yet we spent a massive amount of time on estimations, discussions, etc.

When we removed them, our team became much more efficient, and we could produce more value for our users.

Sidenote: The Bus Factor

The Bus Factor states the minimum number of team members whose loss would put the project in serious trouble.

A bus factor of 1 means one person holds critical knowledge; if they disappear, the project is essentially ‘doomed’ or stalled. A higher bus factor (e.g., 5) means the project could lose any one of 5 specific people before stopping work.

It’s basically a measure of knowledge distribution and risk. A high bus factor is good (knowledge is shared among many), while a low is bad (single points of failure in expertise).

Teams should work to increase their bus factor by sharing knowledge, documenting critical systems, having code reviews, and rotating responsibilities.

Let me share an example from my experience. Once, we had an engineer on our team who was the only one who knew our billing system, and he was preparing for a long vacation.

This was Bus Factor 1, and it’s very problematic. We decided to pair him with another person who would take over some important parts of the system, moving Bus Factor from 1 to 2, and he was no longer a single point of failure.

The question we should always ask for every member of our team is: If person X leaves us tomorrow, can we still operate? If no, then there needs to be more exchange of knowledge.

4. Hofstadter’s Law

As we worked in Scrum for years, we had all the regular estimation sessions. After some time, we figured out that we actually missed each of the deadlines we set.

We knew this, and we tried everything we could to improve, but still deadlines were mostly missed.

This was exactly what Hofstadter’s Law defines: it always takes longer than you expect, even when you account for Hofstadter’s Law.

And when we tried to analyze this (didn’t know about the law then), we figured out that there are many moving parts in our work. API integrations depend on someone else; one engineer got sick, some of our designs didn’t match reality, and more.

Also, there is something called the Ninety-Ninety rule, which says that the first 90% of the project takes 90% of the time, and the last 10% takes the other 90%, and this is true.

When engineers think about the project, they mostly think about the first 90%, and this is actually the core of the implementation, e.g., business rules.

But the last 10% could take the same amount of time, as they didn’t account for integration delays, authentication, edge cases, and more.

Taking all of this into account, I have a few simple rules to follow. First, if I need to estimate some work, I say:

• If it takes 2 min, do it immediately

• If it takes a “few minutes”, estimate it at an hour

• If it takes a “few hours”, estimate it as a day.

Another important thing is communication with stakeholders. We need to be open and honest with them, and what this means is that we don’t accept any roadmaps longer than a quarter to give any kind of estimate.

And for all the estimations, we should always add buffers to cover the Ninenty-Ninety rule.

Here we need to mention also Parkinson’s Law, because it says that work will expand to fill all the time available for it. So, if we can finish something in a day, but we estimated 3 days, it will probably take the full 3 days to finish.

I was on teams where estimations took more time than the implementation itself. So, we as leaders need to take both laws into account when working on projects. It is always better to have short deadlines with clear objectives than longer ones.

5. Amdhal’s Law

This law defines why AI productivity is not the same for everyone. For example, if half of our workflow is sequential, the maximum we can get from speedup is 2x.

If that workflow is 90% parallel, then we can get a 10x improvement.

The main thing here is that often we think that Software Development Life Cycle (SDLC) = coding, but it is not.

It includes many other parts of the job we need to do, such as deciding what to build and how, communication with the product team, reviewing code, waiting for different kinds of approvals, and more.

Coding is now much faster, but the other parts stayed the same. What I found is that teams that were able to increase their productivity more are those that made the human-in-the-loop part smaller.

It is the same on the organizational level as well. If we have an ivory architect or a CTO who needs to approve every decision, adding more resources to the project will not speed it up; you will just get a longer queue.

So, in order to improve your processes first measure the sequential part, because only adding more resources to the parallel part will not do miracles.

6. Amara’s Law

This law is also known as the Hype Cycle and is something we have seen for decades in tech.

We tend to overestimate the effect of technology in the short term and underestimate it in the long term.

We saw this starting in the 1960s and 1970s when work on AI systems started; it promised general intelligence, but the results were modest.

We also had a few long AI winter periods. In the meantime, research continued to work on AI (e.g., Prof. Hinton and his work on neural networks when everyone thought it is a dead end), and now, with all the tools from the past few years, we have seen remarkable changes in our industry.

Usually, the loudest voices are those who don’t use technology so much. So, the short-term promise was not true, while the long-term promise is something we could not imagine.

The same thing we had with Microservices. It was marketed as a one-size-fits-all solution for any scaling problem, but then we had many replicated projects that had more services than users.

I remember seeing only microservices architecture on many projects I worked on, often asking myself if it was really needed. In most cases, it was not.

For leaders, it is important not only to be right with decisions, but to be right at the right time too. If we miss the timing, then it is the wrong decision.

If we adopt it at the top too early, this could cost us later when everything changes (this is actually a Dunning-Kruger effect).

If we completely fail to adopt it, then we are late to adopt something everyone is already using.

What we should do is to treat innovation as a budget. Most of our track stays on proven technology (see Lindy Effect after), while we take small tries on hyped things. If it proves successful, then we expand it; if not, remove it.

Sidenote: The Lindy Effect

Together with the Hype Cycle, we should mention the Lindy effect, which says that the longer something is in use, the longer it will stay in use.

E.g., take an example of SQL from the 1970s or COBOL, which is used in half of the world’s banking transactions. On the other hand, we have all seen many libraries and frameworks that are not used anymore.

So, our main selection should be around the things that are proven and have been around for many years. AI changed one thing, and that is that it is much easier to replace certain legacy software.

A big COBOL codebase was not touched because no one fully understood it. Now, with agents, it’s much easier to do so. Yet, the fundamentals like algorithms, system design, architecture, and data structures are still very crucial.

So, now we should not ask anymore how long this technology will be with us, but whether it is the best way to solve the problem, and if AI can more efficiently replace it.

For me, I invest in things that AI cannot easily replace, such as fundamentals and judgement.

Using the laws together

We should know that no problem involves only one law, but usually a few of them. If our delivery is slow, there are 2 or 3 laws impacting this. The wrong turn would be to fix it before we know which ones exactly.

This is a checklist I run when I have an issue in a team:

1. Conway’s Law

Does our team structure match the system? If this is not true, we are probably losing too much time in coordination activities.

2. Brooks’s Law

Did we add any new people recently? If yes, then this could lead to a stall in the project.

3. The Ringelmann Effect

If our teams have 8 or 9 people or more, the output for each of them will probably drop.

4. Goodhart’s Law

If the team meets goals but our product is not better, nor are users satisfied, then the metric has become the target.

5. Broken windows theory and Tech Debt

This one is usually forgotten. If the codebase is in the state where no one bothers to fix issues, then this is a big problem. Even with AI, this doesn’t improve.

So, to conclude, we don’t need to know all the laws. If we have an issue with our team, we should do the following: 1) name the forces, then 2) rank them by importance. If you have a deadline, Hofstadter is more important than Amdalh.

Also note that in some cases, there are different laws that contradict each other; e.g., Brooks’s Law and Linus’s Law are both true, but in different contexts.

Last words

Special thanks to Milan for all the insights with us! Check him out on LinkedIn, and also check out his book Laws of Software Engineering to get to know all the important laws in software engineering.

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

Feedback or addition? Make sure to 💬 comment.

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

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

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

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

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

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

Get in touch

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

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

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

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

Check the benefits of the paid plan

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

This newsletter is sponsored by Nango.

Connect your products & agents to 1,000+ APIs

Nango offers everything you need to connect your AI agent with external APIs:

• Pre-configured integrations for 1,000+ APIs with 7,000+ tools: let your agents securely discover & call tools across 1,000+ APIs without clogging context.

• Every integration type covered: auth, tool calls (MCP-ready), triggers, and syncs, with token refresh, rate limits, retries, and logs handled for you.

• Extensible and enterprise-ready: customize any integration in code; supports SOC 2 Type II, HIPAA, RBAC, audit trails, BYOC, or self-hosting.

Open source with 11.7k+ GitHub stars, used in production by Smartsheet, Ramp, and ServiceNow. Simple pay-as-you-go pricing.

Try Nango for free

Thanks to Nango for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

You may believe that people will see you as reliable if you do good work. But there’s a lot more to it, and you need to be intentional about how you showcase your reliability.

What seems reliable to you might not seem reliable to your manager or stakeholders, so try to see yourself from their perspective.

In this article, we’ll break down all of the things you should do to be seen as a reliable person who gets stuff done.

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

- Do exactly what you agree to do
- A lot of your success is determined by how well you communicate
- Provide estimates instead of making guesses
- Keep your manager in the loop
- Admit your mistakes
🔒 Get good at time management
🔒 Prioritize ruthlessly
🔒 Block out focus time
🔒 Have separate maker time and manager time
🔒 Use Pomodoro to avoid distractions
🔒 Improve communication to save time
🔒 Cancel pointless meetings
🔒 Say no more often
🔒 Take time off
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published in mid-to-late October this year.

Learn more about the book

Do exactly what you agree to do

During one of my very first freelance projects, I was working hard to build a website for a client. But my communication wasn’t really on point.

I wasn’t asking questions to find out what was really needed, and I wasn’t managing the client’s expectations the right way. I was just focused on building.

To my surprise, what I delivered wasn’t what the client expected. It went too far in a different direction, and the client immediately saw me as less reliable.

I was able to turn the project around by making appropriate adjustments, but my reputation was already damaged. The client didn’t send me any more work after that.

So I learned this lesson the hard way:

You can do the best work in the world, but if you don’t manage stakeholders’ expectations and deliver what they’re relying on you for, it won’t mean much.

After that, I started regularly updating my clients on my progress, asking the right questions, sending previews, and asking for confirmations before I started building.

Being reliable got me more projects than I could handle. I learned that continuous communication works much better than “big-bang” reveals. Clients don’t want to be surprised. This is true for full-time roles as well.

A lot of your success is determined by how well you communicate

Notice that a lot of what we mentioned above takes place before the work actually starts:

Doing great work starts with being careful and precise about what you agree to do (and when and how you agree to do it).

Additionally, look for ways to narrow the scope of the project or a task in order to deliver on time. It also helps to give two options and let the stakeholder of the project choose as well.

An example of a trade-off in order to finish the project on time:

“We found out that to finish X completely, we also need to do Y, which will take 3 to 5 additional days.

I’ve talked with the product manager and, as an alternative, we could adjust the scope of X and deliver without also doing Y.

I suggest we pursue the second option, but please let me know which option you would prefer.”

This clear communication shows that you care about finishing the project on time, have taken ownership, and are proactively searching for a solution.

Provide estimates instead of making guesses

If you’re not exactly sure how long something will take, share a confidence percentage and estimate a range.

I can’t tell you how many times I’ve made the mistake of saying things like “This will take five minutes,” or “This is very easy to do.”

In planning meetings, I used to say that something was very easy to develop and then spend the whole night working on it to prove that it wasn’t that hard.

After making many inaccurate estimates, I learned that it’s much better to not go straight to optimism. If you are not entirely sure, say so and attach a confidence number to it like this:

“With 70% confidence, I estimate that we can finish this within 2 to 3 weeks.”

This sets the expectation that you might be wrong, which in software development is realistic: a lot of things are uncertain and hard to predict.

It won’t be a problem if you’re wrong as long as you communicate as early as possible and don’t make claims you can’t deliver on.

Keep your manager in the loop

Your manager shouldn’t have to ask you for status updates. Be proactive and send the updates yourself. I recommend following this template:

We’re on track to deliver [functionality] by [date]. 
We have completed [recent achievement] and we’re now focused on [next steps].

Risks and roadblocks

[Brief issue summary and mitigation plan

[Brief issue summary and mitigation plan]

What’s next?

[Task or goal: ETA: date-date]

[Task or goal: ETA: date-date]

Support needed [if any]

[Specific ask or decision needed from your manager]

Let me know if you’d like more details!

You can send this update via Slack or email. The important thing is to keep it concise.

Admit your mistakes

If you make a mistake, admit it and learn from it, don’t try to sweep it under the rug. Take ownership and do everything that you can to learn from it and help others to learn from it, so no one else makes the same mistake.

Robert, a student in the course “Senior Engineer to Lead”, suggests sharing what you did that led to the mistake and what you’ll do to avoid the mistake in the future.

Then, share it with your manager and the team. This shows that you’ve taken action to learn from and avoid repeating the mistake and that you care about both quality and learning.

Get good at time management

Read more

Read more

This newsletter is sponsored by DX.

Live webinar: Introducing the CAFE(S) framework for improving AI agent effectiveness

As AI agents become more capable, context quality is increasingly the limiting factor in their performance.

Join leading researchers on September 24 for an early look at CAFE(S), a new framework for evaluating whether AI agents have the context they need to do their jobs well.

The webinar will cover:

• A practical framework to evaluate the five core dimensions of AI agent context quality.

• A shared vocabulary to diagnose context failures before they become production issues.

• Actionable guidance for engineering teams to improve context hygiene and scale AI workflows safely.

Register here

Thanks to DX for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

In one of the previous articles, titled The “Player-Coach” Role is Becoming Increasingly Harder, we talked all about how the role is actually getting harder than it was before.

And the problematic part is that many people don’t understand that and don’t give the deserved credit.

Today, we’re diving deeper into how to actually do the coach part the right way!

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

- Great engineering leaders create leaders
- The difference between coaching and mentoring
- Make the mindset shift from telling to coaching
- Having a coaching mindset is all about asking great questions
🔒 Practical frameworks
🔒 The Solutions Focus model
🔒 The CLEAR model
🔒 Use the core skills for being a great coach and mentor
🔒 How to practice?
🔒 Great leaders multiply others
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

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

Learn more about the book

Great engineering leaders create leaders

I view all the “player-coaches” as engineering leaders, and one of the most important things a great engineering leader does is create leaders.

And to do that, you need to become a great coach and mentor who elevates everyone around you and helps others grow.

You’ve probably had one or more managers in the past who you didn’t see as great managers, and the exact reason for that is that they weren’t leaders. They weren’t making everyone around them better through coaching and mentoring.

To have a great career as an engineering leader, you need to know and understand how to do coaching and mentoring the right way. Let’s go into more details next.

The difference between coaching and mentoring

It’s crucial to understand the difference between coaching and mentoring, so let’s cover that first.

Coaching

Coaching is normally short-term oriented with a specific goal, such as helping someone solve a specific problem or get better at doing something. The focus should be on asking the right questions and guiding the person to finding their own answers.

Mentoring

Mentoring is normally longer-term and about building a good working relationship by sharing your own experiences, offering advice, and being a good role model.

It’s really important to know when to wear the coaching hat and when to wear the mentoring hat. Great leaders know this and are good at both.

Make the mindset shift from telling to coaching

As engineers, it’s in our nature to share what we know and go straight to finding solutions. I like to say that we are “born problem-solvers”.

But to be a great coach and mentor, you need to move from “telling” to coaching. It’s a hard mental shift to make, but it’s crucial.

If you just give people answers to their questions, they won’t get any better at finding answers themselves. And they’ll expect you to just give them more answers in future.

That’s what happens when you have the “telling” mindset.

But instead of just “giving them a fish,” you want to teach them “how to fish”. That’s what you’ll do if you have a “coaching” mindset, which is a lot more powerful because it lets you guide others to finding the solutions to their problems themselves.

Having a coaching mindset is all about asking great questions

Here are some of the questions that I personally like to ask, whenever I’m coaching:

• “What have you already tried?”

• “What would you say is the main problem here?”

• “What are some different ways you could approach this? And what are the pros and cons of each?”

• “What resources or what particular person might help you find the answer?”

This may seem A LOT slower at first, but, in the long run that’s going to make a big difference.

You will boost their confidence, critical thinking and independence, which they need to become resourceful so they can solve new problems by themselves.

As a leader, your job is not to be the smartest person in the room, it is to build a team full of smart and capable people.

Practical frameworks

Read more

Read more

This newsletter is sponsored by G2i.

The bar for “good engineer” moved, your hiring process didn’t.

A year ago, using AI for coding meant using 1 AI agent at a time. Now it means orchestrating 3 or 5 at the same time, with the focus on the right code quality as well.

If your tech interview process still tests for pure syntax, you’re screening for a job that doesn’t exist anymore.

• Live session, judged by a real person in real time

• Scores RL, RAG, agentic development, and eval judgment

• Built from two years inside frontier AI lab work

• Vetted senior and staff-level engineers with 10+ years building production systems

See how G2i evaluates real engineering judgment:

Learn more

Thanks to G2i for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Throughout this year, I had the pleasure of talking with many different people and teams about how everyone works and what makes them successful.

I’ve visited many companies in San Francisco and had countless conversations with engineers and engineering leaders from companies around the world.

In today’s article, I am sharing insights, particularly about what differentiates elite engineering teams from the average ones.

The insights shared in this article are from:

• Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI

• Venkat Venkataramani, VP of Applied Infrastructure, OpenAI

• Katelyn Lesse, Head of Platform Engineering at Anthropic

• Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock

• Andrew Churchill, CTO, Weave

The question I asked them was: “What separates elite engineering teams from the average ones?” Their answers are shared in this article.

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

- Elite engineering teams focus on the “outer loop”
- Clarity on the north star and good metrics in place in order to measure success
🔒 At Anthropic, elite teams are more ambitious than average teams
🔒 Team tenure and committed work say a lot about how great the team is
🔒 Elite teams work within flatter orgs and have a good ratio of spending and delivering values
🔒 Last words

Let’s start!

Elite engineering teams focus on the “outer loop”

Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI, described the difference between an average team and an elite team using the idea of the inner loop and the outer loop of software development.

The inner loop refers to shipping or writing code faster. But the problematic part is that more code is not always better. Many average teams are already good at this, they build quickly and produce a lot of code.

However, the real difference appears in the outer loop.

The outer loop is about getting real user feedback, learning from it, and quickly iterating to improve the product. Average teams often run into bottlenecks here.

Elite teams optimize both loops. They not only write code quickly but also build systems that help them test ideas, gather user signals, and iterate faster toward real outcomes.

And the example Sulman has shared:

Instead of writing code and manually testing it, elite teams use tools like Codex to test and iterate as part of the development workflow. This helps them get to the desired result much faster.

The ultimate version of the outer loop connects development directly to real user outcomes, such as product usage or user engagement.

So, to sum up the insights shared from Sulman:

• Average teams mainly optimize the inner loop, focusing on writing/generating code faster.

• Elite teams optimize the outer loop, learning faster and driving real impact.

What matters most is impact, not the amount of code written.

Clarity on the north star and good metrics in place in order to measure success

Venkat Venkataramani, VP of Applied Infrastructure, OpenAI, mentioned that for a shorter time period of the work of specific teams, it’s easier to see whether the team is doing well or not, because there are clear deliverables and well-defined metrics attached to it. It’s a lot harder to know if the project takes a long time to finish.

This is an important signal for infrastructure teams to break down projects into smaller, more manageable pieces, because that’s how you can show your progress a lot more clearly.

And the 2 specific high-signals of elite teams Venkat shared are:

• Does the team have clarity on what the north star looks like? (long-term goal of the team) And are they able to hit that goal as well?

• Another signal is if the team doesn’t have specific metrics in place that they track in order to know how well they are doing.

And then he also shared the following:

For every infra team, there’s always a time when there needs to be some “hill climbing”, which means that the team may be overwhelmed with the amount of work in a certain period of time because of how unpredictable infrastructure work can be.

Great teams are able to balance that short-term pressure well, without losing sight of the long-term goals.

Which means that they don’t just put “all hands on deck” when there is a certain pressure, but they stay composed, assign specific people to focus on the right areas, communicate clearly if there’s going to be any timeline changes on projects, and manage to juggle everything without dropping the ball.

At Anthropic, elite teams are more ambitious than average teams

Read more

Read more

This newsletter is sponsored by Honeycomb.

Live Masterclass + Q&A: The Business Case for Observability

Observability is a significant engineering investment. On September 2, Honeycomb’s Liz Fong-Jones, co-author of Observability Engineering, will break down how engineering leaders can evaluate that investment, connect observability to meaningful outcomes, and build an evidence-based case for what comes next.

In this virtual masterclass session:

• Evaluate observability against engineering outcomes

• Identify gaps between monitoring and effective observability

• Build an evidence-based case for future investment

Register now and watch what you missed

Thanks to Honeycomb for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I recently had the pleasure of speaking with Eric Sammer, Distinguished Engineer at Redis (formerly CEO Decodable).

We talked all about how Redis builds AI-native engineering teams, their process, culture, and also how they do hiring.

Interestingly, their engineering culture revolves heavily around performance. Not surprising, though, as performance plays a huge part in Redis’s products, and they work within pods of 3-4 engineers, each with a feature lead.

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

- What does AI-native mean at Redis?
- The size of Redis’s product&engineering org
- Redis’s AI-native teams structure
- Their meetings and process
🔒 How are they using AI to be more productive?
🔒 They are measuring token spend, but how effective the spend is is the hard part
🔒 Redis’s engineering culture
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI, Anthropic, and Shutterstock build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Redis?

As with every article about AI-native teams, I always want to understand what AI-native really means for a particular company, and this is what Eric mentioned:

I think it’s similar to “cloud native”. It’s a term people use to mean almost everything and nothing.

To me, being AI native means treating AI as a default way of working, not as something you simply add on later.

The question I like to ask is: If we were building software engineering from scratch today, and AI already existed, what would it look like? How would we build teams, processes, tools, and technology differently?

That’s what AI native means to me. And I think cloud native is a good parallel.

Especially interesting is the parallel to being cloud native, which resonates, because when companies started to shift from on-prem to cloud, quite some time ago, that term got quite similarly sensationalized as AI-native is today.

The size of Redis’s product&engineering org

I was quite surprised to hear that Redis has about 350-400 people across the product and engineering org. They really came a long way from when Redis was just an open-source project started in 2009.

Engineering makes up the majority of that headcount, and around 20-25 people are in product. That’s about a 1:15 PM-to-engineer ratio. Very similar to what Shutterstock does. While Anthropic has a 1:8 ratio and OpenAI has 1:30.

One of the more interesting changes Eric has mentioned is that, looking from 2 years ago to today, there’s a lot less specialization of engineers, and a lot more engineers who are good generalists.

I wrote about this exact trend in this article: Become a Great Generalist or Extreme Specialist.

And he also mentioned that PMs don’t just work on creating PRDs or designing in Figma, but they actually build working prototypes in React and Claude Code.

Redis’s AI-native teams structure

They work within small pods of 3-4 engineers. Every team has a feature lead, which is basically a tech lead, leading the technical implementation of a certain project that the team is working on.

And these teams work with other teams, and people e.g. PMs, designers, customer support etc. when needed.

This is very similar to how OpenAI builds their AI-native teams, just the difference is that the feature lead is called the DRI (directly responsible individual), for both technical and product/business as well.

Eric also mentioned that the teams have support from higher-level engineers e.g. Staff, Principal and Distinguished engineers when needed.

These higher-level engineers are normally also called service leads, they lead specific larger functionalities and ensure that the teams who are building these related projects are aligned with the standards.

Their meetings and process

These teams can generally decide what the best way is to handle meetings and the overall process. Some of these teams work within 2-week sprints, and every team decides how many meetings they need.

Eric mentioned that this is something they are still figuring out and evaluating what the best way to go is, and he sees that alignment is more important than ever. This is what he mentioned:

I’ll be honest, I don’t think we’ve fully figured this out yet. It’s something we’re constantly evaluating to see if there’s a better way to work.

In the past, the biggest bottleneck was writing code, testing it, and getting it into production. Now, the bigger bottleneck is how quickly teams can align and make decisions. The more people you have, the harder that becomes.

That’s why I think frequent communication, like daily stand-ups, is more important than ever. They help teams spot when something is off, when people aren’t aligned, or when they don’t understand why we’re building something.

These stand-up meetings are also less about the technical details and more about timelines, priorities, and cross-team dependencies these days.

Planning also needs to move much faster. Some teams still use traditional 2-week sprints, but a lot can change within those 2 weeks.

Roadmap and prioritization decisions used to happen every couple of weeks. Now, they can happen every few hours. A team might finish something much faster than expected, and suddenly you need to figure out what they should work on next.

My feeling from talking with many different teams is that nobody really has it figured out, and everyone is learning as they go, even Anthropic and OpenAI, they are constantly evaluating and adjusting how they work.

How are they using AI to be more productive?

Read more

Read more

This newsletter is sponsored by Sonar.

Cut AI coding token costs by up to 36% with Sonar Vortex

Sonar Vortex operates directly within your AI coding agent’s reasoning loop to supply architectural context before any code is written.

By verifying output in real time, it empowers you to build safer, higher-quality software while significantly reducing your LLM spend.

• Slash Token Costs: Testing showed reduced LLM token consumption by up to 36% on coding tasks.

• Reduce Bugs: Lowered software defects by 92%.

• Smarter AI Context: Equip your AI agents with deep architectural context before they generate code.

Make your agents more effective

Thanks to Sonar for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I’ve been using Shutterstock’s platform for quite some time now. Whenever I needed a stock image, it was usually one of the first places I’d look.

But in recent years, Shutterstock has been adding a lot of new features and capabilities, especially around AI. It seems they went from focusing primarily on the stock content business to a company focusing a lot more on AI/ML.

A similar transformation I’ve seen with Canva as well (just in a different industry).

That was one of the reasons why I was excited to talk with them and learn how they think about building AI-native engineering teams.

I’ve recently had the pleasure of talking to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock.

He shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams, which I am sharing today in this article.

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

- What does AI-native mean at Shutterstock?
- How big is Shutterstock’s engineering org?
- The structure of their AI-native engineering teams
- The process of AI-native engineering teams
🔒 How are their engineers using AI?
🔒 Advice for writing good prompts
🔒 How do they track token spend?
🔒 What makes an elite versus average engineering team?
🔒 Shutterstock’s engineering culture
🔒 Being vocal and having an opinion is a very important trait
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI and Anthropic build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Shutterstock?

This has now become a standard question that I ask different companies, and the reason is that “AI-native” means different things for everyone. Here is what it means for Jefferson and Shutterstock:

AI-native means that AI is integrated into everything that we do, all the way from coding and architecture to design, and also providing a good experience to our customers.

An interesting thought that he mentioned is that they want to provide the same kind of experience their people have internally using AI tools to Shutterstock’s customers as well. With AI workflows and experiences on their platform.

How big is Shutterstock’s engineering org?

Jefferson mentioned that they have been flattening a bit of their organization over the years, and they want to have an organization that is engineering-heavy.

They have about 350 engineers inside the org, across a lot of different time zones and countries. Their product org is kept purposely small, as they want their product managers to be working across different engineering teams.

And designers work more directly with product managers. The goal is to have the engineering teams autonomous as much as possible, and then bring in additional people when needed.

The structure of their AI-native engineering teams

Their AI-native engineering team structure is 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 utilized when there’s a need for it in parts 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.

Jefferson also mentioned that not every engineer is expected to be full-stack, the goal is to have all different skill sets covered in the team, so the team can be as independent as possible.

In practical terms, that means that some engineers may be a lot better in frontend, some better in backend, and then some better in DevOps, AI/ML, etc.

And one important thing as well is that they encourage their engineers to change teams if that’s their preference, in order to grow and develop various skill sets. To quote from Jefferson:

I can think of at least a dozen folks internally who have spread their wings and moved into different teams, picked up new languages, started working on front-end when they were back-end engineers, etc., and really developed their careers here.

The process of AI-native engineering teams

Their product teams work within 2-week sprints and use Scrum as their way of working, which is the same as traditional teams.

So, they have all the meetings like traditional teams: daily meetings, planning, retrospectives, 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 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.

How are their engineers using AI?

Read more

Read more

Intro

The Forward Deployed Engineer (FDE) role has gained a lot of popularity in recent years, and OpenAI is a good example of fast scaling of their FDE organization.

Additionally, they recently built a separate entity called the OpenAI Deployment Company, focused on helping customers use OpenAI’s products.

I had the pleasure of talking with Colin Jarvis, Global Head of Forward Deployed Engineering at OpenAI.

We talked all about how their team works, what makes a great FDE, how they work with customers, and how engineers can prepare for the role.

This is an article for paid subscribers, and here is the full index:
- How OpenAI built its forward deployed engineering organization
- Forward deployed engineer role at OpenAI
- What does an FDE do on a daily basis?
- About 50% of their time is spent on the customer site
🔒 The hiring process for a new FDE
🔒 Onboarding process for a new FDE
🔒 What makes an FDE successful
🔒 Moving from a software engineer to FDE, how to prepare?
🔒 Last words

Let’s start!

How OpenAI built its forward deployed engineering organization

OpenAI started the forward deployed engineering organization last year, with a focus on gathering insights from customers, learning what the use cases are, and bringing the insights back to product and research.

They started with just 2 people and have now grown to around 140 people in the FDE org. The FDE org sits between the GTM (go-to-market) org and product and research, working with both of them, acting as a “link”.

After some time working with different customers, they have noticed repeatable problems that people and companies are dealing with, and that’s also the reason why they recently started OpenAI Deployment Company (which is a separate entity, but still part of OpenAI).

It has now grown to about 200 people, and I suspect it’s going to grow a lot more in the future. Its goal is entirely to help solve customer problems, which is at the core of what FDE is all about.

Colin mentioned that they intentionally want to keep the internal FDE org at OpenAI relatively small and focused on getting insights for the product and research, but they want to keep expanding the OpenAI Deployment Company in order to support the customers in need of integrating their products.

Now, let’s get more into the FDE role in general.

Forward deployed engineer role at OpenAI

When I asked Colin on how he’d define the FDE role at OpenAI, he mentioned the following:

A forward deployed engineer is focused on outcomes. Which means that their goal should be to work on problems where solving them has a much bigger impact than the work itself.

So, in practical terms, the value is not in writing code, instead, the focus is to solve the problem and, ideally, make themselves obsolete as well, so they are not needed anymore.

And if they are needed again (for the same problem), that usually means that the problem has not been solved entirely.

They want strong software engineers, but at the same time also good communicators, who can really dig into what the actual problem is and explain the solution in a way that resonates with everyone.

And (ideally), these engineers would also have some domain expertise in the field that the specific customer operates in.

For example, a software engineer who has worked in the fintech industry could be a great fit for an FDE helping out a customer who works in fintech, because they understand the domain.

However, an important thing that Colin mentioned is that they want to mix the domain experts and FDEs, who are not. And the reason is that a person who is not an expert in the specific industry, but has experience from another, is going to be much more likely to “challenge the status quo” and have unique ideas to solve certain problems.

What does an FDE do on a daily basis?

Colin shared an example of a project they are working on at the moment in Japan, specifically for “code modernization”. That specific customer has a lot of legacy applications, and migrating one of these systems can cost hundreds of millions of dollars.

They are helping that customer with the migration from older tech to the new tech using AI.

An FDE might spend the full day talking with the payments team to understand what specific things are important to them so that the migration would be successful.

And then the next day, start building tests based on the insights shared from the payments team in order to ensure that the migration is actually successful.

And then another day they might be writing actual migration code, or building the UI to show the progress of the migration, and/or specific steps of it.

So the role is really a mix of engineering and working directly with domain experts (and also having a good understanding of that field), going back and forth between the two.

There’s also a feedback loop with the product and research teams that’s important. And in this specific project, they found out that a specific model used for the migration kept making some simple mistakes.

And as Colin mentioned, they don’t just send the exact customer problem back to the research team. They try to be as specific as possible, for example: “The model struggles with these types of COBOL-to-Java tasks. We need more training data around these examples.”

They’ll do whatever is needed to make a certain customer successful, but the bigger goal is to make sure the model keeps getting better for every customer.

About 50% of their time is spent on the customer site

They generally tell new joiners to expect around 50% of their time on site.

But also, as Colin mentioned, it varies by project. For example, some of their people in the UAE are on site around 80% of the time. People based in Europe or the US might spend 2-3 weeks per month with customers. In Japan, people are also on site around 80% of the time.

But in general, they focus on trying to have the biggest impact possible when on-site, and they’d rather spend 2 or 3 impactful days instead of 4-5 less impactful.

And also, a lot of their customers are spread across different locations, so being on-site all the time isn’t practical. But, as a general guideline, around 50% of the time on-site is a good estimate.

The hiring process for a new FDE

Read more

Read more

Intro

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

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

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

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

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

Let’s start!

Ready, Spec, Ship Hackathon with Kiro

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

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

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

Check the details

Looking forward to seeing what you’ll build!

What has changed for 1:1 meetings in 2026?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Be on time

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

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

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

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

Always keep this in mind.

Get your own 1:1 Notion template that I use

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

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

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

Meeting agenda

Read more