This newsletter is sponsored by Unblocked.

A Pile of MCP Connectors Is Not a Context Engine

Your team connected Slack, Jira and GitHub over MCP, and engineers still spend their time steering agents to the right answer.

This article looks at why: connectors fetch from one tool at a time, so every agent stitches the pieces together itself, trusts the first doc that looks right, and adds a search to your token bill each time.

Read what changes when a context engine sits on top of your connectors: the same coding task finished 83% faster at 48% lower cost.

Read the blog post

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

Intro

My book The Multiplier Mindset published by O’Reilly has recently been released, and has also been a #1 Bestseller (or close to) on Amazon for the past 2 weeks.

Learn more about the book

In the part 2 of the book, I feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:

• How they multiply others

• What makes them successful

• How they use AI

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

Today, I am sharing the case study of Navya Agarwal, Tech Lead at Adobe, which is included in the book.

Let’s start!

What Navya Agarwal Does

A few years ago, if you’d asked Navya Agarwal what a tech lead does, she would have answered in technical terms: the tech lead is the person who knows the system best, makes design decisions, reviews code, and keeps projects moving.

Today, as a tech lead herself, she says this:

That is not wrong. It is about 40% of the picture. The other 60% is harder to explain.

It is turning ambiguity into structure before engineers hit it at full speed. It is noticing when a meeting is about to produce a decision that sounds clear but is not.

It is reading a design doc and asking the uncomfortable question, the one that might mean more work, because it is better to ask it now. It is knowing when someone is stuck but will not say so unless you create the space.

At Adobe, her work spans technical direction, cross-functional coordination, and team support. She works with product managers, designers, engineers, and other teams.

She helps shape scope, surface trade-offs, and make sure teams are solving the right problems, not just the most visible ones.

She also spends a lot of time on what she calls the infrastructure of clarity: documentation, decision logs, onboarding guides, and thoughtful code reviews.

These might not be glamorous, but they’re where much of the real leverage lives. A well-written architecture decision record (ADR) can save a team from having to reconstruct context months later, when the original conversation is long forgotten.

The biggest shift in Agarwal’s thinking has been moving away from the idea that her value is measured by how much code she personally writes.

Early in her career, impact felt like output. More features, more commits, more visible progress. As she grew into leadership, she realized that real leverage comes from helping other people do excellent work.

If she makes the team better, faster, and clearer, the resulting impact outweighs anything she could build alone.

1. How Agarwal Succeeds In Her Role

What makes Agarwal most effective in her role, she says, isn’t technical skill. It’s being willing to slow down and say, at precisely the moments when social pressure says the team should just get started, “Wait, do we actually agree on what we are trying to do here?”

Building a culture where raising concerns is valued

Early in her leadership journey, Agarwal explains, she had a habit of absorbing ambiguity herself. She’d read between the lines of a brief, make a judgment call, and hope it was right. It often was.

But the cost of correcting problems late in the development process was always much higher than it would have been if the problem had surfaced earlier.

Now, she tries to externalize uncertainty quickly. If she doesn’t know something, she says so. If a goal feels not as clear, she calls it out, saying “I want to make sure we are all picturing the same outcome. Can we spend five minutes on that?”

Most of the time, it turns out they were not picturing the same thing at all. Agarwal also cares deeply about building a culture in which raising concerns early is genuinely valued, not just tolerated. There is a difference.

Tolerated means people can speak up but sense a slight friction when they do. Valued means the team treats early warnings as useful data, not as someone being difficult.

She shared a story that illustrates this point:

We were four days from shipping when Dan sent me a message: “Hey. I have been looking at the animation rendering on lower-end Android devices, and something feels off. I think it could get ugly under real usage. Should I dig in, or are we too close to the deadline?”

The feature had been in development for four months, and the team was in final bug-bash mode. Everyone had mentally moved on. Dan had been on the team for seven months, and while he was sharp and thorough, he sometimes hesitated to trust his instincts when the timeline was tight.

I told him to dig in. He was right to flag it. On midrange and lower-end Android devices, which represented a significant portion of our Adobe Express user base in the APAC region, the animation engine was queuing canvas repaints in a way that caused visible frame drops whenever a user interacted with an animated element mid-sequence.

It looked fine in our testing environment, on the MacBooks and flagship phones we all used. It would have looked broken to millions of people on day one.

We delayed the launch by two weeks. We fixed the compositing logic, added a device capability check, and built a graceful degradation path for lower-end hardware. The PM was frustrated for about two days. Then she saw the user feedback from the actual launch: clean, fast, no reports of jank. Delaying, she said, had been the right call.

But the part I keep coming back to is this: Dan almost did not say anything.

He had the technical instinct. He had found the real problem. What he was unsure about was whether it was safe to raise it, whether the timing made his concern unwelcome, and whether he would be seen as slowing the team down rather than protecting it.

That gap between knowing something and feeling safe enough to say it is one of the most expensive gaps in engineering. My job, in that moment and in every moment like it, is to close it.

This story, Agarwal says, is the one she comes back to most often:

Not because we caught a bug. Because he felt safe enough to raise it when it mattered. That did not happen by accident. It happened because of a hundred smaller moments before it, where I had made it clear that speaking up was welcomed, not just permitted.

Building a psychologically safe environment

There is a large body of research on psychological safety, the idea that teams perform best when people believe they will not be punished or humiliated for speaking up.

Google’s Project Aristotle, which studied over 180 teams, found that this was the single most important factor in team effectiveness, more than talent, structure, or resources.

Agarwal has seen this play out enough times that she no longer thinks of psychological safety as a soft idea. She sees it as a performance input.

Building a psychologically safe environment requires consistency from the tech lead, who must respond to candor with curiosity, not defensiveness, enough times and clearly enough that it becomes the team’s default assumption about how they operate.

Agarwal shares an example of modeling this:

We were in the final stretch of a project when a junior engineer (I’ll call him Rajan) came to me after standup and said, almost apologetically, “I don’t want to slow us down, but I think there might be a data consistency issue in how we’re handling concurrent edits.”

He had been sitting on it for two days, unsure whether to raise it.

He was right. It was real. If it had reached production, we would have been scrambling in a way that would have been far more disruptive than the half-day we spent addressing it then.

I made a point of saying to the whole team in our next sync, “Rajan caught something important by speaking up. That is exactly what we want.” Not a big ceremony, just naming it clearly so the team could feel it was real.

That kind of small moment shapes culture more durably than any process or framework. When a leader actively names and appreciates someone for raising a hard thing, it sends a signal that the whole team absorbs: speaking up is what you actually want.

2. How She Multiplies Others

The word multiplier clicked for Agarwal when she understood its opposite: a tech lead who is the answerer of every question, the approver of every decision, and the person the team waits on before moving.

She has seen that pattern and admits that she’s probably been that person at some moments. “A multiplier,” she explains, “is not the person everyone depends on. A multiplier is the reason the team does not need to depend on any one person at all.”

