Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

I have been managing engineers for about seven years now. Like most engineering managers, roughly half my time goes to technical work: architecture decisions, code reviews, unblocking. And the other half goes to people management: 1:1s, career development, goal-setting, and performance reviews.

For the past year, every engineer on my team has been using Claude, Copilot, or similar. They write code faster, debug faster, learn new codebases faster. AI has genuinely changed how they work.

Meanwhile, I was using the exact same tools but only for my technical work. The management half of my job? Still 100% manual. I’d spend hours every month clicking through Linear, re-reading ticket descriptions, cross-referencing Slack threads, and trying to reconstruct what each person actually shipped all before writing a single word of a performance review.

It took me an embarrassingly long time to ask the obvious question: why am I not using LLMs for the tedious part of my job?

This post is about what happened when I did.

Why performance management is so damn hard

Before I get to the AI part, I want to be honest about why performance reviews are difficult. Not “I don’t like doing them” difficult. It is structurally, systematically difficult.

The data problem

A performance review is supposed to be an evidence-based assessment of someone’s work over a defined period. In practice, finding that evidence is extremely difficult.

For a single direct report’s monthly review, I might need to scan 10–20 Linear issues, read the ticket descriptions to understand scope and complexity, check PR activity, look at whether they self-initiated the work or were assigned it, note any SLA timelines, review Slack threads for collaboration signals, and revisit my 1:1 notes for context. That’s one person. I have multiple direct reports. By the time I’ve gathered the raw material, I’ve spent the better part of a day and I haven’t written anything yet.

Recency bias

When data-gathering is this expensive, you unconsciously start to cut corners. And the most common shortcut is recency bias: you remember what happened last week clearly, what happened two weeks ago vaguely, and what happened at the start of the month barely at all. The engineer who shipped a critical feature on the 3rd and then spent the rest of the month on less visible but equally important work? Their review ends up thinner than it should be.

The “vibes” trap

When you can’t easily reconstruct the full picture, you fall back on gut feel. “I think they had a good month.” That’s not good enough. Gut feel is biased toward the visible, the loud, and the recent. The IC who quietly fixed a security vulnerability, wrote developer tooling that saved the whole team time, or unblocked a colleague in a Slack thread. Their contributions vanish if you’re relying on vibes.

Consistency is nearly impossible

Most companies use some kind of rating rubric. I often see a 1–5 scale with an expected distribution. Applying that rubric fairly across multiple people requires comparing apples to apples. But when your raw data for each person exists in different tabs, different formats, and different levels of completeness, calibration becomes guesswork.

The remote multiplier

In a remote setting, things become even more challenging since you can’t rely on physical presence or informal interactions to gauge performance. You can’t pattern-match on “who seemed busy” or “who was in the office late.” If work isn’t documented in a ticket, a PR, or a message, it effectively didn’t happen. That’s mostly a good thing (remote-first culture forces documentation) but it also means the volume of written material you need to synthesize is enormous.

The key insight: Separate the layers

Here’s the mental model that changed everything for me. A performance review is not one task. It’s three distinct layers stacked on top of each other:

1. Data collection: What did this person actually do this month?

2. Analysis: What does their output mean relative to their level, their role, and our expectations?

3. Judgement: What rating do they deserve? What feedback will help them grow? What should I say in the review conversation?

These layers require fundamentally different capabilities. Data collection requires thoroughness and patience. Analysis requires pattern recognition and domain knowledge. Judgement requires empathy, context, fairness, and courage.

Here’s the thing: LLMs are exceptionally good at layer 1, relatively useful at layer 2, and completely unqualified for layer 3.

Once I saw the process this way, the path forward was obvious. I don’t need an AI to do performance reviews. I need an AI to do the part that takes the most time and delivers the least value from me doing it manually.

What I actually do

Here’s the shape of my workflow. Not the exact prompts, but what goes in and what comes out.

The setup

I give the LLM three pieces of context that it keeps across every review:

• Our competency matrix: what’s expected at each engineering level (Senior I, Senior II, Team Lead, etc.) across both technical skills and behaviors.

• Our rating rubric: the 1–5 scale, what each rating means, and the expected distribution.

• A review template: the structure I want the output in: a summary, a “What” section (achievements and delivery), a “How” section (values and behaviors), and areas for improvement.

This context is reusable. I set it up once and it persists across every review I write.

Since I want the model to pull evidence from a system, that system needs a working MCP server with the right auth and permissions. In practice, that means setting up MCP for every tool I expect to collect data from, for example:

• Slack

• Notion

• Linear

• GitLab

• HoneyComb

Otherwise, the model only sees part of the picture and the draft becomes less reliable.

The prompt

Applying the context above, I give the model a prompt like this:

---
name: monthly-review
description: Produce a thorough, evidence-based research brief on a developer's month. Gathers signals from Notion, GitLab, Slack, Sentry, Linear, and Honeycomb. The output is a research document for the manager — not a performance assessment.
argument-hint: [developer-name] [start-date] [end-date]
---

Produce a **thorough, evidence-based research brief** for:

- **Developer:** $0 (or ask if not provided)
- **Period:** $1 → $2 (or ask if not provided)

This is a **research document** — a thorough, evidence-backed account of what the developer shipped and how they worked. It is not a performance assessment. It must:

- Identify meaningful patterns
- Separate signal from noise
- Give the manager the full picture so they can evaluate fairly

---

## Inputs

Use all relevant data sources:

- `summary.md` (company context and guidelines)
- Systems:
  - Notion (documentation, planning)
  - GitLab (code contributions, reviews, delivery)
  - Slack (communication, collaboration)
  - Sentry (ownership, production issues)
  - Linear (execution, task flow)
  - Honeycomb (reliability)

---

## What to Document

### 1. Delivery & Execution
- What did they actually ship?
- Complexity and ambiguity of the work
- Reliability and follow-through

### 2. Ownership & Initiative
- Did they proactively identify problems?
- Did they take responsibility beyond assigned tasks?
- Did they prevent issues or only react?

### 3. Collaboration & Influence
- Visible impact on teammates
- Code reviews, knowledge sharing
- Communication clarity and effectiveness

### 4. Growth & Trajectory
- Signs of improvement over the period
- Response to feedback (where observable)
- Complexity of challenges taken on

---

## Instructions

### 1. Extract Signals (not activities)

Identify **specific, observable behaviors**.

Bad: "Worked on project X"
Good: "Identified and resolved a race condition in service Y, preventing potential production issues"

### 2. Provide Evidence

Every key claim must be supported by:
- A concrete example
- Clear impact
- Links to evidence (Notion docs, GitLab commits, Slack threads, Sentry issues)

If no evidence exists, do not include the claim.

### 3. Identify Patterns

Go beyond isolated events:
- What is consistently strong?
- What is consistently weak?
- What is changing over time?

### 4. Note the Limits of What You Can See

Flag where important context is likely missing. The model cannot observe:
- Work that wasn't documented in a ticket or thread
- Coordination and negotiation that happened before a ticket was opened
- How the developer showed up in private conversations or 1:1s
- Personal circumstances that may have affected output

Where evidence feels thin or a pattern seems off, say so explicitly rather than filling the gap with inference.

### 5. Strengths

List 2–4 **high-confidence strengths**:
- Must be backed by repeated evidence
- Clearly tied to impact

### 6. Areas for Improvement

List 1–3 **observable improvement areas**:
- Specific (not vague traits)
- Framed as behaviors, not personality
- Based only on what the data shows

---

## Output

Follow `template.md` exactly.

Save to: `[YEAR]/[MONTH]/performance_review_[developer_name]_[start_date]_[end_date].md`

---

## Quality Bar Checklist

Before finalizing, ensure:
- No vague statements
- No unsupported claims
- Evidence is concrete and recent
- Gaps and limits are flagged honestly
- The suggested rating is clearly tied to evidence, not inference

The output should give the manager a complete, honest picture of what the data shows — and be clear about where the data runs out.

The draft

The output is a draft for me to review. If all goes well, I will now have a 2–3 page document that gives me a thorough, evidence-backed account of what the engineer shipped, how they worked, and what patterns I can see in their output.

Now, the real work begins. I read the draft carefully, checking the evidence and noting where I have additional context that the model doesn’t. I adjust the wording, add or remove strengths and improvement areas, and make sure the narrative I want to tell is actually supported by the data.

Where the LLM must not replace you

I want to be blunt about this section because I think it’s the most important one.

The draft is not the review.

What the LLM produces is a research document. It’s a thorough, well-organized, evidence-backed summary of what someone shipped. It is not a performance assessment. The gap between those two things is the entire job of being a manager.

Context the model can’t see

The LLM knows what tickets were completed. It does not know:

• That the IC was dealing with a family emergency and still managed to ship on time.

• That a ticket estimated as “Small” actually required three days of negotiation with another team’s tech lead before a single line of code was written.

• That the quiet month wasn’t low output, it was because you asked them to onboard a new hire, and they did it brilliantly.

• That their most valuable contribution this month was a Slack thread where they debugged a production issue and unblocked four people in other teams. There’s no Linear ticket for that.

• How they’ve been showing up in 1:1s. Whether they’re energized or burning out. Whether they’re growing into the next level or coasting.

This is the stuff that separates a data summary from a performance review. And it can only come from you.

Rating calibration is a human job

The LLM will suggest a rating. Sometimes it’s right. Often it needs adjustment. Not because the model is wrong about the data, but because calibration requires context it doesn’t have.

Rating someone a 4 (”Exceeding Expectations”) is a big deal in our system. It means they’re not just doing their job well but that they’re doing work at the next level. That judgement requires knowing what “the next level” actually looks like on your specific team, how other ICs at the same level are performing, and what the organizational bar is this cycle. No model has that context. You do.

The feedback conversation

A review exists to develop someone. The words you choose, what you emphasize, what you deliberately leave out, how you frame an area for improvement. That’s leadership. The LLM can write “consider improving documentation practices.” Only you know whether that feedback will land better as a direct request, a question in a 1:1, or a paired working session.

The ethical bright line

Never let an LLM make a final rating decision. Never let it write a PIP. Never let it determine someone’s career outcome. The model is a research assistant. You are the decision-maker. Your name goes on the review because you are accountable for it. If you can’t defend every word without pointing at the AI, you haven’t done your job.

The elephant in the room: Privacy and ethics

I’d be irresponsible to write this post without addressing the obvious: you are feeding your team’s work output into a third-party model. You need to think about that seriously, not dismiss it.

What data goes in

In my workflow, the data entering the model includes issue titles, descriptions, pull requests, static code analysis, estimates, labels, dates, and assignee metadata, plus internal documents like our competency matrix and rating rubric. Because this is company data, I only use company-approved LLMs (or locally hosted models under company policy). I never paste this data into non-approved tools or consumer chat products.

What must never go in

I have a hard rule: nothing from 1:1s enters a prompt. No personal disclosures, no health information, no family situations, no salary discussions, no PIP documentation. These are categorically off-limits, full stop. The same goes for Slack DMs and any HR-sensitive material. If you wouldn’t paste it into a public channel, don’t paste it into a model.

Tell your team

This is non-negotiable for me. Your direct reports should know you use an LLM to help compile data from their public work output. I’ve framed it to my team straightforwardly:

I use an LLM to help me compile what you shipped each month, so I don’t miss anything. The assessment, the ratings, and the feedback are entirely mine.

Nobody has had a problem with this. Most people actually appreciated it saying that they want their work to be seen, and knowing the data collection is thorough is reassuring.

The power asymmetry

I want to name something that’s easy to skip over: a manager using AI to evaluate reports is not the same thing as an engineer using AI to write code. The engineer controls their own output. The report has less visibility into and less control over the evaluation process.

That asymmetry is why transparency matters. It’s why boundaries on what data enters the model are non-negotiable. And it’s why the human judgement layer isn’t optional. It’s the whole point.

Better data, better judgement

I want to close by pushing back on a framing I see a lot: that using AI for management tasks means you’re “automating management.” That’s wrong, or at least it’s describing something very different from what I do.

What I’ve automated is the tedious, error-prone, time-consuming work of reconstructing what happened. I haven’t automated a single decision. If anything, the decisions are harder now Since I have more data, I see more nuance, and I can’t fall back on “I think they had a good month.”

The real payoff isn’t saving time, though that’s real. It’s that good data collection unlocks a higher review cadence. When building a review draft takes minutes instead of hours, you can afford to do it monthly instead of quarterly. You catch things sooner; both problems and wins. You give feedback while it’s still fresh. You spot growth trajectories early enough to act on them.

The goal is not an EM who does less. It’s an EM who is more present, more informed, and more fair. One who walks into a review conversation having actually seen everything their report shipped, not just the highlights they remember.

The LLM didn’t make me a better manager. It gave me the time and data to actually be one.

If you have been reading this blog for a while, you already know the kinds of questions we keep coming back to:

• How engineering managers make decisions under uncertainty

• How organizations shape outcomes

• How much of this job depends on things nobody explains explicitly

For the past year, and I have been expanding on those ideas and turning them into a book.

Today, we are happy to share that the first half is now available.

How we got here

When we started, we thought we were writing a handbook for new engineering managers: a practical collection of lessons, patterns, and mistakes to avoid.

But the deeper we went, the clearer it became that we were not writing a handbook so much as an encyclopedia. And while there is no shortage of management books, what still feels underexplored is the tacit side of the role: the hidden judgment calls, the unspoken rules, and the context that often determines whether good advice actually works.

That is the part we decided to focus on.

Why we are sharing it now

Like many engineering teams, we initially stayed in our own bubble for too long. We wrote, refined, and kept going. Eventually, we realized that waiting until everything felt complete was not the best way to make the book better.

So instead of polishing in isolation, we decided to share it in smaller iterations and learn from real readers along the way.

That is why we put the first half of the book on Leanpub. It gives us a way to publish early, improve continuously, and incorporate feedback before the full manuscript is done.

In the same spirit, we have also open-sourced the tooling behind this work (and wrote about it). It felt more consistent to share not just the ideas, but some of the practical machinery that helps us develop and publish them.

What you can expect

