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

More and more companies are adopting a “builder” mindset. With Claude, Codex, and similar tools, software creation has become radically more accessible, and almost anyone in a company can now open a PR and ship internal or customer-facing tools.

Today, PRs are pouring in from all walks of life: product managers, customer support agents, the head of finance, and even CEOs. That cross-functional energy is exciting, and some of the best ideas do come from the intersection of disciplines. But this speed also shifts hidden work onto engineering through review load, operational risk, and long-term maintenance.

We’re optimizing for velocity, often as if it were the only metric that matters. If everyone can build, then one question matters more than ever: who owns production when things break?

A whole new world

PR volume is increasing fast, and PR size is increasing with it. Reviews that used to be manageable are now routinely 10–30k changed lines. The bottleneck is no longer writing code; it’s understanding and validating it. To keep up, engineers are increasingly using LLMs to review LLM-generated code. Even CI/CD becomes harder to trust when test logic and pipeline logic are also AI-generated. At that point, we’re often relying on one model to validate another model. But did we really think this through?

What happens when PRs exceed our context windows?

What happens when regressions are introduced far from the files under review?

What happens when our codebases reach 60 million lines?

What happens when token costs increase?

Coding was never the bottleneck

Now we have a fancy new tool running in production. But coding was always the easy part. Shipping was slightly more difficult. But operating it... That was always the hardest bit.

When these systems fail (and believe me they will), who owns the fix?

Who patches the ten new npm dependencies in the PR when zero-day vulnerabilities are disclosed?

Who handles rollback, feature flags, and customer impact if something breaks?

Teams are often told these are “small tools,” maybe not even customer-facing. But internal tools are production systems too: colleagues depend on them, and failures still cost time, trust, and money. If we vibe-code critical internal tooling without clear ownership, the burden defaults to engineering.

So who is on call?

Who monitors the dashboards?

Who is accountable when the system breaks at 2 a.m.?

I guess AI-native observability is going to be the next big thing.

Revolution

This isn’t a reasoning problem; it’s an incentives problem. When teams are rewarded mostly for shipping speed, ownership questions get deferred until incidents force them. We’ve seen the same pattern for years with testing and reliability work: if velocity is the only scoreboard, quality gets postponed. Without changing the system, more output just means more risk.

It’s just like quicksand: the harder we try to contain it, the faster we sink. So the only way out is to give in.

I urge all engineers to go back to their desks, write five PRDs this week, and submit them to their product counterparts for review. Just make sure they get reviewed quickly, since velocity is paramount. While your agents are busy handling comments from product folks, you can also start shaping next year’s company strategy to be submitted to the CPO, or help finance cut costs by replacing some tools with vibe-coded equivalents (just imagine how many millions of euros you’ll save once you retire Microsoft Excel and Google Drive).

Jokes aside, here’s what actually works:

• Cap PR size so reviews remain meaningful

• Require a named owner for every AI-built tool before merge

• Add an operational-readiness gate (monitoring, rollback plan, and on-call ownership)

• Track reliability metrics (defect rate and MTTR) alongside velocity

• Treat internal tools as production systems when business operations depend on them

Conclusion

The future is bright, but we need to be careful about how we navigate it. It is important to experiment and embrace new tools, but we also need to be mindful of the implications and ensure that we are not overloading our teams or creating new problems in the process. More importantly, we need to measure the impact of our actions and be willing to course-correct when necessary.

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 team can have the same headcount, rituals, roadmap, and dashboards, yet be different than it was last month.

The senior engineer who used to challenge plans now stays quiet. Code reviews still happen, but they are thinner. Standup still takes 15 minutes, but nobody names risks. Delivery continues. But the diff is visible.

The useful question is not only “is this team healthy?” It is “what changed?”

The snapshot trap

Managers are surrounded by snapshots: dashboards, engagement surveys, status reports, roadmap reviews, incident reviews. These snapshots matter. They are just incomplete.

A green dashboard can hide a team becoming afraid to take risks. A missed milestone can hide a team finally naming real uncertainty. The danger is not that snapshots are wrong. The danger is treating them as complete.

If you only look at state, you usually notice problems once they affect the dashboard. If you look at change, you can catch smaller shifts while they are still cheap to understand.

What a team diff looks like

Team diffs are usually small at first. They do not arrive with a label. They show up as changes in behavior.