The damage that comes from feeling psychologically unsafe is quiet but real: people stop developing judgment because they don’t need it. They stop feeling ownership because they don’t really have it.

Truly multiplying your team means increasing their capability without increasing their dependence on a tech lead. According to Agarwal, the levers she uses most are clarity, documentation, and deliberate restraint.

Creating clarity

“Clarity first,” Agarwal declares. When people understand the objective, the constraints, and what “good” looks like, they can make better local decisions without escalating.

That creates velocity, but more importantly, it creates ownership. People grow when they are trusted to think, not just told what to do.

Documenting everything that’s important

Agarwal considers documentation one of the most consistent (and widely underrated) multipliers in engineering. She thinks of it as “paying forward context.”

Creating documentation isn’t just a bureaucratic obligation but part of the engineering system itself. If something is important enough to keep explaining in Slack, it’s important enough to write down.

Each person who finds what they need in her documentation is someone who isn’t blocked while waiting for her to answer a question.

Exercising deliberate restraint

One of the most rewarding things Agarwal ever did as a tech lead, she says, was watch one of her reports step up to a level of ownership that they didn’t think they were ready for.

This engineer was “technically strong but consistently deferred in design discussions.” She waited to see what others thought before speaking. When I asked her about this pattern, she said this:

She didn’t think her opinion carried as much weight as the senior engineers’. So I started asking her first in technical discussions, before the more vocal people had set the tone.

Within two months, she was leading the design review for a key component entirely on her own: clear, confident, with strong opinions she could defend. That felt like a real impact. Not something I built, but something I helped unlock.

“Deliberate restraint is the hardest lever,” she adds:

When you know a system well, it is genuinely tempting to answer every question or solve every problem yourself. It is faster in the moment. But if I do that too consistently, I am building a team that cannot navigate without me.

Sometimes, the most useful thing I can do is ask a question back, give a nudge, and let someone else own the thinking. The goal is to make myself progressively less necessary.

3. How She Builds a Thriving Team

There’s a big difference between a performing team and a thriving team. A performing team hits goals. A thriving team hits goals, develops its people, surfaces problems early, and doesn’t crater when something goes wrong. The foundation of a thriving team is genuine trust.

Being on the lookout for the politeness trap

Agarwal says she’s learned to watch for what she calls the politeness trap: a situation in which a team is technically aligned but nobody voices their reservations.

Everything sounds smooth in meetings. The real concerns live in one-on-ones or in direct messages between engineers after the call ends. When that happens, it usually means they feel unsafe disagreeing in public. She counteracts it by modeling uncertainty herself:

I say, “I do not know” when I don’t know. I say, “I changed my mind” when I change my mind. I say, “I got this wrong, here is what I would do differently.” Not performatively, just as part of how I communicate.

The signal it sends is: you do not have to be certain to speak. You do not have to be right to contribute.

Being transparent

Another way Agarwal builds trust is by being transparent about what’s possible. She describes a project where the timeline and scope were not compatible, not dramatically, nobody was panicking, but the math just did not add up.

The project was going to be late, or the team was going to ship something rushed, or she was going to put the team through a bruising sprint for a medium-priority feature. So here’s how she responded:

I took it to the PM and said, “I want to show you what we can deliver by the deadline versus what we can deliver well. Right now, those are not the same thing. Can we decide which matters more?” It felt uncomfortable.

Nobody wants to be the person raising a flag. But we cut two features that, in retrospect, were not as critical as they had seemed in the planning doc. The team shipped the core experience cleanly. Nobody burned out. The cut features were picked up in the next cycle.

Avoiding heroics

She also cites a piece of internal Adobe engineering guidance:

Heroic behavior is tempting because it is visible, and it comes from a genuine desire to own the outcome. But a team that depends on heroics to ship is a team whose planning is broken.

I would rather build a boringly reliable team than one that runs in rescue mode. When the same people are always staying up late to save a release, that is not a sign of dedication. It is a signal that something upstream needs to change

4. How She Leverages AI

Agarwal says that while AI hasn’t fundamentally changed the role of tech leads, it has placed more of a premium on clarity, alignment, and judgment.

When the incremental cost of producing code approaches zero, the question shifts from “Can we build this?” to “Are we building the right thing, the right way, for the right reasons?” That’s a leadership question. That’s a clarity question. That’s a documentation question. These questions were always important; now, they’re critical.

Exercising good judgment and being deliberate

Agarwal quotes Kent Beck, one of the pioneers of extreme programming, describing the moment when he encountered generative AI for the first time.

In a blog post titled “90% of My Skills Are Now Worth $0”, Beck wrote that while 90% of what he’d spent his career learning had suddenly become less relevant, “The leverage for the remaining 10% went up 1000x. I need to recalibrate.”

That 10%, he explained, is about judgment: understanding the system, reading the trade-offs, knowing when something works technically but not organizationally, and sensing when a plan is sound on paper but wrong in practice.

AI is most dangerous, Agarwal says, when it creates the illusion of progress. A model will produce code confidently, and the code will often run. But code is written for humans to read as much as for machines to execute.

AI-generated code that nobody on the team truly understands is not an asset; it’s debt with a faster accumulation schedule. The antidote, she says, is being deliberate:

Design before code. Tests alongside code. Review with the same rigor whether the author is a human or a model. And keep asking: “Does the team understand what we’ve built and why we built it that way?” If the answer is no, you have outsourced something you shouldn’t have.

Writing the first draft, not the final draft

Agarwal advises her team to use AI as a way to lower the cost of the right behaviors rather than a way of skipping them.

• Want to write documentation? AI can produce a solid first draft in ten minutes.

• Want to write tests? AI handles the repetitive parts well.

• Want to explore an architectural alternative before committing? A short conversation with a model can surface edge cases that would have taken days to discover otherwise.

“That is the multiplier effect I am after: more time on thinking, less time on typing,” she says.

“AI raises my floor,” Agarwal says. “It makes the average quality of my work more consistent. But the ceiling, the work that is trusted, differentiated, and irreplaceable, still requires a person who has context, relationships, and taste.”

She says AI has changed her work the most in terms of drafting written documents:

I used to be slow on first drafts, not because I did not know what to say but because the gap between messy thinking and usable text takes real effort to cross. AI closes that gap.

I can share a rough outline or a brain-dump and get a working first draft back. Then I edit, which is much faster than creating from scratch.

I also use it to think through alternatives. When I am evaluating an architectural decision, I might ask AI to enumerate failure modes, edge cases, or angles I have not considered. It is like having a tireless brainstorming partner.

The output still needs my judgment to filter; a lot of it is obvious or not applicable, but it consistently surfaces one or two things worth sitting with.

She notes that tech lead work requires a great deal of context switching: “In a single hour, I might move from a technical review to a planning discussion to a teammate’s question to a cross-functional conversation.” AI, she says, helps her clarify her thinking quickly and move on. But she protects “the relational and judgment-heavy work.” She explains it this way:

[AI] cannot tell me that a technically correct plan is organizationally risky because of the history between the two teams. It cannot sense that someone is frustrated but covers it well.

It cannot decide which trade-off is worth making, given what actually matters this quarter. Those are human responsibilities. And as AI makes the output parts of the job faster, the judgment parts matter even more.

5. Her Advice For Engineers

Here are Agarwal’s tips for thriving in the AI era.

• Use AI to expand your leverage, but protect your judgment

Let it draft, summarize, and explore. Use it to learn faster, write better, and help you move into unfamiliar domains with more confidence. But keep your stand

ards high, your communication honest, and your thinking genuinely your own.

The engineers who will thrive in the AI era are the ones who combine technical fluency with taste, who know when generated output is wrong even when it looks right.

• Resist the pull of zero-shot building for production work

The dopamine hit of going from prompt to running app is real and addictive. But anything you are going to maintain, evolve, and stand behind requires the boring discipline: design before code, tests alongside code, and review that actually engages with what has been built.

The fundamentals do not disappear because generation has gotten easier. They become more important because the cost of skipping them has gotten harder to see.

• Invest in the infrastructure of trust

Documentation. Realistic planning. Honest onboarding. A culture where people surface problems early rather than absorbing them silently. These are not soft investments. They are the foundation that determines whether technical work can actually succeed.

• Reward teams for building well, not for rescuing things at the last minute

If your team’s heroes are always the ones staying up late, ask what the system is doing that keeps requiring rescue. Heroism that becomes routine is a planning problem in disguise.

• Don’t make the team move faster, but better

Speed without clarity is just faster confusion. Use AI where it genuinely reduces friction on the right behaviors. Do not let it become a way to skip the conversations that create alignment.

• Double down on engineering

If you care about the craft, about building systems that are well-designed, well understood, and built to last, then this is the best time to be doing it. The parts of the job that are being automated are the parts that were always the least interesting. The parts that remain are the parts that were always the most important.

Final thoughts

Agarwal says that while she used to measure her success by what she built, she now measures it by what the team becomes:

Did the people around me get stronger? Did they ship work they are proud of? Did they feel safe enough to raise the hard issue before it became the hard incident? Did they grow into ownership they did not have before?

Agarwal thinks of the engineers she works with not as resources to direct but as people who make the actual work happen. “My job,” she says, “is to make that work possible: clearer, safer, and more impactful than it would be without me in the room.”

Last words

Special thanks the Navya for sharing all these insights with us! If you haven’t yet, make sure to check out the book The Multiplier Mindset, where you can find more case studies similar to this one.

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”, 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.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

Kindle and print-version of the book available for purchase:

North America

• 🇺🇸 United States: Paperback (November 17) | Kindle

• 🇨🇦 Canada: Paperback (November 17) | Kindle

• 🇲🇽 Mexico: Paperback | Kindle

Europe

• 🇬🇧 United Kingdom: Paperback | Kindle

• 🇩🇪 Germany: Paperback

• 🇫🇷 France: Paperback | Kindle

• 🇮🇹 Italy: Paperback | Kindle

• 🇪🇸 Spain: Paperback | Kindle

• 🇳🇱 Netherlands: Paperback | Kindle

• 🇸🇪 Sweden: Paperback

• 🇵🇱 Poland: Paperback

• 🇧🇪 Belgium: Paperback

• 🇮🇪 Ireland: Paperback

Asia & Pacific

• 🇦🇺 Australia: Paperback | Kindle

• 🇮🇳 India: Paperback | Kindle

• 🇯🇵 Japan: Paperback | Kindle

• 🇸🇬 Singapore: Paperback

Middle East & Africa

• 🇦🇪 United Arab Emirates: Paperback

• 🇸🇦 Saudi Arabia: Paperback

• 🇹🇷 Turkey: Paperback

• 🇪🇬 Egypt: Paperback

• 🇿🇦 South Africa: Paperback

South America

• 🇧🇷 Brazil: Paperback (November 17) | Kindle

“The Multiplier Mindset” has been a #1 Bestseller now for close to 2 weeks!

With just the Kindle version available, the book has been a #1 New Release and/or #1 Bestseller for most of the past 2 weeks on Amazon across 3 categories! 🤯

And the good news is that the print version of the book is now available across most Amazon stores.

The only exceptions are Canada, Brazil, and the US/international Amazon store. The book will be released on November 17. But of course, you can pre-order it!

I am blown away by the interest and how many copies have already been sold and pre-ordered, this is really awesome.

Thank you so much for the incredible support 🙏

It’s been an incredible journey bringing this book to life, and seeing it finally out in the world makes all the hard work worth it. I hope you find it as valuable to read as I found it rewarding to write!

Early Reviews of the Book

There are already a lot of early reviews of the book. And I am honored to get such great feedback. Here is one by Peter Bell, Founder/CTO of Gather.dev, author of Scaling AI Adoption in Engineering:

This was exactly my intention with the book, to get as close as possible to what senior(+) engineers should be doing now that agents can write most of the code.

I went into detail about different ways you can multiply your effort, and there’s even one whole chapter that’s about how to use AI to be a successful multiplier.

More early reviews:

Thank you so much for the incredible support! 🙏

Gregor

This newsletter is sponsored by Verity.

Verity: a pair programmer for your coding agents

Verity sits inside your agent's reasoning loop, guides its behavior on every turn, and stops future sessions from repeating past mistakes.

It runs AI review, SAST, formal proofs and runtime analysis before the code reaches Git, catches race conditions, intent gaps, logic errors and security vulns, and hands the fix back to the agent. Every decision lands in a knowledge base that new sessions build on, so you can stop maintaining instruction files across repos.

• Catches 2.3x more real bugs than PR review assistants

• Review runs on Verity’s side, without using your agent’s token budget

• Free while in beta. Paid plans launch in November, with 20% off the first year for everyone who signs up by October 31

Try Verity today

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

Intro

Being able to successfully manage up may not seem too important at first glance, but it can make your day-to-day work more productive and easier for you and your whole team or department.

Managing up isn’t about pleasing your manager or agreeing with everything they say. It’s about building trust, communicating effectively, and creating a working relationship where both you and your manager can succeed.

I’ve learned the importance of managing up through my own experiences, both as a freelancer and in full-time roles, and I’ve made a lot of mistakes along the way.

In this article, I’ll share three mistakes I’ve made that you should avoid and walk you through my five-step framework for successfully managing up.

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

- Know what managing up is and what isn’t
- Don’t make the three mistakes I’ve made
- Mistake 1: Going over my manager’s head
- Mistake 2: Trying to change my manager
- Mistake 3: Keeping my problems to myself
🔒 Follow my five-step framework for managing up
🔒 Step 1: Build your credibility
🔒 Step 2: Build a good relationship with your manager
🔒 Step 3: Focus on great communication
🔒 Step 4: Find out what problems your manager is facing and do what you can to resolve them
🔒 Step 5: Always keep your manager in the loop
🔒 Last words