This book is for aspiring, new, and current engineering managers who want practical guidance rather than abstract theory. It is shaped by the same themes we explore on this blog, but in a more structured and connected form.

If you care about topics like:

• Understanding the environment your team operates in

• Building alignment across teams and stakeholders

• Making better plans in the face of uncertainty

• Becoming more effective without becoming performative

then there is a good chance this book will resonate with you.

The launch

The first half of the book is now available here: Engineering Manager’s Compass: Insights for building effective engineering organizations

If you decide to read it, we would genuinely love your feedback. In particular, we would love to hear:

• What resonated with you

• What felt unclear or incomplete

• What seemed most useful in your own context

• What you would want us to go deeper on in the second half

Writing in public is our way of making sure this book becomes more useful than it would have been if we had finished it alone.

Thank you for reading the blog, and thank you in advance if you take the time to look at the book. We hope it gives you something practical to take back to your own work.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

In the post-LLM world, traditional take-home assignments are becoming obsolete. Remote interviews pose a challenge in determining whether candidates are genuinely responding or simply reading the results of a prompt. On the one hand, we want our prospects to be up to date with the latest technologies; on the other hand, we don’t want them to outsource their day-to-day jobs to LLMs.

To make sure that we separate critical thinkers from prompt readers, it’s necessary that we tailor our interview processes.

The problem

Today, it can be practically impossible to distinguish between human and machine intelligence, especially if the candidate has set up a system that can listen to your questions and present results for the candidate to read aloud to an interviewer.

Unprepared, we are seeing more and more companies changing their recruitment process. Some companies are removing the take-home assignment or opting for an on-site interview to mitigate the risks, increasing the chances of attracting better candidates at the cost of longer recruitment duration.

But these solutions come at the cost of candidates feeling as though they’re being interrogated – so what’s a more sustainable path forward?

Interview strategies

The answer lies in designing interviews that embrace LLM usage rather than trying to prevent it. Instead of treating AI assistance as cheating, we can create scenarios where candidates must demonstrate skills that go beyond what an LLM can provide: contextual judgment, critical thinking, real-world experience, and the ability to validate and critique AI-generated outputs.

The following three strategies transform the interview from a test of memory or raw problem-solving into an evaluation of how candidates leverage modern tools while applying genuine expertise. Each approach reveals different aspects of a candidate’s capabilities, and they can be used individually or in combination depending on the role and seniority level.

Going deep

It is very difficult for an LLM to go deep into a specific subject without having been specifically trained on it. This means that we need to move beyond surface-level answers and probe for genuine expertise areas where LLMs typically struggle or provide incomplete responses. Interviewers should design questions and scenarios that require candidates to demonstrate real-world understanding, nuanced judgment, and the ability to reason about complex systems.

For example, during an interview, you could ask the candidate to explain something they’ve built that they are proud of. Then ask them to go deep into specific design decisions they made, trade-offs they considered, and challenges they faced. Don’t stop at the first layer of explanation; keep probing into the details. Someone who has truly worked on the project will be able to provide insights that go beyond surface-level descriptions while an LLM would struggle to maintain coherence and depth.

Ask them what they learned from the experience, how they would approach it differently now, and how they handled specific technical challenges.

Listening to the candidate’s explanations, interviewers should look for:

• Depth of understanding: Does the candidate demonstrate a deep grasp of the subject matter, or are they providing generic answers?

• Contextual judgment: Can the candidate explain why certain decisions were made based on real-world constraints?

• Critical thinking: Does the candidate question assumptions, consider alternatives, and reflect on lessons learned?

• Experience-based insights: Are the candidate’s explanations enriched with personal experiences and anecdotes that an LLM would not possess?

Reading code

It is well known that the greatest part of an engineer’s time is spent reading code. Knowing this, many companies will have a stage in their interview process where they ask the candidate to read and explain what a certain block of code is doing.

With the advancements of LLMs, this process has become much simpler. However, we can still up our game. We could provide the candidate with a much larger codebase (one with many lines of code, high complexity, outdated documentation and maybe even multiple languages) and ask the candidate to explain to us the inner workings of the project. We would allow them to use an LLM of their choice, but provide them with one whose shortcomings we’re aware of. For example, a smaller or more summary-oriented model may produce confident but incorrect explanations when reasoning across a large, messy codebase. This helps us assess whether a candidate can critically evaluate LLM output rather than trust a plausible, but unreliable narrative.

We would be able to observe the following:

• How well does the candidate leverage the LLM?

• How much of the LLM’s output does the candidate take for granted?

• Will the candidate ask clarifying questions to the interviewer to get a better scope of the assignment, or solely rely on the output of the LLM?

• Will the candidate be able to identify the issues with the codebase using an LLM as well as their own experience?

All of the above would give us a clear understanding of the candidate’s skills and mindset.

Reviewing code

Code reviews are an important part of an engineer’s day. Now that LLMs can generate code faster, it has only become more difficult to parse through change requests.

While some argue that engineers can also use LLMs to help review the code, it’s much easier said than done. LLMs, without the full context of the codebase, can easily become confused and come to incorrect conclusions.

To circumvent this in an interview arena, we could present the candidate with a large change request to review. One that has been partially generated by an LLM. To make things more interesting, we could add comments to the code that inaccurately describe what it does. And add even more confusion by including an incorrect README file. Finally, to spice things up, the change request could consist of multiple programming languages.

Due to the complexity of the task, a candidate won’t be able to rely on an LLM; rather, they’ll need to draw on their own experience, providing a more reliable way to discern their competence.

This methodology allows us to observe the following:

• How well can the candidate give feedback? This is crucial for an engineer to be able to give and receive feedback constructively.

• Is the candidate able to make their own observations about the code? Or will they just take the LLM’s output for granted?

• How well does the candidate leverage the LLM? Can they pinpoint sections of the code to keep the LLM focused? Will they be asking verifying questions to ensure accuracy?

• Will they ask for the confusion to be clarified? Or will they just try to muddle through it?

How to evaluate candidates?

Evaluating a candidate’s usage of LLMs during interviews requires a nuanced approach. The goal is not to penalize candidates for using modern tools, but to assess their ability to combine AI assistance with critical thinking, domain expertise, and collaborative skills.

Technical judgment is crucial. Interviewers should observe whether the candidate treats LLM output as a starting point rather than an unquestioned answer. Strong candidates will validate, cross-check, and test the information provided by the LLM, and can spot hallucinations, inaccuracies, or gaps in its explanations.

Problem decomposition is another key area. Candidates who excel will break down complex tasks into smaller, focused questions for the LLM, guiding it to specific code sections, clarifying ambiguous requirements, or asking for alternative solutions. This demonstrates their ability to use the LLM as a tool for exploration rather than a shortcut for answers.

Domain knowledge must also be evident. The best candidates supplement LLM output with their own experience and expertise, recognizing when the LLM’s suggestions are contextually incorrect or outdated. They do not rely solely on the LLM, but use it to enhance their own understanding and decision-making.

Collaboration and communication are essential as well. Candidates should engage with the interviewer, ask clarifying questions, and seek feedback. They should be able to explain their reasoning, including where and why they relied on the LLM, and demonstrate a willingness to critique and improve upon its output.

By focusing on these criteria, interviewers can identify candidates who use LLMs as effective tools and who possess the judgment, expertise, and communication skills needed for modern engineering roles.

Final thoughts

The interview process must evolve alongside technological advances. Rather than fighting LLMs, embrace them as part of the evaluation process. Design scenarios that reveal how candidates think, collaborate, and apply judgment when AI assistance is available. The goal isn’t to eliminate LLM usage; it’s to identify engineers who can leverage these tools effectively while maintaining critical thinking and domain expertise.

This article was originally published on LeadDev.com on January 21, 2026.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

If you’re looking for an introduction to Service-Level Objectives (SLO) check the links at the end of the article.

Why technical SLOs are not enough

Your infrastructure is humming along perfectly. Every metric is green. Response times are excellent. The database is stable. And yet your business is losing money or users. This is the fundamental problem with technical SLOs: they measure whether your system is working, not whether your system delivers what users need.

Consider Uber during rush hour. A rider opens the app. Your backend responds in 150ms. Your database is stable. Your error rate is zero. But the map shows no available drivers close enough to request a ride.

Everything your dashboards celebrate is fine. The only thing that matters to the rider is not.

What a business SLO looks like

A better approach is to define an SLO around the actual outcome riders care about:

99.5% of rider requests have at least 3 available cars within 2 km

This SLO captures what the user actually needs: available transportation options. It doesn’t describe the system. It describes the outcome.

The “3 available cars” and “2 km” radius aren’t arbitrary technical choices, they’re product decisions. The business has decided that riders need at least 3 options within 2 km to feel confident they can get a ride.

Where business and engineering meet

A common concern is: “If I start tracking business SLOs, do I stop caring about technical SLOs?”

No. You need both.

Technical SLOs are guardrails. They ensure your infrastructure can support your business outcome. If your API latency is 2 seconds, you can’t offer a good ride request experience. If your database is down, you can’t compute your business SLI reliably.

But technical SLOs should be set to support business goals, not the other way around. A technical SLO like “99.99% availability” is a means to an end. A business SLO like “99.5% of rider requests have 3+ cars within 2 km” is the end itself.

Start with the business outcome. Then work backward to decide what technical reliability you need to make that outcome consistently true.

Turning a fuzzy goal into a SLI

The SLO we defined is a business goal, but it’s not immediately measurable. We need to translate it into a concrete metric: a Service Level Indicator (SLI).

A good starting SLI could be: Percentage of rider sessions where at least N available cars are present within R km at the time of request.

But there’s not one single right answer. Different dimensions affect how you measure success:

• N (cars): 1, 3, 5

• R (radius): 1 km, 2 km, dynamic by city

• Time window: At request time, or within 30 seconds

• Scope: Per city, per geo-cell, per time of day

These dimensions represent trade-offs that should be made by your business, not your engineering team. Do you measure at the exact moment of request or allow 30 seconds? Does the target vary by city density? Should you track this globally or by geography?

Once the business has answered these questions, engineering has a clear target to optimize toward.

Where the data really comes from

Here’s where business SLOs force a shift in how you think about monitoring.

Technical SLOs are built on infrastructure metrics: request latency from your load balancer, error rates from your API gateway, uptime from your health checks. These are easy to measure because they’re generated by your systems automatically.

Business SLOs require domain events. In our fictive Uber case, the SLI requires understanding the state of available drivers at the moment a rider requests a ride. This isn’t something your infrastructure metrics track. A healthy API and database tell you nothing about driver supply.

So where does this data come from? Upon every ride request, the Uber app queries the backend for available cars nearby. At that moment, the system knows: how many cars are available, what’s their distance, which drivers accepted which requests. This is the raw material for computing the SLI.

The key is instrumenting your domain, not just your infrastructure. You need to log or emit events at the business level: “Rider X requested a ride in zone Y at time Z, and N drivers were available within R km.”

This is harder than passively collecting infrastructure metrics because it requires intentional design. In practice, it often looks like:

• Adding logging/events in the request flow (capture supply at the moment of intent)

• Shipping those events into a pipeline you can aggregate (warehouse or time-series)

• Computing the SLI over a time window (e.g., hourly, daily) and slicing by city/zone/time of day

• Alerting when the SLO is not met so you can respond

But it’s essential. Without this data, you’re flying blind about whether you’re actually delivering value.

Why this matters

When you measure business SLOs, teams naturally align around a shared outcome. Product stops asking, “How fast is the response time?” and starts asking, “Can riders get a ride?” Engineering stops optimizing for abstract numbers and starts optimizing for a real user experience.

It also makes incidents more actionable. When a technical SLO is breached, the response can be ambiguous: scale, refactor, or wait? When a business SLO is breached (e.g. riders can’t request a ride) the problem is unmistakable, and the response is concrete.

Finally, it forces honesty. It makes you measure what matters, not just what’s easy to measure.

Getting started

Pick one user journey that matters most to your business. Define what success looks like from the user’s perspective, not the system’s. Instrument that flow to capture the data you need. Start measuring.

You don’t need to boil the ocean. One well-chosen business SLO will teach you more than a dozen technical metrics ever could.

Useful links to get started:

• Chapter on Service-Level Objectives in Google SRE book.

• “SLO alerting for mortals” covers how to build alerting on top of your SLO.

• Book “Implementing Service-Level Objectives” by Alex Hidalgo.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

If you're like me, you probably also have many scripts lying around which look like this:

CSV.open('jira.csv', 'w') do |csv|
  [2024, 2025].each do |year|
    (1..365).each do |day|
      date = Date.ordinal(year, day)
      break if date > Date.today

      jira.metrics(date.strftime('%Y-%m-%d')).each do |result|
        csv << result
      end
    end
  end
end

Collecting massive amounts of data from various sources across your company's ecosystem. Sources such as Jira, GitHub, Google Drive, and Confluence.

This allows you to have your probes in place so that you can make data-driven decisions. Decisions to help you save costs, improve team performance, and optimize processes.

But just like me, you probably also don't have a good solution to where to store all that data.

You might have been using CSV files, JSON files, or spreadsheets. You might have later upgraded to using a database like MySQL or PostgreSQL. And if you're lucky, you might have even been using a data warehouse like Snowflake or BigQuery.

But none of these solutions work well for busy engineering managers. Files are clumsy to manage, databases can be rigid and require maintenance, and data warehouses are expensive and complex.

Until now!

What is DuckLake?

DuckLake gives you your own data lake which you can carry in your pocket. In essence, it is a data lake specification which uses Parquet files as the storage format and a database to store its metadata. For a more detailed (and accurate explanation), you should watch Hannes Mühleisen and Mark Raasveldt introducing DuckLake.

Nothing magical about it, which is another reason I love it so much. It's simple, lightweight, and easy to use.

First let's install DuckDB. There are a gazillion ways to do this. In my case, I use Homebrew on macOS, so I can install it like this:

brew install duckdb

Once installed, we can launch it with:

duckdb

Now we’re in DuckDB but we still need to install the DuckLake extension of DuckDB which can be done as follows:

INSTALL ducklake;

And to start using it:

ATTACH 'ducklake:metadata.ducklake' AS ducklake;
use ducklake

And we’re off to the races 🏇