Decision latency increases. Review comments become mechanical. One person becomes the default owner for everything. People agree faster but commit less. Small incidents create more anxiety than they used to. Planning discussions contain fewer alternatives. Newer engineers ask fewer questions, then make more avoidable mistakes. None of these prove a problem by themselves. A diff is not a diagnosis. It is a signal.

If a senior engineer stops commenting on design documents, disengagement is only one possible explanation. They may be overloaded, making room for others, tired of feedback that does not change decisions, or focused elsewhere. The same change can have several explanations. Your job is to notice early enough to ask better questions.

Observation before interpretation

Managers get into trouble when they notice a change and immediately attach a story to it. The observation is simple: “Alice has not commented on design docs in three weeks.” The interpretations arrive quickly: Alice is disengaged, overloaded, or convinced decisions are already made. If you skip the observation layer, you enter the conversation with a conclusion instead of curiosity.

“Why are you disengaged?” is very different from “I noticed you have been quieter on design docs recently. Has something changed?” One invites defense. The other invites context.

This matters because managers have power. A casual interpretation can become a label quickly: quiet becomes disengaged, careful becomes slow, direct becomes difficult. Reading the diff does not give you permission to psychoanalyze the team. It gives you a reason to investigate with care.

Write observations in plain language before conclusions. Instead of “the team is becoming passive,” write what you actually saw: fewer risks were raised before commitment and dependencies were escalated late. Those facts may point to passivity, unclear ownership, time pressure, or a team that has learned risk discussions do not change decisions. You cannot know until you ask.

How to practice

You do not need a surveillance system to read a team diff. Pay attention to places where team behavior already shows up: 1:1 notes, PR reviews, incidents, planning, decision records, escalations, onboarding feedback, ownership changes, and meeting energy.

Look for changes over time, not isolated moments. A quiet meeting once may mean nothing. Three quiet planning meetings after a difficult leadership decision may mean something. A month of shallow reviews on high-risk changes may point to a knowledge-distribution problem.

You also need a baseline. A team that looks quiet may be more direct than it was six months ago. A team that looks chaotic may be becoming more honest. A team that looks slow may have stopped hiding unplanned work.

Memory is a bad diff tool. Write lightweight monthly notes about hard decisions, stuck work, unexpected load, fragile areas, and surprises.

Diffs can be positive too

Managers often look for change only when something feels wrong. That misses half the value. Positive diffs tell you what is working: sharper product questions, calmer incidents, more reversible decisions, or a senior engineer no longer being the bottleneck.

Start small

You do not need a new framework, dashboard, or survey. You need a better attention habit. For one month, keep lightweight team notes. In 1:1s, ask “what feels different from last month?” In retrospectives, ask “what changed in how we worked?” Review decisions, not only deliverables. Separate observations from interpretations before raising concerns.

Then pick one diff to investigate. Not ten. One.

Ask the team about it, compare notes, and decide whether it needs action, observation, or acknowledgement.

The discipline is noticing enough, early enough, without pretending every signal is a conclusion.

Conclusion

A good manager is not a dashboard. A dashboard tells you what is red, green, or yellow today. A manager notices that green is becoming yellow before the alert fires, or that a team is becoming stronger before the numbers know how to say it.

The work is not just to know the state of the team. The work is to understand its direction. Read the snapshot. Then read the diff.

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

We humans love to swing between extremes. This is a behavior we see in many aspects of our lives; fashion trends, political ideologies, and even our personal habits. The tech industry is no different.

There are many trends in our industry that swing back and forth over time. In this article, we will explore some of the most notable swings in the tech world, understand why they happen, and look at how we can turn them to our advantage.

The swings

We see many swings in the tech industry. In some cases, they go back and forth indefinitely between two extremes. In other cases, they evolve into new paradigms that build on the lessons of the previous cycle. Either way, these swings reflect our ongoing quest to find the best ways to build and deliver software.

Let’s explore some of the most prominent ones.

Pendulum Swings

Pendulum swings refer to the oscillation between two extremes in various aspects of software development and technology. They tend to happen when there are two legitimate approaches to solving a problem, and the industry swings between them over time as new challenges arise or as different voices advocate for one approach over the other.

Quality Assurance (QA) Engineers

