It’s a book recommendation. For a work of fiction.

And because the year is long, it’s a trilogy, The Mechanical God by Lucian K.

This is an indie publication, so there are some typos here and there, and the pacing varies. The strengths outweigh these challenges.

The books follow twins who join a high school / boarding school on a remote island. It’s where the wealthiest or smartest kids in the world go to get the very best education. Except, as the kids quickly realize, something is wrong. The cost of failing the tests that the school’s AI runs is death.

And there are no adults anywhere.

Here’s why you should read it. This series is actually a history of technological development from the agricultural revolution to the rise of AI. It’s not surprising considering that the author is a data scientist at a tech company and has a Ph.D. in economics. Under the guise of a Hunger Games / Lord of the Flies / Lost thriller, the book explores how tech influences human culture, conservatism vs. progressivism, and human vs. AI.

It’s a fun way to take a step back from the daily grind while still learning something relevant to the job. Especially with how close we are (or not) to the Singularity.

And also, there’s the mystery. Why are kids still joining the academy years after it went mad? Where the hell are all the adults?

I learn from other writers so I can teach you better. Here’s who shaped my thinking in 2025:

Tech newsletters that I pay for

1. The Pragmatic Engineer by Gergely Orosz: I love all of the legwork that goes behind each and every episode. It’s a great way to stay on top of what’s going on in tech.

2. The Engineering Manager by James Stanier: I loved the books and only recently discovered the newsletter. I signed-up the moment the paid option was available. Looking forward to see what 2026 brings.

Non-tech newsletters that I pay for

1. Stratechery by Ben Thompson: I’ve been a paid subscriber since 2015. To be a great engineering leader, you have to understand other functions: marketing, sales, etc. This is the best resource for building a deeper understanding of the business.

2. Unsubscribe by Justin Welsh: I’m not building a unicorn, I’m building a lifestyle business. This is the best newsletter for the job. Even the name is just perfect.

3. Marketing Ideas by Tom Orbach: Marketing is one of my personal growth areas, and this gives me weekly industry insights with an expert analysis.

Leadership newsletters I love

1. Manager.dev by Anton Zaides: varied topics with a very “hands-on” view of engineering management.

2. The Conscious Leader by Taha Hussain: some really great gems in this one. Taha’s courses are one of the few that I find myself referring clients to.

Other newsletters that I love

1. Perspectiveship by Michał Poczwardowski: I love the current series on mental models.

2. The AI Engineer by Owain Lewis: real-world, from the trenches, advice on building AI powered applications.

3. <tech with heart /> by Doina Leovchin: I love the fresh perspective on building a career and a life in tech.

This was a hard list to trim down. There are so many other great newsletters that I read every time.

If you liked any of my writing this year, please let me know (just reply to the email). And if you want to see me change things for 2026, then send that email as well.

After the meeting, on the walk back to my office, a senior-manager tagged along and gave me some feedback. They said the problem was that I didn’t project confidence during the meeting. I pushed back, saying that how I presented shouldn’t influence the decision. They smiled and said that they wished it were true. Instead, in the world we live in, how we present matters. That’s why they practiced in front of a mirror for an hour before every promotion review.

I coached my engineers that their work wouldn’t speak for itself. That they need to advocate for themselves. And here I was, failing them because I didn’t speak with confidence about their work. I failed them.

I should have known better. There was another promotion review I had attended. In it, the consensus in the room slowly coalesced into waiting another cycle. That is until an IC8 pushed us managers to reframe how we viewed the case. It wasn’t just what they said or even their level. I still remember the clarity with which they communicated. The calm confidence behind their words.

Communicating clearly matters not just in promotion reviews. I rambled the first time I presented in an executive review. I stated my point and then continued to restate it three more times from different angles. It’s not just a waste of time; it’s a confidence killer.

I was able to salvage my engineer’s promotion through hours of after-hours work. Afterwards, I decided I had to improve my speaking skills. My personal growth journey started, as it usually does, with books. Big mistake.

Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking.
-- Albert Einstein

Reading is a passive activity. Luckily for us, LLMs can help us turn passive reading into behavior building. In this post, I’ll share how you can leverage AI to build your skills. Throughout the post, I’ll use the example of building your communication skills as a concrete example.

Let’s walk through how you can build your communication skills using AI in 2026. We’ll use Jefferson Fisher’s “The Next Conversation” as an example. You can replace it with your favorite communication resource. It doesn’t have to be a book. This method works great for blog posts, YouTube videos, and online courses.

I call this method the SCRIPT method: Skim, Commit, Record, Instantiate, Practice, and Tailor.

Skim for the skeleton

The first step that you should take when starting a new book is to skim from start to finish. Understanding the overall structure of the book will help you read and ingest the information more effectively. Beyond understanding the general structure, you can make an educated guess about how this book can transform you.

Taking “The Next Conversation” as an example, the book starts with some general principles and ways of thinking about human interactions. It then continues with tactical advice or algorithms that you can use in various situations. There’s much more to it, but that’s a good approximation for the initial scan.

Commit to one change

Reading for reading’s sakes is a waste of time. Even when you’re reading fiction, you’re actually reading it to experience an emotional transformation. For practical books, the aim is to undergo a knowledge or skill-based transformation.

Unfortunately, just like reading most works of fiction, we experience a temporary transformation when we read most books. A few months after reading the book, we only vaguely remember what it was about. We make the exact mistakes that the book tried to prevent. Most often we don’t even notice, because we completely forgot about it.

The secret to lasting transformation starts with intention. With making a commitment. Choose one specific way you will change. One transformation.

The real purpose of the initial skim stage is to help you find and choose this change. It’s fine if you change it as you study the book. It’s not fine to read the book without a clear commitment.

In our example, the change can be clear: build executive presence.

Record in your own words

Now it’s time to read the book. As you’re reading, take notes. Don’t just highlight passages or copy quotes. Write the key insights using your own words. Use your own lived experience. When the author uses one example, switch it with an authentic example that happened to you.

Taking notes is critical. It shifts your brain from passive consumption to a more active mode, which is great for retention. It also helps you capture the data that you’ll use to build your AI agent. Even if an LLM was trained on the book you’re reading, it won’t know what parts were insightful for you. It won’t know how the insights connect to your own experience.

For me, I typically take notes in Obsidian. You can use Notion, Notes, or hand-written notes. Yes, taking notes by hand is great again. Multi-modal LLMs will read your messy handwriting and diagrams.

When Jefferson talks about writing your own manual, I used README in my notes. After reading Oren Ellenbogen‘s articles on writing your manager readme, this term holds a deeper meaning for me. This is just one example of taking notes to resonate with me.

Instantiate your AI coach

This was the end of the learning journey until LLMs came along. With the latest AI advancements, you can now make your own customized AI coach.

Don’t stress too much about writing the perfect prompt. Start a new chat window, let the AI know you want to create a coach for whatever skill it is you want to develop. Then, share your raw notes and ask the AI to help you turn them into structured data you can use as context for the coach. Finally, ask the AI to help you write the system prompt itself.

To fire up your AI coach, just paste the system prompt together with your now-structured notes, together with whatever you’re currently doing. You take it up a level by creating a dedicated project, building a Claude Artifact, or vibe-coding a bespoke tool.

What can AI offer?

Here’s an example. In one chapter, Jefferson Fisher gives a list of 10 specific ways to speak more assertively. The AI can take the transcript of the conversation you just finished and give you feedback on how you could communicate more crisply.

Practice until its permanent

The most common mistake when using the SCRIPT method is to create the AI and use it whenever you remember that the tool exists. Real transformation does not happen in one aha moment. Rather, it’s the result of persistent and continuous progress. It requires practice.

You should integrate your new AI tool into your daily life. Spend five minutes after each conference call using it to get fast feedback. Or practice at the start of each day: ask the AI to throw questions at you, see how you respond, and then provide feedback. Do this for five to ten minutes daily for a month; I promise you’ll be astonished when you go back and watch your early recordings.

This is another reason reading fifty books a year is a fool’s errand. You need time to practice and internalize what you learn. Spend at least a couple of weeks practicing the key skill, the key commitment, that you took for each book before moving on.

Tailor your tool

Don’t create separate AI coaches for every book that you read. Instead, create one AI coach for each of your growth areas. Seed the initial AI from the first book that you read on the subject. As you read new books, update the existing tools.

Building strong in-person communication skills takes months and years to master. As you continue your education, ask the AI to ingest your new notes into your structured context. Prune out tidbits that you have already mastered and don’t provide as much value anymore. The tweaks tailor the tool.

Summary

When you transition from engineering to engineering management, you have to learn a completely job. There’s a broad range of new skills that you need to master.

The rapid rise in the capabilities of AI has unlocked new ways of learning rapidly. This is something I’m very excited about. Not just in my personal growth, but also in how I teach and coach managers. In past cohorts of Build Your Engineering Management OS, I was limited in how much lasting change I could offer for students. With each cohort, the level of skill-building tools I can offer goes up. The cohort starting in January 2026 is already packed with an entire AI toolset.

You don’t have to join the cohort to get these tools. With the information in this post, you can start building your own tools from scratch.

To recap, here are some of the non-trivial points to remember:

1. Choose and commit to a concrete transformation.

2. Take notes in your own words. Imagine teaching this point to a friend.

3. Create daily contact with the AI.

Build better behaviors; don’t just read.

Want to learn how to do this with me in a free live session?

Join the Lightning Lesson

Further reading:

Management was hard enough as it is.

Luckily, there’s a silver lining. Too many leaders focus on how AI helps engineering. Not enough explore how AI can help managers.

I was in a conversation with a Manager OS graduate recently. He shared how he used some of the AI tools we built in the course. It completely transformed his approach to 1:1s and the levels of trust that he could build with his team.

AI is a transformational technology for leadership.

In this new series, I’ll share exactly how to use these tools. Even if you watched my talk from early 2025, this series has new tools.

Stop missing the signals

When I started teaching engineering managers in 2022, I used a radar metaphor. New managers have a common failure pattern: they are blind. So much information about their team is out there, just waiting for them to notice.

• The often chatty engineer is now reserved

• The quiet engineer spoke up with a great idea in the team meeting.

• Terrance and Felippe have been avoiding each other for weeks now.

• The head of engineering shared a change in the organization’s priorities.

• The product manager ignored the tech-lead and talked with Megan instead.

A foundational leadership skill is listening. Not just with your ears but with all of your senses. It’s noticing what’s being said and how it’s being said. Even more important is noticing what’s not being said. The negative space.

So, open your leadership radar. Pay attention. Don’t forget the “Care Bear Frequency” and notice how awesome your team is; how else can you give positive feedback and reinforce great behavior?

This advice is no less true in 2025/6 than it was in 2022. You just have a new tool at your disposal. With LLMs, you can now build your human leadership radar.

LLMs are great at connecting the dots. In fact, this is the transformational breakthrough in transformers, the attention mechanism.

There are many ways to build this AI leadership radar. The easiest to get up and running, at the expense of some usability, is to create one project for each of your directs. The AI persona here is to be their private coach. The key AI context is the user persona document. Before every 1:1, throw the latest meeting transcripts and other artifacts into a new query and ask the AI to refine the persona document and share what the AI learned about them.

As an example, here is a snippet of a persona for one of the course participants (I dog food what I teach):

### Communication Style
- **Thoughtful & reflective** - Asks clarifying questions, seeks understanding
- **Candid about uncertainty** - Comfortable saying “I don’t know if that’s the right strategy”
- **Collaborative learner** - Engages with peer feedback and course discussions
- **Integrative thinker** - Connects concepts quickly (”this is not different from tech lead to manager transition”)

Now that the AI understands the people on your team, you can ask it a series of questions to help you notice. Each question is like a different frequency on your leadership radar.

• What was their latest accomplishment relative to their personal goals?

• Was there an opportunity they missed to pursue a personal goal?

• Did anything change in their behavior?

With this tool, you’ll notice more opportunities to praise, coach, and support the humans in your org.

Before moving on to the next tool, a word of caution. Using an AI leadership radar in 2025/6 is a lot like driving with adaptive cruise control. You just can’t rely on these tools if you lose the skill to notice things yourself. There are a lot of signals that AI just doesn’t have access to, such as tone of voice. Subtle bugs, like context window saturation, can reduce the quality of the feedback.

For 2025/6, use this AI leadership radar as feedback for yourself. The goal is not for it to catch everything. Rather, it’s for it to help you build your own human radar.