Let’s start!

“The Multiplier Mindset” published by O’Reilly is now available!

This article is an adapted version of one of the chapters of my book called “The Multiplier Mindset”. The e-book (Kindle) is available for purchase. The print version is available for pre-order!

Learn more about the book

What managing up is and what isn’t

The idea of “managing up” has been discussed in management literature for decades. It was popularized for a broad audience by Rosanne Badowski in Managing Up: How to Forge an Effective Relationship with Those Above You, which draws on Badowski’s experience as executive assistant to the infamous CEO Jack Welch at General Electric.

Managing up is often misinterpreted, so I’ll clarify what it is and isn’t.

Managing up is:

• Efficiently communicating and collaborating with your manager

• Proactively finding out the problems your manager is facing and making an effort to resolve them

• Being transparent, giving feedback, and asking for help when you need it

Managing up isn’t:

• Going over your manager’s head to try to achieve your goals

• Trying to change your manager

• Keeping your problems to yourself to avoid pressuring your manager

When you manage up correctly, you’ll improve your work experience and your growth in general.

Don’t make the three mistakes I’ve made

Before I show you my five-step framework for managing up, let me share some mistakes I’ve made in this area. It can be uncomfortable sharing mistakes, but I hope that by sharing mine, I will help you avoid making them yourself.

My own mistakes fall into the three previously mentioned categories of what managing up isn’t.

Mistake 1: Going over my manager’s head

As a new manager, I was passionate about making changes for the better, even when those changes weren’t under my control. I talked with my manager a couple of times about changes I wanted to make, but nothing happened and I felt unheard.

I thought the best action would be to involve other people whose jobs would be affected by these changes. So I emailed them all, explaining the issues and outlining potential solutions, and I copied my manager’s manager. My manager wasn’t too happy that I’d gone over his head.

Looking back, while my manager could have done more to make sure I was heard, I shouldn’t have gone above his head to try to achieve my goals. Doing that negatively affected our working relationship, which was crucial to everything else.

Lesson learned: you can control what you can control, and not all changes can happen instantly. Patience is the key here.

Mistake 2: Trying to change my manager

When my manager decided to move on, I got a new manager: a recent hire whose working style was very different. My previous manager had always included me in decisions, but the new manager didn’t.

After onboarding, he made some decisions I didn’t know about. I wasn’t used to that. I thought I could adjust his style to more like what I was used to, but it didn’t work out so well.

Lesson learned: it’s on both you and your manager to find a good way to collaborate, but don’t try to change your manager’s style. Be helpful, find out about their problems, and try to resolve them by focusing on what you can control.

Mistake 3: Keeping my problems to myself

As an engineer, I tried to solve everything myself; sharing my problems with my manager felt like the last thing I should do. I used my one-on-one meetings not to learn and grow my career but to give my manager status updates.

I was missing out on so many learning opportunities: I could have been talking about my career goals, working through promotion plans, or getting coaching and feedback on specific situations.

Lesson learned: keeping all your problems to yourself just causes stress and slows down your progress. Keep your manager in the loop and keep your one-on-one meetings career-oriented.

My five-step framework for managing up

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

Are leetcode-style tech interviews finally becoming a thing of the past?

I’ve been talking with different engineers, engineering leaders, hiring managers, and recruiters about how technical interviews are changing.

And in this article, I am sharing the insights from these conversations and what I’m personally seeing across different companies.

In particular, we will answer the question if leetcode is dead, what are the alternatives that are gaining the most traction, and what I personally recommend instead of leetcode-style interviews.

Let’s start!

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

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

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

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

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

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

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

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

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

This is what Sulman Choudhary, Head of Engineering, ChatGPT, OpenAI, mentioned when I spoke with him earlier this year.

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

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

I feel the same as Sulman, and I have never recommended leetcode-style type interviews (and also never personally advocated for them in my freelance and full-time roles), but surprisingly, there’s still a lot of companies using them.

I’ve talked to many people about this recently, and many share a similar sentiment.

But while many of them don’t like this type of tech interview, it seems they still very much exist across different companies. But I do see a decrease. Let’s go through that next.

Bigger companies are still doing leetcode-style tech interviews

Talking with different engineers, engineering leaders, hiring managers, and recruiters, the leetcode type tech interviews are still very much present in Big Tech and a lot of other bigger companies.

Companies like Google, Meta, Amazon, Apple, Uber, LinkedIn, etc. are still using this type of interview, especially for more backend-related roles.

And I get it; this type of interview is an objective measure, and when you’re dealing with so many engineers interviewing at the same time, it’s a way to objectively measure the results.

So, if you’re planning to interview at such a company, I highly suggest practicing such problems.

I do see some movement and “pilot” adjustments in order to be more reflective of the actual work that engineers do on a day-to-day basis. Google started an initiative called the “Code Comprehension round”.

According to Business Insider, especially for junior and mid-level roles, they have started using such an interview.

In this round, you receive a 200-500 line unfamiliar codebase, and you have 60 minutes to read it, find bugs, discuss design decisions, and suggest improvements, all while they allow you to use AI (Gemini).

There’s a much smaller chance of getting a leetcode-style tech interview at small-to-mid-size companies and AI labs

I know for quite some time now that both OpenAI and Anthropic are not big fans of this type of interview, and as you can see from the X post below, Felix Rieseberg, who is an Engineering Manager at Anthropic, even mentioned that he doesn’t see so much value in coding interviews altogether.

In his post Hunger beats tenure: Advice for junior engineers, he argues that projects beat any code written these days, which is especially relevant for junior engineers.

And the specific projects that have been built should be a much stronger signal than pure coding interviews.

Additionally, from talking with many other folks in small-to-mid-size companies, the leetcode type interview is an exception rather than the rule. Here are some alternatives I have seen or heard of.

3 most popular alternatives

• Code review exercise seems to be emerging as one of the strongest alternatives

A lot of people mentioned that this is the format that they prefer now. This is quite similar to the “Code Comprehension round” by Google, where you provide a piece of code to the candidate, which includes intentional bugs, performance issues, security concerns, or opportunities for improvement.

In this round, you are evaluating how well candidates understand unfamiliar code, identify potential problems, communicate feedback, and make trade-offs. It closely resembles the work engineers do every day → doing a code review.

• Product & Technical deep dive

This was mentioned by Sulman Choudhary, Head of Engineering, ChatGPT, OpenAI. It’s a combination of a System Design interview, together with product/business and AI understanding.

In this interview, candidates are given a problem that is mostly a problem related to AI. They are asked to think about the problem and how they would approach building a product around it. There is no prework required.

During the interview, the candidate and interviewers work through the problem together. They discuss what the product specification might look like and what kinds of systems and architectures would be needed to build it.

• Solving a real-world problem or doing pair programming (with AI usage allowed)