Eating data

First thing you want to do is to start ingesting data into your personal data lake. For the sake of the example let’s assume that you have some data you scraped from Jira which is saved in a CSV file called jira_2024_2025.csv.

Let’s create a table called jira and ingest the data into it.

CREATE TABLE ducklake.jira AS
SELECT * FROM read_csv_auto('jira_2024_2025.csv');

We can verify that the table has been created by running:

SHOW TABLES;

And verify that the data is in place by running:

FROM ducklake.jira;

Which will do a SELECT and return the results.

If we look in the file system we can see that DuckDB has created a couple of files/folders. The metadata.ducklake file is the actual DuckDB database which contains all the necessary metadata. Next to that we have a folder called metadata.ducklake.files which contains all the parquet files. At this point in time you should be seeing a folder called main under which you will see another folder called jira. This represents the table we currently have in our data lake. Under this folder, you will see a single parquet file.

Eating more data

You realize that there is more value in also having data from 2023 so you go ahead and generate the CSV. Now you need to import that as well. In order to do so you can do the following:

INSERT INTO ducklake.jira
SELECT * FROM read_csv_auto('jira_2023.csv');

Now when we look in the file system, you should see a 2nd parquet file appear under metadata.ducklake.files/main/jira.

Road to DataViz

As an engineering manager, we’ve been collecting all this data in order to be able to uncover issues and tell a story. This means that we do need to get this data into our favorite data visualization tool (Tableau, Power BI or Livebook). Since DuckLake is a relatively new technology, there aren’t that many adapters for it yet. But in our example, since we use DuckDB under the hood we can export the data in any format we’d like. I prefer to use Parquet again since it’s so lightweight and all DataViz tools I’ve mentioned above have connectors for it.

We can export a table like so:

COPY ducklake.jira TO 'jira.parquet' (FORMAT parquet);

This will create a new file called jira.parquet on the file system which we can point to with our favorite DataViz tool of preference.

Conclusion

DuckLake makes it incredibly easy for engineering managers to collect, store, and analyze data without the usual headaches. You don't need to rely on the cloud. Everything can live locally on your machine, making it both private and portable. If you ever want to scale up, you can simply move your Parquet files to blob storage and host the metadata database on a server, giving you flexibility as your needs grow (which I doubt you will need anytime soon).

DuckLake is super lightweight, fast, and efficient. You can store years of data in just a few megabytes, and querying or exporting your data is a breeze. With support for open formats like Parquet and seamless integration with popular data visualization tools, you get all the power of a modern data lake without the complexity or cost. For busy engineering managers who want actionable insights without the overhead, DuckLake is a game changer.

This article contains speculative thinking and should be read critically.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Imagine John Stith Pemberton1, sitting behind his desk, experimenting with a new drink. He mixes some ingredients, tastes it, and thinks, "This is good". He decides to sell it and calls it "Coca-Cola".

What would his first instinct be? To tell everyone about his new drink and its ingredients?

Of course not.

He would keep it a secret, knowing that if he revealed the recipe, others would copy it. He might even claim to use a certain ingredient just to mislead competitors.

This scenario is not unique to Pemberton; it is common in many industries, especially technology.

There are numerous examples where tech companies make claims about their internal technologies or methodologies, but in reality, these statements are strategies to mislead and confuse competitors.

In this article, we will explore some of these examples and, ultimately, examine the so-called "AI lie".

Examples

PageRank

In the 2000s and early 2010s, Google's public messaging strongly emphasized PageRank2 as the centerpiece of its ranking algorithm.3

Over time, insiders, ex-Googlers, and leaks such as the 2024 Google Search API leak4, revealed that actual ranking had become vastly more complex, driven by machine learning models and hundreds of other signals beyond PageRank. By focusing public discussion on PageRank, Google potentially distracted competitors and SEO practitioners from reverse-engineering the real system.

Inside the Apple

Apple is legendary for its culture of secrecy. Former employees have reported that Apple sometimes exaggerates the sophistication of its internal tools or deliberately uses code-names and "decoy" projects to keep competitors uncertain about its real activities.

In the book Inside Apple by Adam Lashinsky5, it's described how Apple sometimes assigns employees to projects that have misleading code-names or fake project names so that even those working on them can't fully know what the final product will be. For instance, Lashinsky reports that some engineers hired for secret hardware teams didn't know what product they were building until very late in the process.

Another example is where former Apple engineer David Shayer wrote in TidBITS6 that the company sometimes deliberately overstates the capabilities of its internal tools or keeps separate teams siloed under misleading project names. This keeps details away from both internal leaks and external competitors. Shayer describes how Apple isolated the iPod Linux project team and would occasionally float information about features or tools that were either exaggerated or never meant for release.

The Browser Wars

In the 1990s, Netscape Navigator and Microsoft Internet Explorer were locked in an intense battle to dominate the web browser market7. This was a high-stakes, fast-moving competition where being seen as the technical leader was often as important as actually delivering features.

In their book Competing On Internet Time by Michael A. Cusumano and David B. Yoffie8 talk about how both companies sometimes announced upcoming features or technologies that were still experimental or might never ship. These announcements were often used strategically to influence competitors' product roadmaps and to create the impression of rapid innovation and technical superiority.

One concrete example was Netscape’s "server push". Introduced in 1995, it allowed a web server to send multiple pieces of content over a single HTTP connection without waiting for a new request. It was presented as revolutionary, but in reality, it was a hack around HTTP/1.0 limitations and fragile in practice. It worked in demos and simple cases but wasn’t robust or widely useful at scale.

This feature was heavily marketed and talked about in conferences, articles, and interviews to show Netscape’s engineering superiority even though it was of limited practical use for most developers.

Cryptocurrency / blockchain startups

Similar stories could be found again and again in the world of cryptocurrency and blockchain startups. Many of these companies have made grandiose claims about their technologies, often using buzzwords like "decentralization", "smart contracts", and "consensus algorithms" to create an aura of innovation and technical sophistication. However, many of these claims are often exaggerated or misleading.

One of the well known and ongoing examples is the claim that blockchain technology is the decentralized nature of Ripple's XRP Ledger. Ripple has long marketed XRP and its network as fully decentralized, and suggested its consensus algorithm was novel and highly robust. In practice, Ripple Labs controlled a significant proportion of validator nodes and owned over half the XRP supply. Critics and researchers noted that the network’s functioning depended heavily on Ripple’s infrastructure, making it far less decentralized than advertised.9

Another example is IOTA's "Unhackable Tangle". IOTA promoted its "Tangle" as a quantum-proof, feeless, and unhackable protocol, and boasted about its custom hash function. However, external security researchers (including at MIT's DCI) found serious flaws that could allow for practical attacks. IOTA developers dismissed criticism and even justified intentionally adding "copy protection" to confuse attackers though critics argued this hurt security transparency more than it protected.10

We use AI everywhere

In recent years, the AI industry has become the modern equivalent of Coca-Cola's secret formula: something mysterious, powerful, and carefully guarded. But unlike a drink recipe, AI companies often publicly hint at or exaggerate what's happening under the hood. Not just to impress customers and investors, but also to confuse or slow down competitors.

One clear example is OpenAI. After releasing GPT-4, OpenAI leaders made deliberately vague references to even more advanced systems (often rumored as "GPT-5") supposedly in training.11 They gave no concrete timelines or details, leaving competitors and the press to speculate wildly.12 This ambiguity serves a purpose: it helps keep rivals like Anthropic and Google DeepMind guessing about OpenAI's real progress, making them hesitate or shift roadmaps.

Then there's Tesla with its "Full Self-Driving" (FSD) claims. For years, Elon Musk has promised that Teslas will soon achieve Level 5 autonomy, meaning they could drive themselves without any human oversight. In practice, Tesla's system is still Level 2: it requires drivers to pay attention at all times. Yet these big promises about AI-powered autonomy serve to keep Tesla positioned as an innovation leader, shape public perception, and perhaps most strategically, force competitors to spend resources catching up to something that doesn't fully exist.13

At Meta's LlamaCon event, Microsoft CEO Satya Nadella stated that roughly 20–30% of code across Microsoft's repositories is now "written by software". What Nadella didn’t clarify was whether this includes simple autocomplete suggestions, full function generation, or light templating, leaving the metric open to interpretation. Critics argue that including autocomplete vastly inflates the figures.14

In all these cases, secrecy and hype become part of the competitive strategy. They protect genuine breakthroughs, but they also inflate expectations and obscure real limitations. And just as Coca-Cola never fully revealed its formula, AI companies rarely show the raw code, datasets, or failure cases behind their grand claims.

Conclusion

This is not to say that we are being deliberately lied to, nor is it to deny the genuine power of AI as a technology. However, many claims about AI are often exaggerated or misleading. Much like Pemberton guarded his Coca-Cola recipe, companies tend to keep their AI technologies and methodologies secret.

It is important to remain skeptical and critical of such claims, recognizing both the limitations of these technologies and the influence of marketing hype. Making drastic decisions, such as reducing the workforce by 20% in the belief that AI will seamlessly take over, or filling half the codebase with AI-generated code, can lead to significant regret and technical debt.

Ironically, these missteps may eventually create opportunities for a new wave of engineers to clean up the resulting mess.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

In many disciplines, engineering, economics, medicine, there's a clear path to improvement: study the established material, practice the techniques, and apply the best practices. The resources are there, and progress comes from working with them deliberately.

Management, however, is different.

Ask a group of engineering managers how they learned their craft, and you'll rarely hear them cite a single book or course. More often, they'll say they learned by watching others, imitating great managers, avoiding the habits of bad ones, and figuring things out through trial and error.

This isn't just folklore. It reveals something important about the nature of management itself and why developing as a manager requires something more than theory.

This article explores why management can't be taught the way other skills can, and how the most effective way to grow is by exposing yourself to real situations, real people, and the choices managers make in the moment.

The material

Every craft has its material.

For a carpenter, it's wood.
For a musician, it's sound.
For a mathematician, it's numbers.

And while these materials are complex and full of nuance, they're also deeply abstracted so that people can actually work with them.

Take wood. Every piece is unique; grain, density, moisture, even how it responds to a tool. But in practice, we don't obsess over those differences. We categorize it by tree type: oak, pine, mahogany. These broad categories are useful enough to make decisions. What to use for a floorboard, what to carve into a chair leg.

The same goes for music. Sound exists on a continuous spectrum, but we don't treat it that way. We break it into notes and scales. We agree that an A is 440Hz, and we build instruments and songs on top of that simplification. It’s not the full reality but it's enough to work with.

And numbers? There are infinitely many of them. But we've built layers of abstraction; digits, notations, number systems, formulas so we can reason about the infinite without being overwhelmed by it.

In all of these disciplines, complexity is simplified into usable forms. The uniqueness of each unit, each board of wood, each note, each number, doesn't stop us from working with them, because we've learned how to generalize them just enough to be productive.

But management doesn’t work that way.

People

As a manager, your material is people. And people don't follow the same rules.

Every person is different. Genetically, emotionally, and experientially. Like snowflakes, no two are exactly alike. Even identical twins raised apart develop distinct personalities, preferences, and perspectives. That uniqueness isn't surface-level, it runs deep, shaping how each person thinks, feels, communicates, and responds to pressure.

Of course, we've tried to make sense of this complexity. We've built frameworks to help us generalize people such as:

• DISC profiles1

• Myers-Briggs Type Indicator (MBTI)2

• Big Five personality traits3

These models are useful. They give us a vocabulary for tendencies and behaviors. They can highlight communication styles or help structure feedback.

But they are simplifications, not the reality.

You can't manage someone solely based on their DISC type. You can't assume two engineers with the same MBTI will have the same needs, fears, or blind spots. These tools give you a starting point, but they don't replace the need to actually understand the individual in front of you.

Because in practice, people resist generalization. They surprise you. They grow, regress, mask their emotions, contradict themselves.

And because people are your material, their uniqueness becomes your challenge.

You're not just managing tasks or processes, you're managing emotions, expectations, and motivations that are specific to each person. One team member might flight when facing conflict. Another might become more vocal. One might crave autonomy, while another needs reassurance. Even if the surface problem is the same (say, missing a deadline) the underlying cause and best response may be wildly different.

This means that every issue you face as a manager comes wrapped in the specific context of the individual involved. There's no standard playbook. No generalization that holds for long.

Each person brings their own texture. And every conversation, every problem, every decision is shaped by that texture.

Embrace variety

If you're working with people, you can't standardize your way out of complexity. You can't reduce every challenge to a framework, and you shouldn't try to.

The reality is: there is no universal playbook. The same management tactic that motivates one person might backfire with another. A direct conversation might build trust with one team member and shut down another completely. What worked last time might not work next time, even with the same person.

This variety isn't a bug. It's the nature of the material. And the only way to become better at working with it is to embrace the variety, not resist it.

The best managers I know aren't the ones who've memorized the most models or frameworks. They're the ones who've seen the most. They've been exposed to a wide range of people, situations, and reactions. They've built judgment not through theory alone, but through experience.

You may not have a team of twenty. You might only manage three or four people right now. But that doesn't mean your growth has to be limited. You can still expand your exposure by working closely with other managers, by reflecting deeply on the situations you do encounter, and by studying real examples from the field.

Management isn't about applying the right rule. It’s about recognizing patterns in real people, and the only way to get better at that is to see more of them.

Practice pair management

One of the most effective ways to broaden your exposure is to manage in pairs.

This doesn't mean you co-manage a team full-time (though that can work). It means creating deliberate opportunities to observe how other managers think, and to let them observe you in return.

You can do this in a 1:1 peer setup or in a small group of fellow engineering managers. The mechanics are simple but powerful: take notes after a tricky 1:1 or team situation, and bring that scenario to your peer or group. Walk them through what happened, what you did, and where you felt uncertain. Then ask: What would you have done?

This kind of debrief builds your pattern recognition. You'll start to see how other managers approach similar problems. What they focus on, what they ignore, what questions they ask. And in the process, you'll start to refine your own instincts.

The benefit compounds when your peer does the same. Now you're learning not just from your own experience, but from theirs too.