What next?

So what do you actually do?

Hack away at your first AI leadership radar. Create a Claude/ChatGPT/Gemini project for the person you have a 1:1 with next. Ask it to act as their coach and drop in your last three 1:1 notes and to interview you to create the initial persona document. You can get it up and running in fifteen minutes.

Using it for a 15+ person team will require manual work, so tie it to a recurring anchor, like your 1:1s. Once you figure out how you like to use the tool, invest a couple of hours to scale and automate it.

If you do, you’ll have an AI tool that won’t just help you manage better. It will help you become a better listener and a better leader.

Fifteen years ago, I changed how we did interviews. I looked at what I and my peers actually did all day, and then I looked at what we forced candidates to go through. It just didn’t really connect. My hypothesis was that the closer the interview was to the real job, the more predictive it would be. If we improve our hiring process, we’ll build a stronger team.

And so, my crusade began. I badgered our Head of Engineering. Stalked our HR head in the hallways and annoyed our head of IT. Eventually, I got my way. A new proof-of-concept step in our interview process. Candidates would come into the office and get a laptop with a full IDE and a connection to the internet. They’ll work on a real task with the resources that they’d have if they joined.

I learned something that changed how I think about interviews.

If you’re designing your interview process right now, maybe you’re thinking of letting candidates use AI, pair program with the interviewer, or anything else to make it more like the real job. Well, you’re going to learn this too.

The impossible math of interviewing

Imagine you have access to a multiverse machine. And a time machine. Maybe a 2-for-1 combo machine you found on Amazon for Black Friday. The Universe Splitter 3000.

You can use this machine to actually solve hiring once and for all. Any candidate who applies for the job? Hire them! Send them off to some other universe to do the job and see how well they perform. Now take this data, go back across space-time to our universe, and hire the top performer.

Hiring. Solved.

Before we come crashing back down to reality, one question first. How long would you need to observe each candidate performing on the job? You’ll certainly want to see how they onboard first. You’re hiring for the long term, and not everyone ramps up as quickly. Maybe your best performer takes a while longer to ramp-up?

It’s common to use 30-60-90 ramp-up plans (please don’t!). So, let’s say 100 days is enough to make an informed decision. Let’s round it to 1,000 hours of real work. We’ll observe each candidate spending 1,000 hours working on our team and then choose the best one.

Alright, back here in reality.

You don’t have 1,000 hours to evaluate each candidate. You have 5 hours.

I assumed that if I simulated work, I could compress 1,000 hours of data in 5 hours, with very little information loss. If you stop and think about it, there really is no reason to assume this to be true. There’s no reason to assume that the more similar an interview is to real work, the more predictive it will be of success in the work. The order of magnitude just makes little sense.

You can’t win this game.

But you can change the game entirely.

What you can actually do in 5 hours

Okay, here’s what we know. We have five hours to make a judgment call. Here are three proven techniques that will help you build a great team:

1. Look at the inverse problem.

Don’t predict who will succeed on the job. Try to find who will be bad at the job.

Here’s an example. When I designed that interview process, one books that was fresh on my mind was Jon Bentley‘s Programming Pearls. In the book, he describes asking computer science Ph.D. students at Carnegie Mellon to write a binary search function. Not on the spot, but at home with no time constraints. Turns out that most students had a bug. Most? 90%. And it’s not just in academia; turns out it was true in the industry as well.

Spoiler. This statistic barely changes when people know about this grim reality before trying to do it. If you haven’t tried this yourself, I recommend trying to solve it on your own. These days, it means writing code somewhere with no LLM-powered autocomplete.

Now, there’s nothing inherent to imply that being able to write a binary search without bugs implies being good as a software engineer. The inverse is clearer, though. If you write buggy code in a well-defined problem, after being told most people write buggy code, then you will do so for the ambiguous problems at work.

Through this lens, the interview process is not about vetting. It’s about filtering.

2. Gather 1,000 hours of work in 5 hours.

You don’t have the Universe Splitter 3000. No multiverse for you. What you have is a time-machine. I mean, I wrote these words long before whatever the present is for you right now. You’re looking backward in time right now.

You can’t look forward in time, but you can look backwards.

This is the key insight behind Behavioral style interviews. You can do a 1,000-hour interview asking the candidate about the thousands of hours of work that they already did. Instead of inventing artificial and simulated scenarios, talk about real challenges that they faced. Ask them how they solved hard problems, navigated ambiguity, or considered trade-offs.

The real insight won’t come from the initial questions that you ask. It will come through the follow-up questions that dive deep and cut through the noise. This gets into the biggest challenge in integrating these interviews into your process. Running a good behavioral interview is hard, and you’ll need to invest in training your interviewers.

Once you have a good set of interviewers who have mastered asking piercing follow-up questions? It’s time to pick up the most under-used of all interviewing hacks: the reference calls.

Start calling references and interviewing them. This gives you the most confidence and data on those thousands of hours. It gives you another perspective on the candidate. Another not-very-objective perspective, which is why you need trained interviewers.

3. Run situational interviews

The research is pretty clear^[1]. Behavioral interviews outperform situational (simulation-based) interviews for knowledge workers. It’s also clear that combining both performs even better.

So how do you run a situational interview well? Well, first, don’t aim to simulate the work environment itself. Instead, work backwards from what success and failure look like, based on the historical data you have in your company. Then, design interviews that test these traits. By going upstream, you can get relevant data in a much shorter time.

Here’s an example. Let’s say you noticed that at work, the requirements sometimes change. Maybe the product manager changed their mind, Sales promised a non-existent feature that needs to be ready yesterday, or the business landscape changed. I’m sure nothing like this happens at your company, but I’ve heard it happens in other places. This means that any engineer who can’t handle these changes will fail. Now you have a specific trait to evaluate: adaptability.

You can evaluate adaptability in a situational interview. Give the candidate a programming task. Then, midway through, change the requirements. Do so in a way that breaks some implicit assumption they depended on until then.

Here’s a fun one that one of the Big Tech companies used to ask. Given two sorted arrays, find all the elements that are in both arrays. Seems like a super simple question. You can then throw in additional information, such as one array is too big to fit in memory.

This third example is a great segue to talking about LeetCode.

Why LeetCode works (when you use it right)

LeetCode questions really are terrible interview questions. Candidates who blindly grind through LeetCode can ace your interview questions and completely crash on the job.

LeetCode questions done well are great interview questions. Here’s what this means in practice:

• It’s not a binary test. Solving the question shouldn’t mean passing the interview. Failing the question shouldn’t mean failing the interview. Whether or not they solve it, it should be one data point.

• Work backwards. Coding speed is a perfectly reasonable evaluation criteria, for some companies. For others, it will have nothing to do with the traits that are upstream of success (or failure) on the job. Start with the traits and work backwards.

• Focus on signal collection, not decision making. This focuses the interviewer on the evaluation criteria. Their biased minds will jump to hire / no-hire decisions quickly. Instead of fighting this human shortcoming, accept it and make it as irrelevant as possible.

Most interviewers do the opposite.

They pick a problem they think is clever. Wait for the candidate to solve it. Then grade on completion.

That’s not interviewing. That’s testing trivia with extra steps.

The tool trap: from IDEs to AI

What happened 15 years ago when I let candidates use IDEs? The ones who used the tools did worse. They wasted time searching online instead of thinking. They threw minutes away fighting IntelliJ when they were used to Eclipse. Lots of time, very little data for us. Poor experience (and outcomes) for them.

Whiteboard questions are simple. No tech setup. No distractions.

Here’s an interesting data point. Meta uses Coderpad for remote coding interviews. They just turn off the ability to compile the code that you write. This surprises a lot of candidates. On the job, everyone can use a compiler. We already established that this isn’t really a useful consideration. Instead, the compiler is a distraction that provides little value.

Now we have AI. Should you allow AI in coding interviews?

My take is yes and no. You should have one coding round with LLMs allowed and one without. The evaluation criteria for the LLM-enabled interview should be different. The question design should be different. You just have to work backwards for the specific trait that you’re evaluating.

And you have to account for the churn and distraction. The coding environment will be more jarring for some candidates than others. This will mostly be based on their experience, with very little predictive power for the future. Right now, in late 2025, for most companies, this is still a worthwhile effort.

In 5-10 years? I think LLM-enabled interviews will be a waste of time.

Realistic feels better, artificial works better

I’ve written some controversial posts in the past. My guess is that this one will be my most controversial take. That’s fine. If it got you thinking more seriously about structuring interview loops, I’ll be happy.

And if you want to tell me just how wrong I am, please do.

P.S. One more thing. If you don’t work in Big Tech or one of the hottest startups, there’s a far more important lever to pull before you optimize your interview process. Get more qualified people to the top of your funnel. 9 times out of 10, you’re better off investing your efforts there.

Further reading:

Also, turns out we even had company values.

Our reaction was pure cynicism. What a total waste of time and money. Those suits out there at headquarters have no idea what we’re doing. A bunch of MBAs getting money to make believe while we’re here doing the real work.

Three months after the big reveal, they kicked us out of the big conference room again. This time to paint the walls bare again. What a total waste of time and money.

Years later, I joined Amazon. The company’s legendary Leadership Principles? You won’t find them anywhere on the walls. Instead, you could find them everywhere. In how managers design org-structures, engineers work through design and correct bugs, and in how product managers plan out new features.

If you’re interviewing at a startup and see a list of values on their website, you should consider looking elsewhere. There are three reasons why startups shouldn’t have formal values.

What they say vs. what they actually reward

One set of values painted on the walls and another set of values driving decision making is a perfect recipe for cynicism. The only time when values matter is when making hard decisions.

Founders and leaders often think that they can tell everyone how to make these decisions. And it can work well for simple decisions. It never works like that for hard decisions, because hard decisions are painful.

The right algorithm for making hard decisions is different for different companies. The most obvious example of this is the speed vs. quality tension. Some companies should bias more towards speed, while others towards quality. Think of a language learning app versus the software that runs your local nuclear power plant. This one seems obvious, but there are dozens of such tensions.

This gets to the fundamental truth about values. Values are revealed preferences, not stated preferences. You can identify your values in retrospect, looking backwards at how you made successful decisions in the past. You can’t force your preferences for how to make hard decisions on a company. I mean, you can; it just guarantees failure.

Look at how you took big bets, made promotion decisions, build vs. buy. Any time you had to make a tradeoff, you had to weigh one bad outcome versus another. These are the situations that reveal your company’s values.

A clear sign the founders don’t know what they’re doing? Values that are meaningless. Values that can’t help you make hard decisions, because they just state obvious truths. Integrity. Excellence. Passion. You’re better off finding a company with some backbone.

They’re writing values before they know what they’re building

Startups are not regular companies. Here is Steve Blank’s definition of what a startup is:

A startup is a temporary organization designed to search for a repeatable and scalable business model

The purpose of a startup is to run a search algorithm over the space of all business models. Finding Product-Market-Fit (PMF) is only the first step to success. A single, one-off, PMF is not success. A PMF that isn’t scalable is a failure.

Once the startup finds a business model that’s repeatable and scalable? It stops being a startup and starts being a scaleup. The company’s leadership needs to change gears and switch how they execute. This often means it’s time for a new CEO.

When the scaleup has a successful thing going on, it’s time to expand to new business models. Apple under Tim Cook, is an example of doing this very well. After decades of making money from selling hardware, Apple expanded to making money through Services revenue. The same plays out at most mature companies.

Startups explore, scaleups exploit, and companies expand. Explore-exploit-expand.

How can you write values before you know what you’re building? Pivots and major course corrections are a real possibility. Each change can mean that the algorithm for making hard decisions will need to change.

Values as a solution looking for a problem

If the values are real and the company has a repeatable and scalable business model, things are looking better. The company knows where it’s going. It uses values as a tool for making hard decisions based on what actually made it successful. There’s just one more test to look at.

How many humans are working at the company?

Codifying values comes at a cost. The moment you write your values down is the moment misunderstanding starts. When you say “Dive Deep” you have a picture in your head of what that means. Everyone in the company will have a picture in their head of what “Dive Deep” means. Everyone will have a different picture of what it means.

This is why Amazon executives spent countless hours writing and editing the brief paragraphs that accompany each value. This is why Amazon’s CEO recorded an entire video for each value. Or why Mark Zuckerberg talks about “Move Fast” in nearly every weekly company Q&A. Values, done well, are expensive. They require constant leadership effort.