The candidate is given a practical engineering task. The goal is to evaluate how effectively they use AI, understand generated code, identify mistakes, write tests, and verify their solutions.

More on this in the upcoming sections.

My personal recommendations instead of leetcode

Option 1: Open-ended questions

This is my recommended type of a tech interview. This is where you are talking about a certain project, or a problem that is highly relevant to what the candidate would face on the job.

And the goal is to get a feeling how the candidate thinks and approaches problems. I definitely also recommend talking about how to use AI, when to use it, how to structure the prompts, and how to optimize them in such an interview.

Here are some questions:

• Tell me about the hardest problem you have solved?

• Tell me about the recent project you have worked on?

• How would you solve X? (where X is a highly relevant situation in the role they are interviewing)

Sub-questions like:

• What was your role on the project?

• How have you contributed to its success?

• What alternatives have you considered before implementing the solution?

• What trade-offs did you make?

• How did/would you use AI to help you deliver the project faster?

• How did you know the output was correct?

• How to optimize the output?

The key is to understand their judgment. How they approach solving problems, what alternatives they have thought of, whether they are a team player, and of course, how they have used AI or would use it to help them deliver the project faster.

And very importantly, you get a sense of how they communicate. Are they clear in how they are describing things, are they confident in their knowledge and understanding, or are they just blindly accepting the first solution that has been generated by AI.

Option 2

The second option is a pair-programming challenge.

I recommend giving a task that is closely related to what the candidate will be doing on a daily basis. That may be implementing a new backend service, a frontend functionality, or maybe a landing page for a new marketing campaign.

The key is to get as close as possible to what they would be doing on the job.

The candidate then shares the screen, and you work with them together, like doing a pair-programming session with a fellow engineer.

They can ask any questions they want, they can use any of the tools they would like, AI tools, IDEs, Google, Stack Overflow, etc.

The key to this challenge is not the end solution and how the code looks in the end, but how it feels working with them, and how good their judgment is in general.

Are they considering the trade-offs, are they thinking about alternatives, are the structuring prompts the right way, are they validating the output from AI tools, etc.

That tells me a lot more than the end solution.

Option 3

Another option can be a mix of both open-ended questions and a challenge, or you can also do 2 (or more) challenges, where one focuses more on solving the challenge that is highly relevant to the role without AI tools, and another challenge with AI tools.

And then you focus more on pure implementation in the first challenge, and in the second, you focus more on how they are using AI tools, whether they are validating the output, and whether they keep in mind good practices.

My recommendation is to use any of the variation/combination that you see best fit for your case. Every situation is different, and one interview type may not work for all different organizations.

What I don’t recommend

The take-home task is something that I believe to be less relevant these days, as basically anyone can generate the solution based on requirements and push it to a public repo on GitHub.

So, that gives less of a signal on how well they’d perform in the role. You can, of course, jump on a call with them and ask them for an explanation on certain parts, ask for alternatives, and why a certain decision was made.

But the reality is that with AI, you can already “prepare” quite well in advance for such questions, and a person could be lucky to get away with not really understanding what they have built.

Last words

Let’s end this article with the following:

Leetcode is not dead, but I believe the actual usage is declining and is used mostly in bigger companies, due to the high volume of applicants. I was never a fan of them, and I have always advocated for other options.

But the reality is that if you want to work at a bigger company, especially in Big Tech, there’s still a good chance you’ll need to prepare for them.

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 State of AI Impact in Engineering: Q3 Report

AI has sped up how fast code gets written, but not how fast it ships. DX’s Q3 report draws on data from 500+ organizations to show where delivery is slowing down and where AI spend is actually going.

What you’ll learn:

• Why pull requests from teams generating 80%+ AI code wait more than twice as long for a first review

• Where AI spend is going: it doubled in Q3, and 94% of tokens now go to re-reading context

• Where engineering leaders should focus so individual time savings actually reach production

Download the report from DX

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

Intro

As you grow in your career, there comes a time when your impact is no longer determined only by the quality of your work.

The more senior you become, the more your success depends on your ability to communicate, influence decisions, build trust, and help others succeed.

A lot of engineers feel that great work speaks for itself. In fact it rarely does.

The engineers and leaders who create the greatest impact aren’t just great at getting things done; they know how to align people around a vision, communicate progress clearly, manage expectations, gain trust, and inspire others to do their best work.

In this article, we’ll go through all about why great work often goes unnoticed and what may be holding you back from being considered impactful.

I’ll also share 5 practical ways to help you share your wins, build credibility, and make sure the right people understand your value, without feeling like you’re bragging or selling.

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

- Your Work Doesn’t Speak For Itself
- Help Others See The Great Work You Do
- The Hidden Roadblocks to Good Communication
🔒 How to Communicate Your Impact (5 Methods)
🔒 Last words

Let’s start!

“The Multiplier Mindset” published by O’Reilly is now available!

This article is an adapted version of one of the chapters of my book called “The Multiplier Mindset”. The e-book (Kindle) is available for purchase. The print version is available for pre-order and will be released on October 31st!

Learn more about the book

Your Work Doesn’t Speak For Itself

I’ve seen countless engineers doing great work but afraid to come across as if they are “bragging” or “selling.” But then, when it’s time to announce the next promotion, they get overlooked. Or worse, they might be part of the next layoffs.

Great managers will notice this and give feedback and direction on what to do, but not everyone has a great manager. So it’s really important that you take ownership and find ways to not only do great work but also make sure that everyone knows about it.

If you find yourself saying things like “My work speaks for itself,” there’s a good chance you haven’t been communicating your impact well. And it’s time to make some adjustments.

What I like to say:

You can do the best work in the world, but if you don’t manage people’s expectations correctly, they won’t perceive it that way.

In most cases, everyone does not already know that you’re doing good work. You need to actively tell them so.

You may object, “But, Gregor, this sounds like I need to brag or sell myself, that just isn’t me! I just like to be in the fine details, coding and making technical decisions.”

Let me tell you a very important thing: we are all selling ourselves, all the time, both personally and professionally. But you don’t have to think of it as selling or bragging! I see it as being clear and ensuring that my work is perceived the right way.

Help Others See The Great Work You Do

In the best-case scenario, your manager will see perhaps 40% of all the work that you do on a daily basis. You need to let them know about the rest, including all the wins you achieve.

The only way to improve this situation is to take full accountability. Ask yourself, “What can I do to learn from this and make sure I improve my situation?”

Of course, there are managers who don’t do their jobs well and make their direct reports’ lives a lot harder. But you can’t control that.

It’s easy to blame others, especially your manager, for not seeing all your hard work, because that lets you off the hook and gives you permission to think there’s nothing you can do. I think that’s a totally wrong way to look at it.

There are many things that you can do to make sure that everyone around you (including your manager) understands what a great job you’re doing. Neglecting this puts you in a bad light.

Ask yourself the following questions:

• How can I share my wins in a better way and make sure everyone understands them? (We’ll go through how to keep a brag list” in the last section).