Companies that are sufficiently large will often have Quality Assurance (QA) engineers. In some organizations, QAs are deeply integrated into the development teams, working closely with developers to ensure quality throughout the development process. This inevitably leads to a more collaborative approach to quality assurance, where the QA engineers develop alongside the developers and quality becomes a shared responsibility.

In other organizations, QAs operate as a separate entity. They will often have their own organization (eg. QA managers, QA leads, etc.) and will be responsible for the testing strategy and for ensuring quality independently from the development teams. This separation can lead to a more formalized and structured approach to quality assurance but may also create silos and communication gaps between development and QA teams.

As with anything, there are no right or wrong approaches.

There are no solutions. There are only trade-offs.

Designers: Embedded or Centralized

A similar swing happens with designers. Should designers be embedded within product teams, sitting next to engineers and product managers, sharing the same goals and rituals? Or should they live in a central design organization that guards consistency, owns the design system, and serves the rest of the company as an internal agency?

When designers are embedded, they develop deep product context and move quickly with their team. The risk is fragmentation: each team evolves its own patterns and the overall experience starts to feel stitched together.

When designers are centralized, consistency and craft tend to improve, and there’s a clear career path within the discipline. The risk is distance from the product: designers can end up as order-takers, delivering mockups that miss the nuance only daily exposure to the team’s problems can reveal.

Neither extreme is sustainable for long, which is why we keep seeing companies swing between the two.

On-Prem vs Cloud

For decades, running your own data center was simply how you ran software. Then the cloud arrived, and the industry swung hard: AWS, Azure, and GCP became the default, and “cloud-first” turned into “cloud-only” for many organizations.

Now the pendulum is moving again. Rising cloud bills, latency requirements, data sovereignty regulations, and the realization that not every workload benefits from elasticity have pushed companies toward hybrid setups, edge computing, and even outright repatriation back to their own hardware. The next generation of engineers will likely inherit a world where the question isn’t “cloud or on-prem” but “which workload belongs where”.

Specialized Roles, Full-Stack, and T-Shaped Engineers

The shape of the engineer has also swung over time. Early software organizations leaned heavily on specialists: database administrators, front-end developers, back-end developers, and operations engineers all living in separate boxes. Then the full-stack developer emerged, someone expected to handle everything from the database to the browser, often on small teams where specialization was a luxury.

Today, many organizations talk about T-shaped engineers: broad enough to collaborate across the stack, but with one area of genuine depth. This is arguably an evolution rather than a pure swing, but it’s driven by the same underlying tension: how much breadth versus depth do we want from any given person?

Progressive Evolution

Some swings don’t return to exactly where they started. Instead, each oscillation incorporates lessons from the previous one, and the industry settles into something new.

Architecture: Monoliths, Microservices, and Back Again

We started with monolithic applications, large single deployables that were easy to reason about but hard to scale organizationally. The industry then swung toward microservices, promising independent scalability, team autonomy, and polyglot freedom.

After years of living with distributed systems, many teams discovered that the operational and cognitive overhead of microservices was often larger than the problem they were trying to solve. The pendulum is now swinging back toward “modular monoliths” and “macroliths”, architectures that preserve clear module boundaries without the distributed-systems tax. We’re not back where we started; we’re somewhere new, armed with better tooling and a healthier respect for complexity.

Waterfall, Agile, and Post-Agile

Software delivery methodology has followed the same pattern. Structured waterfall gave way to the Agile revolution, with its sprints, stand-ups, and iterations. Now we see “post-agile” movements questioning the ceremony overhead, pushing for continuous delivery, smaller batch sizes, and less ritual for ritual’s sake. Again, we’re not going back to Gantt charts, but we are questioning which parts of Agile actually deliver value and which parts are just theater.

Why does the pendulum keep swinging?

With all the examples above, I’m certain you had an opinion on which side is better. For every person who believes in one extreme, there’s another who believes in the opposite. Since opinions tend to balance out around the 50% mark, the pendulum keeps swinging. Whenever there’s a slight imbalance favoring one extreme, the pendulum starts to move in that direction, and the louder voices pull everyone else along.

If one approach could be definitively proven better than the other, the pendulum would settle. However, most of the examples we’ve examined require years of execution to demonstrate their effectiveness. Since technology landscapes rarely remain stable for that long, these approaches are seldom proven definitively superior. Therefore, the pendulum continues its motion.