And most companies don’t need to pay this price. They get it for free.

When your org size is below Dunbar Number, roughly 150 people, everyone knows everyone. People interact with each other. They see firsthand how the hard decisions are made. The revealed values are there, reinforced every day by the more tenured employees. Values propagate through osmosis.

This breaks down eventually. You can usually identify this stage through the grumbling of the old guard about how things aren’t how they used to be. That’s a sign that it’s time to scale. It’s time to pay the Values tax.

If you’re interviewing for a company with about a hundred people that has formal values, leadership is prematurely optimizing. Not a red flag, but a real warning sign.

What to Ask Before You Sign the Offer Letter

What if there aren’t any red flags? The company has a clear path forward, growing, and large enough to warrant formal values. Should you be worried about joining? Here are three questions to help you figure this out:

• “Can you walk me through a specific example of how the company’s values influenced a recent difficult decision?”

• “What gets someone promoted here? Can you give me examples of people promoted recently and why?”

• “Can I speak with 2-3 people on the team who aren’t part of the hiring process?”

The first question gives you insight into whether the values are just art on the wall or part of the company’s operating system. If the company’s values are generic fluff, then every team will make hard decisions differently. It will be hard for you to figure out how to succeed and grow. And there’s a good chance that the company will flounder instead of flourish.

The second one is more targeted. Promotions are the highest-stakes rewards that companies hand out. Promotions define and sustain a culture for years. If there’s a mismatch between the stated values and the behavior that the company encourages, you should be concerned.

The last ask is the most important one. Remember, the company may be interviewing you, but you’re also interviewing the company. If they run reference checks, you should too. Back-channel evaluations are a way for you to get an honest assessment of how things really work.

If the company passes all three tests, you’ve found a place where values are tools, not theater.

The Real Culture Signal You Should Be Looking For

Joining a company is a risk, and you need to manage this risk. You’re going to spend months and years at this place. You’re going to give more than half of your waking hours to the company. Don’t waste it.

Values done right are an amazing tool. It forces coherent execution across the entire company. It spreads best-practices to every room where painful trade-offs get evaluated. It’s the tool that winners use and losers emulate.

The best career accelerator? Joining a winning team.

My phone buzzes. PagerDuty alert.

The system is down.

I scramble to my laptop. Check the alerts. Database connections maxed out. API timeouts everywhere. Users can’t access the service.

First priority: get it back up. We identify the offending caller and block them. System stabilizes. Crisis averted.

The post-mortem hits differently.

We built a new feature. Added fan-out to notify multiple services. Seemed fine for manual usage. We tested it. Reviewed the PR. Shipped it.

But one user scripted their access.

That single script triggered the fan-out hundreds of times per minute. Brought down the entire system.

The fix? A simple rate limit. One line of code. Would have taken 5 minutes to add.

I pulled up the original PR. Two reviewers had signed off. “LGTM.” All the tests passed. The code worked exactly as specified.

Nobody thought like an adversary.

Nobody asked: “How would someone abuse this?”

But here’s what everyone misses: The code review worked perfectly. Two experienced engineers approved it. Tests passed. The code did exactly what we built it to do.

The problem wasn’t the review process.

The problem was nobody changed their thinking between Line 1 and Line 300.

The code review problem nobody talks about

Code review has massive value in theory.

In practice? Two extremes.

Most engineers rubber-stamp with “LGTM.” They don’t see the value. They have their own work. So they skim it, see tests passing, and approve it.

The other extreme? Engineers who spend hours digging through every line. They block progress. They argue about formatting. They slow everyone down.

Microsoft studied 900+ developers and found 36% perform code reviews multiple times daily. Google analyzed 9 million reviews and found median time under 4 hours for small changes.

We’re spending massive time on this.

And still missing critical bugs.

Both problems stem from the same root cause.

Nobody taught us how to review code.

The checklist trap

I started as that junior engineer who winged it. No structure. No method. Just looked at code and hoped I’d catch something.

As I grew, I over-indexed on what I’d personally seen go wrong. Saw a race condition once? Now I check every PR for race conditions. Saw a memory leak? Now I’m the memory leak police.

Eventually I got serious. Read the book on code reviews. Studied the research. Built comprehensive checklists. Shared them with my team.

I even ran formal code review sessions. Got everyone in a room. Went through the code together. Line by line. Following the checklist.

First few sessions? People were engaged.

Then the fatigue set in. Hour-long meetings. Everyone’s calendar blocked. The checklist grew longer. The sessions felt mechanical.

People stopped seeing the value.

Research backs this up. A 2015 Microsoft study found that as PRs grow larger, the proportion of valuable comments drops. Checklists make you thorough but mechanical. You tick boxes. You lose the forest for the trees.

Eventually it fizzled out.

Back to square one.

The breakthrough

Here’s what I learned after that production incident and years of iteration:

Code review isn’t about what to check.

It’s about how you think.

Google analyzed their review process and found something surprising. Design is the FIRST thing reviewers check. Not bugs. Not syntax. Design.

Microsoft’s research showed 75% of review comments address long-term maintainability, not immediate functionality.

The best reviews aren’t about catching today’s bugs.

They’re about preventing tomorrow’s disasters.

What actually works? Personas.

Instead of one exhausting pass through a 47-item checklist, you make three focused passes. Each time, you put on a different hat. You step into a different role. You ask different questions.

The three-pass system prevents checklist fatigue because each pass requires a completely different mindset.

Pass 1: Does it work and make sense?

Mental frame: “Can I understand what this does and verify it’s correct?”

You’re the engineer on the team right now. Today. You need to understand this code.

Three questions:

• Does the code do what it claims to do?

• Do the pieces fit together sensibly?

• Are there tests that verify the right behaviors?

Design naturally emerges while you’re reading for correctness. When you find yourself asking “why is this structured this way?” - that’s design review happening organically.

You’re not checking boxes. You’re understanding the code.

Google’s guidelines explicitly call this out: “Do the interactions of the various pieces of code make sense?” This is where you catch architectural issues before they become technical debt.

AI can help here: semantic bug detection, cross-file logic analysis, automated test generation. Let AI catch the mechanical stuff.

Pass 2: Can we live with this code?

Mental frame: “Will this code age well and operate reliably?”

Now you’re the future engineer. Six months from now. You need to modify this code or debug a production issue at 2 AM.

Will you thank or curse the original author?

Look for:

• Can we modify this later without breaking things?

• Will it handle errors gracefully?

• Do we have logging for debugging?

• Is performance reasonable for requirements?

This is your future-proofing pass.

Research shows that 75% of review value comes from catching maintainability issues, not functionality bugs. This pass is where you earn that value.

Microsoft’s study found that poorly-reviewed code directly correlates with post-release defects. Code that’s hard to maintain becomes code that breaks in production.

AI can help: documentation generation, code smell detection, error handling gap analysis, performance bottleneck identification.

Pass 3: What could go wrong?

Mental frame: “How would I attack or break this?”

This is the pass that would have caught our production incident.

You’re no longer an engineer on the team. You’re an outsider. A user with a weird name. A black hat hacker. Someone trying to use the system in unintended ways.

Stop assuming the happy path.

Look for:

• Security vulnerabilities - injection, auth flaws, crypto issues

• Edge cases - null handling, boundary conditions, race conditions

• Resource issues - memory leaks, connection pooling, scalability concerns

• Abuse scenarios - what happens if someone scripts this?

If I’d done Pass 3 on that original PR—the one that caused our 3:47 AM incident—I would have asked: “What happens if someone scripts this?”

That single question would have led to: “We need rate limiting.”

One line of code. Five minutes. Crisis prevented.

Put on your chaos monkey hat.

AI can help: vulnerability scanning, fuzzing, edge case test generation, resource leak detection.

Why three passes?

I tried everything. Two passes felt incomplete. Four passes brought back checklist fatigue.

Three is the sweet spot.

Research supports this. Studies show review effectiveness drops after 60-90 minutes. Three distinct passes let you maintain focus without burning out.

Two passes miss something. You can’t fit all three personas into two mental frames without overlap.

Four or more? You’re back to checklist fatigue. Too many context switches. Too much cognitive load.

Three passes get you 95% of the value. Easy to remember. Each pass feels distinct. No checklist required.

What changed when we adopted this

My team complained about long PR review cycles. Inconsistent quality. Nobody saw the value.

I introduced the three-pass system.

Two weeks later, Sarah caught a SQL injection vulnerability in Pass 3. She posted in our team channel: “Just did Pass 3 on the user profile endpoint. Asked myself ‘how would I attack this?’ Found we’re concatenating user input directly into queries.”

She was excited about it. Not because I forced her. Because she felt smart.

The next week, Marcus caught a memory leak in Pass 2. “Imagined debugging this at 2 AM. Realized we never close database connections in the error path.”

In our next team meeting, people started sharing what they caught. Real problems. Security issues. Scalability concerns. Edge cases that would have caused incidents.

Engineers got excited about code review again.

A few weeks later, it came up organically. Engineers asking others: “Did you do all three passes?”

The system stuck because it worked.

How to start using this

Next PR you review, try this:

Pass 1: Read it like you’re trying to understand it. Does it make sense? Does it work?

Take a break. Get coffee. Reset your brain.

Pass 2: Read it like you’ll have to debug it at 2 AM in six months. Will you hate the person who wrote this?

Take another break. Walk around. Clear your head.

Pass 3: Read it like you’re trying to break it. What happens if someone abuses this? What edge cases exist? What could go wrong?

The breaks matter.

For small changes under 200 lines, you can do all three passes in one sitting. For larger changes, spread them across different times.

SmartBear’s research shows reviews under 400 lines are most effective. Keep PRs small. Do thorough passes.

The hardest part

Learning to actually reset your mindset.

When you’re tired, when the PR is 800 lines, when you have five other reviews waiting - it’s tempting to skip passes. To blend them together. To fall back into checklist mode.

That’s when you have to be disciplined.

Take the break. Reset completely. Step into the next persona with intention.

That discipline is what makes this system work.

What you’ll notice

After using this for a few weeks:

You’ll catch bugs you would have missed. Real bugs. The kind that cause incidents.

You’ll review code faster. Not because you’re rushing. Because you’re focused. Each pass has a clear purpose.

You’ll stop arguing about formatting. Pass 1 doesn’t care about that. Pass 2 might note if it’s unreadable. Pass 3 definitely doesn’t care.

You’ll build better intuition. The personas become second nature. You’ll start thinking adversarially when writing your own code.

And when someone asks “Did you review this thoroughly?” - you’ll actually have an answer.

Yeah. I did three passes.

Pass 1: It works and makes sense.

Pass 2: We can live with this code.

Pass 3: I tried to break it and couldn’t.

Ship it.

For other points of view:

Manager.dev

The price of mandatory code reviews

“You should do code reviews” is an unwritten law of software engineering. Like “Always have a rollback plan” and “Everything should be saved in Git…

Read more

6 months ago · 71 likes · 13 comments · Anton Zaides

The System Design Newsletter

I Studied How Top 0.1% Engineering Teams Do Code Reviews

Keep pull requests SMALL, so they’re easy to understand and review. Plus, small pull requests create fewer problems later…

Read more

6 months ago · 95 likes · 3 comments · Neo Kim

Jurgen De Smet

AI Code Review vs Manual PRs: Why the ROI Is Too Big to Ignore

Code review has always been the gatekeeper of software quality. Traditionally, this job sat firmly on the shoulders of senior engineers, painstakingly combing through pull requests (PRs) or merge requests (MRs). While their wisdom is invaluable, manual, asynchronous reviews are slow, inconsistent, and often cluttered with trivial nitpicks. Enter AI-powe…

Read more

6 months ago · Jurgen De Smet

Level Up Engineer

Your Code Review Reputation Is Your Engineering Currency

You approved that pull request in 30 seconds…

Read more

6 months ago · 9 likes · 2 comments · Shireen Nagdive

The courses that I never finished? I could see the effort and quality that went into crafting them. I took courses in marketing, sales, engineering, storytelling. You name it. There’s a good chance you heard about or even took some of them. I still didn’t finish them.

Until a year ago.

I was consistent. I showed up every day and did all of the exercises. I learned real lessons and applied them directly in my professional life. The difference was that it wasn’t built like a course. It was built (and framed) as a challenge.