• How can I collaborate better with my manager and build a good working relationship?

• Have I fully understood my manager’s feedback?

• How can I improve my credibility, inside and outside the organization?

The Hidden Roadblocks to Good Communication

Now, let’s look at some other, less often discussed side effects of not actively communicating your impact:

Burnout

First, there’s burnout. I’ve found that hard work alone does not burn me out. What does burn me out is doing something for a long time that doesn’t fit my goals or my expectations for myself.

That’s why not knowing my next step after becoming a senior software engineer really demotivated me.

I believe the biggest reason people burn out is that they don’t see the necessary outcomes or receive the recognition they deserve.

When you put a lot of effort into something that you come to see as a total waste of time, that’s when you risk burning out.

Marginalization

I’ve also noticed that engineers I’ve worked with and managed who are from marginalized groups (particularly women, but often people from ethnic or religious minority groups, and others who often deal with prejudice) have had trouble communicating their impact.

They’ve been some of the best engineers I’ve worked with and crucial to the success of the projects, but in many cases, if I hadn’t been heavily involved, seen all the great work they were doing, and recognized them publicly for it, their work would have gone unnoticed.

Manager disinterest

When great work goes unnoticed, it’s often because the person’s manager isn’t very involved and the person doesn’t personally communicate their impact the right way.

You can’t control how involved your manager is; you can only control doing great work and that you are communicating the right way. We’ll go through how to do that, next.

How to Communicate Your Impact (5 Methods)

Read more

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

Last Friday, I announced the release of the e-book (Kindle) version and opened pre-orders for the print edition.

Just a few days later, the book has already become a #1 New Release and #1 Bestseller on Amazon across 3 categories! 🤯

And the physical version hasn't even been released yet! That's coming on October 31st.

I am blown away by the interest and how many copies have already been sold and pre-ordered, this is really awesome! Thank you so much for the incredible support! 🙏 I didn’t expect this at all.

I've spent almost a year writing this book, and seeing this kind of response makes all those hours totally worth it.

It's a surreal feeling to see something you've worked on for so long finally out in the world.

Early Reviews of the Book

There are already a lot of early reviews of the book. And I am honored to get such great feedback. Here is one by Peter Bell, Founder/CTO of Gather.dev, author of Scaling AI Adoption in Engineering:

This was exactly my intention with the book, to get as close as possible to what senior(+) engineers should be doing now that agents can write most of the code.

I went into detail about different ways you can multiply your effort, and there’s even one whole chapter that’s about how to use AI to be a successful multiplier.

More early reviews:

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

Thank you so much for the incredible support! 🙏

Gregor

This newsletter is sponsored by Atono.

AI is definitely making engineers ship faster than ever. But AI-generated specs keep coming back with questions. And the problem is the missing product context, understanding in detail, how the product should actually work.

In this recorded webinar from Product School’s AI Builder Week, Doug, CPO at Atono, shows how important giving AI real product context is.

In the webinar, you’ll learn:

• Why your AI keeps guessing and how product context fixes it

• How to ground AI in your actual product decisions and architecture

• When your spec is actually ready to hand off to engineering

Get the recording

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

Intro

A lot of engineering professionals may think that writing (generating) code is the best use case for AI. But some of the biggest opportunities are actually outside of coding. Preferably, even before the coding starts.

And especially as an engineering leader, the more you grow in your career, the more of your impact comes from making better decisions, communicating effectively, helping others grow, and removing bottlenecks.

And AI can help you with all of these things.

In this article, I’ll share 5 practical ways you can use AI beyond coding to become a more effective engineer and engineering leader, with examples you can start applying right away.

Let’s start!

My book “The Multiplier Mindset” has just became a Bestseller! 🥳 🎉

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

I announced the e-book (Kindle) version and pre-orders on Friday, last week, and the book is already a #1 New Release and Bestseller on Amazon in 3 categories 🤯

And the print version of the book hasn’t even been released yet, it will be on October 31st!

I am overwhelmed by the interest and how many copies have already been sold and pre-ordered, thank you SO much! 🙏

Learn more about the book

Communicate More Effectively

A lot of engineering is about communicating and aligning with others: colleagues, stakeholders, the PM, and your manager. You can use AI to perform the following communication tasks by writing prompts like the ones in the examples.

Drafting design documents

You may know about the blank page syndrome, and the gist is that it’s always easier to start with something already, instead of staring at an empty Google docs, Notion, or any other page.

And if you and your team have been discussing about a certain feature, it’s much easier to feed the context of the conversation to AI and create the design document that way, instead of starting from scratch!

You can use this prompt:

Turn these notes into a design document. 
Include the problem,proposed solution, alternatives considered, trade-offs, risks, 
and open questions. 
Create diagrams where appropriate.

Improving technical specs

What I like to say: What seems clear to you may not be clear to others. AI can help you find your blind spots, edge cases that you are missing, or any incorrect or missing assumptions. Always remember the following:

The most expensive change is the one you realize you need after the code has already been written (generated).

You can use this prompt:

Review this spec for anything that is unclear, ambiguous, or missing. 
Pay particular attention to assumptions and edge cases.

Summarizing long documents

The more you grow in your career, the more projects you’ll be involved in, and it’s impossible to understand (or go over) every single detail, so you need ways to make your life easier. And using AI to summarize longer documents is a great way to do it.

You can use this prompt:

Summarize this document for an engineering leader. 
Give me the key decisions, risks, open questions, and anything that requires my attention.

Preparing for important meetings

Whether you’re preparing for an architecture discussion meeting or getting buy-in from the stakeholders on a new initiative, AI can help you gather your thoughts, provide discussion points, questions, and overall key points to cover.

You can use this prompt:

Based on this context, help me prepare for the meeting. 
Identify the key points I should cover, questions I should ask, decisions we need to make,
and potential areas of disagreement.

Adapting your communications for nontechnical audiences

Adjusting your communication based on who the target audience is crucial and can be the difference between successfully getting buy-in on a new project or not.

I always suggest “reading the room”, which means understanding what motivations and problems the stakeholders are dealing with, and focusing on explaining things in a way that would resonate with them.

You can use this prompt:

Rewrite this explanation for a product and business audience. 
Remove unnecessary technical details but keep the impact, tradeoffs, and risks clear.

These are some examples of how you can use AI to communicate more effectively.

The important part is that AI helps you communicate your own thinking; it shouldn’t do the thinking for you. You still need to decide what matters, what you want to communicate, and whether the final message accurately represents your view.

Find Relevant Internal Information Quickly

A lot of engineering work involves simply finding information. Manually searching Slack, Jira, GitHub, and Notion (or whatever your organization uses) can take a long time.

I’ve seen different companies address this issue by having a shared knowledge repository that brings together information from various sources. This repository normally lives on GitHub or GitLab, and it’s version-controlled.

This doesn’t necessarily mean you need to copy everything into one place. You can also connect your existing tools and continuously index through the sources of these tools.