This is especially true in the software industry, which is relatively young and still exploring different approaches. The journey from monoliths to microservices and now back to modular monoliths exemplifies this ongoing exploration. We still don’t know what the optimal approach is. When we refactored our monoliths into microservices, we believed we had discovered the best solution. But after staying at that local maximum for several years and experiencing the challenges of maintaining such systems, we’re exploring alternatives once again.

What can you do about it?

Keep calm and carry on.

The worst thing you can do is jump on every swing as it happens. By the time a trend has enough momentum that you’re hearing about it at every conference, you’re already late, and the pendulum is probably already preparing to move in the opposite direction.

Instead, a few habits can help you stay grounded:

• Be observant of the swings. Notice which direction your corner of the industry is moving and, more importantly, why.

• Understand where you are in the swing. Are you near an extreme, or somewhere in the middle? The closer you are to an extreme, the more likely the next move is away from it.

• Prepare yourself for the swing. If you see momentum building in one direction, think through what it means for your team, your architecture, and your career before you’re forced to react.

• Build skills that are independent of the swing. If you invest all your energy in becoming the world’s leading expert on microservices, you’ll be in an awkward spot when the pendulum swings back to monoliths. Skills like systems thinking, writing, communication, debugging, and reasoning about trade-offs survive every swing.

• Be honest about trade-offs. Every side of a pendulum swing optimizes for something and sacrifices something else. Name those trade-offs explicitly instead of pretending one side is just “better”.

Conclusion

The pendulum will keep swinging. It’s inevitable, because it’s human nature to over-correct, to chase novelty, and to believe that the latest idea is the final one.

Our job as engineers and engineering managers isn’t to stop the pendulum or to perfectly predict its next move. It’s to stay aware of the motion, to make deliberate choices about when to ride it and when to stand still, and to keep investing in the skills and judgment that stay valuable no matter which way it’s swinging.

Better to be ready for a swing that never comes than to be caught off guard by one that does.

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

Writing a book is a bit like climbing Mount Kilimanjaro. It looks romantic from a distance. You imagine the view, the achievement, maybe even the story you will tell afterwards. But once you are on the mountain, the work is much less glamorous. You put one foot in front of the other. You deal with altitude, weather, tired legs, and the constant temptation to stop.

Writing is similar.

Having the right gear helps. Planning helps. We covered both in the previous articles:

But at some point the tools are ready, the outline exists, and the only thing left is the uncomfortable part:

You have to keep writing.

This article is about the mindset that helped us keep pushing the book forward when the novelty wore off.

Pick a point of reference

A book is too large to hold in your head all at once.

If you only think about the finished manuscript, the work quickly becomes intimidating. There are too many chapters, too many open questions, too many sections that still feel vague. The gap between where you are and where you want to be can become paralyzing.

What helped us was having a point of reference.

Not a perfect plan. Not a promise that the structure would never change. Just a clear enough direction to return to when we got lost.

For us, that point of reference was the kind of reader we wanted to help: aspiring and new engineering managers trying to make sense of the role. Whenever a chapter became too abstract, too broad, or too clever for its own good, we came back to that reader.

Would this help them make a better decision?

Would this make an invisible part of the job more explicit?

Would this be useful in practice, or only interesting in theory?

Those questions became our compass.

Find your octant

A compass tells you the direction. An octant helps you navigate when the exact path is unclear.

That distinction matters for writing, because you will rarely have complete certainty. Some chapters will change shape while you write them. Some ideas that felt strong in the outline will collapse once you try to explain them. Some sections will turn out to belong somewhere else entirely.

That is not failure. That is the work.

The goal is not to remove uncertainty before you start writing. The goal is to create enough orientation that uncertainty does not stop you.

In practice, this means keeping a few simple anchors visible:

• Who is this for?

• What problem are we helping them solve?

• What should they understand or do differently after reading it?

• How does this chapter connect to the rest of the book?

Whenever we felt stuck, we did not try to solve the whole book. We tried to answer these questions for the section in front of us.

That made the next step smaller.

Choose habit over goal

Goals are useful, but they are bad company on a difficult day.

“Write a book” is a goal. It is also too large to be helpful on a Tuesday evening when you are tired, your calendar was full, and the chapter you are working on still does not make sense. A habit is different.

A habit turns the question from “Will we finish the book?” into “What do we write today?” That smaller question is much easier to answer.