For the first time, I couldn’t wait until the next session. I protected my time religiously and had my notebook open and ready before each class. I connected with the other students over WhatsApp and still stay in touch with them.

Nothing like the on-demand courses sitting abandoned in my account. Here’s a stat that blew my mind. 85-88% of learners don’t finish online courses. This is the most generous statistic that I could find, with other sources going as high as 97%.

Turns out, it wasn’t just me. It’s human nature.

But here’s what everyone misses: the problem isn’t your discipline. You’re plenty disciplined at work, at the gym, with your kids. The problem is that online courses are designed like books when they should be designed like teams.

That challenge I took? It had three things every abandoned course in my graveyard was missing.

Why your course graveyard keeps growing

Problem one: You’re learning alone

You’re sitting in front of your computer. The instructor recorded this six months ago. There’s a comment section, but it’s either crickets or someone asking “Where’s the download link?”

You hit a confusing part. You rewind. Watch again. Still don’t get it.

There’s nobody to turn to and ask “Wait, did you understand that?” Nobody to explain it differently. Nobody to tell you that yeah, this part is actually confusing and here’s how they figured it out.

I still remember my Physics TA freshman year telling us the secret to passing his brutal course. Study partners. Not because they’re smarter. Because explaining something to another human forces you to actually understand it.

Digital courses skip this completely. You’re on your own.

Problem two: Life happens, and nothing stops you from quitting

Week one: You’re motivated. You block time. You take notes. You’re doing this.
Week two: Big project at work. You skip one session. It’s fine, you’ll catch up this weekend.
Week three: The course is still sitting there. Waiting. You’ll get back to it.
Week six: You’ve forgotten you even bought it.

The problem isn’t your discipline. You show up for work meetings. You make it to your kid’s soccer games. You hit the gym.

The difference? Those have consequences. Your boss notices if you skip the meeting. Your kid notices if you miss the game. Your running buddy texts you “Where are you?”

Digital courses have no consequences. They just sit there. Forever patient. Forever guilt-inducing.

Problem three: Nobody adapts to how YOU learn

Here’s what happened in that challenge I took last year.

I asked a question about applying the framework to my specific situation as a new solopreneur. The instructor didn’t just answer my question. He listened deeply and then showed me three different approaches I could take.

Then another student said “Wait, I work at a startup. Would this work for me?” The instructor adapted the same framework to their context. Different constraints, different approach.

You can’t get that from a pre-recorded video.

Learning isn’t about absorbing information. It’s about connecting new concepts to what you already know. A great teacher adapts their metaphors, their examples, their entire approach to match where you are.

Digital courses can’t do that. They’re one-size-fits-all. Which means they’re one-size-fits-nobody.

How to actually finish what you start

I tried fixing digital courses first.

Time-based releases. Study partners. Scheduled calls to discuss what we learned. It helped. But coordinating schedules? Finding someone interested in the same niche topic? Hard.

Then I took that challenge last year. Live cohort. Real people. Fixed schedule.

Everything changed.

You get instant answers from people like you

Week two of the challenge. I was stuck on how to apply the framework to my LinkedIn strategy. I posted in the WhatsApp group at 11pm.

By morning, three other creators had responded with how they tackled similar situations. One worked at agency. Another was getting a non-profit off the ground. Different contexts, same framework, different approaches.

I learned more from those three messages than I would have from rewinding the video 10 times.

The more you engage with other students, the more you get out of it. Not because you’re being a good community member. Because their questions surface gaps you didn’t know you had. Their contexts force you to think differently about the same concept.

You show up because people notice when you don’t

Week three. Big family obligations. I almost skipped the session.

But I knew Sarah and Marcus would ask where I was. I knew I’d have to explain next week why I missed it. I knew I’d be the only one lost when they referenced what happened.

So I showed up. Tired, distracted, but there.

That’s the difference. There’s a recording, sure. But you won’t watch it later. You know it. I know it. The recording is a safety net you’ll never use.

The live session forces you to protect that time. To show up even when you don’t feel like it. To actually do the homework because you don’t want to be the only one who didn’t.

Is this annoying sometimes? Yes. Does it lead to actually integrating what you learn into your real life? Also yes.

You can ask YOUR questions in real-time

My favorite part. Direct access to the instructor.

I asked how to handle a specific situation where I wanted to grow across social networks. The instructor didn’t give me a generic answer. He drew out my exact scenario, asked clarifying questions, then walked me through three different approaches based on my specific constraints.

You can’t get that from a video.

Here’s the move: prepare questions before each session. Write them down. Bring your actual problems, your actual context, your actual constraints.

You didn’t pay to hear someone talk. You paid for them to adapt their knowledge to your unique situation. That only happens if you ask.

What I do differently now

I still sell courses. But I changed how I build them.

For quick wins, I make them short enough to finish in one sitting. Like The Essence of Management. Turns out if you can complete something in 90 minutes, you actually will.

For everything else? Live cohorts only.

Every cohort is different. Some are mostly younger managers at startups. Others are experienced leaders at Meta, Amazon, Google. The content adapts to who shows up and what they need.

That’s the point. The humans matter more than the curriculum.

I’m done contributing to course graveyards. Including my own.

If you’re sitting on a pile of unfinished courses, you’re not broken. The model is. You don’t need more discipline. You need other humans learning alongside you.

Join the next cohort or grab a course you can finish today.

Either way, stop blaming yourself for a design problem.

• Gather concrete evidence for every claim Don’t just say a project was “complex” or “high-impact.” Back it up with quantitative metrics (team size, budget, timelines, percentiles), qualitative indicators (stakeholder testimonials, peer recognition), and organizational evidence (promotions earned, policy changes, spec modifications).

• Pre-compute your strongest examples Don’t improvise during the interview. For each common question type (performance management, growth, conflict, trade-offs, hiring, etc.), prepare 2-3 specific stories in advance with the structure and evidence already mapped out.

• Have a dialogue, not a monologue After your initial 2-3 minute overview, explicitly ask: “Where would you like me to go deeper?” Present menus of options throughout: “I can talk about the technical approach, the stakeholder management challenges, or the team scaling decisions. What’s most interesting to you?”

• Start with a compelling headline Open each story with a one-sentence “trailer” that captures the scope and impact. Instead of diving into details, begin with something like: “Let me tell you about the time I led a global infrastructure overhaul that reduced latency by 93% and reduced customer attrition by 13%.”

• Write out your scope in bullet points Before interviews, identify and document what made each scenario challenging: ambiguity level, cross-org complexity, stakeholder seniority, team distribution, technical constraints, business risk. Build your entire answer around proving these difficulty dimensions.

I’d like to say it was brilliant foresight on my part, but the truth was just blind luck. Everyone around me was frantically trying to find a job and figure out how to pay the next mortgage bill. I was worried about my new job, with the startup struggling to make it through the crash. Overall, it was not a fun time.

Over the past few years, in my coaching career, I’ve worked with dozens of people who were laid off. Finding a job: sending resumes, talking with recruiters, interviewing, the wait afterwards, that’s an emotional roller coaster. Doing so after layoffs? That’s ten times worse.

Job security in tech? It never existed. But here’s what everyone misses: Real security isn’t about keeping your current job. It’s about never needing to worry about losing it.

The Lie We All Believe

Just like teenagers who truly believe that bad things only happen to other people, too many engineers believe that they are irreplaceable. They engineered their way into a position that no manager can take away.

Maybe you are the only Subject Matter Expert (SME) in a critical field. Or you’re the only one who knows how to maintain the infrastructure that makes everything run. Reddit is full of stories of how companies crash after firing these people.

I worked with such an engineer. They really were a world class expert in their domain and owned a critical component in our system. I can still remember them telling me in the hallway that they have real job security, because no one can fire them.

Spoiler: they were fired. The company did fine.

It took me years to learn these two lessons:

1. No one is really irreplaceable.

2. Trying to become irreplaceable actually incentivizes leadership to replace you.

I really thought Twitter/X would collapse after Elon fired 80% of the workforce. There’s a lot to say about the company, but it’s still working.

Brutal. But that’s the reality we live in.

The 5 Ways to Build Real Job Security

Every time I left a company, I had to leave some things behind. My work laptop, sometimes a work phone, the badge. Definitely the work I put years of effort into. My internal writing and the software that I built.

Every time I left a company, I got to keep some thing with me. And if you want to have real job security in tech, then you should focus on these things. The things that stay with you.

Because these are the things no one can take away from you.

Your expertise. The deep human connections you build. Your full piggy bank. Your interviewing skills. And your resiliency.

You can always build and curate each of these. When you do, you’ll be ready for anything life throws your way.

Your Skills Can’t Be Laid Off

You have to build your craft, continuously.

It’s not just the tech skills. It’s problem solving, communication, business understanding, etc. Humanity has figured out how to excel at all of these. It’s just us, the individual humans, that need to learn it for ourselves. So figure out where to invest in yourself.

Especially with AI getting more competent by the week.

Action Item: Pick one skill from your last performance review and spend 30 minutes tomorrow learning it.

Your Network is Your Net Worth

I really hate the saying “It’s not what you know, it’s who you know.”

The truth is that both sides matter. It does matter what you know. And it does matter who you know.

Most engineers hate networking. It doesn’t have to be this way. Networking doesn’t have to be something sleazy.

It can be organizing a book club. Or forming a study group to learn Rust. Or just joining a mentoring group.

Most importantly, it’s realizing that you’re already networking. The people that you work with everyday. The people that you used to work with in the past.

Action Item: Schedule a coffee chat with two old colleagues this week.

Your Net Worth is Your Net Worth

Money makes the world go round. For me, it gave me the confidence to take a big risk, relocate across the world, and more than double my total compensation.

Having money in the bank can reduce much of the stress involved with lay-offs. I know that many people have invisible obligations: paying off debt, helping family back home, paying for medical expenses. Even without the fear of layoffs, it’s good to be prepared.

If you’re not saving right now, you should. I’m not saying that you should take cold showers, but maybe buy a slightly older car?

Action Item: Open your bank app and identify the three biggest expenses. Cut one by 20% by the end of the month.

Keep Your Interview Muscles Warm

Interviewing is a skill. I’m guessing that you’re not solving LeetCode style questions at work or developing Netflix from scratch in 40 minutes.

For better or worse, tech interviews don’t look much like tech day jobs.

Every month, you should practice interviewing. Work your way through LeetCode or your favorite coding preparation book. Watch system design interviews on YouTube, but pause and try to solve it yourself first. Review and update your story bank for your behavioral interviews.

And yes, go on actual interviews. Even if you’re not actively looking.

Action Item: Apply to one job you’re underqualified for. Just to practice.

Resiliency is a Muscle, Not a Moment

Skills, network, and money are nice and all. At the end of the day, we’re all living in our bodies, full of hormones and fears and worries.

When the moment comes, it doesn’t matter if you’re ready. It doesn’t matter if you think you’re ready. The only thing that matters is if you feel ready.

Just like a muscle, resiliency is something that you can build. It takes practice and effort. Maybe taking that cold shower isn’t such a bad idea after all. Small discomforts that you overcome add up.

Just like a muscle, resiliency can atrophy. You use it or lose it. I spent two weeks in an intensive meditation retreat. I could handle anything you threw at me. But without daily practice, the mental toughness goes away, slowly, over time.

Action Item: Write down three uncomfortable things you’re avoiding. Do one.

The Payoff

The only thing that you take with you between jobs is you. The better your skillset, the more valuable you’ll be to more companies. The stronger your network, the easier it will be to get your foot in the door. Savings, resiliency, and interviewing practice will give you the mental confidence to weather the ups and downs of finding a new job.

You’re not preparing for disaster.

You’re building the kind of career where layoffs are just... inconvenient. Where recruiters chase you. Where you interview companies, not the other way around.

That’s real job security.

It turns out it starts much earlier, when no one is listening and you have to lead anyway.

For me, it began in a downpour.
Soggy boxes. Cold hands.
Wondering why anyone would follow me.

Since then, I’ve learned leadership isn’t one big moment.
It’s a few small ones that change you for good:

• the day I stopped pretending,

• the review I deserved,

• and the notes that saved a promotion.

Each one taught me a different truth.
Together, they taught me what leadership really is.

Earned in the Rain

It was a cold day in November, and I was drenched. I like sunshine and warm weather, but here I was in the rain, hands shaking, delivering food to volunteers. They were spread out in junctions outdoors, but at least they had some protection from the rain.