The goal is to give AI one place to search across your organization’s knowledge, so that you don’t have to open five different search tools. Once you have all the knowledge in one place, you can use prompts like these to get the information you need:

Why did we decide to use PostgreSQL for this service? Find the relevant
discussions, design documents, and pull requests, and summarize the
reasoning.

What did we decide about the authentication migration in last month's
meetings, and who owns the follow-up actions?

Having a shared knowledge repository is very useful in situations like these, as such information often gets scattered across different tools and nobody really knows how to find it when they need it.

Using AI to search a shared repository can save a lot of time, especially if you are part of a larger organization where many different things can happen at the same time and it’s impossible to be on top of everything.

Here are (quoted) words from Anton Zaides, who is an Engineering Manager at Honeybook, on such a repo being extremely useful to him:

Meeting transcripts automatically sync into the repo. The repo connects to Slack and can summarize discussions. There are markdown files organized by topic that automatically sync to Notion as we work on them. The repo becomes a living, queryable record of the project, not just our decisions but our thinking.

When I want to get up to speed on a specific part of the project, I just talk to Claude. I can ask what specific people think about a given decision, and I’ll get an accurate answer grounded in the Slack threads and meeting transcripts.

Instead of scheduling 10 conversations to understand where 10 people stand, I can ask one tool to figure it out for me in minutes.

Coach and Lead Your Team

AI can help you be a better coach and mentor to your team, but make sure that you use it in the right way.

It shouldn’t replace your judgment, which means that you still need to understand your people, build trust, and make the final decisions yourself. Let’s go through some examples next.

AI can act as a thinking partner when you’re dealing with challenging situations. You can use it to role-play difficult conversations, explore different approaches to giving feedback, or brainstorm ways to help overcome certain challenges that your people are facing.

The more you grow in your career, the more you need to focus on making everyone around you better, and that takes a lot of preparation. AI can help you prepare for one-on-one meetings by generating discussion points and action items, reviewing promotion packets, and even help you prepare for performance reviews.

But at the same time, its really important to understand that AI should help you become a better leader, not replace your judgment.

Additionally, be very careful about using AI note-taking tools during one-on-ones. In most cases, I recommend avoiding recording or transcribing these conversations altogether.

One-on-ones should feel like a safe, private space where people can open up about wins, struggles, concerns and frustrations.

Even if you ask for permission, a direct report may not feel fully comfortable saying no to their manager. Knowing that everything is being transcribed can also make people a LOT less willing to share what they really think.

A safer approach to write down your own notes and use AI to help organize or summarize them without creating a full transcript of what was said.

Make Better, More Data-Driven Decisions

During my recent visit to the OpenAI offices in San Francisco, I talked to engineers and engineering leaders. I asked them, “What do your dashboards look like, and what tools are you using?”

Interestingly, they said that while they do use some external tools, they mostly use their internal data agent to help everyone in the company make data-driven decisions.

Anyone inside OpenAI can ask data-related questions and get the insights they need to make data-driven decisions.

They don’t need to go to the data engineers and ask them to generate another dashboard; they can simply ask the data agent.

Some use cases include the following:

• Reviewing metrics

• Identifying bottlenecks and specific issues

• Analyzing user behavior

• Creating dashboards

• Evaluating trade-offs

That's a really great use case to help everyone inside the company make better, data-driven decisions (including yourself).

Automate Repetitive Work

Try to automate anything that doesn’t require human judgment. Every hour you save on repetitive work is an hour you can invest in higher-leverage activities, like mentoring your team or solving problems.

For example, many companies automate part of incident reporting, with AI collecting information about incidents from alerts, logs, Slack discussions, deployment histories, and recent commits.

This would take an engineer hours to gather. An AI agent does a good job (in my experience) of reconstructing timelines, summarizing what happened, and identifying possible root causes, as long as it’s given access to all the relevant data.

The engineer can then review the agent’s draft, make adjustments, determine the root cause, evaluate the team’s response, and possibly decide on specific changes to the system and processes.

This is just one example. Other highly valuable tasks you can automate include the following:

• Turning incident report action items into Jira/Linear tasks

• Setting up automatic proposed updates of your libraries in your repositories (after you have implemented any relevant changes to the code)

• Setting up reminder emails, alerts, or Slack notifications for specific purposes

• Running code formatting, linting, and other routine checks

• Automating any manual filling out of forms

• Updating tickets with progress from commits and pull requests

• Making recurring status updates from completed work

• Keeping documentation or changelogs updated after releases

• Collecting information from several systems and putting it into a standard report

There are many more ways AI can help you automate repetitive work, and you just need to investigate and determine where such work creates bottlenecks so you can find better solutions.

Last words

Let’s end this article with the following:

Always keep in mind that AI is like any other tool, it’s just more powerful. It can help you generate ideas, code, or give feedback, but you’re still responsible for deciding what’s correct and what really matters.

LLMs and overall tooling for AI will keep getting better, but the goal will always stay the same. To create more value for your team, your organization, and the customers.

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.

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

“The Multiplier Mindset” hit the #1 New Release in Computer Engineering on Amazon

I was casually checking Amazon’s book page yesterday evening, and couldn’t believe that the book hit the #1 New Release in the Computer Engineering category.

I was so thrilled I needed to let know everyone in the community chat asap :)

I notified everyone earlier in the day that the e-book (Kindle) and pre-orders are now available, posted a LI post, X post, and also sent out the newsletter.

I knew it would take time for everyone to process and decide whether they’d like to buy or not, especially since the physical book is currently in production, available for pre-order, and will be sent out in about 3 weeks.

So zero expectations of something like that happening.

But yeah, it’s interesting how life can surprise you. And on top of that, another great surprise!

“The Multiplier Mindset” is also the #2 Bestseller in Computer Engineering on Amazon

While checking the New Releases page, there’s also a link to Bestsellers in the same category, and surprisingly, we also hit the #2 Bestseller in Computer Engineering, right behind the infamous AI Engineering by Chip Huyen 🤯

Which is really amazing. We just launched the Kindle version yesterday, and it’s really awesome to see that so many people are interested in it!

Early Reviews of the Book

There are already a lot of early reviews of the book. And I am honored to get such great feedback. Here is one by Peter Bell, Founder/CTO of Gather.dev, author of Scaling AI Adoption in Engineering:

This was exactly my intention with the book, to get as close as possible to what senior(+) engineers should be doing now that agents can write most of the code.

I went into detail about different ways you can multiply your effort, and there’s even one whole chapter that’s about how to use AI to be a successful multiplier.

More early reviews:

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

Wishing you a great weekend!

Gregor

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

After close to a year of extensive writing the book, I am happy to share that we have now come to the finish line!

The book is currently in production, and the paperback version will be available in about 3 weeks! You can already pre-order it on Amazon.

The main premise of the book:

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

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

And engineers with the biggest impact have the multiplier mindset.

In the book, I cover:

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

• Important traits and skills to develop

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

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

Early Reviews of the Book