For us, progress came from making writing a regular activity rather than a heroic one. Some sessions were productive. Some were not. Some produced pages we kept. Others produced paragraphs we deleted the next day.

But the cadence mattered more than any individual session.

The uncomfortable part is that writing often feels inefficient. You can spend two hours producing something that later gets cut. That does not mean the time was wasted. The deleted paragraph may have been the thing that helped you understand what you actually wanted to say.

You are not only producing text. You are clarifying thought.

Keep writing, even when most of it will be thrown away

This is one of the hardest parts to accept.

Most writing does not survive in its first form.

You will throw away examples. You will rewrite introductions. You will move sections around. You will discover that a sentence you loved does not belong anywhere. That can feel painful, especially when time is scarce.

But keeping weak text because it was expensive to create is the writing version of the sunk cost fallacy.

The draft is not the product. The draft is the material.

Once we accepted that, writing became easier. We stopped expecting every session to produce publishable prose. Sometimes the output was only a rough argument. Sometimes it was a bad version of a good idea. Sometimes it was a list of questions we still had to answer.

All of that counted as progress, as long as it moved the work forward.

Remove friction

This is where tools matter again.

Not because tools will write the book for you, but because friction compounds. If opening the manuscript is annoying, if generating a preview is slow, if collaborating requires manual file juggling, every session starts with resistance.

And resistance is dangerous because writing already has enough of it.

The goal of the toolchain is not to be impressive. The goal is to make the next writing session easy to start.

For us, that meant keeping the workflow close to how we already work as engineers: plain text, version control, automation, and fast feedback loops. The fewer things we had to think about before writing, the more likely we were to actually write.

A good setup should make the right behavior boring:

• open the project

• write a section

• preview the result

• commit the change

• continue later without wondering where things are

Nothing else should get in the way.

Use deadlines carefully

Deadlines are dangerous and useful for the same reason: they create pressure.

Without pressure, writing can expand forever. There is always another example to add, another sentence to polish, another chapter to rethink. If you are not careful, “not ready yet” becomes a permanent state.

This blog helped us create a useful kind of artificial deadline.

Publishing smaller pieces gave us a reason to finish slices of the work. It created presence, forced clarity, and gave us feedback before the entire book was done. That made the deadline a win-win: useful for the audience, and useful for us.

But the pressure has to be calibrated.

A deadline that forces progress is helpful. A deadline that forces you to publish something you no longer believe is not. The trick is to use deadlines to create movement, not panic.

Find a partner in crime

Writing alone is possible. Writing together made it more sustainable.

A partner creates accountability, but that is only part of the value. The bigger benefit is that they give you another mind to think with. They notice when an argument is unclear. They challenge examples that only make sense in your own head. They keep the work moving when your own energy drops.

For us, the partnership worked because we were not trying to protect every sentence. We were trying to make the book better.

That requires trust.

You need to be able to say, “This section does not work,” without turning it into a personal attack. You need to be able to cut your own favorite paragraph if it weakens the chapter. You need to care more about the reader than about being right.

A good writing partner does not make the work effortless. They make it harder to fool yourself.

Get feedback before you feel ready

Feedback is most useful before the work feels finished.

That is also when it is most uncomfortable.

If you wait until every chapter is polished, feedback becomes harder to accept. You have already invested too much in the current shape. Suggestions feel like threats. Structural problems become expensive.

Earlier feedback is cheaper.

It can tell you whether the argument lands, whether the reader gets lost, whether the example works, and whether the chapter solves a real problem. You do not need hundreds of readers for this. A few thoughtful people can already reveal patterns you would miss on your own.

The important part is to ask for the right kind of feedback:

• What was clear?

• Where did you slow down?

• What felt missing?

• What did you expect next?

• What would make this more useful in your context?

Do not only ask whether people liked it. Liking is pleasant, but it is not always actionable.

Conclusion

Writing a book is daunting because it exposes the distance between what you think you know and what you can actually explain.

That distance is uncomfortable. It is also the point.

The way through is not one perfect tool, one perfect plan, or one burst of motivation. It is a system that helps you keep going: a clear point of reference, a regular cadence, low friction, useful deadlines, a trusted partner, and feedback before you feel ready.

In the end, the book moves forward the same way the climb does.

One step at a time.

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

For years, engineering teams have used a simple rule when deciding whether to build something themselves:

If it’s core to your product, build it. If it isn’t, buy it.