It was several months since a friend told me that as a manager I was, well, bland. Unremarkable. The kind of manager that no one remembers. That doesn’t change lives. I wasn’t really thinking about this when I carried the soggy food boxes. What I thought about was that I had no idea what I was doing.

This time, I was the youngest person in the non-profit. Everyone else was older, more experienced, and much more financially well-off than I was. Through some bug in the universe, I was in charge. My usual playbook, of pretending to be the perfect manager, just wouldn’t work in this situation.

I could try to speak confidently. Well, pretend to be confident and speak with authority. Be decisive and make the hard decisions without knowing all the facts. Because that’s the kind of things that leaders do, in the books.

But something changed for me that November day. My teeth chattering, my breath steaming, I stayed to talk with the volunteers. Mostly, I just wanted a few more minutes out of the rain. I was too tired and wet and miserable to try and “lead,” so I just listened. I stopped trying to hide my discomfort, I just let myself... be.

They were older and wiser. And they talked. And they listened. And they smiled.
Later, they did what I asked, before I even asked it. They chose to follow.

In that downpour, I realized that I don’t need to pretend. I can be myself, with all my quirks. My passion for Origami, folding complex beetles and dragons from a single uncut sheet of paper. Or my nerdiness with the math behind this folding.

Years later, at Meta, I picked up a square pink sticker.
It said: “Be the nerd.”

Whether you have authority or not.
There’s only one real way to lead.
And that’s to be your authentic self.

The Review I Deserved

It was supposed to be a formality.
I was sick, my head pounding, when my manager asked me to come to the office. I figured we’d wrap up a quick performance review and be done.

Instead, they cut straight to it. No preamble. Just the rating. Then silence. Space for me to read the feedback myself.

I skimmed it once. Then again. The words didn’t sting as much as they numbed. I wasn’t angry. Just detached.

I thought I’d done fine. My team was strong. We were shipping. But the review said something else: I was too focused inside the team, not enough on the broader organization.

At first, I disagreed. I rationalized. But over the next few weeks, I started following the suggested next steps. They worked. My performance improved.

Months later, I reread the review, and this time, it landed.
I saw the pattern stretching back years. I’d been optimizing for my immediate world, not the larger system around it.

That realization changed everything.
The next time I walked into a meeting with senior leaders—the kind that shapes the work of thousands of engineers—I didn’t just represent my team. I connected dots across the organization. I brought context they hadn’t considered. And the project changed direction.

That’s when I finally understood:
Leadership isn’t about owning a team.
It’s about serving the system the team belongs to.

The Notes That Saved The Promotion

It was supposed to be easy.
A promotion discussion for one of my engineers. The work was strong, the impact clear, and the reputation solid. I expected agreement all around.

Then a manager from another team spoke up.
They said my engineer had ghosted their team at a critical moment. That they couldn’t support the promotion.

I was caught off guard.
This wasn’t just a disagreement; it was new information, and it came from someone I thought was an ally. I kept calm, said I’d look into it, and promised to follow up. But I knew I had only a few hours before the decision would be finalized.

So I went back to my notes.
For months, I’d been keeping detailed records of every 1:1, stored in a simple system I’d hacked together with scripts and tags. I connected those notes to our shared project documents and found the exact week that manager was referring to.

The trail was clear. Their team had changed priorities and told us they no longer needed support. My engineer hadn’t disappeared. They’d simply moved on, as requested.

Armed with that evidence, I rejoined the forum later that day and walked everyone through the timeline. The promotion went through.

That experience taught me something I still carry:
The quiet systems you build when no one’s watching can change the outcome when everyone is.

Closing

The funny thing about leadership is that no one hands it to you.
You stumble into it.
In the rain.
In a performance review that doesn’t go your way.
In the quiet moments when you’re digging through notes to defend someone who deserves better.

Each of those moments stripped something away.
The act.
The ego.
The illusion that leadership is about control.

What’s left is simpler, but harder.
You lead by showing up as yourself.
You lead by seeing the system, not just your piece of it.
And you lead by preparing quietly, so that when it matters, you can act fast and stand firm.

Authority can be granted.
Titles can be given.
But leadership, that has to be earned.
Sometimes in the rain.
Sometimes in silence.
Always through the work no one sees.

And all of a sudden, I couldn’t type anymore.

Every morning I’d show up to work early, fire up GNU Typist, and learn how to type all over again. It took a few weeks to relearn how to type and my wrists thanked me.

It’s been a few years since this happened. I eventually switched back to a staggered layout (with the Ultimate Hacking Keyboard) and forgot about this whole story. Until I talked with John on the Coding Chats Podcast about the three stages of career development:

1. Craftsmanship

2. Leadership

3. Specialization

You don’t have to go through all stages. You can have a wonderful and fulfilling career focusing solely on your craftsmanship. If you do choose to go all the way, a $1M+ annual salary is just one of the benefits that you can unlock.

The trick is that “specialization” does not mean what you think it means.

Craftsmanship

But we have to start at the beginning. Software development is not an art. It also isn’t a field of engineering, despite the common framing. Rather, it’s a craft.

Learning touch typing is just one small aspect of honing the craft. Every tool you touch shapes what you can build.

Early on in my professional career, I’d spend time looking at how the compiler converted my C++ code to assembly. This investment helped me pierce through the abstractions and build a deeper sense of how my code actually worked. It paid off multiple times, especially when debugging or profiling a performance bottleneck.

Speaking of languages, the language itself is a tool. I believe strongly that you need to master a few diverse languages early in your career. You need to develop a deep understanding of a few languages so that you can understand the trade-offs in the language design. It’s this understanding that unlocks productivity irrespective of the specific language that you’re using.

Here’s a fun story. Two of my colleagues pulled me aside and asked me to help them work through some C code that wasn’t compiling. Everything looked correct, until I remembered that they were working with a compiler for an embedded chip. These compilers are notorious for being out of date with terrible error messages.

The problem? The compiler only supported an older C standard (ANSI C/C89/C90), where you had to declare variables only at the start of the function. I remembered this small piece of trivia mostly because Pascal enforced a similar constraint.

The bottom line, you have to develop your craft, and that means mastering your tools. The keyboard, your operating system, power tools, languages, compilers, profilers, experimentation frameworks, observability tools, etc.

Your craft is a moving target. The day you stop learning is the day you start falling behind.

But here’s what everyone misses...

You can spend 20 years getting better at the same tools. You’ll plateau around $300K. Maybe $400K at a top company.

The leap to $1M+ doesn’t come from mastering one more language.

Leadership

With a basic proficiency in your craft, you can start to build your leadership skill set. You need to become the person that others choose to follow. It is 100% a skill that you can build from the ground up.

I pushed back on making this jump formal several times, mostly because I didn’t feel I had invested enough in mastering my craft yet. When I did make this transition, the beginning was... rough.

For me, the “aha” moment happened when I was in a not-for-profit. All of a sudden, I had to lead people much older than me. People who had more experience and many of whom were financially much ahead of where I was. All of a sudden, I had to lead without any real authority.

I learned to be me.

I stopped pretending to be someone else. You see, I had a picture of what great leaders were like, and I tried to act like them. The moment I stopped trying to be someone else was the moment I really started my leadership journey.

It wasn’t any of the countless blogs or books that I devoured. It was a simple realization that I can still be myself and lead. All it took was a Brain Refactor.

This was me. You will have a different growth trajectory. Unlike the Craftsmanship stage, the learning is more personal. There is one piece of advice that helps most people.

Don’t be Frodo. Be Samwise Gamgee.

I learned this metaphor during my time at Meta. Anuja Jaiswal wrote an internal post that really struck a chord with me. Your job as a leader is to be the side-kick, not the hero. In fact, most of your job really is to make them the hero.

One of the biggest risks at this stage of your growth is neglecting your basic craftsmanship. Leaders who neglect this part will not just get stuck at the second rung of the ladder, they’ll actually fall behind. It’s a subtle shift, very hard to detect in real time, but it crashes careers.

Developing both is hard.
And if you can manage it, there’s one more step to climb.

Specialization

There are fun click-bait articles on the common traits of successful entrepreneurs. What do Elon Musk, Steve Jobs, and Rafaela Diamant have in common. Besides one trait (hint: open up relentless dot com), there really is very little in common.

The top 1% of the 1% are unique.

And if you aim to be at the top of your profession, then you too have to be unique. You have to be uniquely you.

I spent some time interviewing very senior individual contributors (ICs) at Meta. The most common trait that they had? They knew exactly what they were great at. And they knew what they weren’t great at.

For example, I once asked one such engineer for help with a project. They refused. They shared exactly why they were not the right person for this job, and suggested some alternatives. It wasn’t a bandwidth or focus issue, it just wasn’t aligned with their strengths. And they were laser focused on their strengths.

One of the biggest and hardest lessons that I had to unlearn is that I can identify my own strengths. And that you can’t identify your own strengths.

We all look at the world from behind our own eyes.
To see ourselves, we need a mirror.

When you practice your craft publicly, and when you lead others authentically, others can see you: your strengths and your weaknesses. If you have the courage to seek feedback, with purpose and great effort, then you will get your mirror.

You will see yourself.

And then embrace what you see. Double and triple down on it.

Summary

The path to the top of the engineering field is simple, even if walking it is hard.

1. Master the tools of the trade. Never stop learning and practicing.

2. Become a leader that people choose to follow. Be authentic.

3. Journey to find your strengths, then focus on them.

Several times in my career I ran very detailed and intimate feedback circles. These sessions let me see my own weaknesses and strengths. Any time I focused on my strengths, my career soared.

Then I became a solopreneur.

No more feedback circles. No more mirror.

I’m still figuring out what makes me uniquely me in this new chapter. Still learning which strengths matter when you’re building alone.

20 years in, I’m still on this journey.

Where are you in your journey?

Towards the end of this week I had an interview lined up with Amazon. Every spare moment I studied Amazon’s Leadership Principles and brainstormed potential stories. One of the first things I bought was a notebook, and throughout the week I filled it to the brim with notes and STAR structured narratives. When I finished a full day of interviews I was completely exhausted.

Lots of things surprised me.

The intensity of a full day of onsite interviews. The open-ended direction each interviewer chose to follow-up on my answers. How totally draining speaking in English for 7 hours straight would be. Or the tech difficulties I had to address with my recruiter to get my writing homework exercise through. Or that there even was a homework writing exercise.

These day, I coach managers and staff+ engineers trying to land their next job. And it’s not 2017, it’s 2025, and Large Language Models are a thing. If you’re in the job market today, you should use AI in your job search. Just do so efficiently.

Here’s exactly how I recommend clients leverage AI in 2025 to help them land their dream job:

1. Have the AI interview me to gather laser-focused context.

2. Have a separate AI conduct research on the current market conditions, guided by the data collected by the previous interview.

3. Put it all together into a daily coaching app that gives clear action items.

If you want to accelerate your job search then download the complete prompts.

The Interviewer

The corner stone of effective LLM usage is context management. I see people miss this key insight all the time. They jump straight into a coaching session with the AI without first providing the right context.

Think about it. The same AI helps people trying to find their first job in a fast food restaurant, children study for their math test, and scientists working on a ground breaking research. Without enough context, you’ll get generic and low quality responses. With the right constraints, you’ll get high quality and focused answers.

So how do you gather the right context? Here’s where most people miss out. The AI can’t help you with what it doesn’t know, and you can’t help the AI with what you can’t think about. The solution is to leverage the AI to extract the right data.

The general flow is:

1. Ask the AI to interview you, continuously adapting to your answers, to extract the right data points.

2. Summarize the entire interview as context for a separate LLM conversation.

I spent about 30 minutes answering questions about my goals, experience, and constraints. I’ve literally coached hundreds of managers in their job search, and I was surprised by how great some of these questions were.

The Researcher

The first AI gathered context about you. This second AI gathers information about the environment.

Starting with a fresh chat is important. LLMs have limited context windows. Quality goes down while latency goes up the more you fill up the context window. The anti-pattern that I see with clients is that they try to put everything into just one conversation session. And once they finish with that session, they start a new session with a blank slate!

Here’s what works. Collect information and then compress (summarize) it for a different fresh session.

The Coach

Finally, it’s time to put it all together. Instead of a chat interface, I recommend to build a bespoke app that is tailored just for you and your unique situations.