Pair management isn't about finding the one right answer. It's about building a richer mental library of situations, reactions, and possibilities so you're better equipped when the next one comes along.

Borrow experiences

You won't encounter every kind of situation in your own team. But you don't have to.

The second-best way to increase exposure, after direct experience, is to read about what other managers are going through. Real examples. Real people. Real stakes.

Books are a good starting point. Many great management books share stories from the author's career, offering a glimpse into how they handled complex or ambiguous situations. But remember: you're still only seeing one person's experience.

To truly benefit from variety, find places where multiple managers share real problems and perspectives. One of the best resources I've found is the Rands Leadership Slack4. There, managers of all levels post daily about situations they're dealing with from performance issues to hiring dilemmas to conflict within their teams.

Some channels worth following:

• #hiring-and-interviews

• #management-craft

• #leaving-a-job

• #firing-people

• #help-and-advice

What makes this so valuable is the range of reactions. You'll see five different takes on the same scenario, each shaped by different values, teams, and personalities. Over time, you'll build a more flexible and nuanced sense of what "good management" can look like.

You may not live through every situation yourself. But you can borrow experience from those who have.

Shadow and be shadowed

One of the most underrated ways to grow as a manager is to sit in and observe how someone else handles the exact same job, but in their own way.

You don't need to do this regularly, just occasionally, and with intent. Ask a peer if you can shadow them during a specific kind of meeting: a 1:1, a performance review, or a team discussion. Then, return the favor. Invite them to sit in on one of yours.

When done respectfully and with consent, this kind of shadowing is a goldmine You'll pick up subtle differences in tone, phrasing, pacing, and even body language. You might notice how they defuse tension, ask follow-up questions, or bring someone back on track. None of this tends to show up in books but it's where the craft of management really lives.

What's more, you'll begin to see that there's no one right way to manage. Different personalities, different styles, and different teams all shape what “good” looks like. And by seeing more of those possibilities in action, you'll expand your own range and confidence.

This isn't about copying someone else. It's about learning from their version of the same job.

Sometimes, watching one conversation is more educational than reading ten case studies.

Conclusion

You won't find a universal framework that works for everyone. You'll never reach a point where you've "seen it all". But you can get better.

Watch how others manage. Talk through real situations. Read about the choices others have made and the trade-offs they faced. The more examples you absorb, the better your instincts will become.

So if you want to grow, don't look for perfect answers. Look for more examples.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

When it comes to your career, understanding where you stand is the first step to moving forward. Whether you're aiming for a promotion or negotiating a raise, knowledge is your most powerful tool. In this article, we'll break down the key concepts you need to master to advocate for yourself and maximize your impact.

Understanding your company's compensation structure

Not all companies are created equal, especially when it comes to pay. In the tech industry, Gergely Orosz introduced the idea of a trimodal compensation structure: big tech, mid-tier, and startups or legacy companies1. Understanding which category your company fits into helps you set realistic expectations and benchmark your compensation. Start by researching the typical salary ranges for your role across these different company tiers. This can involve reaching out to colleagues, checking resources like Glassdoor, or asking direct questions during interviews. Once you know where your employer sits in this structure, compare your compensation to the market rate for your role and experience. This context is essential for effective negotiation and career planning.

The Compa Ratio

Every company tracks compensation bands for each role, from the lowest to the highest paid. Your compensation ratio, often called the "compa ratio", tells you how your pay compares to others in your position2. Companies have an incentive to keep the gap between the lowest and highest paid within a band from growing too wide, as large disparities can lead to dissatisfaction and turnover. If possible, find out your compa ratio; in some places, such as the Netherlands, transparency around this metric may soon become a legal requirement. Knowing your compa ratio gives you a clearer sense of your negotiation power and future earning potential, and helps you set realistic goals for raises and promotions.

Input → Output → Outcome → Impact

When it comes to career growth, it's not just about what you do, it's mostly about the impact you make. Kent Beck's Input → Output → Outcome → Impact model3 is a useful framework for connecting your daily work to broader business goals.

Here's how this model breaks down in practice:

• Input is the work you put in; such as the code you write, the designs you create, or the research you conduct.

• Output is what gets produced as a result; like the features your team ships or the documentation you deliver.

• Outcome is what changes for your users; customers start using the new features, or colleagues rely on your documentation.

• Impact is the broader effect on the business; such as increased revenue, improved customer satisfaction, or growth in your user base.

Reflect on how your work moves through these stages. Are you focusing only on inputs and outputs, or are you also tracking outcomes and impact? The more you can connect your daily work to real business results, the easier it is to demonstrate your value and advocate for your growth. Using this framework helps you prioritize your efforts and clearly communicate the difference you make.

The power of Bragdocs

Keeping a record of your accomplishments isn't just for performance reviews, it's a habit that builds self-awareness and confidence. A Bragdoc, as described in more detail in a separate article, is a living document where you track your achievements, both big and small.

Prepare your Bragdoc template so that it prompts you to record the impact of your work, not just the tasks you completed. Regularly reviewing your contributions and assessing their impact can help you measure and visualize your progress. If you notice that your work isn't having the desired impact, it may be time to reconsider where you're investing your time and energy.

Beyond your accomplishments, I also recommend tracking the people you collaborate with during each project or initiative. This serves two purposes: it helps you remember who to request feedback from (which strengthens your evidence base), and it documents your growing professional network which is a valuable asset in itself.

When it's time for performance reviews or compensation discussions, your bragdoc becomes a powerful resource. I often transform mine directly into promotion cases or raise requests, where all the documented metrics, feedback, and achievements serve as concrete evidence of my value. This approach turns what could be a subjective conversation into one grounded in measurable contributions.

Visual storytelling

When it comes to advocating for yourself, data is your friend. But purely presenting an Excel sheet of numbers won't get you far. To make your case compelling, focus on visual storytelling that transforms raw data into a clear, impactful narrative.

From spreadsheets to stories

Imagine presenting your manager with this:

Now compare that to this:

The difference is dramatic. The first requires your manager to work hard to understand your value. The second does the work for them, guiding their eye to exactly what matters.

Making your data speak

To create effective visual stories:

1. Choose the right visualization for your message. Line charts show trends over time, bar charts compare quantities, and pie charts display proportions.

2. Highlight what matters with color, annotations, or callouts that direct attention to your key accomplishments.

3. Connect to business metrics whenever possible. Show how your work influenced customer satisfaction scores, reduced costs, or drove revenue.

4. Keep it simple by focusing on one clear message per visual. Multiple complex charts can overwhelm your audience.

5. Provide context with brief explanations that help interpret the visual without requiring detailed study.

When preparing for compensation discussions, create a small portfolio of 2-3 visuals that tell a coherent story about your growth and impact. These might include your contribution trends, feedback patterns from peers, or direct business outcomes from your projects. This approach transforms abstract accomplishments into tangible evidence that's hard to dismiss.

Conclusion

By understanding your company's compensation structure, knowing your compensation ratio, focusing on impactful work, and tracking your achievements, you'll be well-equipped to negotiate for what you deserve. The more informed you are, the more confidently you can advocate for yourself and the more likely you are to achieve your career goals.

1

The Pragmatic Engineer

The Trimodal Nature of Tech Compensation Revisited

👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. To get articles like this in your inbox, every week, subscribe…

Read more

2 years ago · 365 likes · 28 comments · Gergely Orosz

3

The Pragmatic Engineer

Measuring developer productivity? A response to McKinsey

👋 Hi, this is Gergely with the monthly, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers…

Read more

3 years ago · 657 likes · 23 comments · Gergely Orosz and Kent Beck

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

You know that feeling when you're on holiday and you come across a fellow tourist from your home country? Even though you have no idea what kind of person they are, you still feel the urge to say hi. Or that energy you get when you're at a game cheering for your favorite team, and you're empowered by the chant of your fellow supporters?

Both of these feelings come from a basic human need: The need to belong.

We're social animals. We crave connection and community, a sense of being part of a tribe. But this feeling can turn sour in a company setting. When we find our group, every other team, track, or department becomes "them". We begin to judge others more harshly and praise our own team excessively.

Research1 backs this up: people tend to rate their immediate team more positively than their department, and their department more positively than the company. The further the distance in the organizational hierarchy, the weaker the sense of belonging.

As engineering managers, we need to recognize this pattern and help channel the "us vs. them" dynamic into something constructive, rather than letting it damage collaboration from the inside.

Where do we belong?

It's easy to forget: we all work for the same company.

If our team is doing great work but every other team isn't, then the company fails. And if the company fails, so do we.

Sometimes, focusing too much on our team's goals can actually mean we're working against others. We might unintentionally hoard knowledge, block cross-functional progress, or simply not care what happens elsewhere. So what causes these splits in the first place?

Why do we split?

In small companies, culture is more unified. You probably know everyone's name, and collaboration feels natural.

But as companies grow, they naturally split into functions, disciplines, and departments. That's not inherently bad (it brings clarity and focus) but it does increase the risk of isolation.

Over time, "us" becomes our team, and "them" is everyone else.

It doesn't just happen across teams. It also shows up in hierarchies. As a manager, you might feel you're part of the "management team", separate from Individual Contributors (IC). Or as an IC, it might feel like the C-level execs are some other species entirely.

This is inevitable. But it's not unchangeable.

As engineering managers, we can play a key role in bridging these gaps.

What can you do about it?

Company alignment

Be the person who reminds others: we're all rowing in the same direction.

Clarity around company goals is essential. Mission, vision, and values are a good starting point but they mean nothing if they aren't lived.

Make the connection visible: show how each team, each person, contributes to broader goals. When that connection is clear, the sense of shared purpose grows.

For example, imagine the company has this top-level OKR: Improve customer retention by 15% over the next two quarters.

Now see how different teams align their OKRs with it:

• iOS Team Objective: Increase app stability and performance to enhance user satisfaction.

  • KR1: Reduce crash rate from 1.2% to 0.4%

  • KR2: Improve app launch time by 25%

• Backend Team Objective: Ensure fast and reliable delivery of key user data.

  • KR1: Bring 95th percentile API latency under 400ms

  • KR2: Improve data consistency between services to 99.9%

• Customer Support Team Objective: Provide faster, more helpful support responses.

  • KR1: Reduce average first-response time from 12 hours to 4 hours

  • KR2: Improve customer satisfaction score from 82% to 90%

Even though each team focuses on different areas, they're all pulling toward the same outcome: better retention through a better experience.

Team outings

When we step out of our work environment, we often speak more freely. Use that to your advantage. Create space for open conversations. Let your team voice their frustrations and help them unpack those feelings together.

Often, what feels like interpersonal tension is actually caused by:

• Lack of transparency: We don't know what other teams do, so we assume the worst.

• Lack of empathy: We don't understand others' constraints, so we think they have it easier.

• Lack of communication: We don't talk, so we assume others don't care about us.

Talking about these issues outside day-to-day delivery can create powerful shifts in perspective.

For example, during an offsite lunch, one of the engineers vented about how frustrating it was to deal with “slow responses” from the QA team.
That sparked a candid discussion where QA shared they were short-staffed and juggling three overlapping releases.

What started as a complaint turned into a moment of empathy, engineering offered to help write better pre-check documentation to reduce back-and-forth.

That one conversation did more for cross-team trust than weeks of status updates.

Cross team pollination

Don't stop at outings—organize cross-team events. Mix entire departments. Encourage interaction across boundaries.

Recurring rituals like weekly engineering meetings, chapter gatherings (e.g., iOS, backend, QA), or demo days can help teams see each other's work and challenges.

The goal: reduce "us vs. them" by building more "us".

For example, once we ran bi-weekly Engineering Demo Fridays. Each team had 10 minutes to share something they'd shipped, learned, or struggled with.

At first, attendance was low. But over time, people got curious: “Wait, how did the backend team cut deploy times in half?” or “Who built that accessibility tool?”

It created organic cross-team conversations, knowledge-sharing, and a renewed sense of pride in each other's work. People stopped seeing their colleagues as distant strangers and started seeing them as partners.

Externalizing

There's nothing wrong with a little rivalry if it's aimed in the right direction.

Instead of letting frustration turn inward, try turning it outward. Make the "them" an actual competitor.

Channel that energy into building better products, shipping faster, or solving harder problems than the company across the street.

For example, a frontend team was frustrated by slow decision-making and design changes. Instead of letting that resentment fester internally, their manager reframed the conversation: “What if we were a startup trying to beat us? How would we build this faster and better?”

That turned into a small, focused initiative: a three-week sprint to rebuild a key flow with half the steps, faster load times, and fewer dependencies.

The energy shifted. It wasn't about internal blockers anymore, it was about outpacing the competition and making something great.

Internal Mobility

The longer someone stays on the same team, the more they identify with it.

Encourage internal mobility, both temporary and permanent. Short-term embeds, rotations, or transfers help people understand how other teams operate and what challenges they face.

This builds empathy, reduces silos, and spreads skills and best practices.

For example, a backend engineer joined the mobile team for a one-month rotation.
At first, they were surprised by how much time was spent handling edge cases and App Store constraints, things they’d never had to think about.

By the end of the rotation, they not only appreciated the complexity of mobile development, but also suggested improvements to their own APIs to make mobile work smoother.

The rotation led to stronger collaboration, faster feature delivery, and a new culture of mutual respect.

Metrics and transparency

Trust erodes when we can't see what others are doing.

Instead of expecting every team to explain their internal workings, give them clear, observable metrics that reflect their contributions to company goals.

Think of each team as a black box: We don't need to know exactly how it works, as long as we can see it's moving the right metrics.

When we do see something off, we don't assume incompetence, instead we reach out to help.

For example, the infrastructure team was often seen as a black hole. Tickets went in, and weeks passed with little visibility.

To fix this, they started publishing a simple weekly dashboard: uptime metrics, average ticket response times, and progress toward quarterly goals.

Other teams quickly realized infra was actually delivering consistent value, they just hadn't been talking about it. The dashboard didn't just build trust. It opened doors to new questions, aligned priorities, and unexpected collaboration.

Conclusion

"Us vs. them" is a deeply human instinct. But in a company, it's not a fight we want to win because it means someone else in the company is losing.