If you’re launching an online radio service, you don’t write your own authentication system. You grab something off the shelf. But you might build your own audio encoder, because streaming quality is central to the experience you’re selling.

The rule works because it forces you to be honest about two things: what actually differentiates you, and what is just table stakes. Everything that isn’t differentiated is a tax on your roadmap.

Shouldn’t we apply the same logic to AI?

The AI version of the same question

The temptation today is to treat “AI” as a special category that escapes the usual trade-offs. It isn’t. The question is the same, only the verbs have changed:

• Classic software

  • Core to your product: Build

  • Not core: Buy

• AI

  • Core to your product: Train / fine-tune / build tooling

  • Not core: Use an existing tool (or wait)

If you’re building a product where the AI behavior is the product (say, a coding assistant, a medical triage tool, a fraud model on your own transaction data) then training, fine-tuning, or building bespoke tooling makes sense. That’s your audio encoder.

If you’re just trying to write code a bit faster, summarize a meeting, or automate some internal busywork, you don’t need a custom tool. Use what already exists. That’s your authentication system.

“Wait” is a legitimate answer

There’s a third option the classic rule rarely needed, but AI does: wait.

The AI tooling market is moving fast enough that something you’d spend a quarter building today may ship as a feature of an off-the-shelf tool next month, often for less than the cost of one engineer-week. If the problem isn’t core and no tool exists yet, the cheapest move is often to do nothing, document the need, and revisit in a few weeks.

Not every problem needs a bespoke AI solution. Not every bespoke AI solution needs to be built now.

What this means in practice

Before greenlighting an AI project, ask three questions in order:

• Is this core to what we sell?
  If yes, investing in training, fine-tuning, or custom tooling is probably justified.

  If no, keep reading.

• Does a good-enough tool already exist?

  If yes, buy it, wire it in, and move on.

  Your differentiation isn’t in the tool, it’s in using the time you saved.

• If nothing exists yet, can we wait?

  Usually, yes.

  The cost of waiting is almost always lower than the cost of maintaining a half-built internal tool that a vendor will obsolete in six months.

Conclusion

The discipline that served us in the software world still applies. If anything, the speed of the AI market makes it more important, not less. Build when it’s core. Buy when it isn’t. Wait when the market is about to hand you the answer for free.

The companies that get burned in this cycle won’t be the ones who were late to AI. They’ll be the ones who built their own version of something they could have bought, or bought something they should have waited a month for.

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

It’s 2026. A developer opens a ticket, types a prompt, and walks away to grab a coffee. An agent vibecodes the feature, opens a merge request, and pings a reviewer. The reviewer’s bot reads the diff, leaves a dozen suggestions, and waits. The author’s bot responds to the bot, rewrites half the patch, and pushes again. Somewhere in the background, CI spins up, a security bot chimes in, and an architecture bot asks whether we’ve considered the implications on the service boundary.

The merge request eventually lands. Everyone is happy. Nobody asks the obvious question: how much did this actually cost?

The invisible meter

Every step in that pipeline burns three things: time, tokens, and attention. Time is the easy one to talk about and the hardest one to measure, because most of it happens while humans are doing something else. Tokens have a price tag, but it’s spread across half a dozen vendor invoices and rarely attributed back to the change that triggered them. Attention is the one nobody logs at all.

We’ve built a system where the marginal cost of kicking off another round of review feels like zero. It isn’t. It’s just been moved off the human’s calendar and onto a GPU somewhere, which is exactly the kind of cost that doesn’t show up until the quarterly bill lands.

Three ways to ship the same change

Let’s imagine the same small feature, delivered three different ways.

1. The human-driven version

One engineer writes the code. Another engineer reviews it. They have a short conversation in the PR, maybe a call if it gets spicy. The change lands.

Total cost: two humans, a couple of hours each, maybe a day of elapsed time.

Artifacts produced: the code, a short review thread, a shared mental model of the change in two heads.

2. The pair-programming version

Two engineers sit together (or on a call) and write the code as one. Review is continuous. The change lands with no formal PR review, or a rubber-stamp one.

Total cost: two humans, roughly the same hours, but fully overlapping.

Artifacts produced: the code, two heads that deeply understand it, and a transfer of skill in both directions.

3. The bot-mediated version

An agent writes the code. A review bot reviews it. The author’s bot responds to the review bot. A human skims the final result and clicks merge.