Most people default to the ... defaults. Which for LLMs is a chat interface. It makes zero sense that this interface will be the optimal interface for every situation. Going with the default chat interface may make sense for a one-off session, but not when you spend weeks (hopefully) searching for a job.

Build. Custom. Interfaces.

You can code one yourself, there are lots of great frameworks to make this easy. Or you can go the Claude Code route and have it create this app for you.

For this exercise, I went with a Claude Artifact. Using chat only, I created a dedicated coach with daily advice.

Summary

I eventually got the Amazon job. If I had to do it again today, I’d do many things differently. ChatGPT changed the rules. I charge hundreds of dollars for an hour of coaching. Now, most people can get 70% of the benefits that I offer for free.

But 97% of people waste their time playing with AI. Now you can be part of the 3%.

I was in a group meeting and this leader, with thousands of people reporting to them, asked me question after question about the people on my team. They wanted to know every little detail about each person. Their strengths, hobbies, passions, and weaknesses. They actually cared.

It was surreal.

I later followed up with them to understand why they cared so much. Their answer shaped how I think about building winning teams. About how I approach diversity.

Over the years, I built a four-step process to team composition. I’d love to share it with you.

Yep, that’s me. You’re probably wondering how I got here.

in medias res. That’s Latin for in the middle of things.

You start at the end, then begin your journey. It makes for interesting movies and stories. It’s also a wonderful leadership tool.

Before you figure out what your ideal team composition should be, start with what your team will accomplish.. Not what it needs to, not what it should, but what it will achieve. You can call it a vision statement if you want.

Examples:

• In three years, we handle Black Friday traffic every single day.

• In three years, our platform handles 100x current traffic with the same team size.

• In three years, our API is the industry standard that every competitor integrates with.

That’s the first step.
Invent an enticing future.
A “Big Hairy Audacious Goal.”
(A BHAG, pronounced “Bee Hag.”)

Yep, that’s you.
Now wonder how you got there.

Outputs

Let’s take ‘making our API the industry standard’ as an example.

How do you get there? What needs to happen for this to be true?

In this example, these can be:

• 1k+ developers use implementations of our standard.

• A member of our team is on the relevant standards committee.

• Two major companies publicly commit to implementing this standard.

• A major standards body (W3C, IETF, etc.) adopts our API specification.

• Three competitors integrate with our standard instead of building a competing API.

Inputs

Now, let’s continue. What needs to be true about our team for us to achieve these outcomes? What behaviors, skills, knowledge, or connections do we need to have?

For our example:

• Standards Presence - Active participation in relevant standards body working groups (attending 80%+ of meetings)

• Industry Network - Existing relationships with decision-makers at 5+ major tech companies in the space

• Proven Track Record - Successfully shepherding at least one technical proposal through a standards process

• Specification Writing - Ability to write technical specifications that pass standards body review on first or second iteration

• Domain Expertise - Deep expertise in the specific protocol/API domain being standardized

• Public Credibility - Speaking/publishing presence in the technical community (3+ conference talks or papers per year)

• IP Navigation - Understanding of IP/patent implications and ability to navigate legal considerations in standards

• Consensus Building - Skill at building consensus across organizations with competing interests

• Long-term Commitment - Patience and willingness to work on 3-5 year timelines

• Strategic Positioning - Strategic thinking to position the standard for broad adoption beyond just technical merit

This gives you a clear and specialized list of competencies that you need on your team. It is tailored exactly for achieving the BHAG that you set out to achieve.

Here and now

Finally, let’s get back to the present. You have an existing team, a group of humans.

Give every person a 1-5 rating on each dimension:

The purpose of this exercise is to identify big gaps in your ability to achieve the future that you invented. A great way to see these gaps is to use Radar Diagrams, which display the above table visually:

It’s now clear that your team is not very diverse. Not diverse in the ways that matter for your unique situation.

With it, you can:

• Hire new people, starting with a very clear job description.

• Get specialized training for people already on your team.

• Partner with Subject Matter Experts (SMEs) in your company, such as Legal.

• Tune growth plans. Match personal career aspirations with closing gaps, such as sending Sam to standards meetings.

• Get a budget to hire consultants.

The Four Step Process

To recap:

1. Invent a compelling future.

2. Identify what needs to be true for this future to materialize.

3. List all the team competencies that you need to make these things true.

4. Assess your current team against these bespoke competencies, and plan how to close the gaps.

When that senior leader grilled me, this is what they were getting at. They wanted to understand how I built my team. What I was looking at. How close I was to the details.

Winning teams have both a big hairy audacious goal and dive into the details to make it happen.

To follow up on Anton’s Dungeons and Dragons inspired post, great leaders are like Gandalf. They figure out what they need to accomplish, then build a specialized team. A team where every person brings unique strengths that are necessary to make that impossible heist a success.

That’s what my Gandalf taught me. Now I’m passing it to you.

If someone is surprised by their performance review, you’ve failed as a manager.

I definitely failed at this.

Early in my career I shied away from small uncomfortable conversations. Big discussions? I could handle those. I’d prepare mentally, deliver the harsh truth, push through the discomfort.

Regular feedback? Not so much.

People on my team got blindsided. I can still remember David’s face during his review. The confusion when I mentioned concerns about his work. Then the switch - jaw tightening, eyes narrowing. “Why didn’t you tell me sooner?”

I didn’t have a good answer.

As I learned to embrace the discomfort and started sharing more consistent feedback, I got better. Fewer surprises. More trust.

But I realized something new.

You can minimize surprise, but you can never completely eliminate it. As hard as you try, some things fall through the cracks.

Why?

Management is constantly failing at eight things so that you can crush the two most important priorities.

So you need to learn to fail well.

Three steps:

1. Acknowledge the mistake

2. Do the right thing anyway

3. Learn from it, with compassion

Acknowledge the Mistake

I remember sitting across from Marcus, about to deliver devastating feedback.

For months, I’d been expecting senior-level work. He’d been delivering solid mid-level work. The gap? My fault. I never told him what senior-level actually looked like here.

This wasn’t my first time screwing up calibration. In the past, I’d just delivered the hard news. Plowed through. Hoped they wouldn’t notice I’d failed them first.

It doesn’t work.

This time, I started differently.

“I need to own something first. I should have told you months ago what senior-level looks like here. I didn’t. That’s on me.”

His shoulders dropped slightly. Not relief exactly, but acknowledgment that we were in this together.

Then I delivered the hard feedback anyway.

That’s the first step. Acknowledge that you messed up. Not to soften the blow - it won’t. Do it because it’s true.

Do the Right Thing Anyways

Here’s where many managers fail.

When you deliver hard feedback, the conversation is about them. Your job is to help them grow. To support the team and the project.

It’s not about you.

But when you acknowledge your mistake, you make it about you. And there’s a danger in this.

We all have defensive mechanisms that kick in when we hear things we don’t like. The person getting feedback? Their defenses are in overdrive.

When you say you messed up too, they latch onto it.

After I acknowledged my mistake to Marcus, I watched it happen in real time.

“So... if you’d told me earlier, I could’ve fixed this?”

Yes. True. Also irrelevant to what we needed to discuss.

“Maybe. But we’re here now. Let’s talk about what senior-level looks like going forward.”

Your apology becomes their deflection. It blocks their growth.

I’ve done the opposite too many times.

You acknowledge you should have shared feedback earlier. Their performance now means a lower rating or they need to leave. Because you know you could have done better, you share this news with guilt written all over your face.

Their defenses pick up on it.

So you roll back your feedback. You delay.

Everyone loses.

The project suffers. The team suffers. You suffer. Even the “low performer” suffers.

Here’s what to do instead.

Do the right thing even if it hurts. You screwed up, yes. That doesn’t mean you get to avoid the hard call.

Learn From It; With Compassion

Later, once the dust settles, that’s when you learn.

Marcus’s performance didn’t magically improve after our conversation. But something shifted. We both knew where we stood. No more ambiguity. No more surprises.

Three months later, I sat down to review what went wrong.

I could have set clearer expectations in month one. I could have checked in at month three when I first felt the gap. I could have asked him what success looked like instead of assuming.

I couldn’t change the past. But I could change my next hire’s onboarding. I could change how I checked in with the team.

Six months after that, I almost made the same mistake with someone new. Caught it earlier this time. Still not perfect - I should have caught it even earlier - but better.

That’s the goal. Not perfection. Better.

You’ll mess up again. Different people, different situations, different mistakes. Management is constantly failing at eight things so you can crush the two that matter.

Learn to fail well.

So what mistake are you avoiding right now? What hard conversation have you been pushing off?

And you didn't even drink your morning coffee yet.

Now all eyes are on you. The agenda for this meeting is to make some decision. The team came up with several options and it's up to you to make a call. Emotions are high. A wrong decision could lead to throwing away months of work or damaging user trust.

If you've been a manager for a while, this probably sounds like a typical Tuesday.

Your job isn't to make a decision. Your job is to make the best decision with the information that the team has. It's to leverage your experience to help this group of humans uncover the landmines below the surface. The secret is to ask the right questions. Questions that go deep and cause everyone to think harder.

Managers are professional question askers. By the end of this post you'll be able to ask high-signal questions quickly. You'll learn The Hat Analogy, the Mental Walkthrough, and the Question Vault, all powerful tools to add to your leadership toolbox.

So put on your Sherlock Holmes hat, and let's get started.

The Hat Analogy

One of my proudest creations as a tech lead is the Hat Analogy for code reviews. After years of writing and reviewing code, I developed a process that helped me consistently catch bugs in critical code. As I grew in my leadership role, I started teaching this process to others.

The main concept is simple. When you review code, review it in several focused passes. In each pass you look at the code and try to answer a single question. Once you're done with the pass, go back and review the code again, this time trying to answer a different question. These questions are:

1. Does the code do what it says it does?

2. Is this code easy to maintain?

3. How can I break this code?

Over the years, I slowly added questions to this list. For example, I broke down that last question to focus on Usability, Security, and Privacy. The foundation never changed: a targeted multi-pass review of the code led to higher quality software.

I called this process the Hat Analogy.

You start reviewing code wearing the "white hat" and finish it with the "black hat." From an optimistic view of the world to a cynical and pessimistic view. What happens at the edges of the inputs? What unexpected input behaviors can I engineer that will cause the code to break?

This same analogy served me well as a manager too. Instead of looking at lines of code, I used it to review product trade-offs, software architectural decisions, and even organizational design dilemmas. Whenever the team came up with several proposals, I methodically took out hats from my mental box and wore them one at a time.

The Black Hat of the insidious user is always useful. This is a common blind spot of most engineers. Most builders are optimistic by nature, that's the only way to invent a future that doesn't yet exist. The real world is not as forgiving. Yes, even organizational politics in your perfect company.

This hat analogy ended up pairing well with another tool that I learned from a very senior leader early in my leadership career.

The Mental Walkthrough

Do you have a morning routine? Maybe you wake up at 5:00 am and start your day with a cold plunge. If so, great for you. If you're like me, it likely involves more grogginess, prepping food for the kids, and pushing everything forward. And coffee.

We are creatures of habit.

These habits make our lives easier. They also, slowly, blind us. To the wonder of existence and everyday life. Also to user journeys, the struggles of new grads, and the challenges of people who are not native speakers.

When we're in a meeting with a group of humans who worked hard to come up with several potential paths forward we can't be blind. Our habits, at work and in our personal lives, can prevent us from finding the best outcome. The people in the room likely have somewhat similar lived experiences and therefore similar blind spots. Our job is to push through all of this conformity.

The Hat Analogy helps you be conscious in bringing in diverse user personas to these discussions.

The Mental Walkthrough lets you become these user personas. It's a simple thought experiment. Imagine yourself as this persona in a situation that's relevant to the discussion at hand. Then mentally go through the step-by-step actions that this user needs to take. As you're going through this story in your mind, try and find the challenging situations.

For example, if you're debating how to restructure the org to adapt to the latest leadership directive, wear the hat of a specific individual contributor (IC) in your team. Picture yourself as this IC when you hear about the reorg announcement. What are they in the middle of? What are their current personal goals? What will they be afraid of?

Now, start the clock and move forward in time. How will the reorg play out for this specific person? How fast will it be, and what will change about their daily work? When they get back to the office the next day, will they need to change desks?

This thought experiment doesn't take a long time to go through. It can help you identify critical blind spots. Maybe you didn't consider that in Option A of the new org structure three-quarters of the people working towards a promotion will now report to a new manager? Should that be a consideration in how you plan out the reorg?