As an engineering manager, you have the opportunity and the responsibility to bridge the gaps between teams, functions, and layers of the org.

Remind your team that we all belong to something bigger. Create opportunities to connect. Bring visibility, empathy, and transparency to your work.

Because when "us" starts meaning "all of us", then everyone wins.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Every project starts with optimism and good intentions, but even the best plans can go off track. What if you could spot potential problems before they happen, while there's still time to do something about them? In this article, you'll learn about the pre-mortem: a simple, practical technique for identifying risks early and building more resilient plans.

We'll explore what a pre-mortem is, why it's valuable for teams of any size, and how you can run one effectively. By the end, you'll have a clear, actionable approach to help your team anticipate challenges and avoid failure before it happens.

What is a Pre-mortem?

A pre-mortem is a proactive technique for uncovering potential problems before they happen. Instead of waiting for things to go wrong and analyzing failures after the fact, a pre-mortem asks you and your team to imagine that your project has already failed. Then, you work backwards to brainstorm all the reasons why things might have gone off track.

By anticipating obstacles and pitfalls in advance, you can develop strategies to prevent them or reduce their impact. This approach helps teams surface hidden risks, challenge assumptions, and prepare more effectively for success.

Why do a Pre-mortem?

Big projects—like migrating a service, enabling a major feature, or launching a new product—are complex and full of unknowns. Even the most experienced teams can overlook hidden risks or make assumptions that don't hold up in practice. When things go wrong, it's often not because of a single mistake, but a series of small issues that add up.

A pre-mortem helps you get ahead of these problems. By imagining your project has already failed, you give your team permission to voice concerns, challenge assumptions, and surface risks that might otherwise go unspoken. This process not only uncovers potential pitfalls, but also encourages creative thinking about how to avoid or mitigate them.

Ultimately, a pre-mortem builds resilience into your planning. It helps teams feel more prepared, reduces the likelihood of unpleasant surprises, and increases the chances of a successful outcome.

How to do a Pre-mortem?

Running a pre-mortem is straightforward and can be adapted to any project or team.

Here's a simple step-by-step approach:

• Set the stage: Gather your team and explain the purpose of the pre-mortem. Make it clear that the goal is to surface risks and concerns in a safe, blame-free environment.

• Imagine failure: Ask everyone to imagine that the project has failed spectacularly. The goal is to suspend disbelief and assume things went wrong, no matter how confident you feel today.

• Brainstorm reasons for failure: Invite each team member to list all the possible reasons why the project might have failed. Encourage people to think broadly. Consider technical issues, communication breakdowns, resource constraints, external dependencies, and even unlikely scenarios.

• Share and discuss: Collect everyone's ideas and discuss them as a group. Look for patterns, common themes, and surprising risks that might not have been obvious.

• Prioritize risks: Identify which risks are most likely or would have the biggest impact. Focus on the issues that could truly derail your project.

• Develop mitigations: For each high-priority risk, brainstorm actions you can take now to prevent it or reduce its impact. Assign owners and make these mitigations part of your project plan.

• Review and revisit: As your project progresses, revisit your pre-mortem findings. Update your risk list and mitigations as new information emerges.

This process is similar to planning a big family holiday: you map out each step, anticipate what could go wrong, and put plans in place to avoid or handle problems. By thinking ahead, you give your team the best chance of a smooth journey and a successful arrival.

It's time for a holiday

Imagine you're planning a family holiday. From leaving your house to arriving at your hotel, countless things could go wrong. A pre-mortem approach helps you anticipate and prepare for these risks, making your journey smoother.

For example:

• Packing the car: You might forget essential items.
  Mitigation: Use a checklist and involve everyone in packing.

• Getting to the airport: Traffic, getting lost, or a flat tire could delay you.
  Mitigation: Leave early, check traffic, and ensure your car is ready.

• Checking in: Missing documents or luggage can cause stress.
  Mitigation: Keep travel documents together and double-check your bags.

• Going through security: Forgetting to remove items can slow you down.
  Mitigation: Pack smart and wear easy-to-remove shoes.

• Boarding and flying: Missing snacks, toys, or comfort items can make the trip harder, especially for kids.
  Mitigation: Prepare a travel kit with essentials for everyone.

• Arriving and getting to your hotel: Transportation mix-ups or missing luggage can derail your plans.
  Mitigation: Pre-book transport and clearly label all bags.

By thinking through each step and planning for what might go wrong, you set yourself up for a successful, stress-free holiday. The same mindset applies to projects: anticipate, prepare, and mitigate risks before they become problems.

Conclusion

Pre-mortems are a simple but powerful way to build resilience into your projects. By taking the time to anticipate what could go wrong, you empower your team to surface hidden risks, challenge assumptions, and put practical mitigations in place—before problems arise.

While no process can guarantee a flawless project, running pre-mortems will help you catch issues early and avoid many of the pitfalls that lead to failure. The more you invest in pre-mortems, the fewer postmortems you'll need to write. In the end, it's about giving your team the best possible chance for success and learning from challenges before they become setbacks.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Giving and receiving feedback is an essential part of an engineering manager's life. Yet, it's a skill that many find challenging to master. Effective feedback can accelerate growth, build trust, and strengthen teams, while poorly delivered feedback can have the opposite effect.

Over the years, a variety of established techniques have emerged to help managers and engineers develop this crucial muscle. Each method offers its own perspective on how to structure and deliver feedback, aiming to make the process more constructive and less daunting.

In this article, we'll take a quick look at some of these widely used techniques, highlighting their strengths and limitations. More importantly, we'll introduce a novel approach, what we call the "Superpowers" method, which can help you deliver feedback in a way that feels more genuine, mature, and ultimately more effective for both you and your team.

What's Out There

BIO Model

The BIO model is a simple and effective framework for structuring feedback. BIO stands for Behavior, Impact, and Outcome. The idea is to focus on what was observed, the effect it had, and the result or consequence. This helps keep feedback objective and actionable, rather than personal or vague.

• Behavior: Describe the specific behavior you observed. Avoid making assumptions or interpretations—just state the facts.

• Impact: Explain the impact this behavior had on you, the team, or the project. This helps the receiver understand why the behavior matters.

• Outcome: Share the outcome or consequence of the behavior. This could be positive or negative, and helps clarify the bigger picture.

For example:

When you interrupted the team meeting yesterday (Behavior), it made it difficult for others to share their ideas (Impact), which led to a less productive discussion (Outcome).

The BIO model encourages clarity and empathy. By focusing on observable actions and their effects, it reduces the risk of feedback feeling like a personal attack. However, it's important to use this model as a guide, not a rigid formula, otherwise, feedback can sound robotic or insincere.

BOOST Model

The BOOST model is another popular framework for giving effective feedback. BOOST stands for Balanced, Observed, Objective, Specific, and Timely. This model is designed to ensure that feedback is constructive, actionable, and delivered in a way that maximizes its positive impact.

• Balanced: Provide a mix of positive and constructive feedback. Recognize what is working well, as well as areas for improvement.

• Observed: Base your feedback on behaviors or events you have directly observed, rather than hearsay or assumptions.

• Objective: Keep your feedback factual and free from personal bias or emotion. Focus on what happened, not why you think it happened.

• Specific: Be clear and precise about what you are addressing. Vague feedback is hard to act on.

• Timely: Give feedback as soon as possible after the event, while it is still fresh and relevant.

For example:

I noticed during yesterday's code review (Observed) that you provided detailed suggestions to help improve the module's performance (Specific). This was really helpful for the team (Balanced). However, there were a couple of comments that came across as abrupt (Objective). In the future, taking a slightly softer tone could make your feedback even more effective (Timely).

The BOOST model helps ensure feedback is fair, actionable, and delivered in a way that supports growth. By following these principles, you can help your team members understand both their strengths and areas for development, without undermining their confidence.

360-Degree Feedback

The 360-degree feedback1 method involves gathering input about an individual's performance from a variety of sources; peers, direct reports, managers, and sometimes even external stakeholders. The goal is to provide a more comprehensive and balanced view of a person's strengths and areas for improvement, rather than relying solely on a manager's perspective.

This approach is especially useful for uncovering blind spots and ensuring that feedback is not biased by a single viewpoint. By collecting feedback from multiple people who interact with the individual in different contexts, you can build a richer and more nuanced picture of their impact on the team and organization.

360-degree feedback is most commonly used as part of formal review cycles or development programs. It can help identify patterns in behavior, highlight consistent strengths, and surface opportunities for growth that might otherwise go unnoticed.

However, it's important to note that 360-degree feedback is primarily a tool for gathering information, not for delivering feedback directly. As a manager, you are responsible for synthesizing this input and presenting it in a constructive, actionable way. Care should be taken to ensure anonymity and to frame the feedback in a way that supports development rather than feeling overwhelming or punitive.

Shit Sandwich

The "Shit Sandwich2" is a feedback technique where constructive criticism is placed between two positive comments. The intention is to soften the impact of negative feedback by starting and ending on a positive note. For example, a manager might begin by praising an engineer's recent work, then mention an area for improvement, and finally close with another compliment.

While this approach is common among new managers and can make giving tough feedback feel less awkward, it has significant drawbacks. Many people quickly recognize the pattern, which can make the positive feedback feel insincere or manipulative. Over time, this erodes trust, as team members may start to anticipate criticism whenever they hear praise.

In the tech industry, the Shit Sandwich is generally discouraged. Authenticity and directness are valued, and feedback is most effective when it is honest and straightforward. Instead of relying on this formula, it's better to focus on delivering feedback with empathy and clarity, ensuring that both positive and constructive points are genuine and meaningful.

STAR Method

The STAR method3 is a widely used framework for both giving feedback and conducting behavioral interviews. STAR stands for Situation, Task, Action, and Result. This method helps ensure that feedback is grounded in context and focuses on specific examples, making it easier for the recipient to understand and act upon.

• Situation: Set the scene by describing the context or background where the behavior occurred.

• Task: Explain the specific task or challenge that was involved.

• Action: Describe the actions taken by the individual in response to the situation or task.

• Result: Share the outcome or impact of those actions.

For example:

During the last sprint (Situation), you were responsible for refactoring the authentication module (Task). You proactively identified legacy issues and communicated your plan to the team (Action), which resulted in a smoother deployment and fewer bugs reported (Result).

The STAR method is effective because it encourages feedback that is concrete and actionable, rather than vague or general. By walking through each step, you help the recipient see exactly what they did well or where they can improve, all within the context of real work situations.

Beyond formulas

Many of the feedback models above can be helpful, but they often assume the recipient isn't already aware of their own strengths and weaknesses. In reality, most engineers are thoughtful, capable professionals who are doing their best and have a good sense of where they excel and where they can improve.

When feedback is delivered in a way that feels overly formulaic or scripted, it can come across as disingenuous or even patronizing. People are quick to pick up on unnatural or insincere communication, which can erode trust between managers and their teams.

This is similar to the concept of the "uncanny valley4", a term from robotics and animation describing how something that appears almost, but not quite, human can feel unsettling or off-putting. In the same way, feedback that closely follows a formula but lacks genuine intent can feel unnatural and inauthentic. Team members can sense when feedback is being delivered just to tick a box, rather than to truly help them grow.

Often, when engineers make mistakes, it's not because they lack ability or awareness, but because their greatest strengths are being overused or misapplied. For example, someone who is extremely passionate about their work might sometimes come across as blunt or impatient. Another engineer who is highly detail-oriented might struggle to see the bigger picture.

This is where the Superpowers method comes in. By recognizing and naming these strengths, and acknowledging how they can sometimes go too far, you can deliver feedback that feels both genuine and constructive, helping your team grow while honoring what makes them unique.

Superpowers

Superpowers is not a formal feedback method or framework; it's a mindset shift. The idea is to observe and recognize the unique strengths each engineer brings to the team. This approach is inspired by concepts like CliftonStrengths5, which emphasize identifying and leveraging individual talents.

The key is to notice what someone does exceptionally well, their "superpower", and then reflect on how that strength, when overused or applied in the wrong context, can sometimes create challenges. For example, an engineer who is extremely fast at delivering code (superpower) might sometimes sacrifice quality for speed if not careful. Similarly, someone who is highly detail-oriented might struggle to see the bigger picture when their strength is taken to the extreme.

By framing feedback around superpowers, you acknowledge and celebrate what makes each person valuable, while also providing constructive guidance on how to balance their strengths. This helps feedback feel more genuine and supportive, and encourages engineers to grow without feeling diminished.

This approach is about seeing the whole person: honoring their strengths, understanding their impact, and helping them channel their abilities in ways that benefit both themselves and the team.

Conclusion

Giving effective feedback is one of the most important responsibilities of an engineering manager, but it's also one of the most nuanced. While established frameworks like BIO, BOOST, 360-degree feedback, and STAR can provide helpful structure, the most impactful feedback goes beyond formulas. By focusing on each person's unique strengths, and understanding how those strengths can sometimes create challenges, you can deliver feedback that is both genuine and constructive. The Superpowers mindset encourages trust, growth, and authenticity, helping engineers feel valued for who they are while supporting their ongoing development. Ultimately, the goal is to foster a culture where feedback is not just a process, but a meaningful tool for personal and team success.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

A big topic of debate among engineering managers is whether or not to have 1:1s with their engineers. Some embrace the stereotypical introversion of engineers and avoid 1:1s out of respect for their nature, while others strongly believe in the importance of regular 1:1s.

Even among those who value 1:1s, there are debates over:

• Cadence: Weekly, bi-weekly, monthly, etc.

• Leading the session: Should the manager define the agenda, or the engineer?

• Main topic: Should the 1:1 focus on work or on the engineer's Personal Development Plan (PDP)?

In this article, we offer a practical framework. You'll learn not just why 1:1s matter, but how to make each conversation truly impactful, helping you meet your engineers where they are, uncover hidden challenges, and guide them toward meaningful growth. Whether you manage one engineer or twenty, these insights will help you maximize the value of your limited time and become a multiplier for your team's success.

Why?

We believe 1:1s are one of the most important tools an engineering manager can leverage. They create a safe space for important topics, constructive feedback, and learning. Most importantly, they are the best opportunity to ensure the health and happiness of your engineers.