Total cost: minimal human time, substantial machine time, a long trail of generated artifacts nobody will ever read again.

Artifacts produced: the code, a transcript of a conversation between machines, and zero heads that deeply understand what just shipped.

What we’re not measuring

The uncomfortable part isn’t that option 3 is slower or more expensive in raw terms. It might not be. The uncomfortable part is that we don’t know, because almost no one is measuring:

• Wall-clock time from ticket to merge, across all three modes.

• Total compute and token spend per merged change.

• Rework rate: how often does a bot-mediated change come back as a bug or a follow-up?

• Knowledge retention: six weeks later, does anyone on the team know how this code works?

• Review quality: are the bot’s comments catching things humans would have caught, or are they noise that trains humans to rubber-stamp?

Without these numbers, every debate about AI-assisted development is vibes versus vibes.

The back-and-forth problem

There’s a specific failure mode worth naming. When two bots talk to each other across an PR, the conversation can go on for a surprisingly long time. Each suggestion triggers a rewrite. Each rewrite triggers new suggestions. The diff churns. The humans, who were supposed to be the circuit breakers, have long since tuned out because “the bots are handling it.”

In a human review, social cost caps the loop. Nobody wants to be the reviewer who left seventeen nits, so they don’t. Bots have no such governor. They will happily optimize a function eight times in a row, each time producing a “better” version by some metric that nobody chose.

This is the bot tax: the cost of a loop that has no natural stopping condition.

What you can actually do

I don’t think the answer is “turn off the bots.” The answer is to treat them like any other expensive system: instrument them, attribute their costs, and put a human in the loop at the points that matter.

A few things worth trying:

• Measure per-PR cost. Time, tokens, and review rounds. Make it visible on the PR itself.

• Cap the loop. After N bot-to-bot rounds, a human has to step in. Not as a rubber stamp but as a decision-maker.

• Compare modes. Pick a sample of changes and deliver them three ways (solo, pair, bot-mediated). Measure outcomes at one week, one month, and one quarter.

• Track rework. A change that ships fast and comes back as three bugs was not cheap.

• Protect pairing. It’s the mode most at risk of being quietly eliminated, and the one that produces the most durable outcome: humans who understand the system.

Conclusion

The promise of AI-assisted development was that it would free humans from toil. The risk is that we’ve built a toil generator that runs on someone else’s bill and on our team’s understanding of its own code.

Before we declare the bot-mediated workflow a win, somebody has to do the math. Not the vendor. Not the bot. Us.

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 watched this famous talk Focus (or Stop Starting, Start Finishing) by Henrik Kniberg where Henrik tries to teach us that context switching is killing your throughput.

Every time you jump between tasks, you pay a tax. You lose your place, your focus, and a surprising amount of time just reloading the mental state you had before.

Most of us know this intuitively. And yet, most of us still do it all day long.

AI made it worse

The rise of AI-assisted work has, paradoxically, made context switching harder to manage.

On paper, AI makes us faster. You can spin up a draft, generate a test, review a PR, or summarize a meeting in seconds. But that speed is deceptive.

Because work is cheaper to start, we start more of it. We run multiple agents, multiple branches, multiple tabs, and multiple half-finished drafts in parallel. We’ve traded one deep focus thread for five shallow ones.

The result: more starts, fewer finishes, and a lot more context switching hidden under the illusion of productivity.

Two kinds of context switch

Here’s something that doesn’t get talked about enough: not all context switches are the same.

There are two distinct flavors, and they cost you very differently.

Horizontal context switch

A horizontal context switch is when you move between tasks of the same type.

You’re programming feature A, and then you switch to programming feature B. The work is different, but the mode you’re in isn’t. You’re still writing code. You’re still thinking in terms of functions, tests, and edge cases. Your brain doesn’t need to shift gears, it just needs to reorient within the same gear.

It still costs something. You have to reload the domain, the file structure, the naming conventions. But the cognitive machinery underneath stays the same.

Vertical context switch

A vertical context switch is when you move between different types of work.

This is the bread and butter of engineering management. One hour you’re debugging a production issue with an engineer. The next, you’re in a 1:1 navigating someone’s career anxiety. Then you’re in a roadmap discussion with product. Then you’re reviewing a design doc. Then back to a performance conversation.