The Hats Analogy brings structure in how you apply diverse viewpoints to problems. The Mental Walkthrough is an empathy supercharger that lets you dive deeper with each hat. As you employ these two tools you'll be able to ask more powerful questions that lead to higher quality decision-making. And over time, you'll slowly find yourself repeating some of these questions. That's where the third tool comes in.

The Question Vault

Half of leadership is asking the right questions at the right time. Great leaders treat questions seriously. They are question connoisseurs.

Start collecting questions.

I keep a bank of what I call "Power Questions." These are questions that are great at piercing through the noise in a broad range of situations. Questions like: "What problem are you trying to solve?"

Say you're in a heated debate on how to fund a new request from product. When you ask this question, "what problem are we trying to solve?" you enable everyone to take a step back. Why are we even trying to build this new feature? Why does it even matter? In what way? Maybe we can achieve a similar outcome with a quick test to validate the value first?

Or maybe you ask: "How would we accomplish this in one-tenth the time, if we absolutely had to?" The answer may be a hacky cron job that would work most of the time. Throw in some alerting, and this solution may do the job for a few months.

Power questions tend to make everyone reconsider their assumptions and find more creative solutions. As a leader, you have to keep your eyes open and look for power questions. Collect them like my son collects Pokémon cards. Cherish each and every one of them. Put them in your binder and review them, reverently, every once in a while.

Start building your Question Vault.

Summary

The Hat Analogy, the Mental Walkthrough, and the Question Vault are excellent tools to cut through the noise. They will help you adapt quickly to whatever meeting you stumbled into.

Even if you haven't had your morning coffee yet.

The session went well, but honestly? I was feeling pretty deflated.

I knew from interviewing other course instructors that first lessons get the lowest ratings. I also knew my first session lays the foundation for everything else. It takes time to build on these concepts before students really get them.

Still felt discouraging.

So there I was, going over the session with Izzy. At the time, I didn't know how those ratings would completely change. And Izzy shared exactly what I needed. Some tips I'd given others but couldn't see in myself. Others were completely new ways to look at growing leaders.

These lessons? They apply to you too.

As a manager, you're a part-time teacher. That's part of what makes this job so exciting and infuriating. You have to be Everything Everywhere All At Once. Sometimes you're a teacher. When you manage managers you're both a teacher and teaching the teachers.

Warning: this post might make your head spin. See if you can count all the different levels of meta.

Practice What You Preach

As managers, we lead whether we want to or not. Sheryl Sandberg told a great story to drive this point home at Meta. It's the story of the "Gold Problem."

It was 1990 and Ron Rubin was ramping up as the new CEO of Goldman Sachs. Each day he toured a different part of the business. One day he walked the trading floor. Standing behind one of the analysts, he casually mentioned that "gold looks interesting." At the end of the week, he reviewed the company's books and noticed something strange. For some reason, the company owned a large amount of gold. After some digging, it turned out that his casual remark earlier in the week led to the analysts buying tons of gold. Because that's what they thought their new CEO wanted.

Sheryl shared this as a cautionary tale to us managers. As leaders, people look up to us. They listen when we talk, even when it's a joke or an offhand remark. They notice what we say, how we say it, and what we don't say. Your team will invent meaning to your actions (or inaction) in ways that you can't even anticipate.

My interpretation of this has always been a defensive one. Minimize jokes. Try to be on your best behavior at all times. Be cautious about how you react when you're surprised. It was only Izzy's feedback that made me look at this leadership challenge in a different light. I shouldn't fight this reality. I should embrace it.

When you can't change the direction of the wind, adjust your sails."
-- H. Jackson Brown Jr.

Instead of always having a background thread that's worrying about all the ways that people will misinterpret my behaviors, I should tackle this challenge on the main thread. I need to pre-compute ways to leverage this reality.

You need to prepare a script.

This is what I did before our second session. After gathering the rating for the first session, I followed up in private to drill down into the challenges and strengths. This led to concrete lessons, most of which I could address by our second session. Previous version of me would have left it at that. But I knew that one of the topics for the second session was about earning trust. And this was the perfect opportunity.

I talked openly about what I learned. I was honest about what I could have done better and focused on what I learned. Then, I climbed the meta-ladder and talked about how this is what leaders should do to earn trust. This was an example of what the students can do in their own job.

Then Izzy upped it a notch.

Tell Them What Showed Told Them

Here's what Izzy taught me.

When you show leadership by example, most people miss it.

The challenge with the Gold Problem isn't just that people will misinterpret you. It's that you have no way of knowing if your intentional examples even landed. You showed them something valuable, but did they notice the lesson?

So talk about it.
You already showed. Now you tell.

When I talked to the students about the changes I made based on their feedback, I told them that this was an example of how they should share their mistakes with their teams. Of how this was a tool for earning trust. I made this lesson explicit.

I also told them that this was another example of "practice what you preach." That this is an example of taking ownership of how you show up. Because managers are teachers, so we have to climb the meta ladder.

One key point. You should tell, not shout. Make it a side-lesson. Call it out briefly, then return to your main focus.

Expectations

Back to that first lesson. There were tangible ways to make it stronger. It also had an inherent challenge. I teach a foundational system that enables the rest of the course. It takes several interactions before everything clicks.

It's an inherent part of these systems.

That doesn't mean that I can't do better. Because as leaders, we have two fundamental levers that we can pull. We can influence reality and we can influence expectations. Reality and expectations.

All of suffering happens in the gap between expectations and reality
-- Poppy James

Before big meetings or high-stakes interactions, you need to figure out what expectations you need the other humans to have at the end. Then, you need to create a communication plan so that you can create this alignment on expectations.

For me, this means over-communicating on the outcomes of the first session. I did talk about it, but mentioning something once is a rookie management mistake. I should have talked about it multiple times. I should have repeated it verbally and in writing. In the syllabus, the written material, and the summary. I should have made it very clear what to expect at the end of the first session versus the end of the course overall.

Managing expectations means narrowing the gap between the expectations and reality. It means reducing suffering in the world, and that is a worthy goal any time.

Your Action Items

How can you apply these lessons in your job?

Think about your next large meeting. This could be a presentation to senior leadership or your daily standup. Go over the topics on your agenda and plan ahead. What can you do or say to "practice what you preach"?

For example, let's say that the team needs to manage time more proactively. How can you manage time in the meeting more deliberatly? If you never finish your sprint tickets, can you manage the next standup so that you go through all the topics on schedule? How do you make that happen? Then, mention that you used the standup as an example of proactively managing time.

What are some possible pain-points that may come out of the next meeting? Which of these pain points can you solve? For the remaining points, how can you proactively manage expectations?

In our example, you may need to cut people off in the middle or ask them to get to the point. If that's not how your regular stand-ups run, then you have to reset expectations. Call it out at the start of the standup. Then, for the first few times you interject, repeat the new expectations.

When I applied these lessons, I could see the results by the end of the next session. Student rating went up, exceeding my expectations. The great thing is that preparing my script of what to share for each session takes just a few moments. It usually comes up naturally during my runs or when I'm doing the dishes.

Are you going to try this out?

In the next post we’ll talk about the hidden danger of buffers and how to manage stakeholder expectations.

But first, there's something we have to talk about: AI.

In today's post, you'll learn how to use Large Language Models (LLM) to further improve the accuracy of your estimations. I'll cover three tips, including one that 95% of technical people don't know about. Let's get started.

Prompting for Feedback

Instead of using LLMs to write for you, use them to critique your work. There's a lot of information out there about writing high-quality prompts. And frankly, it's still a moving target.

Luckily, you don't have to know too much here. I fired up Claude and asked it to:

I want to write a high quality prompt. Ask me questions until you are highly confident that you can craft an excellent prompt for me.

I'll spare you the full back and forth. Here are some of the instructions I shared in response to the AI's questions:

I want to use AI to critique my project estimations. For context, I'm a software development manager.

We usually plan one half ahead. My team has 7 software engineers and we typically work on one big project and 1-4 small projects per half. We're using the estimation methodology described in this post: https://posts.managementdeltas.com/p/your-estimates-are-lies-heres-how My main goal is to meet or exceed stakeholder expectations.

and:

I'll share a 3-point estimation spreadsheet and another text document listing the assumptions I made, such as dependencies on external factors. In the prompt, leave a placeholder for me to include my recent estimation mistakes and pain points. I want the AI to help me identify methodological mistakes as well as technical blind spots.

This was enough for Claude to create a reasonable starting prompt:

# Project Estimation Critique Prompt

You are an expert software engineering consultant specializing in project estimation and risk assessment. I'm a software development manager leading a team of 7 engineers, and I need you to critique my project estimation for the upcoming half (6-month period).

## Context

- My team typically works on 1 large project and 1-4 smaller projects per half
- We use three-point estimation methodology (best case, likely case, worst case) with PERT distribution
- My primary goal is to meet or exceed stakeholder expectations
- I want to identify both methodological mistakes and technical blind spots

## What I'm Providing

1. **Three-Point Estimation Spreadsheet**: Contains task breakdowns with best/likely/worst case estimates
2. **Assumptions Document**: Lists dependencies, external factors, and key assumptions I've made
3. **Recent Pain Points**: [PLACEHOLDER - Insert your recent estimation mistakes, missed deadlines, or recurring issues]

## Please Analyze and Critique

### Estimation Methodology Review

- Are my task breakdowns granular enough, or am I missing intermediate steps?
- Do my best/likely/worst case scenarios seem realistic given the task descriptions?
- Are there patterns in my estimates that suggest systematic bias (too optimistic/pessimistic)?
- Am I properly accounting for integration complexity between tasks?
- Are my confidence intervals (using PERT distribution) appropriate?

### Technical Risk Assessment

- What technical risks or dependencies am I potentially overlooking?
- Are there tasks that seem underestimated given their technical complexity?
- Do I have adequate buffer for integration testing, debugging, and rework cycles?
- Are there potential performance, scalability, or security considerations missing?
- What external API dependencies or third-party integrations could cause delays?

### Team and Resource Considerations

- Given a team of 7 engineers, are there resource bottlenecks or single points of failure?
- Are there knowledge transfer requirements or skill gaps that could impact timelines?
- Do my estimates account for code review, testing, and deployment overhead?
- Are there tasks that require specific expertise that might not be immediately available?

### Stakeholder Expectation Management

- Based on my assumptions, what are the highest-risk items I should proactively communicate?
- Which estimates have the widest confidence intervals and need careful stakeholder communication?
- Are there any "unknown unknowns" that could derail the project timeline?
- What early warning indicators should I track to detect estimation drift?

## Output Format

Please provide:

1. **Overall Assessment**: A summary of the estimation quality and key concerns
2. **High-Risk Items**: Top 3-5 tasks or assumptions that are most likely to cause delays
3. **Methodological Improvements**: Specific changes to my estimation approach
4. **Technical Red Flags**: Technical risks or complexities I may have underestimated
5. **Stakeholder Communication Plan**: What to communicate upfront vs. what to monitor
6. **Follow-up Questions**: Questions I should ask my team or stakeholders to validate assumptions

Be direct and specific in your feedback. I'd rather hear uncomfortable truths now than discover them during execution.

If you want to improve this prompt, ask another AI model to critique it. Most importantly, try it out and tweak it.

Save this prompt. If you don't already have a prompt library, then you should start one. I use Obsidian, but you can use Notion or just a dedicated folder on your machine.

Prompt for Growth

You may have noticed that placeholder I asked the AI to prepare for me. One of the best uses of AI is to use it to amplify and accelerate our personal growth.

The trick to fast learning is to use it on the job. You can use LLMs to surface your growth areas and give you advice exactly when you need it. Instead of you prompting the AI for growth, you should have the AI prompt you for growth.

The way to accomplish this is to have a single global personal growth document. Make sure to feed this document into all of your prompts. This way, the AI can take into account what you're working on right now when it gives you advice on whatever it is you're asking it.

Say you are not in the details. You delegate many of your tasks and don't have the systems to know what's actually going up. This appears in your global growth list. When you use the estimation prompt, the AI will connect the dots between this personal growth area and potential misses in how you scope various tasks without consulting with your team.

Connecting dots is at the heart of modern LLMs and their attention mechanism.

Prompt for Pain

LLMs are trained to please us. If you want to get brutally honest and highly influential feedback then you have an uphill battle to fight.