It's your chance to understand the components that make your team tick.

Why not?

There are valid reasons why an engineering manager might choose to reduce the frequency of 1:1s. For instance, if you're managing 20 engineers, holding weekly 30-minute sessions with each would consume 10 hours of your week, a significant time investment. While those conversations are incredibly valuable, some senior engineers may require less frequent check-ins, making it practical to adjust the cadence in a way that benefits both you and your team members.

Additionally, some engineers naturally prefer asynchronous communication, like written updates, chat, or team meetings over one-on-one conversations. For those who are more introverted or who haven't yet built a strong rapport with their manager, 1:1s can sometimes feel intrusive or uncomfortable. Managers may worry that pushing too hard for these meetings risks disengagement if the approach isn't thoughtful.

That said, we strongly advise against skipping 1:1s altogether. Regular face-to-face time remains essential for truly understanding how your engineers are doing and for fostering trust and connection that can't be replicated in group settings or written communication.

Tips & Tricks

The 1:1 is meant for your engineers' well-being and personal development. Here are some ideas to help you shape your 1:1s:

What would Maslow do?

Maslow's hierarchy of needs is a useful mental model for running effective 1:1s. It describes how human needs are layered, from the most basic (food, shelter) to growth and fulfillment.

Here's a simplified version:

• Physiological needs: Food, water, rest, shelter

• Safety needs: Personal and financial security, health, stability

• Belonging and love: Relationships, friendship, connection

• Esteem: Recognition, respect, achievement

• Self-actualization: Growth, purpose, personal potential

When your engineers show up to a 1:1, they're somewhere on that ladder. Your job is to meet them where they are—and help them move up.

If someone is struggling with basic or safety needs, they're not ready to talk about long-term growth. They need support and empathy. Once those needs are met, 1:1s become a platform for deeper topics: Team belonging, recognition, skill-building, and personal development.

Ask yourself:

Where is this person on the ladder today and how can I help them climb?

Have a Gemba mindset

Gemba Kaizen is a Japanese concept meaning "continuous improvement at the real place", where the work happens.

For engineering managers, this means using 1:1s to understand the real challenges your engineers face day-to-day, not just high-level updates, but the frustrations and blockers they encounter.

A good question to ask:

What's something frustrating you right now that I might not be aware of?

This invites your engineer to share real pain points and shows you're invested in making their work smoother.

Feedback Culture

If you're building a culture of feedback, 1:1s are invaluable. Feedback should flow both ways. Be open and receptive to feedback about your management style or team dynamics, and provide timely, constructive feedback to help your engineers grow.

Radical Candor, coined by Kim Scott, is a great framework: care personally, challenge directly. Show empathy and concern, but also be clear and honest about areas for improvement. This balance builds trust and accelerates development.

Tips for cultivating feedback in your 1:1s:

• Ask for feedback regularly: "What's one thing I could do differently to support you better?"

• Be specific and timely with your feedback.

• Balance praise with areas for growth.

• Use feedback as a conversation starter, not a lecture.

• Follow up on feedback to show you're invested in their development.

If your company uses tools like a Manager Performance Survey (MPS), 1:1s are an excellent opportunity to review and discuss feedback results in a personal, nuanced way.

Building a feedback culture takes time and consistency, but when done well, it transforms 1:1s from routine check-ins into powerful growth sessions.

Have an Agenda

As with any meeting, come with an agenda. This serves as a backbone for the conversation and ensures important topics aren't forgotten.

Our template is based on the concepts we've just discussed, and it can be adapted to fit your team's needs.

How are you? Happy and healthy?

Start by understanding the engineer's mental state. If they're not in the right headspace, address that first. Sometimes, just giving them space to talk helps them move forward.

Anything I can do for you?

Open yourself to supporting the engineer's needs. Your job is to help them be their best selves, and you can only do that by understanding what they need.

Day to day

Discuss day-to-day work. Engineers may want to share challenges or interesting learnings. Touch on this to get a sense of how things are going.

Personal development

This is the most important section. Help your engineers grow. If they have a PDP, ensure they're making progress. Use this time for coaching and clarifying next steps.

Translation

Part of your role is to translate strategy into tactics. Provide updates on new topics or changes relevant to your engineers. The clearer the "why", the more interested and accountable they'll become.

Dynamic topics

Sometimes, you'll want to uncover or address issues that have surfaced (e.g., from an MPS) or discuss recent company updates. Bring these topics up at the end of the 1:1, so the engineer is in the right headspace to discuss them.

Conclusion

1:1s are a powerful tool for engineering managers. With the right mindset and structure, they become more than just a meeting; they're a platform for growth, feedback, and real connection.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

There's nothing more important than time, yet most of us don't pay enough attention to how we use it—especially when it comes to our calendars.

In this article, I'll share some thoughts on how to take control of your time by designing a calendar that works for you, not against you.

Tips'n' Tricks

Ideal Calendar

Plans often fall apart—and that's fine. But that doesn't mean we should let our days drag us along. We still need to fight against entropy.

One powerful tool is the Ideal Calendar: a deliberate design of your week that reflects how you want to spend your time. Then, aim to bring your actual calendar as close to it as possible.

Oren Ellenbogen discusses this well in Leading Snowflakes1, a book tailored specifically for engineering managers. While the concept of time blocking and ideal weeks is covered more broadly in books like Deep Work2 by Cal Newport, Ellenbogen applies it directly to engineering leadership.

He introduces the "Ideal Week" as a tool to proactively block time for your most important responsibilities, such as:

• 1:1s

• Focus / thinking time

• Team rituals (standups, planning, retros)

• Learning and improvement

• Cross-functional collaboration

• Strategic work

Without designing your calendar with intention, it gets filled reactively and you drift away from being the kind of leader you want to be.

Context blocks

Not all work is created equal. Some of it is strategic, some operational. The cost of switching between these modes is high.

That's why it's helpful to break your week into context-specific blocks. Cluster similar types of work together to reduce context-switching and reclaim mental energy.

Put all your work in the calendar

Work lives in too many places: Jira, Google Docs, Notion, Post-its, email, Slack, your head. But everything you commit to will take time, so your calendar should reflect that.

No, you don't need to create an event for every single email. But you should absolutely have blocks for things like:

• Email and message triage

• Presentation preparation

• Deep work

• Admin tasks

This forces you to reckon with the true cost of your commitments.

Maker Time vs. Manager Time

This concept comes from Paul Graham's 2009 essay, "Maker's Schedule, Manager's Schedule"3. It's essential reading for anyone in a hybrid IC/leadership role.

Maker's Schedule (e.g., engineers, writers, designers) requires long, uninterrupted blocks of time.

Manager's Schedule (e.g., leads, execs) is structured around hourly meetings and rapid decisions.

The two schedules conflict. A meeting in the middle of the day can ruin an entire afternoon of focused work for a maker.

Being aware of which mode you're in, and protecting the right kind of time, makes a huge difference in your productivity and satisfaction.

Color Coding

Color coding your calendar is a simple but powerful technique. You can use it to:

• Distinguish between types of work (e.g., meetings, deep work, admin)

• Separate planned vs. unplanned work

• Highlight strategic vs. operational tasks

What you choose to color will depend on what you're trying to optimize for—and that can change over time. Personally, I tweak my color scheme every 6 months or so.

The visual feedback helps you quickly spot imbalances. Are you slipping back into IC habits? Avoiding strategic work? The colors will tell you.

Measure what matters

People often underestimate how easy it is to measure their time—and how valuable those insights can be.

Google Calendar has an API. You can pull your events and analyze things like:

• Hours spent in 1:1s

• Time in meetings

• Slack or focus time

• Work-life balance trends over time

With just a bit of scripting or a spreadsheet, you can get a data-driven view of where your time goes—and start making real improvements.

Final Thoughts

Your calendar is one of the highest-leverage tools you have as a leader. Use it with intention.

Design your ideal week. Block your time. Track what you do. Review and adjust. Your time is too valuable to leave to chance.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Introduction

Have you also noticed how companies are like people? They're born, they grow up, they stumble through awkward phases, and if they're lucky, they grow old. This blog post is a fun exploration of this idea, nothing too serious, just a lighthearted look at how companies evolve over time. From the naive newborn to the wise (but slow) elder, let's dive into the quirky life cycle of a company.

Phases

New born

The newborn phase is when a company is just an idea brought to life. It's naive, full of hope, and doesn't know much about anything. Like a baby flailing its arms around, it's trying to figure out what works and what doesn't. There's no business model, no structure, just vibes. The first prototype is a Perl script that uploads data to an Excel sheet, and that's all you need. Remember the early days of Twitter?1

It was just a place to tell people what you had for breakfast. No one knew what it was supposed to be, but it was fun.

Children

In the child phase, the company starts to get a hang of things. Revenue starts trickling in, and there's a sense of freedom. Every team has its own way of working. No structure, just play. It's like a playground where everyone is experimenting.

Think of early Google, where engineers had 20% time to work on whatever they wanted. It was chaotic, but it worked.2

Teenagers

The teenage years is the most awkward and dangerous phase. The company thinks it's all grown up now. It goes into hyperscale mode, burns through cash like there's no tomorrow, and buys every shiny new tool in sight. Developers try every new programming language they can find, the tech ecosystem becomes a jungle. This is where many companies make fatal mistakes.

Remember WeWork? They thought they were invincible, expanded too fast, and then... well, you know the rest.3

Adults

If a company survives its teenage years, it enters adulthood. This is where things start to stabilize. The books are in order, the product matures, and tooling gets standardized.

Think of Microsoft in the Satya Nadella era. Focused, efficient, and finally cool again. The company finds its ideal size and starts to operate like a well-oiled machine.

Mid-life

Mid-life is when the company starts to feel the weight of its years. This is the phase of re-orgs, layoffs, and rebranding.

Remember when Facebook became Meta? It's like a mid-life crisis but for companies. They might suddenly pivot to something completely different, hoping to stay relevant. It's a time of introspection and big, sometimes questionable, changes.4

Elderly

Very few companies make it to this phase. These are the giants that have been around forever such as IBM or General Electric. They've found their way of being, but they're so large and processed that adapting to change becomes painfully slow. When disruption hits, they look awkward and out of place, like your grandpa trying to use TikTok. They survive, but they don't thrive.5

Conclusion

Understanding the life cycle of a company isn't just a fun analogy It can also be a useful tool. By identifying the stage a company is in, we can get a sense of where it's headed and whether or not we want to be part of that journey. Is it a chaotic teenager burning through cash, or a stable adult with a clear vision? Recognizing these behaviors can help us make better decisions about where to work, invest, or collaborate. After all, every company has its phases, what matters is how they navigate them.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Interviewing candidates for roles that have opened up in your company has to be predefined for a truly unbiased approach.

Hiring managers evaluate candidates based on limited interactions, often relying on incomplete information, where unconscious biases might influence outcomes. This is a risky game, as hiring someone unfit for the role can lead to costly mistakes. Even greater risks lie in overlooking strong candidates from underrepresented groups due to a poor interview process – an issue that is even more urgent today, as diversity, equity, and inclusion (DEI) initiatives face ever-increasing political and corporate pushback.

To help hiring managers avoid these risks, it’s beneficial to outline a structured approach to interviews, where candidates are evaluated based on predefined competencies. This way, managers can make more informed decisions, reduce bias, and increase the likelihood of selecting the right talent for their teams.

What is bias?

Bias is an unconscious tendency of skewed judgment, often leading to unfair assessments during interviews. For instance, an interviewer might undervalue a candidate’s communication skills due to their accent or misinterpret nervousness as incompetence. Bias can arise from factors such as personal perceptions, prior experiences, or giving extra weight to minor details.

Daniel Kahneman describes an example of the halo effect in his book, Thinking, Fast and Slow, with a simple experiment. Participants were asked to guess the Grade Point Average (GPA) of a graduating student. One group received no details about the student, while the other was told: “Julie is a graduating senior at a university. She read fluently at the age of 4. What is her GPA score?” With no information about Julie, an average GPA of 3.3 is a reasonable guess. However, prompted with the piece of information “she read fluently at the age of 4,” the participants guessed higher scores. Similarly, interviewers might overestimate a candidate’s abilities based on minor details like a CV formatted in LaTeX.

Recognizing bias isn’t enough to eliminate its effects – just as understanding an optical illusion doesn’t change how we perceive it. For example, squares A and B in the image below are the same color, yet most people perceive A as darker due to contextual cues.

How to design a non-biased interview process

A well-designed interview process begins before the initial sit-down. First, define the candidate profile – a list of skills and behaviors that a new hire will need to succeed in the role. For technical skills, it might be:

• Knowledge of database performance characteristics.

• Ability to design complex APIs.

• Proficiency with a programming language used in the company.

Beyond technical skills, consider team culture and define expectations in that regard. Does the role require a candidate with strong collaboration skills? Should candidates be data-driven? Should they be able to learn new things quickly? Defining these expectations ensures consistency across evaluations and reduces reliance on subjective impressions.

Once you have a profile, craft interview questions that elicit evidence of these skills and behaviors. While you’re crafting these specific questions, consider what you’d need to hear from a candidate that proves their ability to perform in the role.

For example, if you’re looking for an applicant’s ability to learn and adapt, you might ask them:

• Can you share an instance where you had to learn new tools or technologies quickly?

• Can you tell me about a situation when you made a mistake?

• Can you give me an example of when a major change forced you to re-plan an ongoing project?

Similarly, if you’re looking for collaboration and communication as core characteristics, think about asking:

• Can you describe a situation where you helped a colleague with a task?

• Can you describe a challenging disagreement with a co-worker and how you resolved it?

• Give me an example of when you pitched an idea to your team.

If you’re looking for someone with business awareness, ask questions like:

• Can you tell me how your current work affects the end customers of your product?

• Give me an example of when a change you made had a significant business impact. How did you measure it?

Importantly, you evaluate candidates on all skills and behaviors listed in the profile to avoid the Halo-effect.

By focusing on evidence-based questions, you create opportunities for candidates to demonstrate their fit while minimizing personal biases.

Running a bias-free interview