Each of these requires a different mode of thinking: analytical, empathetic, strategic, critical, supportive. And every time you switch modes, you’re not just reloading context, you’re reconfiguring your entire brain.

That’s expensive. Much more expensive than most of us realize.

Vertical is worse than horizontal

If horizontal context switching is a tax, vertical context switching is a penalty.

When you flip between coding and people management, you’re not just losing the state of the previous task, you’re losing the shape of your attention. You need time to come down from a tense conversation before you can think clearly about a system design. You need time to warm up to a 1:1 if you’ve been heads down in code for two hours.

Most people underestimate this warm-up and cool-down cost. They schedule a 1:1 between two coding blocks and wonder why neither the conversation nor the code felt great. They jump from a strategy review to a bug hunt and notice they’re irritable, scattered, or just slower than usual.

It’s not a lack of discipline. It’s the nature of vertical switching.

Minimize vertical, tolerate horizontal

You can’t eliminate context switching entirely. But you can be deliberate about which kind you absorb.

The goal isn’t zero switching. The goal is to keep most of your switches horizontal, and to cluster the vertical ones so you only pay the penalty a few times a day instead of constantly.

Here are two practical ways to do that.

Time blocks

Group similar work into dedicated blocks on your calendar.

Put all your 1:1s back-to-back instead of sprinkling them across the day. Stack your deep work in a single uninterrupted chunk. Batch your code reviews. Batch your Slack and email triage.

The mechanic is simple: once you’re in a mode, stay in it as long as you reasonably can. Every hour you spend in the same mode is an hour you’re not paying the vertical switching penalty.

Themed days

For larger rhythms, consider assigning types of work to specific days.

Some managers keep Mondays for planning and strategy, Tuesdays and Thursdays for people work, and Wednesdays and Fridays for deep or technical work. The exact split doesn’t matter. What matters is that when you sit down on a given day, your brain already knows what mode it’s in.

Themed days don’t have to be rigid. Emergencies happen, and a good day plan survives contact with reality. But having a default theme means that when nothing is on fire, you naturally drift toward fewer vertical switches and more sustained focus.

Delegate to reduce switch count

Calendar tricks help you absorb switches more gracefully, but the bigger lever is making fewer of them in the first place. Every recurring thing you delegate is a vertical switch you no longer have to make. The status update you used to write, the triage rotation you used to own, the stakeholder sync you used to attend, each one was pulling you into a different mode, and now it isn’t.

This is often more powerful than any time block or themed day. A calendar trick reshapes the cost of switching. Delegation removes the switch entirely. When you look at your week and see too many vertical transitions, the first question shouldn’t be “how do I rearrange these?” but “which of these does someone else own now?”

Office hours

Ad-hoc questions are one of the biggest sources of unplanned vertical switches. A Slack DM at 10:47 might take two minutes to answer, but it pulls you out of whatever mode you were in and charges you the full switching cost on the way back. Do that five times a day and your deep work is gone, even though your calendar looks clear.

Office hours turn N interruptions into one batched block. Pick a recurring slot, tell your team that’s when you’re available for anything that isn’t urgent, and hold the line the rest of the time. Most questions that feel urgent in the moment can comfortably wait a few hours, and the ones that truly can’t will still find you. What you get in return is a predictable container for a whole category of vertical switching, instead of it leaking into every hour of the day.

Physical separation

If your setup allows it, let your environment do some of the switching work for you. One pattern that works well: do people work at the office and IC work from home. The office is where you have 1:1s, meetings, hallway conversations, and coffee chats. Home is where you write, code, review, and think.

The point isn’t the specific split, it’s that your brain uses location as a cue. Walking into a different space is a much stronger mode signal than closing one tab and opening another. You stop trying to squeeze a deep work block between two meetings in the same room, and you stop trying to be warm and present in a 1:1 from the same desk where you were just debugging. The commute, however short, becomes the buffer that your calendar was never going to give you.

Conclusion

Context switching will always be part of the job, especially as an engineering manager, and especially in a world where AI lets you juggle more threads than ever.

But not all switches are equal. Horizontal switches are the cost of doing business. Vertical switches are where the real damage happens.

So be honest with your calendar. Look at a typical day and count how many times you’re asking your brain to change shape. Then do what you can to bring that number down.

Stop starting. Start finishing. And when you do have to switch, try to switch sideways, not up and down.

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.