There are already a lot of early reviews of the book! And I am honored to get such great feedback. Here is one by Peter Bell, Founder/CTO of Gather.dev, author of Scaling AI Adoption in Engineering:

This was exactly my intention with the book, to get as close as possible to what senior(+) engineers should be doing now that agents can write most of the code.

I went into detail about different ways you can multiply your effort, and there’s even one whole chapter that’s about how to use AI to be a successful multiplier.

More early reviews:

Kindle version and pre-order on Amazon available here: Kindle and Pre-order.

E-book available for purchase here: E-book.

Read it online on O’Reilly’s website: Read it online.

Wishing you a great Friday and an upcoming weekend!

Gregor

This newsletter is sponsored by LlamaIndex.

Your engineers weren’t hired to parse PDFs

Every few quarters someone proposes building document parsing in-house. It scopes like a sprint. Five years on and it’s roughly $1.6M more than buying, and an engineer still owns maintaining the pipeline.

KPMG, Sandisk, and Lovable run their documents through LlamaParse by LlamaIndex instead, handling messy tables, charts, scans and handwriting, on one API.

Use code SUMMERGIFT26 for $250 in credits on signup. You can try it yourself and point it at the documents that are currently costing you engineering hours. Closes October 30.

Try LlamaParse for free

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

Intro

With AI-assisted engineering becoming the standard way of building software, the speed of writing (generating) code has significantly increased.

But faster code generation doesn’t necessarily mean better software.

What I like to say: You can generate thousands of lines of code in a matter of minutes, but if the requirements are unclear and the architecture is bad, you’ll spend more time fixing and rewriting code than you saved generating.

That’s why spec-driven development (SDD) can help a lot with this. You spend more time thinking about what needs to be built and how it should work, and almost no time fixing issues.

In this article, I’ll share 2 practical approaches to SDD: a simple workflow used by Michael Bolin, a tech lead on OpenAI’s Codex repository, and a more structured 7-step process used by the engineering team at Larridin.

You’ll also learn when SDD makes sense and when it’s better to keep things simple.

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

- Most of the code these days is AI-generated
- Option 1: Use a simple workflow
- Option 2: Use a detailed process
- Step 1: Start with a spike
- Step 2: Promote the spike to a reference implementation
- Step 3: Write the spec
🔒 Step 4: Write and refine the test plan before the implementation plan
🔒 Step 5: Create the implementation plan
🔒 Step 6: Implement
🔒 Step 7: Verify the implementation
🔒 When to Use SDD (and When Not To)
🔒 Last words

Let’s start!

E-book and pre-order of “The Multiplier Mindset” published by O’Reilly now available!

This article is an adapted version of one of the chapters of my book called “The Multiplier Mindset”. E-book or pre-order now available. Paperback version coming out in 3 weeks!

Learn more about the book

Most of the code these days is AI-generated

Based on my conversation with Katelyn Lesse, Head of Platform Engineering at Anthropic, engineers at Anthropic have begun using LLMs to generate 100% of their code.

Instead of adjusting the generated code themselves, they provide feedback and guide the LLM to the correct solution. That is considered an effective use of AI for creating code.

And that’s also a reality (or close to) in many other companies. Additionally, many of the engineers spend a lot more time creating the spec, instead of writing or generating code just based on pure prompts.

That’s what we call: Spec-driven development. Which is a way of building software where you focus on building a good specification first, and then use AI to implement the project.

Now, let me share 2 options for doing spec-driven development, a simple one and a more structured process, next.

Option 1: Use a simple workflow

Michael Bolin, a tech lead for OpenAI’s Codex open source repo, has a very simple workflow:

1. Write an initial tech spec in Notion, describing the requirements and functionalities that the code must support.

2. Ask colleagues to review and comment on the draft.

3. Use a simple prompt to tell the LLM tool to build code from the spec.

4. Review the code and make appropriate adjustments.

Michael’s workflow is a great example of a simplistic and effective use of spec-driven development. This works particularly well for smaller, less complex projects where the risks are relatively low.

It’s also important to mention that as AI coding tools use more and more tokens, you need to be mindful of the cost, as most of us don’t work with unlimited tokens.

With a great spec, you can usually get good output even if you use a lower-tier model, because a great spec is one that provides very clear instructions. Many companies use a higher-tier LLM to write the spec and a lower-tier LLM to build it.

Option 2: Use a detailed process

Earlier this year, I visited several companies in San Francisco, including Larridin, which is building an enterprise intelligence platform. The engineering team and CTO Ameya Kanitkar shared a 7-step process that they use when practicing SDD, and I’ll summarize it in this section.

Step 1: Start with a spike

It’s impossible to write a complete spec when dealing with unknowns. So the team creates what it calls a spike task, a throwaway prototype, to resolve unknowns before starting a new project.

The goal is not to build a full minimum viable product (MVP) that it can extend into a real product; a small, ugly prototype will do.

All it has to do is answer one question: “Does this idea actually work?” This helps to remove any technical uncertainty.

Building a spike task is a much better option than contaminating the spec with various options the team might not use.

There are many unknowns in a complex project, and a throwaway prototype can show you whether specific parts of projects are actually feasible within the current architecture and how they mesh with other constraints.

You can’t write a full spec with too many unknowns. For example, if the unknowns you’re dealing with are edge cases for the API, you can spike those edge cases and see if you can get an answer.

If your whole system depends on how fast your API is, spike the hot path and measure it. If you’re building a new view that has a lot of records in it, spike it to prove that the API can return the results fast enough.

The goal is to stop when you have an answer, not when the code is pretty.

If you’re worried about naming variables, functions, and file structure, stop! You’re putting too much thought into the implementation details.

Step 2: Promote the spike to a reference implementation

Once the spike works, don’t throw it away. It’s now your reference implementation. Save it in the repo in a known location, something like spec/spikes/reference/APIStressTesting.

You can point the LLM to it and say, “I know this pattern works, because here it’s working!”

The Larridin team called this one of the most underrated aspects of SDD: a working example is worth a lot more than a full page in the spec, because it helps the model stop guessing (and thus hallucinating).

When you provide the reference implementation to the model, comment on the specific parts that prove the approach, as well as any deficiencies, like parts where things are hardcoded or the error handling is missing.

The more info you give the model, the more accurate its overall implementation is going to be. Providing a spike without comments can be as dangerous as not providing one at all, because the model will just reproduce the wrong parts alongside the right ones.

Step 3: Write the spec

Now it’s time to write the spec, which you can and should do with AI’s help. It should be detailed enough to hand to a junior engineer or a small model.

Kanitkar suggests forcing the model to restate what needs to be done, list any assumptions, and flag any ambiguities. If it finds any remaining unhandled assumptions, you can create a new spike or update the existing one.

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

As an example, he shared a full spec for the Zero-Dependency Brainstorm Server.

Step 4: Write and refine the test plan before the implementation plan

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

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

Read more

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

Read more

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