During the interview, your job is to collect as much information pertaining to the role’s desired skills and behavior. Your drafted interview questions should be deliberately broad; that way, they open the conversation and provide opportunities to follow up. It’s totally fine if the candidate’s initial response is vague; at that point, it’s down to you to dig into details to assess the candidate.

For instance, if you were to ask about a time the candidate’s work had been blocked waiting on someone else, their initial answer might be, “Our team was blocked by another team. We needed a change in the API of their service.”

It’s not really what we’re looking for. This answer describes the skeletal context, but it doesn’t provide much else about their actions. Your follow-up questions and the subsequent conversation might look like this:

• Hiring manager: Tell me more. What did you do to resolve this situation?

• Candidate: We organized a meeting and discussed all the details.

• Hiring manager: I understand there were other people involved. Can you please describe the steps you took to unblock your team?

• Candidate: I went to the other team’s code base and checked if they had the data that my team needed. I also briefed my manager on the results of my research and why we require this new field. Then, I asked my manager to lead the conversation with the other team about the timelines for the changes.

This answer might be sufficient. Ultimately, you want to understand whether the candidate’s approach would translate well in your team and if this is the level of seniority you expect from the candidate. The conversation might go smoother if the candidate uses a framework when answering, such as the STAR system. However, not being familiar with it doesn’t make the candidate a bad fit for the job.

If you’re finding that the candidate’s questions lack elaboration, lean on probing questions like these:

• Describe the timeline of the situation; when did it start? How long did it take to resolve it?

• What was the outcome of the situation? Which of your actions contributed to this outcome?

• What did you learn from this experience? What would you do differently?

Making a decision after the interview

Hiring decisions should rely on documented evidence rather than gut feelings or peer opinions. To avoid groupthink, each interviewer should independently record their observations immediately after the interview, focusing on facts rather than interpretations. Observation is objective and focuses on “what” is happening without adding personal judgment. On the other hand, interpretation seeks to explain “why” or “how” something happens by adding evaluation. For example:

• Observation: The candidate provided only one example of helping peers – doing code reviews.

• Interpretation: The candidate lacks collaboration skills.

The nonviolent communication approach provides guidance on noting observations: speak what you see or hear, avoid generalization, and fact-check your statements.

It takes practice to incorporate this approach. As a hiring manager, encourage interviewers to distinguish between these two types of statements and back up interpretations with specific observations. Ask the interviewers what they observed, and remind them that we don’t judge personalities; we assess fit for the job based on behaviors crucial to the role.

Final thoughts

Personal preferences, which can be biased, shouldn’t be the main reason for hiring someone. The goal of the interview is to gather evidence of the candidate’s ability to perform the job. How you conduct the interview and the process you follow make the difference between “I kind of like them” and an informed decision.

Remember that when it comes to the interview, the best candidates could be on their worst day, leading to a poor outcome. You never know what a candidate is going through, and with a well-designed process, you should be able to discern their competency for the role despite superficial trip-ups. Design your process well, be humble, and treat people with respect.

This article was originally published on LeadDev.com on March 03, 2025.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

As an engineering manager, one of your most challenging responsibilities is addressing performance issues within your team. How do you help struggling engineers improve while maintaining team morale and productivity? And what steps should you take if improvement doesn’t happen? This article is for managers navigating these tough situations, offering practical advice on using a Personal Improvement Plan (PIP) effectively to support your team and protect your organization.

Tell me about a time

You will remember from the first time you had an engineering manager interview that you get asked about what you would do with low performers. Of course, you told the interviewer that you would do your utmost best to re-integrate the engineer into the team and help them improve.

You likely mentioned that you would:

• Have regular 1:1s to understand underlying issues

• Provide clear feedback and expectations

• Offer additional resources, training, or mentorship

• Adjust assignments to better match their strengths

• Create opportunities for them to demonstrate their capabilities

Then the interviewer probably went on asking about what you would do if all else fails. The answer they're after is a PIP. This is a formal document that outlines specific steps an engineer must take to improve their performance. Both you and the engineer sign this agreement.

The PIP is a last resort, implemented only after other improvement strategies have failed. It serves two purposes: ensuring you've exhausted all options to help the engineer succeed, and creating a necessary paper trail should termination become unavoidable.

What's in an Effective PIP?

A PIP must be specific and comprehensive. It should clearly outline:

• Concrete steps the engineer must take to improve

• Support measures you as a manager will provide

• Potential consequences if improvement goals aren't met

• A realistic timeline for achieving the required changes

Remember that a PIP represents a critical juncture in an employee's career path. If it fails, termination is often the next step. This decision carries significant weight and shouldn't be made in isolation. Always involve Human Resources (HR) and your own manager throughout the PIP process to ensure proper guidance and compliance with company policies.

The Setup

Creating an effective Personal Improvement Plan requires careful documentation and structure. A well-crafted PIP clearly identifies performance issues, connects them to company expectations, and establishes specific success criteria.

Essential components of a PIP document

A comprehensive PIP should include:

1. Performance Gaps: Document specific behaviors that don't meet expectations

2. Alignment with Competency Framework: Connect issues to your company's career ladder

3. Performance Improvement Objectives: Define clear, measurable expectations

4. Measurement Criteria: Establish both qualitative and quantitative metrics

5. Timeline: Set specific deadlines for improvement milestones

6. Support Resources: Outline what tools, training, or coaching will be provided

Sample PIP structure

Here's a template of how a formal PIP might be structured.

This structured approach ensures all parties understand the performance gaps, expectations, measurement criteria, and timeline. By explicitly connecting issues to your company's competency framework, you create an objective foundation for evaluation.

Remember that the PIP should be treated as a collaborative tool for improvement rather than simply documentation for termination. The goal is to provide a clear path for the engineer to succeed.

Monitoring Progress

As a manager, ensure you have regular check-ins (which should already be part of your routine) to track the engineer's PIP progress. Maintain a detailed paper trail documenting all steps taken to support the engineer's improvement.

This documentation should record all topics discussed during your 1:1s. This paper trail is essential because if the PIP ultimately fails and termination becomes necessary, you'll need evidence demonstrating you provided adequate support. Remember that termination carries legal implications, so thorough documentation protects both you and your organization.

Closing the PIP

If all goes according to plan, the engineer will successfully re-integrate and operations will return to normal. However, if improvement targets aren't met, you'll need to have a serious conversation about their future with the company.

A PIP can conclude in several ways:

1. Success: The engineer meets all improvement targets and returns to good standing.

2. Extension: Progress is evident but incomplete, warranting additional time.

3. Demotion: The engineer might be better suited for a different role with adjusted responsibilities.

4. Termination: If improvement targets aren't met despite adequate support, employment may end.

If termination becomes necessary, the conversation typically leads to one of two outcomes:

• The engineer acknowledges their challenges and agrees that parting ways is the best solution

• The engineer disputes the assessment, requiring HR and your manager's involvement

Once the case transfers to HR, your direct responsibility in the process generally concludes as HR manages the remaining procedures.

In rare cases, the situation may escalate to legal proceedings, which underscores the importance of maintaining comprehensive documentation throughout the PIP process.

While hopefully you'll never need to navigate this challenging scenario, being prepared ensures you can handle it professionally if necessary.

Conclusion

Implementing a PIP is undoubtedly one of the most challenging aspects of engineering management. No one enjoys putting a team member on a PIP, and the process can be emotionally taxing for everyone involved. However, when used correctly, a PIP is an essential tool that serves multiple important purposes.

First and foremost, it provides struggling engineers with a structured framework to understand expectations and improve their performance. It demonstrates your commitment to their growth and success rather than simply giving up on them. Many engineers have successfully used PIPs as catalysts for significant professional development.

Second, it ensures fairness and transparency within your team. Other team members notice performance issues, and addressing them properly maintains team morale and standards. Ignoring problems sends the wrong message to your high performers.

Finally, a PIP protects your organization by ensuring due process and proper documentation. While we hope every PIP leads to improvement rather than termination, being prepared for all outcomes is part of responsible management.

Remember that how you handle these difficult situations defines you as a leader. Approach PIPs with empathy, clarity, and professionalism, and you'll build trust with your team even through challenging circumstances.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Have you ever wondered how some organizations decide on their structure? How do they decide who reports to whom? Which teams collaborate together whereas others are placed apart?

Regardless of who makes these decisions, the structure of an organization will have an effect on the software that is produced. This is known as the Conway's Law1 (based on his article titled “How do committees invent?“)

Conway argues that there is a two-way relationship between a company's structure and its software architecture. A rigid, top-down team structure often leads to unusual architectural patterns. Similarly, a monolithic system with poorly defined boundaries tends to result in teams that are also poorly defined.

Where is the link

The link between organizational structure and system architecture lies in the way teams communicate and collaborate. When teams are structured around specific functions or departments, the systems they build often reflect these boundaries. For example, if a company has separate teams for frontend and backend development, the resulting system might have a clear separation between frontend and backend components. While this can work well in some cases, it can also create inefficiencies when changes require coordination across multiple teams.

A real-world example of this can be seen in e-commerce platforms. Imagine a company where the product catalog, search, and checkout systems are owned by different teams. If these teams are siloed and rarely collaborate, the systems they build might have poorly defined integration points, leading to a fragmented user experience. Conversely, if the organization is structured around user journeys (such as a team owning the entire "browse and purchase" flow) the resulting system is more likely to have seamless integration, as the team is incentivized to optimize the entire experience rather than just their individual components.

The mess you’re in

You shouldn't worry if your organization or architecture is a mess. It's natural for structures to evolve chaotically over time. In such cases, Conway's Law can actually be leveraged to your advantage.

If you want to change your system architecture into a more modular one, start by restructuring your teams. Once you have the right teams configured appropriately, the architecture will naturally evolve in the desired direction.

This transformation won't happen overnight. It requires patience and persistence, but gradually, the system architecture will begin to mirror your new organizational structure. By intentionally designing your organization to reflect your desired technical architecture, you can guide your systems toward a healthier structure.

Map and Align

To leverage Conway's Law effectively, you first need a clear understanding of both your organizational structure and system architecture. A comprehensive, though not necessarily perfect, view of how different system components interact is essential.

Mapping Your Organization

Most companies have HR tools that can export the current organizational structure. This gives you a visual representation of reporting lines and team compositions.

Often, the structure that organically emerges in an organization feels logical at first glance. The marketing department might have an Ads team and an A/B testing team, while a communications department might have email and in-app communications teams. This division seems natural until you examine the actual workflows. For example, if the Ads team heavily relies on email campaigns for their advertising efforts, then separating them from the email team creates unnecessary coordination overhead. In such cases, it would make more sense to structure teams around these workflow dependencies rather than traditional departmental boundaries.

Ultimately, you should have something similar to the following diagram:

Mapping Your Architecture

With your organizational map in hand, you can then document your system architecture. The C4 Model2 provides an excellent framework for this purpose. Start with Context and Container diagrams to gain sufficient understanding.

Context diagrams offer a high-level system overview, helping you engage with individual teams as they create more detailed container-level diagrams.

For more sophisticated mapping, consider using graph databases like Neo4j3. These tools excel at visualizing complex relationships between systems and teams, making it easier to identify misalignments.

Visualizing the Relationship

In the visualization below, we've mapped both teams (represented as blue nodes) that belong to the same track and the systems they own (represented as red nodes). The solid lines connecting blue nodes to red nodes indicate ownership relationships, which team is responsible for which system. Meanwhile, the lines between red nodes represent dependencies between different systems. This dual-layer mapping reveals where organizational and architectural structures may be misaligned. When a system has many dependencies with systems owned by different teams, it suggests potential communication bottlenecks and coordination challenges. Ideally, systems with strong interdependencies should be owned by teams with equally strong collaboration channels, minimizing the organizational "distance" that information must travel.

We can see a couple of issues here. Even though these teams all live in the same track, it appears that except for Teams 2 and 4, no teams' ownables depend on each other. This raises the question: should Teams 1 and 3 remain in this organization or be moved elsewhere?

We can also see an interesting balance between the number of ownables per team. Assuming that each ownable has similar complexity and codebase size, if Team 1 is maintaining its systems without issues, it might be worth considering merging Teams 2 and 4 since they have fewer ownables. Conversely, if Team 1 is struggling with its ownership load, it might be wise to adopt a similar approach to Teams 2 and 4 by breaking Team 1 into two smaller teams.

Start to optimize

Once both architectures are mapped, you can identify optimization opportunities. A common goal is increasing delivery speed. This often means arranging your organization so that components that change together are owned by teams that work closely together.

The principle "things that change together should be close together" applies to both code and organizational structure. Teams with similar or interdependent responsibilities should be grouped proximally in the organizational chart, mirroring how their code components interact in the system architecture.

By intentionally aligning your organizational structure with your desired system architecture, you can create a virtuous cycle that improves both over time.

Another valuable optimization target is innovation capacity. When mapping reveals that certain teams are heavily constrained by cross-team dependencies, it may indicate barriers to experimentation. By restructuring to create more autonomous domains, where teams have end-to-end ownership of user-facing capabilities, you can unleash creative potential. This approach allows teams to innovate within their domains without being blocked by organizational boundaries. For instance, if your mapping shows that every feature enhancement requires coordination across five different teams, consider reorganizing around capability-focused teams instead of technology-focused ones. Teams empowered with full-stack expertise and clear domain boundaries can rapidly prototype, experiment, and deliver novel solutions, turning Conway's Law into an innovation accelerator.

Conclusion

Conway's Law reveals that software architecture and organizational structure are deeply intertwined, each influencing the other. By understanding this relationship, organizations can strategically align their team structures with desired architectural patterns. This alignment doesn't happen automatically—it requires intentional mapping, analysis, and restructuring. When done effectively, organizations can optimize for delivery speed, innovation, and overall system health. Rather than fighting against Conway's Law, successful organizations embrace it as a powerful tool for driving positive change in both their teams and their technology.

Our Thoughts