"Be brutally honest."
"Give me constructive feedback."

or my favorite:

"You are my devil's advocate."

These are all reasonably starting points. They work ... okay.

There's one trick that will help you get much higher quality feedback. Instead of fighting the uphill battle, embrace it. All you have to do is lie. Instead of telling the AI that you are the software manager, tell the AI that you are the stakeholder.

Ask the AI to critique the latest estimation plan that you, the Product Manager, got from your engineering counterpart. You can still list out all of the past mistakes, just frame them as the mistakes of this specific EM. Likewise for the growth areas.

This small trick works surprisingly well. You will leverage the AI's training to please the user to trick it into giving you more brutally honest feedback. And as a nice bonus, you will also develop a deeper appreciation for what your stakeholders are going through.

Summary

We covered three LLM prompting tricks:

1. Use the AI to write the prompt for you.

2. Embed your growth areas into all of your prompts.

3. Create a real Devil's Advocate prompt by fooling the AI that you're the Devil.

What other uncommon tricks do you use?

It's September 2025 and I haven't been this busy in months. The last Manager Operating System cohort of the year starts next week. I partnered with an education science expert to completely shred how I teach, which means tons of unexpected work. On top of it all, my wife will be out of the house and I have four kids to take care of.

I have a choice to make. All of this is on top of my regular work and commitments. I can work into the night and compromise on sleep. Or cut some of my grounding activities, such as exercise and learning Arabic. I can also cut back on time with my kids.

If you're an engineering manager, this should sound like your typical week. An endless stream of tasks and all of them are critical and due yesterday. I learned the biggest tool to thrive in the chaos during my onboarding to Meta.

The Problem with Being Busy

A few years ago, in a 1:1 with a strong senior engineer, I brought up the subject of working towards a Staff level promotion. They were happy where they were. They had good work-life balance, good performance, and were good at their job. Meeting next level expectations meant working longer hours and compromising on what they cared about. Which is all reasonable, just not necessarily true.

There's a common misconception that each new title means longer working hours. That the only path "up" in the career ladder involves working longer hours. More hours means more performance. Except that it doesn't pass the sniff test. If that were true, your typical Principal Engineer wouldn't have time to shower or eat.

More senior engineers are better at creating value. They pull bigger levers and scale their impact.

Another common mistake is to believe that x10 engineers exist...and that's it. These engineers 100% do exist, they're just rare. In my career I've worked with a literal handful. The issue is that x10 teams also exist, and that they are in fact much more common.

It's a hundred times easier to build a x10 team than it is to find and hire a single x10 engineer.

There are several ingredients to a x10 team, but the most fundamental one is ruthless prioritization.

The Pedestal of Focus

One thing that Meta does better than most companies is support new engineering managers. Picture this: I'm a few weeks into being an EM at Facebook, in a meeting with a few dozen other managers. Sheryl Sandberg is on the stage, sharing from her experience. My biggest take away from that day was the concept of "Anti Goals."

Back when Facebook was a smaller company, already printing money from ads, everyone at the company had the same idea. Create an ad network. It sounded like a great idea. It was an excellent idea.

But there were even more important ideas to work on first.

So Sheryl introduced the concept of the Anti Goal. In the end of every planning cycle, the idea of the ad network came up, and it was never the right time to work on it. It was "below the line." But instead of letting it go at that, Sheryl put this idea on a pedestal. She put the spot light on this great idea that everyone was not working on.

When changes, interruptions, and new requests came in during execution, there was now a bar they had to pass. Is this new ask more important than working on the ad network? The answer was always a clear "no." And this made it easy to say "no" to these distractions and focus on what matters.

Anti Goals help you focus on the most important work.
Anti Goals help you scale focus on the most important work.

It is an amazingly useful tool.

But it's much more than that.
For me, this was the moment it finally clicked.
Real impact is not about addition, it's about subtraction.
Outsized impact is first and foremost about what you are not doing.

The Three Pillars of Prioritization

I've seen countless x10 teams. There is no greater professional experience that being a part of a x10 team. The key ingredient is what the team builds, more than how they build it.

It's about Ruthless Prioritization.

Here are your three pillars to building what matters.

Pillar 1: Align Before You Execute

Your first job is to talk to people. You have to do this very early, long before you even think about planning and prioritizing the team's work.

There are three key outcomes for these meetings:

1. Figure out what matters.

2. Create alignment on what matters.

3. Build peace time relationships.

The secret to x10 output is knowing what work creates x10 output. This sounds trivial, borderline tautological. The issue is that most of the work that's passed around in Jira tickets, Epics, or large meetings with Product Managers don't create x10 output. Most of the time, you will have to do work to find the x10 work.

You will have to invent this work.

The only way to be able to do this is to build a deep understanding of the both the business and technical landscape. You have to invest hours talking with your leadership, business partners, product managers, finance partners, and more. Have meetings to learn about their perspective but also share your ideas and ask them to shred them to pieces. It will take reps and effort.

Once you build this sense of what matters and invent the x10 work (with your team), you need allies. You need to drive alignment with the key leaders and stakeholders that this work matters. Creating a clear narrative, a captivating story of the impact is important. Your job is to create a shared picture of success.

The alignment helps during planning. The relationships will help during execution. Things won't go smoothly because, well, they never seem to go smoothly.

Pillar 2: Prioritize Until It Hurts

You found the x10 work. More likely, you had to sweat and work hard to identify these projects. Then corporate reality crashes your hopes and dreams.

Don't be discouraged. Corporate reality is really just hundreds (thousands) of humans, each trying to do what they think is best. You're smart and brilliant, just don't forget that they are too.

This means pain.

You will have a long list of asks to prioritize. It's all nice and good that you have alignment from your leadership on just how wonderful your project is. That doesn't stop other people from needing your support for their projects. And these other people include the people in your team as well. That technical debt project that your tech lead is passionate about. Or the new feature that your engineer is banking on as their promotion project.

Lots of work that is valuable and important and a net benefit. All work with a positive ROI, and the data to prove it.

The secret with x10 teams? They don't do any of that.

They face the pain of uncomfortable discussions and dashed hopes, and move forward. They throw great ideas to the backlog. Amazing projects to the graveyard of "next time."

If you prioritize your team's work and don't squirm in your chair, you are not prioritizing hard enough.

Pillar 3: The Anti Goals

You did the work (to find x10 projects).
You faced the pain (to drop everything else).
Now you are ready to execute and reap the benefits.

And then, when you don't notice, you wake up one day and notice that you're not accomplishing anything. You're finishing projects, landing impact, doing good work. Just not the great work that you set out to do.

The distraction is subtle. Small asks creep in. Tiny favors from partner teams and your PM. Just one tiny project to pick up. There's always a good reason.

Yes, sometimes it's a really smart Product Manager that got the "no" during planning and circled back later, when you weren't paying attention. That started with a really small ask midway through the project, and then had another ask, and another. Then, before you notice it, you're working on a completely different project. They are not evil, they are just motivated and competent.

Your best protection is the Anti Goal.

Set this exactly after you walked through all of the pain during planning. When everyone is still hurting. That's when you can identify the biggest work that you are not doing. Harness the pain to put this project on a pedestal.

And then refer to it, any time even a tiny ask comes through.

The Results

I'm a solopreneur right now. In many ways, I have it easy right now. I have CEO-level understanding of my business. Sure, a crappy CEO who has no idea what they're doing. But a complete picture of all the five pillars of business, including Marketing, Sales, and Finance. And I don't have to drive alignment with dozens of humans on the direction to go through.

And it's still hard to focus.

I have an Anti Goal for each month. I'm itching to work on September's Anti Goal so much right now. I know that it will improve both the financial rewards and my work-life balance. I actually have the data to back it up. But I'm not working on it right now, thanks to my Anti Goal. You'll have to wait a few more weeks to hear what it is. Hey, I can't be the only one on my toes...

As an Engineering Manager, you have it harder. You need to build a deeper understanding of your business, when you're just not exposed to many aspects of it in your regular work. And after you find a golden opportunity, you have to create alignment with your leadership and stakeholders. You have to push through hard conversations, crushed hopes, and disappointed team members.

And then you have to maintain the focus throughout.

The outcome is x10 performance. Not for yourself, but for your entire team. That's the stuff that transforms the career trajectory of a dozen humans at once.

What's the one project your team should put on a pedestal?

I like to read books that stood the test of time.
One of my favorite books is the 80 years old book, "How to Read a Book."

I like to read small books like Sun Tzu's "The Art of War."
And I like to read huge books, like Clausewitz's "On War."

So when Mario Caropreso wrote an article about management and positioning, I was intrigued. At first I thought it was positioning from a branding perspective. Then I realized it's positioning from the realm of military leadership.

There is so much to learn from military leadership.
There are so many things to avoid transferring into out lives.

In this post, I'll walk through where Positioning fits into military planning, what we can learn from this as engineering managers, and share general advice on how to effectively learn from adjacent fields.

SMEAC and Other Acronyms

Most Western armies have a standardized process for planning military activities, called the Five Paragraph Order. Here's how this looks like in the US Marine Corps: SMEAC.

If there's one field that likes acronyms even more than tech, it's the armed forces. So let's break it down:

1. Situation

2. Mission

3. Execution

4. Administration and Logistics

5. Command and Control / Communication

The structure is pretty simple:

1. Situation: Where are we right now? What's "point A."

2. Mission: What do we want to achieve? What's "point B."

3. Everything else: How do we achieve it? How do we get from point A to point B.

This structure brings a lot of clarity. I also love the way it puts the most weight on the How, while still placing it last in the ordering.

Positioning goes in the last paragraph. It details where the Commander will be at each stage of the tactical operation. Because leaders can lead from the front, and they can lead from the rear. Marco's post explores one aspect of these tradeoffs in detail. There are other aspects, such as morale.

What Does it Mean to Me?

Marco's post is worth a read to see how to translate Positioning into Engineering Management. There's a time to dive deep into the details and a time to take a step back and look at the bigger picture. Every great manager knows that you need a mix of both, with the balance shifting based on the situation. Jeff Wilke did a great job teaching this skill.

There's much more to learn from the 5-Paragraph process.

It's a simple process that brings clarity to a complicated organization that needs to move thousands of humans towards a common goal in a short amount of time.

The structure itself is worth learning from. If you're familiar with the STAR1 format from your interviewing days, it should look pretty familiar. The only difference is the ordering: Situation, Result, Task, Action. This is because the Five Paragraph Order is a forward-looking narrative structure, whereas STAR is backwards-looking.

Don't discount the importance of narrative structure in your management role.

I can go on for several hours on what you can take just from this version of the Five Paragraph Order. The full version has much more details and carries many other lessons.

But I want you to take a step back.

Why should we learn from Military Leadership in the first place?

The answer should be simple.
Military Leadership is like Engineering Management, just a 100 times harder:

• The pay is lousy.

• The risk isn't being fired, it's death.

• There's no 9-5. Not even 996. It's 24/7. Literally.

• Your competitors are trying to kill you and play dirty.

So it makes sense that there's a lot to learn here.

How To Learn

Except that it doesn't make sense at all to learn from Military Leadership.

If the people on your team don't like you or the job, they can just quit. That's not really an option during war.

Military leaders have to think about so many things that you just shouldn't waste your time on. Your offices have working bathrooms, for example.

So what am I saying?
I'm saying that you need to do Transfer Learning.

Say you want to build an app that takes photos of cars and tells you what they are worth. You need a classifier model that identifies which car it is. Training such a classifier requires a lot of data. If you're wise, you'll cheat.

Instead of training a model from scratch, you'll train an existing model. You'll take a model that can classify cats, and train it on cars. This is called Transfer Learning.

This works well because some layers of the cats-model do work that's relevant for all vision models, like detecting edges. Other parts of the neural network are not relevant, and they will diminish in weight through the (re)training process.

This is exactly how you should approach learning from other fields.

The more in common that the adjacent field has with engineering management, the more you can take away.

You just always have to be careful to identify what is not relevant for engineering management.

Summary

Early career engineers often ask me if they should be generalists or specialist. The right path depends on the individual, but my general bias is towards being a generalist, at least early in your career. The more fields of software engineering that you get to experience, the deeper understand you'll have of engineering overall.

And it doesn't have to stop at engineering.
Your existing experience, from your hobbies to your past career, are valuable.
Spend the effort to figure out what learnings are valuable in your new career.

You'll be surprised how much learning is transferable.