Michael Lopp, a veteran engineering leader with experience at major tech companies like Apple, is well-known for his sharp, insightful writing on leadership and workplace dynamics, often infused with dry humor and relatable anecdotes. His blog, Rands in Repose, has become a staple for engineering managers seeking wisdom with a side of wit, and his books, like Managing Humans, blend deep experience with entertaining storytelling. His humor shines in the way he skewers corporate absurdities while offering genuinely useful advice. Beyond writing, Lopp is also the creator of the Rands Leadership Slack, a thriving online community where thousands of engineers and managers exchange ideas, share struggles, and, true to his style, engage in plenty of irreverent banter.

The book is a collection of insightful essays packed with practical tips and tricks for engineering managers. Drawing from his extensive experience, Lopp shares guidance on navigating leadership challenges, fostering team culture, and making effective decisions. One of his key insights is that it takes ninety days to truly understand a new job—after an initial honeymoon period, a month of doubt follows, where everything broken or strange about the role becomes glaringly obvious, making you question your decision. Another highlight is his reliance on the whiteboard as a leadership tool, using it to visually map out evolving situations, helping to clarify discussions and track shifting priorities. Throughout the book, Lopp's signature humor and real-world wisdom make it a must-read for managers looking to level up their leadership skills.

Call to Action

Do you have a go-to tool, like Lopp’s whiteboard, to help you clarify complex situations and communicate evolving priorities? If not, what visual or organizational method could you start using today?

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

Software development is a complex endeavor. Despite our best efforts, failures are inevitable. The key isn't to avoid failure altogether (which is impossible), but to learn from it and improve. This is where the software post-mortem comes in.

What is a post-mortem?

A post-mortem (also sometimes called a retrospective, though the terms aren't perfectly interchangeable) is a structured meeting or process conducted after an incident, project completion (successful or not), or significant event. Its purpose is to analyze what happened, why it happened, and what can be done to prevent similar issues in the future.

Why are post-mortems important?

Learning from mistakes: The most obvious benefit is the opportunity to learn from errors. By dissecting what went wrong, we can identify patterns, weaknesses in our processes, and areas where we need to improve our skills or tooling.

Improving processes: Post-mortems help us refine our development, testing, and deployment processes. They can reveal bottlenecks, inefficiencies, and areas where automation could be beneficial.

Building a culture of blamelessness: A crucial aspect of effective post-mortems is a blameless environment. The goal is not to assign blame to individuals, but to understand systemic issues that contributed to the problem. This encourages open communication and honest reflection.

Knowledge sharing: Post-mortems create a shared understanding of what happened and why. This knowledge can be disseminated throughout the team and organization to prevent similar issues from recurring.

Key elements of an effective post-mortem

An effective post-mortem should be conducted in a timely manner, as soon as possible after the event, while the details are still fresh in everyone's mind. It's important to define clear objectives, outlining the specific event or project being analyzed and the desired outcomes. Diverse participation is crucial, including representatives from all relevant teams such as development, testing, and operations, to ensure a comprehensive understanding from different perspectives. Data collection is essential, gathering relevant information like logs, error reports, performance metrics, and communication records. A structured discussion should be facilitated, using frameworks like "Start, Stop, Continue" to identify what to start, stop, and continue doing, the "5 Whys" to drill down to the root cause, or creating a timeline of key events. Finally, action items should be identified, assigning owners and deadlines to address the issues, and the entire process should be documented for easy access and future reference.

Creating a blameless environment

Creating a blameless environment is essential for honest and productive post-mortems. Here are some tips:

Emphasize systemic issues: Focus on identifying systemic issues rather than individual errors.

Use inclusive language: Avoid accusatory language. Use phrases like "What happened?" instead of "Who did this?".

Lead by example: Managers and team leaders should model blameless behavior by openly discussing their own mistakes.

Celebrate learning: Recognize and reward teams that demonstrate a commitment to learning from failures.

Incident recreation in controlled environments

Creating safe opportunities to reconstruct failures provides teams with profound learning advantages beyond traditional discussion-based post-mortems. By establishing isolated sandbox environments that mirror production settings, engineers can methodically reproduce the incident conditions without risking further system damage. This hands-on approach transforms abstract conversations into tangible demonstrations where team members can directly observe failure mechanisms and test theories in real-time. The recreation process itself often reveals subtle contributing factors that might be missed in purely theoretical analysis, as engineers watch the actual cascading effects unfold before them. These controlled recreations serve multiple purposes beyond immediate understanding—they become perfect testing grounds for proposed fixes, allowing verification that solutions actually address root causes rather than just symptoms. Additionally, documented recreations create invaluable onboarding and training resources, helping new team members understand complex system interactions through concrete examples rather than documentation alone. When combined with video recordings or step-by-step guides, these recreations build an institutional knowledge base that preserves hard-won insights for future teams.

Reverse chronology analysis

Approaching post-mortems through reverse chronological examination offers a fresh perspective that often uncovers insights missed by traditional forward-facing analysis. In this approach, teams begin with the final error state and methodically work backward through each preceding event, decision point, and system interaction that ultimately led to failure. This backward-facing technique naturally counteracts hindsight bias by positioning the team at each historical moment with only the information available at that time, revealing genuine intervention opportunities rather than idealized scenarios. As teams trace backward through the incident timeline, they naturally identify the earliest inflection points where alternative actions could have prevented cascading failures. This approach particularly excels at uncovering organizational and procedural weaknesses, as it highlights decision constraints that may have seemed reasonable in isolation but proved problematic in sequence. The method also focuses attention on practical prevention mechanisms rather than theoretical causation models, leading to more actionable recommendations. Teams commonly report that reverse chronology sessions generate unexpected insights about monitoring gaps, alert thresholds, and early warning indicators that might otherwise remain undiscovered through conventional analysis methods.

Following up

The post-mortem is not the end of the process. It's crucial to follow up on the action items and ensure that they are implemented. Regularly review the post-mortem documentation to track progress and identify any new issues that may arise.

Site Reliability Engineering (SRE) teams can play a pivotal role in this follow-up phase, serving as neutral third-party enforcers to ensure that critical improvements identified during post-mortems don't fall victim to competing priorities. By embedding post-mortem action items into engineering roadmaps and sprint planning sessions, SRE teams create accountability across the organization without appearing punitive. The SRE perspective brings valuable operational insight, helping development teams understand which fixes will have the most significant reliability impact. These teams can establish formal review cadences—weekly for critical issues, monthly for less severe findings—where action item owners must demonstrate progress, creating healthy pressure to complete remediation work.

Service Level Objectives (SLOs) provide concrete measurements to validate whether implemented fixes actually resolve the underlying issues. By establishing clear, measurable SLOs that directly connect to incident causes, teams gain quantifiable evidence of improvement rather than relying on subjective assessments. For example, if a post-mortem revealed database timeouts as the root cause of an outage, an SLO monitoring connection pool exhaustion rates provides clear evidence of whether the fix successfully addressed the problem. This data-driven approach transforms abstract promises into empirical results, enabling teams to confidently close post-mortem action items only when metrics demonstrate genuine improvement. Additionally, tracking SLO violations before and after implementing fixes creates a feedback loop that reinforces the value of thorough post-mortems and diligent follow-through, ultimately building organizational resilience against similar failures in the future.

Conclusion

Software post-mortems are a valuable tool for improving software quality, processes, and team performance. By embracing a culture of blamelessness and focusing on learning from mistakes, we can turn failures into opportunities for growth and innovation.

If you’re curious to see some template post-mortems have a look at this GitHub repository. Another great resource is public post-mortems published by companies. Have a look at this GitHub repository for a nice collection.

Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.

Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.

Get the book

In the world of engineering management, the journey to becoming an effective leader is akin to the path of a master craftsman. Just as a craftsman hones their skills through a deep understanding of their tools and materials, an engineering manager refines their abilities by deeply understanding themselves. This self-awareness is the cornerstone upon which a robust managerial style is built, a style that defines not only how you lead but also how you navigate challenges and inspire your team.

Defining your unique approach

To begin this journey, consider defining your unique approach to work, your values, and your non-negotiables. Reflect on what you are willing to tolerate and what you unequivocally stand against. Delve into questions about delegation. How comfortable are you in entrusting tasks to your team versus handling them yourself? Moreover, envisage how you might respond to a spectrum of situations, from triumphs to setbacks.

Drawing inspiration from leaders who resonate with you can offer valuable insights into your own style. Take figures like Barack Obama, consider what aspects of their leadership strike a chord within you. It could be their eloquence, their coaching approach, or even their presence. Admiration for a leader often stems from shared perspectives, providing a foundational blueprint for your managerial evolution.

Unlocking insights through DISC analysis

One powerful tool at your disposal for this self-discovery journey is the DISC analysis1. This assessment delves into your Dominance, Influence, Steadiness, and Conscientiousness tendencies. By exploring these facets, you gain a comprehensive view of your natural inclinations, communication preferences, and decision-making tendencies.

Understanding your DISC profile empowers you to tailor your managerial approach. Are you someone who excels in visionary thinking and strategic planning (Dominance)? Do you thrive on building relationships and fostering collaboration (Influence)? Are you a steadfast advocate for stability and harmonious teamwork (Steadiness)? Or do you prioritize precision, structure, and meticulousness (Conscientiousness)?

Through this understanding, you can play to your strengths while also identifying areas for growth. DISC analysis provides a lens through which you can adapt your approach to different team members, effectively bridging gaps in communication and work styles.

Harnessing Clifton Strengths to leverage strengths

In the journey of crafting your managerial identity, exploring different tools for self-discovery is invaluable. Alongside the DISC analysis, another illuminating avenue is the Clifton Strengths2 assessment. This assessment, based on positive psychology principles, unveils your innate strengths and talents—assets that play a pivotal role in shaping your unique management style.

Clifton Strengths identifies your top strengths from a list of 34 distinct themes. These themes encompass a spectrum of attributes, such as strategic thinking, relationship building, influencing, executing, and more. Recognizing these strengths helps you comprehend your natural tendencies and the aspects of leadership that come naturally to you.

Armed with insights into your dominant strengths, you can tailor your management approach to leverage what you naturally excel at. For instance, if your strengths lean toward strategic thinking, you might find solace in crafting long-term visions for your team. On the other hand, if relationship building is a forte, you could foster a collaborative and inclusive team culture.

Clifton Strengths not only uncovers your strengths but also highlights areas where you might need complementary talents. This awareness aids in assembling diverse teams that collectively possess a wider spectrum of skills. A balanced team can more effectively tackle multifaceted challenges.

Your Clifton Strengths profile can guide your communication strategy. If your strengths lie in empathy and understanding, you can foster open dialogue and empathetic listening within your team. If your strengths involve strategic thinking, you might excel at conveying a clear vision and strategic goals.

While your strengths provide a strong foundation, they don't limit your growth. Clifton Strengths also offers insights into potential blind spots or areas for development. Acknowledging these areas encourages your ongoing personal and professional growth.

By incorporating Clifton Strengths into your journey of self-discovery, you gain a multi-dimensional understanding of your managerial style. Like a master craftsman who knows the intricacies of their tools, you'll have a clear grasp of your inherent abilities, and how they can be fine-tuned to guide your team toward success. Remember, your strengths aren't just assets; they're the building blocks of a dynamic and effective leadership approach.

Management styles

Understanding your character and personal management style is crucial. Some people tend to have a more democratic, coaching style, whereas others might be more autocratic and teaching. There is no good or bad when it comes to management styles. What is important is understanding your own style and the tools that work well with it. For example, a democratic leader would greatly benefit from tools such as polls, elections, referenda, and surveys, whereas an autocratic leader could better leverage certain award and punishment systems.

Strengths vs Weaknesses

Focusing on your strengths is essential, as highlighted by the principles of Clifton Strengths. Apply the same to your team to ensure you have a rock-band and not just a group of rock-stars.

The Dimensions of engineering management

Nothing in the realm of engineering management is confined to absolutes of black and white. Instead, every facet resides on a dynamic spectrum. These are dimensions of variability, characteristics that shape the tapestry of an engineering manager's approach.

Autocratic vs Democratic

In the intricate realm of engineering management, there exists no singular "right" or "wrong" approach to leadership. Instead, it's about discerning which tools align best with your style, thereby enhancing your efficiency and your team's effectiveness. One of the fundamental dimensions in leadership style revolves around the spectrum between an autocratic and a democratic approach.

Hands-on vs Hands-off

Some engineering managers believe that it’s better to be able to actively do some individual contributor work. This has several benefits, such as being able to help the engineers when they get stuck and better understanding the needs of the team. However, it also has disadvantages, such as the difficulty of balancing the workload and the risk of becoming a micro-manager.

Strategic vs Tactical

Within the realm of engineering management, a fascinating spectrum of managerial styles emerges, each driven by a unique emphasis on aspects like strategy, execution, and involvement. At the heart of this dichotomy lies a dynamic interplay between the 'Why,' the 'What,' and the 'How'—three pivotal components that shape an engineering manager's approach.

Pragmatism vs Precision

The spectrum of approaches within engineering management is akin to the spectrum one finds among engineers themselves. This dimension becomes especially relevant for Engineering Managers, many of whom come from an engineering background. It revolves around the interplay between pragmatism and precision, and it influences not only how an engineering manager manages but also how they guide their teams.

Emotion-driven vs Data-driven

In the realm of engineering management, the debate between emotion-driven and data-driven decision-making is critical, with both approaches offering unique advantages and drawbacks. Emotion-driven leadership, rooted in empathy and intuition, enhances team morale, builds strong relationships, and allows for adaptability, but can sometimes lead to subjectivity and potential burnout. Conversely, data-driven leadership relies on empirical evidence and analytics, ensuring objectivity, measurable outcomes, and informed strategies, yet risks overreliance on data and neglect of human factors. The most effective engineering managers recognize the importance of balancing these approaches, integrating empathy with data, communicating transparently, fostering a culture of feedback, and adapting to situational needs. By doing so, they create a leadership style that not only drives results but also fosters a culture of trust, collaboration, and growth.

Conclusion

In the dynamic world of engineering management, the interplay between various dimensions of leadership is a nuanced dance. The best leaders understand when to step lightly and when to lay a solid foundation, recognizing that success often lies in finding the delicate equilibrium between these dimensions. By embracing self-awareness and leveraging tools like DISC and Clifton Strengths, you can craft a managerial style that not only achieves results but also fosters a culture of excellence, growth, and camaraderie.