Thanks CodeRabbit for supporting today’s article!

You ping an engineer about a big PR. You ask one real architecture question, and they can't answer it. Nobody can - it's a huge diff, everyone's rushed, so it gets approved and merged unread.

That's what AI reviewing its own code looks like. Asking the same agent to check its own work is a student grading their own exam. It always passes.

CodeRabbit CLI is an external reviewer for AI-generated code - the lowest-noise, most-trusted review tool, used by Nvidia, Indeed, and 15,000+ other teams. Different agent, 40+ static analyzers, zero attachment to what it wrote. It flags the parts that don't hold up, so the problems you'd have skimmed past are the first thing you see.

You still own the code. CodeRabbit just makes sure you actually know what's in it.

Try CodeRabbit CLI for free

An engineer in your team asks you to go over a PR. It’s quite a big one, tens of files, 1000+ lines of code added.

You roll up your sleeves and start to dive into it. You leave a couple of comments, but after 15 minutes, you feel there are too many things that don’t make sense to you, so you ping the engineer for a quick huddle.

You ask a question (not a small syntax question, a fundamental software architecture question) and receive a response that makes you want to scream:

“I don’t know, Claude wrote this”.

NO NO NO. YOU wrote this. YOU opened the PR. YOU are responsible for it. Claude is just a tool, it’s not the one making the decisions.

A viral post on reddit sparked a debate about it:

Turns out it’s becoming a widespread issue:

Addy Osmani (Director of eng in Google) covered it in a recent article, calling it ‘cognitive surrender’.

Cognitive offloading is delegating to the AI and still owning the answer. Cognitive surrender is when the AI’s output quietly becomes your output and there is nothing you feel is left to check. For software engineers the line between the two moves under your feet most days, and most of us are crossing it without noticing.

How did we get here?

You have a task you need to complete, and it’s not small. So you start a planning session with Claude. You use the famous superpowers brainstorming skill, it explores the codebase, asks you clarifying questions, and you get a plan. You read the plan in depth, correct a couple of problems, and send it off to execution.

You review the code, and it looks good. You correct the small problems with a couple of prompts, and send it to review.

Next comes a bigger task. It’s a bit ambiguous. In a pre-AI world, you would have split the task into smaller pieces. But you're in a rush. Claude produces a plan that sounds reasonable, so you move straight to execution. The result works. You skim the code, open a PR, and move on.

You just skipped the part where you actually understood what's going on.

In the best case scenario, the reviewing engineer will ask you questions that you don't fully understand. Hopefully you won't just forward those comments to Claude, but try to understand what's going on.

Worst case scenario, it's a very big PR, everyone is rushed, and it's just approved and merged. Nobody understood, not the author and not the reviewers.

Instead of driving yourself, you let Claude drive your car of the cliff.

It’s very hard to resist

A couple of weeks ago, I spent 2-3 hours in a planning session with Claude. I tackled an ambitious mission, and the plan was quite big. I really wanted to accomplish it, and it felt so much ‘in reach’. Just a couple of prompts away!

Halfway during the execution, I felt lost. There were just too many moving parts and decisions that Claude made. I ended up typing /clear and resetting everything,

There were 2 problems:

• I started with a vague idea of what I want to accomplish

• I didn’t understand enough in the area I worked in

When your plan is vague and you don't know enough to make the decisions yourself, you'll end up delegating the decisions to Claude. As Addy wrote, the line between using Claude and letting it drive is very blurred, and it takes a lot of effort to resist the temptation.

The alternative

I had a relatively small task in our internal AI agents infrastructure. I needed to add event tracking through Segment, so we could see what tools were used.

I haven't worked in this repo before. So I planned with Claude, used the brainstorming skill, answered some questions. Plan made sense, so sent of to execution.

Right before add the files to be committed, I reviewed every change in the IDE. The ones I didn’t understood, I asked Claude about. When the answer didn’t make sense, we changed the code and I reviewed it again.

By the time I understood every file change, by definition, I understood the full solution.

I opened the PR and got some great comments from our most senior engineers. I was able to understand the comments, jump on a quick call to discuss the best way forward, and not hide like a fish behind Claude.

The skills you are willing to lose

I recently finished reading The Book of Elon (a great one, no bullshit at all). Here’s a great quote (about how civilizations lose skills):

We are living in an era when we constantly give up some of our skills. Since Google Maps and Waze almost nobody can navigate without them. In 2026, it feels like everybody lost the ability to write long-form essays without LLMs.

EMs and engineers need to decide which skills are they willing to lose. For me, those are things like:

• Writing code manually

• Language syntax

• CSS especially

But I’m NOT willing to lose my ability to:

• Understand how software systems are built

• Analyze tradeoffs

• Read the fucking code and see it makes sense

• Read and understand design plans

I want to still be able to ‘drive’ Claude in the direction I want, and not to be driven by it - and that’s the expectation I have from all of my engineers.

Discover weekly

1. On mid-career (dis)satisfaction. On your ability to combat career envy when it arises.

2. 24 tips for giving amazing demos as an engineer. Most developers don’t invest in learning how to demo well - probably because we enjoy building things more than presenting them. Worth 5 minutes of reading to get better at it!

3. Your AI strategy has a trust problem, not a tooling problem. Even the best employees with all the most magical tools will get trapped… if your org structure and culture don’t adjust.

   
   

Manager.dev is proudly supported by CodeRabbit!

In every team I've managed, the same friction kept showing up: decisions made in Slack threads that nobody can find a week later. You end up re-debating things your team already solved. That's exactly the kind of root cause excellent teams fix.

CodeRabbit Agent lives in your Slack channels and remembers what your team decided, pulling context from code, tickets, docs, and monitoring. From the team behind 2M weekly code reviews, 6M repos, and 15K customers.

Try CodeRabbit’s Agent for free

In 15+ years in tech and 7 years of managing engineering teams, I've worked in (and managed) both kinds of teams.

In Peopleware (one of the all-time best books about engineering management), the authors defined an excellent team as follows (they call it a ‘jelled’ team):

I strongly agree with every part except the last one. I believe that engineering managers CAN build excellent/jelled teams.

An ‘okay’ team is not a bad team. It’s not dragging the organization down. It delivers new features, owns some product areas, solves customer problems, and slowly drifts along, like a fish in the stream.

Excellent teams are the ones that change the trajectory of the company, and the ones every engineer in it will remember for the rest of their career. It’s definitely not about working twice as hard or having only ‘10x engineers’. In my experience, it’s just a few small habits, which are definitely up to us.

Inspired by Julie Zhuo's excellent article about what separates okay growth teams from excellent ones

1. Okay teams patch. Excellent teams know when to fix the root cause.

In Shadow work in engineering teams, I shared an example from my own team. We had an annoying issue that took ~15 minutes to fix manually, and each hotfixer would just solve it and move on.

Over months, the team burned 10+ hours on the same issue. Fixing the root cause would have taken 5-6 hours, but there were always more urgent things to do. This is how okay teams work. They patch, they move on, and then they patch again (and again). As time passes, the small fixes take more and more of their time.

It extends beyond bugs, it’s also the alerts you keep ignoring, the flaky test you restart instead of fixing, the manual process you keep doing because automating it "isn't worth it yet", and so on.

There are also ‘okay’ teams that take the other extreme. If you spend all your time refactoring and solving issues, you’ll have barely any time for product work.

This genius table is the excellent team’s best friend:

Source - xkcd

You can see here that weekly 15 minutes is worth 2 days of your time to fix (across 5 years).

Life is, of course, not as simple as a table - you don’t always know how often something will happen, or how long it’ll take to fix. In excellent teams, there is always a debate and a concrete decision, not just inertia.

In many cases, killing the tiny annoyances is one of the highest-ROI things you can do.

2. In okay teams engineers DO things. In excellent teams engineers OWN things.

In okay teams, everything goes through the Engineering Manager. You prioritize, triage, and decide what everyone works on, and they execute. You are basically a human Jira router.

(I have this tendency myself, not judging here)

In excellent teams, engineers own kingdoms. A "kingdom" can be an application, a microservice, a 3rd party integration, or a critical tool. The engineer who owns it makes decisions about it, monitors its health, works closely with the PM, and is the go-to person for other teams.

The key is decision-making, not just responsibility. If you ask people to be "responsible" for just the bad parts (the on-call, the bug fixes), nobody will want it. The magic happens when you give them the authority to make real decisions. The top reason why engineers quit is that they don’t feel challenged and growing anymore.

The more you let your engineers own, the more connected they’ll feel and act.

3. Okay teams unblock themselves. Excellent teams unblock others first.

A great team that everybody in the organization hates is not a great team.

Here’s a painful example (that I shared in the delayed opinions givers): My team had to work on another team's codebase. Their EM was busy, asked us to talk only to him, and then took 2 weeks to review our first PR. We were so frustrated that we just merged it and moved on. The quality suffered, and the relationship suffered even more.

If that team had dropped what they were doing and reviewed the PR within a few hours, what would it have actually cost? Maybe 2-3 hours of focused work time.

Excellent teams put the needs of other teams before their own 90% of the time (yeah, I know that’s freaking hard).

If it happens repeatedly, the reputation you gain is of a team that always helps other teams. Being an engineer on such a team is a much more joyful experience. And of course, it’s not one-sided, other teams will be quicker to unblock you when things switch around.

4. Okay teams execute the roadmap. Excellent teams shape it.

In okay teams, the PM creates the roadmap and engineering delivers it. The EM's job is to estimate, plan sprints, and make sure things ship on time. PMs are responsible for ‘what’, and we are for ‘how’.

In excellent teams, the EM and engineers are partners in deciding what gets built. They talk to customers, they understand the business, and they push back on features that don't make sense or when they don’t agree with a decision.

Okay teams fall into the victim trap, complaining about bad product decisions. Excellent teams take ownership and do something about it. They are not satisfied with beautiful code and scalable systems. If the roadmap is wrong and you know it, it's your problem too…

5. Okay teams stick to the plan. Excellent teams are willing to kill it.

Have you seen a roadmap like this?

You pre-define phases 1,2,3, and follow through no matter what. When you get customer feedback after phase 1, you hear what you want to hear. Any negative signal about the future phases gets ignored, and the chances you will stop after phase 1 are very small.

This might seem like a product management problem - but very often the engineers are to blame! Because engineers complain so much when the code they wrote gets thrown away, it puts pressure on the PM to make the wrong decisions.

A decision to stop working on a feature is one of the best signs of a strong product culture. It means the decision-makers are listening to feedback and considering carefully what's the best way forward.

Before excellent teams start to work, they ask:

• How are we going to measure this?

• How is the success of the first phase defined?

• What will happen if the criteria are not reached?

• What can make us decide not to continue with this feature?

That last question is the toughest. I would be surprised if you get an answer in most companies.

6. Okay teams launch features. Excellent teams land them.

Okay teams treat deployment as the finish line. When the feature is in production, the PR is merged, and the ticket is closed, they celebrate and move on.

Excellent teams treat deployment as the halfway point.

They ask:

• Is anyone actually using this?

• Are they using it the way we expected?

• Did it move the metric we cared about?

• Are there friction points we didn't anticipate?

I've seen teams ship feature after feature, each one "done", while the product barely improves - the features launched, but they didn't land.

7. Okay teams treat tech debt as a 20% tax. Excellent teams treat it as product work.

"20% for tech debt" doesn't work.

Okay teams end up with 2 separate backlogs, and nobody on the business side understands or cares about the tech backlog. Your initiatives are always the first to be deprioritized when something "urgent" comes up.

In excellent teams, (almost) every technical initiative has a clearly defined business value, and it lives on the product roadmap, prioritized alongside everything else.

This requires the EM to actually explain the business impact of technical work. Not "we need to refactor the monolith" but "if we move this logic to a new service our team owns, we can ship future features 3x faster without being blocked by other teams".

This requires a very strong EM-PM partnership, which is a critical building block for excellent teams.

Discover weekly

1. The steepest slope - from being fired 6(!) times to COO. On unconventional careers.

2. Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech. An interesting take on tokenmaxxing (the good and bad sides of it).

3. Atrophy - Mental Model: Use It or Lose It. It’s been only a few months but I don’t think I can write working code manually anymore 😅

   
   

   
   

You hired an engineer 3 months ago, he's clearly not a good fit, but he's a father of 4 and was unemployed for a year. What do you do? (I asked this question on LinkedIn, got some great comments)

Did you squirm inside a bit?

Here’s my version of it:

A few years ago, I had a remote developer from Ukraine who was clearly underperforming. Not answering Slack messages, barely making progress on tasks. I gave him clear feedback and expectations. He improved for a couple of weeks, then went right back.

I planned to let him go (really!). Then the war with Russia broke out.

In the first month, we didn't expect any work from him and gave him full pay. He escaped to Prague, found a place, and slowly got back to work. And then the same behavior repeated itself.

I gave him some leeway - this guy was a refugee in a different country, of course he couldn't work the same. But after a few months, it was really dragging the team down.

I still couldn't do it. My manager ended up forcing the decision.

Afterward, I felt pure relief. Thank god someone made the call for me.

Don’t they see?

Every engineering manager has a version of this thought running in their head:

• Someone requests a vacation at the worst possible time, and you think: "Don't they see it's bad timing? Why make me decide?"

• Someone asks for a promotion they're not ready for, and you think, "Can't they see how far they still have to go?"

• Someone's doing the bare minimum, and you think, "Don't they know I can see it? Why not just leave?"

• Someone asks to work from home when the company is strict about office days. You think, "Don't they see I can't allow it? Why put me in this spot?"

In all of these cases, you're hoping reality will do your job for you, that the situation will somehow resolve itself. That people will magically improve (or magically quit), that they will just make the right choices themselves.

With my developer in Ukraine, I was hoping the same. That he'd improve, or that he'd just leave - anything but me being the one to make that decision.

Me dragging my feet had a price.

The team always knows

My team carried the frustration for months. They depended on this guy and he wasn't delivering, and they saw I was delaying. I've seen this pattern play out dozens of times across my career: when a manager finally lets someone go, the team is almost never surprised. I don't remember a single case where the team was angry at the manager for the decision, or didn't understand where it came from.

What the manager feels, the team almost always feels stronger.

The Radical Candor lie

Kim Scott’s Radical Candor is one of the most famous leadership books. The TLDR is simple: a 2x2 matrix. The X axis is how direct you are. Do you give tough feedback, do you let people go when needed, do you say no to requests. The Y axis is how much you care.

On the bottom left you have the manipulators, who never tell you anything to your face and don't care about you. On the bottom right you have direct and cold managers who will tell you exactly what you do wrong, but won't give a shit about your feelings. On the top left you have the most common trap: Ruinous Empathy. Managers who really care about their people and don't want to hurt them, but end up hurting their careers because they don't provide any tough feedback.

And on the top right, the goal: care personally and challenge directly. Sounds amazing, right? I can be kind AND do the right thing!

The problem is that the framework describes YOUR intent, not the other person's experience.

You can be in the Radical Candor quadrant and the engineer sitting across from you still experiences it as Obnoxious Aggression. You think you're being caring and direct, and they think you're being an asshole.

And there is no way to completely eliminate that gap.

Most of us became managers because we care about people, we genuinely want them to succeed. But human beings are social creatures. When you care about someone, feeling disliked or hated feels almost physically uncomfortable.

We have that strong need for the other person to recognize our good intentions in real time, to think: “wow, he's being so candid but I can tell he really cares!” (yeah, that never happens).

I don't want anyone to be angry with me, to dislike me, to hate me. I don't want to ruin someone’s day (or year).

I want to be un-hateable.

Being OK with ruining people’s days

I sometimes ask managers in interviews: 'Tell me about a time you ruined someone's day.' The actual question is: are you willing to put the team's needs above the need to be loved?

After 7+ years of managing, I still haven't completely figured it out.

I still catch myself wishing someone would "just understand" instead of me having to say it.

But I'm now willing to step into what might feel like Obnoxious Aggression to the other side, as long as I feel deep inside that I'm doing the right thing (which doesn’t mean always laying people off).

I'm more ok with people being angry at me, not liking me, or even thinking I'm unfair. Hopefully it won't get to hate, but that might happen too. I still squirm inside a bit every time - which I think is a good sign. When I stop squirming, it’ll mean I stopped caring.

Discover Weekly

1. What every dev should know about AI sandboxes. If you don’t build agents yourself, I feel it’s truly a must-read for every EM in 2026.

2. Irreducibility - Mental Model: Find the Floor. On simplifying a process until the ‘floor’. With LLMs, it’s common to think a process is easier than it actually is (thus creating a shitty automation).

3. Too many meetings? Try this. A great short overview of why meetings multiply and how to combat that.

Thanks CodeRabbit for supporting today’s article!

When you ask an AI to review code it just wrote, you get the intellectual equivalent of a student grading their own exam. Shockingly, they always pass.

CodeRabbit CLI acts as an external reviewer for your AI-generated code. Different AI agent, different architecture, 40+ static analyzers, and zero emotional attachment to what it's reviewing. The agent writes, CodeRabbit catches what's wrong, the agent fixes.

One command, autonomous generate-review-iterate cycles. The AI still writes the code, it just doesn't get to decide if it’s good anymore.

Try CodeRabbit CLI for free

In my 8 years as an engineering manager, I always felt my brain was enough. I never took notes or had a structured system, but I still easily remembered where every project stands, who's working on what, where I should focus next, who wants what from their career, who's struggling, and so on.

Recently, I started feeling my brain is running out of RAM (more on that analogy soon).

The average number of direct reports per manager has grown from 8 to 12 in the last decade, and continues to rise. On top of that, 97% of us also do IC work. We're expected to somehow manage more people while still shipping ourselves.

Original video here

Today I’ll talk about:

• How a greenfield project changed my approach

• 2 open source projects worth checking out (Cabinet and Tolaria)

• How I’m trying to solve this problem (and what I suggest to start from)

2 months ago, in a meeting with my peers, I shared that I was feeling quite overwhelmed. While I manage ‘just’ 7 engineers, we are spread across multiple projects, and we also have the maintenance of the existing products.

I felt there is no way I could be involved in the work of all engineers enough to give good feedback, do some IC work myself, and also manage the team as a whole. The advice I got is “it’s actually possible, and you need to build a better system”.

Like when someone tells me to “be more AI oriented”, the “better system” advice made me want to puke a bit.

It’s not that I’m an AI skeptic, but I’m also not a huge believer. I’d place myself somewhere close to the middle when it comes to AI adoption. I see many benefits in some parts (like debugging and understanding codebases) but know it’s terrible in others (like writing and management advice).

I tried a couple of times to give it a try by asking ChatGPT about some tough situations (and yes, I gave lots of context). The problem of course is that LLMs are the average of the internet, and the average manager sucks (and doesn’t read newsletters to get better). "Have you considered having an open and honest conversation?" hmmm, haven’t thought of that, thanks!

Anyway, few weeks later, I joined a complex greenfield project with a cross-org team. About 10 people involved, split into 3 work streams, trying to come up with architecture decisions in 2 weeks.

Before we started, a principal engineer requested that ALL work be organized in a dedicated GitHub repo. Every meeting transcript, every Slack conversation, and every decision to be uploaded there.

To be honest, I thought it was ridiculous (and I told him so). Notion felt much more convenient, why would I gather feedback on a document using GitHub PR comments? But he convinced me to at least give it a try.

Man, I was so wrong.

An LLM ‘project-brain’

It took me a couple of days to adjust. I started slowly, opening a Claude Code session inside this cloned repo whenever I needed to work on something. I was already brainstorming with Claude anyway, so the additional context helped.

But pretty quickly, I found myself starting the morning with "what should be my top priority now?" and getting an answer that actually made sense. When a meeting ended, all the new decisions/thoughts were entered automatically in the right places, making it super easy for anyone to catch up. There was no need to watch meeting recordings. I could ask "What does John think about this problem?" and get an accurate answer without pinging John. I could see what the other 2 streams were working on and how it impacted mine. It even flagged conflicts I hadn't noticed, and suggested what topics I needed to discuss with the other stream leaders.

Every thought I had - "we need to remember to consider Y in this area" - I'd just mention it (either in a meeting or a Claude session), and it was captured in the right place.

All of it was done by dedicated skills the principal engineer had set up in the repo, that automatically synced everything - meetings from Fellow, Slack channels, Notion pages. Keeping it updated was barely any work.

I’ve read many people mentioning Andrej Karpathy’s famous ‘LLM knowledge base’ tweet, but until that project I didn’t fully understand how useful this concept can be. When a new engineer onboarded to this project, she did it 100% alone with Claude. All the dilemmas and final decisions were there to explore, there was no need for lengthy explanations.

The feeling of again being in control and on top of things was amazing. I knew EVERYTHING I needed about this 10-person, 3-stream project without holding most of it in my head.

My brain needs help

After 2 weeks I admitted to the principal engineer that I was wrong, and that it was super convenient. With the increasing scope and responsibility, I had to admit my brain needed help.

My best analogy is RAM and SSD.

I feel I have a powerful brain, like a 64GB machine. It can handle a lot of work purely in RAM, and it has been enough until now. With the increase of the complexity and scope of work, it’s becoming impossible to constantly hold everything there, so I need extra storage to load parts from when I need them. Using only my brain is like depending purely on RAM - it works great until you run out.

Taking notes is like adding an old HDD. You have the storage, but every read and write operation is very slow. You spend more time searching for what you wrote than actually using it.

Having an LLM connected to all your context is like upgrading to an SSD with a smart file system, which knows what to load into your RAM at every given moment.

But the critical part (that I feel many people miss) is that you don't let the SSD do the computation. You can't outsource the thinking and decision making to LLMs. They handle the storage and retrieval, but the processing should still happen in your brain.

A system that is built for YOU (and where to start)

I know, I know. Very close to the ‘better system’ advice. What can I say, it actually works…

What gave me an additional push to explore this is the My CTO daily driver article by James Stanier (author of ‘Become an Effective Software Engineering Manager‘, and one of my favorite newsletter writers). He calls it a daily driver, but the concept is the same:

The core idea is very simple - a collection of constantly updated files managed via git. Here are 3 examples:

The project-brain system

For this, I recommend quickly building it yourself. It’s not that hard, and every company/project has a bit different needs. You can also check out Cabinet, an open source project that aims to solve this exact problem.

I’d bet that if you gave this article to Claude, and ask to build something that fits your team for the next project, you’ll get 80% there.

The critical skills to build first are:

• How is information stored (what goes where)

• How to sync from different systems (can be done at first by manually calling the sync skills)

• How to retrieve the right context

The engineering management system

After wrapping up with the project, I decided to try something similar for the other aspects of my role - the people management, the day to day dilemmas, influencing the org, etc.

As I actually wanted useful answers and not bullshit, I started by combining all the knowledge I accumulated over the years. I (well, Claude) went over notes from ~40 engineering management/leadership books and 100+ articles I've saved.

I then turned all the knowledge into 26 specific skills:

My goal was to feel like I consult with my favorite authors, and to call me on my bullshit.

Then, I opened a local github repo on my computer, installed the skills, and started to work there. I synced context from Slack and Linear, and built some basic understanding about my team.

I ask questions like "Where do you think X is struggling in project Y?" or "What am I missing?". It’s very early days, but it recently helped me nail some quite tough feedback I’ve had to deliver.

One thing I'm still figuring out is where to store the sensitive stuff - career conversations, tough feedback, people dynamics. A private repo technically works, but company admins can see it. If anyone has solved this elegantly, I'd love to hear about it.

The personal system

I’ve been following Tolaria’s progress since it started to gain some serious traction (currently at 10k github stars).

It’s a simple desktop app that helps you organize all your notes as Markdown files, with native relationships, Git, local agents, and direct AI model providers.

I’ve just started the migration process from Evernote (I’ve been paying them $100 every year for a while!).

Final words

In the last 3 months, I have transitioned from a skeptic to a strong advocate of this ‘LLM-based-brain-and-personal-operating-system’. I’m sure the tools will change, but the concept itself, of having all info organized and accessible by LLMs is here to stay.

And it’s not that I feel like I solve it - I still struggle to build this habit, it’s much easier for me to fallback onto using my own brain (especiallyin the management part). But I’m getting there!

If this article was useful in any way, or you have your own tips to share - please reply with your thoughts! Writing a newsletter can be quite lonely, as I have no idea how my content is received.

discover weekly

1. Outcomes > Learning Opportunities. Why in some cases your team member’s learning is quite secondary. I also REALLY loved that Shreyas Doshi shared his full conversation with Claude (powerful way to deal with generic objections).

2. Great companies are built in hackathons. I really believe we should have more space for engineers (and other functions) to play around and explore new ideas. With the current speed of building (especially new things), the ROI will be crazy for the companies brave enough to do it.

3. Radical Honesty Isn’t a Policy. It’s a Habit. From the cofounder of Netflix, a great take about small lies.

   
   

Manager.dev is proudly sponsored by Unblocked!

There are two kinds of context you can give your AI coding tools. The first is easy - writing skill files, rules, and prompts that teach it how you like to work. The second is nearly impossible to maintain manually - your full codebase history, past decisions, and team conventions spread across PRs, Slack, and docs.

Unblocked solves the second one. It builds a context layer from your engineering stack - so Cursor, Claude, and Copilot generate code that actually fits your organization. Less rework, fewer wasted tokens.

See how Unblocked works

Most world records in distance running were set with a “negative split” - running the second half of the race faster than the first. You start disciplined, you save your energy, and you speed up when everyone else is slowing down.

On April 26th, for the first time ever, a human ran an official < 2-hour marathon. Everyone talks about his light shoes, but the interesting part is the crazy negative split he achieved.

With all the AI craze out there, 90% of companies are doing the exact opposite.

I learned this one the hard way, both with the team I started managing recently and in the marathon I finished at the end of February.

Just SLOW DOWN

I've been training with a group for the last couple of years. There is one mantra our coach constantly pushed into our heads: run by heart rate, not by pace.

For most people, their legs and their hearts are not in sync. When you run too fast, your heart rate spikes, and your glycogen (the fuel your muscles run on) burns out way earlier than it should. Research shows that starting just 5-10% too fast can deplete your energy stores up to 30% earlier. That's why people hit the wall at kilometer 30 and can barely move.

The same thing will happen to many AI-crazy teams. A company's life is measured in years (say 7-10 years on average for a startup). The ones popping up everywhere are barely at 20% of the race. So you start super fast, and you continue to go fast, but you accumulate technical debt in your codebase and shortcuts in your architecture. You will slowly slowly start to “get tired”, and you'll finally hit that same wall.

The fix for runners sounds very simple: run slower, at the right heart rate, and you'll actually improve your pace faster. My coach was telling me this for months, but my answer was always the same: "I came here to train, to get my energy out, I can go faster." It took me a loooong time to actually stick with it. I always cheated a little, always ran faster than I was supposed to, because that's how my brain was wired for satisfaction. What's the point of running at 6:30 minutes per kilometer? It’s too boring.

But when I finally did listen, the results were amazing. I finished my first half-marathon at 5:40 per kilometer (~9 min/mile), faster than my best 10km run. I ran the last 3 kilometers at 5:00/km, as I had tons of energy left. And across 3 years of training, a triathlon, and a full marathon, I had zero injuries. Not one missed training session because of pain. Seriously, not a single one (injury = your people burning out or you have a production disaster, pick your favorite).

My shitty positive split

So there I was at the marathon, after a great half-marathon race, knowing all of this. I even wrote a whole newsletter article about intensity zones.

I initially planned for 6:00 m/km, but my 2nd son was born a month before the race, so my training was not ideal. The day before the race, I decided to go for 6:30 min/km, an easy pace.

Then the race started.

Sun on my face, 3,000 runners around me, kids cheering on the sides, people running with smiles everywhere (Sonnet 4.7 released, tons of AI tools, everyone says to have 10 agents running in parallel). I felt amazing.

I ran 6:10. Then some at 6:30. A couple at 6:20. First half average: 6:22. Just 8 seconds per kilometer faster than the plan. My heart rate spiked a bit, just a little over what I planned. But it was enough…

After kilometer 30, it became HARD. I slowed down considerably. Second half average: 6:42, for a total of 4:36 hours.

I am absolutely sure that if I had been more disciplined in the first half, I would have finished faster. It was just my own brain, telling me I can handle it.

A few weeks prior, I did the exact same thing to my team:

Positive-split engineering management

I wrote about it last week in detail - taking over an existing team in a new area, pushing scope to get early wins, until our most experienced engineer pulled me aside and told me to stop. What I want to add here is what he said in a longer conversation after that:

"It's very, very rare that I feel a change of cadence of work is justified. I give estimations, and I try to be as accurate as I can, but once truly asked, I'll give you an honest answer: it'll be done when it'll be done, take however long it'll take."

This is not a developer who works slowly. He did a massive refactor of our most critical system - initially estimated at 2 months for 2-3 people. He did it alone in 2 weeks, with zero production incidents.

He doesn't let external pressure change his pace. And when the complex, risky part comes, he has the energy and stability to handle it.

There's a quote from Peopleware I keep coming back to:

People want to finish. Time constraints have value, but not for making people work harder - they're just about using time as a forcing function to prioritize and cut scope.

Negative-split AI adoption

In a recent all-hands, our CTO surprised everyone by saying he expects us to stop writing code manually entirely in a few months.

What made me take him seriously is that he mentioned the company is willing to go SLOWER in the short term to make this happen. The goal is to right high quality code, not to just rush blindly forward. It was not a "hype" sentence, telling us to go all in on LLMs.

He gave a concrete example: say you prompt an LLM to write a feature for you, and the result is bad. You try to adjust in a couple of prompts, but end up giving up and writing manually. He asked us not to do that, but to figure out what info could have helped the LLM to write better code.

The answer is almost always better context and guidelines, and those don't have to come from the end-user's prompt. They'll mostly come from a rich, company-specific, and constantly maintained layer. This is a difficult problem to solve, and most companies with strong engineering cultures are hard at work solving it for themselves.

It takes a lot of patience and cooperation by the majority of engineers, this is not something that can be built "in the basement" by hands-off architects.

When you decide instead to move fast with mediocre code (or to quickly type the right code yourself), you are running a positive split - you banked "progress" early, and you'll keep paying for it on every future prompt (which will either need to be adjusted manually, or shitty code will slip into production).

Final words

Not every run is a marathon. Sometimes you have 100m sprints, where you just need to go as fast as you can. When you test a concept, and you know this code will be thrown away, by all means, go turbo.

The challenge is that sometimes you don’t know when you start the run how long it’ll take.

My advice is not to go slower for the sake of it - it is to go slower so you’ll build a better foundation to move faster later. Slow down to speed up.

Giving this advice is so easy, but it is REALLY hard to follow, and I’m unfortunately creating ‘positive splits’ all the time. Still working to improve that :)

Discover weekly

1. High Amplitude Disagreeableness - loved this frame: Frequency: In this case, how often someone is disagreeable. Amplitude: When they actually disagree with something, how intense is the dispute? On how to deal with startup people, who all share the ability to reach an extremely high amplitude of disagreeableness.

2. Nobody knows where AI is going  - you are not late. We are early.

3. We Are Done as Managers According to Anthropic - the death of the “Human Jira Router”.

manager.dev is proudly supported by leadjobs.dev

The ‘hacker news’ of engineering leadership job search. Simple UI, 100% free, no ads, and actually useful filters like global remote, relocation packages and visa sponsorships.

Sign up, save your filter, and get bi-weekly emails with relevant new roles for you:

Check it out

6 months ago, after a 9-month career break, I started a new role as an Engineering Manager at HoneyBook. It’s my 4th management role, but the first time I took over an existing team and not promoted from within.

I was told many times that in the first 30 days I must ‘only listen and learn’. I tried, but felt it’s the completely wrong approach to take. Last week I wrote about how we must adapt ourselves to our team’s needs - so here’s my honest self-retro:

• The perfect plan that died on day one

• Pushing the team into a wall

• What? 21 open tickets???

The perfect plan that died on day one

I had a VERY clear plan before I started.

I told everyone during the final interviews and after signing the contract that I'd like to spend the first 6-8 weeks quietly understanding the codebase, and even do a couple of weeks of technical support. I thought it would be a great way to onboard, as it would both give me better technical understanding, and let me observe from the sidelines how the team operates before I'm officially the manager.

Everyone agreed to the plan. I was explicitly told I'm not expected to manage anyone in the first month. The engineers will report to the director, and he'll also take the day-to-day job.

It took me just a couple of conversations to understand it's the completely wrong plan…

My first action when I got the laptop was to schedule 1:1s with all of my 7 engineers. I just wanted to make sure they were ok, and to see if there's anything urgent I need to tackle before I dive into the code.

What I learned: three days before I started, the team was moved to a new group, thrown into a completely new project, under a new PM. On top of that, all of them mentioned the last 6 months were quite challenging. They had no manager, no 1:1s (although officially reporting to the director), and the 7 of them were split between 4 completely unrelated projects. They barely felt like a team, and they missed that feeling.

So once I understood that the plan was for them to continue reporting to their old director (with whom they didn't have any contact), while the new director (who didn't have any context) will be the one managing the day-to-day of the brand new project...

It became very clear that disappearing into the code would be a very bad decision.

The team was much more senior than I was used to. I had a former EM (now staff engineer), 2 other staff engineers, 2 seniors, and 2 mid-level engineers. The technical side was in very good hands, my input was not needed there. Six chaotic months, and now a new project, a new PM, and a new director - what they needed from me is to focus on building the team itself.

So instead of coding quietly and being a shadow, I spent most of the first month talking to people and managing the day to day. 1:1s with any relevant person in the org, many discussions with the new PM. I'd say 90% of my day was in meetings.

The engineering manager's attention budget

It was naive to make concrete plans without understanding the reality first. All those 30-60-90 suggestions are nice, but every team has a different situation. I felt I talked way too much about my "self technical onboarding plan" before starting.

The good part is that I was able to adapt even though I knew not everyone would accept it well (my director would have preferred I get better technical foundations first). I had to push a bit to do it, but I felt it was the right decision.

The irony is that adapting so fast created its own problem. I went from planning to be invisible to being everywhere, which set me up for the next mistake:

Pushing the team into a wall

We had our first team meeting at the end of my first month. I put every team process up for discussion: the length of cycles, cooldown, daily meetings, team meetings. It was a chance to reset and combine what worked for them in previous iterations with what I brought. We settled into 3-week cycles and 1-week cooldown, (inspired by Shape Up). A veteran engineer mentioned they used to name sprints after desserts and bring them in for the demo. We decided to restart from A but go with cocktails. Sprint A was Aperol Spritz, B was Bloody Mary, and so on.

In our first cycle, we planned to complete a basic version of one big project and multiple small ones. But we were working on a completely new area for the team, so of course we hit a lot of unexpected surprises and blockers.

I was clueless. I had zero understanding of the work itself. Most of it was backend Ruby on Rails, which I'd never worked with before. I understood maybe 30% of the technical conversations.

By the end of the sprint, it felt really close, so we (well, mainly I) decided that 3 engineers will continue working during the cooldown to wrap it up. It felt so close. The engineers were frustrated, as the whole point of the cooldown is to not rush it with finishing the previous cycle.

The second sprint went a bit better, but we again didn't finish the main parts. This time, our most senior engineer took me aside, and told me to stop rushing us. There are things we need to learn and improve on, he said, but I'm being unrealistic. I'm grateful he did that. I really wanted us to have some early successes, so I pushed hard to find the minimal scope we could release. But the result was everyone always feeling behind and pressured.

The constant pressure to finish on time was not healthy at that stage (too many unknowns). Having zero technical understanding made it worse. I feel the situation wouldn't have happened if I was an engineer promoted from within.

Our third cycle went much better. By the end of it, we prepared Caipirinha together for the demo. People were laughing, chatting about random stuff between the updates. I felt we were finally becoming a team.

What? 21 open tickets???

After around 2 months, I finally had some time to breathe.

We had a weekly hotfixer responsible for all incoming tickets, and I had completely ignored that part until now. It was a bit against my instinct (I usually put support very high on the priority), but they'd been managing like that for 6 months, so I felt there was no rush. I prioritized the team and people first.

When I started to dive deeper, I saw to my horror there were 21 open tickets, with some of them open for more than a month. For 3 weeks in a row there were more tickets opened than closed, and the snowball kept increasing. The main problem was that we had some areas for keep-the-lights-on that nobody knew, and they were hell to debug, so people tended to do them last. With the volume, those were the ones that kept getting pushed.

This instantly became a high priority. Together with one of the engineers we organized a "hotfixing blitz." We closed a conference room for a day, and I ordered lunch for all of us. We also bought 20 $3 scratch tickets, so everyone who completed a ticket got to do something fun as a ‘reward’.

We ended the blitz completing 18 tickets, and solving multiple problems at the root, not just patches. (Someone won $20 on the scratch tickets)

I also chose for myself the 2 most painful areas to work on. In the weeks after, I took a full shift for myself, to experience the work.

After 2 months, I shifted from delivery to customers & support

Since then, I've been much more involved in the support area, covering for people, and getting to know our products that way. An EM should be able to solve tickets, and do so now and then, but shouldn't become the protection wall of the team.

And then everything reset

Four months went by very quickly. I'd gone from people focus, to delivery focus, to support focus. Things got stable and we found our rhythm. People felt they had someone to talk to, and understood what was expected of them. We were a team again, with culture, rituals, and even cocktail names :)

And then, 2 things happened:

• Another reorg moved my team to a greenfield project on additional revenue sources

• My wife gave birth to our second son, and I took a planned paternity leave for a month

I came back a few weeks ago, and I'm recalibrating again. The plan I had 6 months ago before I started was useless. The plan I'd make now would probably be useless too in a few weeks. The only thing that actually worked was paying attention, overcorrecting, and then listening when someone told me I'd gone too far :)

Final words

This is becoming the reality for more and more EMs - constant changes. I was used to a very stable routine, working with the same engineers, on somewhat related areas. In 2026 and beyond, I’d bet that this will become rarer and rarer, with the pace of both tech change and org changes. We need to make sure we are constantly adapting to our team needs.

Also - don’t be afraid to break some rules. I was repeatedly told you should just learn in the first 30 days on a job. I tried, but felt it was not the right approach, and I’m happy I didn’t stick to it.

Discover weekly

1. The golden rules of agent-first product engineering. Superb article from PostHog, a must read in case you need to build agents (and as we discussed in “Engineering Managers are going to hate OpenClaw”, you will probably have to).

2. The Real Reason Innovation Dies Inside Big Companies - why "we need to take more risks" is the most reliably broken promise in business.

3. The Physics of Starting and Stopping - How to start what matters and stop what doesn’t (hint: with mental models).

Manager.dev is proudly sponsored by Unblocked!

Stop babysitting your coding agents. Cursor, Claude, and Copilot are fast and capable - but they're context-blind. They generate code that compiles but misses your conventions and past decisions. You end up with ballooning token costs and review cycles you didn't need.

Unblocked gives your agents the organizational knowledge they're missing. It builds context from your engineering stack, resolves conflicts, and delivers only what agents need for the task at hand.

See how Unblocked works

Every Engineering Manager has 5 jobs, but most of us only care about 2 or 3 of them.

In my first engineering management role, I basically did two things: I made sure we shipped fast, and I talked to customers. I didn't give real feedback, didn't run team meetings, didn't think about my engineers career progression or what the codebase would look like in two years. This was what I felt the team needed at that point (we were working on an ambitious greenfield project).

But somehow, this became my “playbook”. The team’s needs changed, but I continued to focus only on the delivery and customer support.

2 years later, when I was promoted again to Management in my next company, I was lucky to have a great manager who challenged my “playbook”, and helped me see parts I was neglecting.

Here’s the analogy I’ve been using since then:

Every EM has 100 ‘attention points’ they can distribute across 5 main areas:

1. Delivery

2. People

3. Support

4. Technical direction

5. Team Future

Note: “Points” capture depth of engagement, not just time. How much mental energy, ownership, and active effort you're putting into an area.

Some come naturally, others we avoid. Most EMs operate like I did, distributing their points without real intention, just by inertia based on what they are used to doing.

But every team needs something completely different from you (and even the same team needs different things at different times). A huge part of being a successful EM is adapting yourself to what your team needs, not just rerunning the same playbook.

When I started managing my current team of 7 engineers back in October, I planned to spend 6-8 weeks slowly understanding the codebase, with the blessings of my director. But after just 2 days it became very clear to me that it was not what the team needed from me right now. They didn’t have a manager for 6 months, and they missed feeling like a team (everyone was working on different things with different PMs).

So I postponed my ‘technical onboarding’ and focused mainly on the people and delivery parts:

Since then, I’ve adjusted my ‘dials’ many times, almost on a weekly basis. I’ve dialed up customer support to 50 for a couple of weeks, and spend another one mainly focused on the team’s future. Today, I’m roughly 20 points on people, 30 team’s future, 10 customer support, 10 delivery and 30 technical direction.

Throughout the changes, I try to follow the “10-60” rule:

The 10-60 rule

You can distribute your 100 points in endless ways. An even split of 20 each is NOT the goal - from my experience, you’ll achieve nothing that way, just spreading yourself too thin. On the other hand, just putting 80+ points into a single area will harm the other ones.

If you put less than 10 points in an area, it will not stay stable - it will get worse. In addition, going over 60 usually means you became too obsessed (which might be ok for a short time to achieve a specific goal, but becomes harmful if continues for long).

Here’s how the range looks in each area:

People

This one feels natural to most EMs - it's why many of us got into management in the first place. The risk is going too far in either direction: ignoring your people entirely when things get busy, or making their happiness your single measure of success.

The 10 points minimum:

• Weekly or bi-weekly 1:1s, 30 minutes

• Knowing their career aspirations

• Knowing how they feel, what bothers them

• Knowing what they are working on

Under 10 points is when engineers start feeling invisible. No one checks in on them, no real feedback on their work. You find out someone is unhappy or disengaged only when they quit.

How additional attention can look like:

• Working on a promotion package for an engineer

• Fighting for salary increases

• Mentoring

• Doing a project with an engineer together - they lead a feature, you give high-touch feedback

• Building team culture - organizing team meetings, fun events, hackathons (those can take LOTS of attention points)

Trying to do it all at the same time will definitely bring you over 60%. I’ve seen managers like this, who desperately want their team to love them, putting their needs above everything else in the organization. Long term, this hurts the team too.

Delivery

This is the obvious one. It's what you get evaluated on, and what takes up 80% of most EMs' mental energy. The risk usually isn't that you ignore it, it's that you’ll obsess about it and forget the other four exist.

The 10 points minimum:

• Everyone has work to do

• It's aligned with the PM

• You know what people are actually working on

Under 10 points usually looks like this: engineers drifting toward whatever interests them, a shadow backlog forming where the PM goes directly to engineers with ad-hoc requests, and you being the last to know something is slipping.

How additional attention can look like:

• Working closely with the PM to understand the problems behind the roadmap, not just the tasks

• Connecting engineers to those problems early, getting them involved in brainstorming

• You and your engineers meeting customers for direct feedback

• Watching session recordings to understand what's actually happening

Over 60% is when you're reviewing every PR yourself or deep in coding tasks. Nothing wrong in doing a bit of either - but if you solely focus on delivery (like most freshly promoted EMs do), the other parts suffer.

Customers & Support

Most engineers don't enjoy this part. Tickets are often poorly defined, context is missing, and the areas that generate the most issues tend to be the oldest and least understood parts of the codebase. There's a lot of activation energy just to get started on one. So if you're not actively managing this area, it slowly degrades.

The 10 points minimum:

• There's always an assigned hotfixer responsible for tickets

• On average, tickets closed ≥ tickets opened, no snowball effect

Under 10% looks like tickets treated as optional, requests sitting for weeks without a response, and you not even knowing what's currently open (and what bothers your customers the most)

How additional attention can look like:

• Doing hotfixer shifts yourself

• Shadowing support engineers to understand their challenges firsthand

• Working on your team’s communication with customer support - not just whether you respond, but how

• Analyzing ticket patterns and fixing root causes, not just individual issues

Over 60% is when you become the permanent hotfixer, personally reviewing every issue, treating everything as urgent. Or, when you treat every customer problem as urgent, constantly causing context switches for your team.

Technical Direction

This is the how of building - the processes, the tools (yeah, AI tools too), the tech debt you're accumulating or paying down. It's the area where EMs often either abdicate ("the seniors own this") or overclaim ("I need to be in every architecture decision").

The 10 points minimum:

• You understand the tech stack being used, and you're involved when there are decisions to change it

• You know what the main tech debt areas are and can advocate for them

Under 10% looks like not being involved in technical decisions at all - and worse, not being able to explain them. You agree to every product request without pushing back on what it'll cost technically.

How additional attention can look like:

• Actively leading a refactoring project

• Researching a new technology

• Contributing to design review meetings and docs - both being capable of it, and spending the time

• Working with other teams and org guilds to improve shared tools and infrastructure

Over 60% is the "we have to do it the right way" manager - constantly fighting the PM for refactoring time, nitpicking every design doc, getting satisfaction from beautiful code while customers wait.

The team's future

This one is not about just managing what the team is doing now, but about figuring out what it will be in 6-12 months. Especially now, with all the AI-craze out there, it’s important to be part in the conversations your leadership team is having.

The 10 points minimum:

• You’re thinking about gaps in the team (skills, ownership, seniority)

• You know what your team owns today, and it’s clear to others

• You have a point of view on what your team should own next

Under 10 points looks like this: you focus solely on sprint after sprint, reacting to product requests. You wake up one day and realize your team is working on things that don’t really matter anymore to the company.

How additional attention can look like:

• Expanding (or narrowing) your team’s ownership intentionally

• Positioning your team around high-impact areas (not just what you historically owned)

• Re-shaping the team to match that direction - skills, roles, responsibilities

Over 60% is when you’re living too much in the future, constantly reinventing the team, thinking about “the ideal team” instead of the current one. The team feels unstable, like the ground is always shifting.

How to distribute those points

What a great question! :)

seriously though, it’s quite a challenge for me. My simplest tip is to periodically (weekly/monthly) look backward and see which parts you didn’t give enough attention points too.

Next week, I’ll share my experiences from the past 6 months on how I shifted between those parts and what caused the shift.

Discover weekly

1. Who will be the senior engineers of 2035? 

2. When Expertise Becomes a Boundary. More true than ever in 2026.

3. Compressed Words, Identity Steps, and Borrowed Opinions.

18 months ago, I wrote about why I believe sprints are taking the joy from building software. When I met Matthew in my course and learned his org fully adopted Shape Up, we started working on this article. 

His team ran eight Shape Up cycles. Here's what worked and what didn't. 🎤 to Matthew!

In December 2024, we came out of a reorg a leaner engineering team than we had ever been. We had a choice to make - accept that we were just going to be in maintenance mode, or find a way to actually ship.

We are a 10+ year old company, with a large and complex codebase. And, like many organizations, our engineering teams’ feedback was consistent: too many interruptions, unnecessary meetings, and context switching, without enough time to focus. 

We had always been an scrum-based shop - 2 week sprints, planning, stand ups, ticket pointing, backlog grooming, etc. We had limited resources and we were going into 2025 assuming that we would just be in maintenance mode moving forward.

Having recently explored alternative SDLC methodologies, we had some familiarity with the Shape Up. This seemed like the right moment to give it a try.

We had some internal discussions on how we would adapt and what our processes could look like, then prepared a presentation for leadership on what would change. Leadership, obviously, wanted to get more than “just maintenance” out of the team, so they were willing to let us try a new methodology - especially if it meant being able to produce more features. Shape Up meant some changes in expectations from their side, but they supported the changes and gave us the go-ahead to move forward. 

After sharing out with the team and some refinement of the new processes, at the beginning of January 2025 we had our first Shape Up project cycle.

Shape Up in practice 

Basecamp’s official Shape Up guide is full of great guidance and process, but (as they recommend) we had some modifications to make to accommodate the makeup of our team. 

Planning

Leading up to a project cycle, product, engineering leadership, stakeholders - or really anyone in the organization - brings a project pitch together. A project pitch outlines a business problem that needs to be solved, not the actual feature to develop.

Once ready, the pitches are presented to the company leadership team, where they ask questions, provide appetite for each project, and help prioritize. Appetite is another Shape Up term - instead of committing to specific features, we decide how much time we are willing to invest in each problem. It can be a full cycle, but can also be smaller parts. 

These meetings are not about presenting the solution. The pitch process forces people to break down the problem to the basics - as the pitch might not get picked up, or the appetite for the project might change. This helps prevent the common case where the product org brings to the table detailed solutions instead of problems.

We've found that through this process, we often end up shaping pitches even further to bring alignment with leadership's goals as the projects became more clearly defined.

On shaping: Shaping means defining the problem and solution at a level of abstraction that's concrete enough to act on but loose enough to leave room for the team to figure out the details. 

From the BaseCamp site

This whole process happens in parallel with the projects that are in flight. Engineers are brought in when necessary to talk about technical constraints, evaluating scope, or to  provide their input on feasibility:

From the BaseCamp site

During the cooldown, the product & engineering leadership team chooses the projects for the next cycle (called bets in ShapeUp). 

Teams

Teams are formed around the selected projects. Often projects will require specific skills or knowledge, but we try to rotate engineers into areas they may be less familiar with. This allows us to pair senior engineers with more junior engineers to share knowledge and experience.

One of the tenants of Shape Up is that we are committing to solve a problem within six weeks. This can be a challenge for projects that may take longer as it goes against the principle to commit to multiple cycles. Often, there are clear themes that we can identify carrying over to the next cycle. If this is the case, we usually carry over a couple engineers from the teams between cycles.

Part of the goal, though, is that people gain experience across the codebase. This means that cycle to cycle, someone may switch projects every couple weeks. 

Another important aspect of each project team is the Tech Lead. Since we are a flatter organization, this provides a way to have a single point of contact for me on each project. The Tech Lead also provides leadership for the team in decision making, stakeholder coordination, and scoping. 

(An additional side effect of the Tech Lead role is that it gives engineers experience that can lead to a future people manager role or continued growth as an IC/technical leader)

Every team has a PM, a tech lead, product engineers (generally 3-4, but can vary in size), and an assigned Platform/SRE engineer for support.

Each team has the full autonomy to decide how they operate:

• How often they want to meet 

• How detailed they want to create tickets

• Or any other aspect of running the projects. 

Work

The cycle starts with 1-2 exploration weeks. Usually there are more meetings, as the team begins to shape the scope of the project. We found that taking time for this part is crucial for the success of the projects. The scope is much easier to negotiate at this early stage, before you are rushing to implement. You can properly investigate the risks or the tech debt you might create.

Tech leads coordinate together on any impacts to each other's teams' projects. This is facilitated by a weekly tech lead meeting where tech leads have an opportunity to share status on projects and anything that might need coordination with other teams

The sync with the business side happens throughout the process:

• Cross functional stakeholders are regularly included in meetings for demos and  questions.

• Mid-cycle there is a demo meeting for our whole tech org. It isn’t a deadline, just there to share status and stay updated with others’ work. Stakeholders are invited, but the environment remains technical

• At the end of the cycle, we do a similar demo meeting to share out the final versions of the delivered projects. 

• Following the release of cycle projects, the tech organization is invited to share out demos of projects company wide.

That last bullet is really valuable. Often, we’ll have a stakeholder demo the functionality delivered to the entire company. This closes the loop on projects the business has prioritized with the impact the project has had for specific stakeholders.

Cool-down

The next (and super valuable) part of this process.

The cool-down is a two-week period where the engineering team itself gets to lead what gets done. Teams or individuals can work on identified tech debt they've discovered, complete documentation for projects, handle smaller support requests from the business - whatever just needs to get done that doesn't fit into a project.

There are cases where an urgent request comes through from the business that takes priority, but in general we have been able to use this time as intended, 

Overall, that is the flow. We are now in our eighth project cycle since starting Shape Up, and have seen multiple advantages from working this way.

Why Shape Up works for us

3 main reasons: Better developer experience, stronger business buy-in and involvement, and consistent delivery. 

Developer Experience

I can't emphasize enough how much value this process has given in terms of available focus time for the engineers. 

First, Shape Up provides focus through clear priority guidelines. Any request that comes through outside of the pitch process is triaged before any individual engineer is interrupted by it. If a request comes through, whether it is a new feature, an enhancement, or even a bug, the request is weighed against the projects that had been selected through the pitch process. Other methodologies can hold on to a similar prioritization process, but Shape Up provides a clear way to say, “is this request more important than the projects already prioritized?” Sometimes it is and then there’s a further conversation on the impact to the projects, but either way, the process protects the engineers from interruptions that would normally take them away from the project they are one

Additionally, the six-week timeframe also provides enough time to complete full projects, whereas in two-week sprints, a request might get shoved in and distract from the project work that was in progress.

Second, teams have autonomy to decide how they work. If teams only need one in-person meeting a week, then they can decide to do that. No scrum ceremonies constraints. Sprint planning, stand ups, ticket pointing, backlog grooming - these are all potential distractions.

Third, there is a trust that is established between the business and the engineers. The engineers have clear guidance on what the priorities are because the business has decided on specific projects. Giving engineers the problem instead of the specific tickets creates genuine ownership - they're not just delivering a feature, they're solving a business need.

All this leads to massive gains in developer productivity and satisfaction. Multiple engineers over this past year have told me how much more work they are getting done. We had projects where we were able to not only tackle the business problems, but underlying technical debt that had lingered for years. One cycle we were able to remove over 100,000 lines of code.

The process also leads to more opportunities for developers to grow, whether in their leadership or technical skills. Knowledge sharing is much better, and the separation between engineering ownership is removed. 

Business Buy-in

Trust takes time to build. I would say that it took about two to three cycles for the business to see the full value of this methodology. But now, project pitches and working through them with stakeholders is a valuable part of the rhythms of the company as a whole. Anyone can bring forward a project pitch.

For example, we were approaching a significant Python end-of-life upgrade, which also resulted in a need for product engineering work because of functional requirements related to several dependencies within our application. Our platform/SRE team brought forward a pitch for the Python upgrade, presented the requirements, and relayed the importance of this work for the business. 

There are other methodologies that have processes around how priorities are determined, but none seem to be as clear cut as Shape Up. The business is making a commitment to the technology team, just as the technology team is committing to get the project done. This 2-sided trust and commitment begins to remove boundaries between organizations within the company. There's less head butting, less confusion, and more ownership.

Consistent Delivery

In the eight cycles we've run we have consistently been able to deliver nearly all committed projects (~25 of them). Some went a little long into the cool-down, but some were also done earlier than expected.

Previously, interruptions, unclear expectations, and lack of focus time resulted in many projects being delayed (or worse, not feeling like they had a clear end) - and there was also never time to address the underlying tech debt. And often there was a feeling that product and engineering weren’t always aligned with what the business or stakeholders were looking for.  

Our challenges with Shape Up

Of course, there were some learnings along the way and the process is made to serve the team, not the team for the process.

Scoping

One thing we learned early is that the first one to two weeks are critical for scoping. It can feel frustrating, like no progress is being made on the feature. But shaping the project to a scope that the committed team can deliver has proven to produce higher quality by the end of the cycle, and sets expectations for the business and stakeholders more clearly.

Of course, even with the best defined scope, unforeseen issues will always come up. The defined scope might have a feature that is more complicated than previously thought, tech debt might get in the way, or a bug might come up. The team’s scoping and flexibility needs to account for this.

Large projects

Larger projects become a challenge if they can't be scoped down to six-week deliverables. In a purer form, a twelve-week project should be broken down to two projects where the second project may not be prioritized in the next cycle. This isn't always possible.

There may also be cases where it takes six weeks to release a feature, but we want to test its impact. It's challenging to integrate the testing follow up in the next cycle, especially if the teams are dispersed into different projects. This is a challenge we're still working on, but often we will scope the testing follow up into the cycle capacity as planned interruptions.

And, while the cool down period is good in theory, in practice it often gets co-opted by the business for small projects and little requests. Engineering's ownership of that time is limited. In one instance, we had a two-week project that ended up taking more time and affected the start of the next project in the following cycle.

Lastly, I'm not sure how well this scales. Our team is ~20 engineers. We can share information across the entire engineering organization quickly and efficiently. Once the product and engineering organization grows, larger teams within the organization would need to be responsible for their own Shape Up process and cadence. I think it can work, but there would be challenges.

Conclusion

One of my favorite aspects of how we've adopted Shape Up is the inclusion of business stakeholders in how we demo releases to the rest of the company. 

Often we have the business owner of the project run the demo at a monthly company-wide meeting. This does two things, first, it shows appreciation for the engineering team who worked on the project. It's one thing for them to show off what they've done, it is more meaningful when the stakeholder does it.

Second, it ties together the business investment in the cycle. At the beginning of the cycle, the business chose the priorities, then at the end, by demoing, they confirm those priorities. This idea isn't isolated to Shape Up - it can be done in whatever process you're using. It breaks down silos between engineering and other organizations in the company, provides empathy between them, and effectively shows how the project will be put into use by the people who will be using it.

Every cycle I am continuously impressed with how much we deliver on the projects we've picked up. My team went into 2025 thinking that we would be in maintenance mode, but we came out delivering on large initiatives, massive tech debt reduction, consolidation and simplification of services, and, most importantly, an engineering team reinvigorated to write great software.

Scrum certainly has its place, but teams considering a process change should absolutely take a look at Shape Up. There is no way to overstate the amount of focus, efficiency, and delivery we've seen. Software engineers want to focus on solving problems without interruption - the Shape Up process can provide that and add value to your business at the same time.

Thank you Matthew!

I've only done a partial version of this - 3-week cycles with 1-week cooldowns, skipping the proper scoping and betting. Even that partial adoption showed me how powerful the cooldown is. Once engineers get dedicated time to tackle what they know needs fixing, good luck taking it away :) 

Discover weekly

1. Confessions of a Millennial in Tech. Elena Verna (heading growth at Lovable) shares that even she constantly feels behind. Crazy times, and a very honest reflection.

2. Finding Lagom in Your Org. Lagom is a Swedish word that means having just the right amount. Not too much, not too little, but what’s appropriate for our actual life. Suzan shares about what commonly happens in organizations as the years accumulate: The decisions deferred, the processes patched together, the relationships neglected, the capabilities we meant to build but never did.

   And here's how you know it's gotten out of hand: everything feels harder than it should.

3. How to Use AI Without Losing Your Mind. On balancing the hype with practicality.

   
   

Manager.dev is proudly supported by leadjobs.dev!

My friend Piotr got frustrated job hunting - every existing engineering board was shitty. They hide details, miss critical information, and are a pain to navigate. Together, we decided to build leadjobs.dev - an engineering leadership board that actually works.

18,400+ engineering leadership jobs, updated daily. Every listing shows the tech stack, real remote status, and compensation where available, and nothing is gated. Sign up and you'll get two free emails a week with the most relevant new roles for you.

Whether you're looking or just keeping a pulse on the market, take a look:

Browse Engineering Leadership Roles

Hi, it's Anton. Welcome to manager.dev V2 - I recently migrated to Beehiiv after getting tired of some parts of the Substack experience (forcing readers to download the app, dropping open rates, no proper API). That said, I'm grateful to Substack - it took me from zero to 25,000 subscribers, completely free, and the community of newsletter writers there is really special.

The move is part of a bigger push for the newsletter: I want it to become THE place for engineering managers, by investing more effort and research into each article. The newsletter stays 100% free, supported by sponsors! (thanks to Linear and Unblocked for being long-time supporters 🙏)

(I'm also looking for additional sponsors - if you know anyone at Datadog, Meticulous, or another relevant company, I'd really appreciate an intro! And if you're a fellow newsletter creator considering a switch, here's my Beehiiv referral link.)

Back in Q3 of 2023 my company’s CPO stopped the roadmap and told us to build an LLM-based feature. It was right at the peak of the ‘chatbots’ hype, where every company wanted its own version of ChatGPT.

I really hate decisions based on hype, so I asked: "What if we have no adoption at all in phase 1? How do we decide whether to continue?" (phase 1 was around a month, the full vision was 3-4)

He (at least honestly) replied: "We're continuing with all future phases no matter what. It's a strategic initiative." In other words - the board wanted an AI feature → we are going to build an AI feature.

In 90% of the products, nobody asked for those features nor wanted them. Nobody opened their expense tool thinking "I wish I could have a conversation with this." They wanted to submit an expense.

There were many famous disasters - like Chevrolet bot selling a car for 1$, a supermarket’s bot suggesting poisonous recipes, and snapshot seeing huge spike in 1-star reviews after adding the ‘My AI’ feature.

But of course, our teams still had to build the features and deal with the mess. We learned about prompt engineering best practices, and brought something to production fast (without even proper evals in place…).

In recent weeks I started to get a feeling we are reaching a similar wave of hype with OpenClaw, and it looks scary.

What Is OpenClaw

In case you missed it - OpenClaw is an open source GitHub repo that exploded in the last few months, becoming the 8th most-starred project with 350k stars (passing React), and will probably become #1 soon.

It was built by Peter Steinberger, an Austrian developer who connected three things: a messaging app, an LLM model, and a terminal. He assumed Google or OpenAI would build the same thing within weeks, but they didn't. His "small toy" became the fastest-growing open-source project in GitHub history.

The concept is actually very simple:

You have a single long-running Node.js process (the "Gateway"), which orchestrates everything. It is able to use any LLM (the ‘brain’), and also execute commands on your computer (the ‘hands’).

So far, this is not very different from a Claude Code experience. The difference comes from the other 3 things:

• Memory - it writes plain Markdown files in your file system, and remembers quite well everything you need it to.

• Channels - this is what caused it to go viral. You can talk to it in whatever chat platform you want (Slack, iMessages, Whatsapp, Telegram), making it much more accessible and addicting.

• Heartbeat - and this is the biggest ‘innovation’. Every 30 minutes, the agent triggers and checks if there is anything that needs to be done, and can proactively send you messages. It can check your Gmail, monitor your deployments, summarize new Slack messages and so on.

The 3rd part, the heartbeat, is where most of the hype is coming from.

Reactive vs proactive

Let’s imagine you are an engineer working on a tool for accountants, like QuickBooks. In the first wave, you probably built a chatbot that lets users upload expenses and categorize them automatically (with maybe a few clarifying questions).

This is reactive - the user is the one initiation the interaction.

In the “OpenClaw wave”, your users could ideally say: "Monitor my Gmail and forever submit my expenses. Every morning send me a report for what you did the day before so I could correct you."

The agent checks your Gmail every 30 minutes, finds receipts, categorizes them, submits them through the API, and every morning sends you a summary on WhatsApp. You review it over coffee, correct the one it miscategorized, and that's it.

Isn’t it just automation?

Actually, yes. I like to think about it as smart automations, now accessible to everyone.

I run manager.dev as a side business. I have expenses to file, content to write, sponsors to book and negotiate with. I could have partially automated a lot of this years ago by stitching n8n or Make with LLMs. I never did, seemed like too much effort.

Now, it’s gotten MUCH easier.

In the last week, I’ve built my ‘AI employees’ in paperclip (basically a nice way to orchestrate multiple Claude Code processes), and played with a OpenClaw (deployed it on Railway, breaks quite a lot, will switch to NanoClaw in the upcoming weekend).

The tech is not there yet, but it’s very close. I can understand the excitement.

And that's what makes this wave more dangerous than the first one. When you build an automation yourself, whether in n8n, make, or inside a SaaS you use, you are doing it in a mindful way. You think about what you want to achieve, you clearly define it (or at least arrive to a definition through trial and error), and you (usually) test it.

With prompting, you are much less careful.

How it’ll impact your product

The ‘ChatGPT’ hype will repeat itself. Your board/exec team will feel your product needs to be more ‘agentic’ and include ‘OpenClaw-like’ features to stay relevant.

And for some products, they might be right.

Take Linear’s agent for example (not sponsored this time!). As their CEO said, issue tracking is dead. In the last month, my team uses Linear almost solely through Claude Code. Imagine if sales people around the world started to use Salesforce only through OpenClaw or similar products that will pop up. Tools that will become just ‘databases’ might become obsolete, or at least replaced more easily.

And it's not like there will be just one agent that solves all your problems, same as there won't be a "single SaaS" to run your company. In her great article, Claire Vo shared her OpenClaw setup, using 9 different agents for different purposes (from family, to her podcast, to content).

Here are some examples of how those agents could look like:

Datadog agent. Monitors your error rate every 30 minutes. Spike detected at 3am, pages the right person, pulls the relevant logs, drafts the incident summary, and posts it to Slack.

Salesforce agent. Monitors your pipeline every 30 minutes and sends follow-up emails to prospects.

Greenhouse/Ashby agent. Checks new applications every morning, scores them against the job criteria, surfaces the top three, sends them slots to schedule automatically.

Some of those features might be actually useful, but I'm sure there will be some much bigger disasters too. A McDonald's agent that detects what you're craving and orders your food before you even open the app, or a Notion agent that reorganizes your workspace overnight because it decided your folder structure was too messy.

In any case, you’ll still be required to implement it.

Your part in it

We can't let this conversation happen without us.

The "our own OpenClaw" discussion is already happening in your company, probably between your CPO and CEO, who both read some hype tweets.

If Engineering Managers aren't in that conversation early, we'll get a requirement that was designed without understanding the possible blast radius, the infra work, or the difference between a good agent workflow and a shitty (and dangerous) one.

That's how the first wave went… But this time the impact might be worse than an unused feature. A chatbot that gives wrong answers is embarrassing, but an agent that acts on wrong assumptions is like a bomb.

Final words

I believe we have a big headache coming for us, but it can also be an exciting change.

You have enough on your plate, and this feels like complete bullshit hype, I know. I still highly recommend setting aside a couple of hours aside to play with OpenClaw/NanoClaw/PaperClip or any tool in this area.

Having at least some early experience on the consumer side of it can help you a lot in upcoming conversations - your PM is already thinking about this, maybe you should too.

Discover weekly

1. The Two Most Powerful Words in Any Negotiation. I love Marc’s storytelling, super relevant read for any manager of people.

2. How Multiplayer Pomodoro Cured My Productivity Debt. A peer-pressure based productivity method I really liked 🙂 

3. OpenClaw: The complete guide to building, training, and living with your personal AI agent. A really nice start for playing with it yourself.

   
   

   
   

Heavily based (with permission) on Amitay’s great article

The more technical an engineer or manager is, the worse they are at explaining their thoughts and opinions, and the more frustrating it is for them (and for everyone else).

But let’s start at the beginning.

What’s this thing we call “Red”? In a way, there is no such thing. “Red” is a simplified representation of a range of visible wavelengths.

We compress infinite complexity into finite language.

When your engineer says “I’m frustrated”, they are actually compressing a complex range of emotions into a single word, making it communicable.

When we transfer information from one person to another - feelings, thoughts, technical concepts - some of it is always lost. When I say “I’m happy,” I lose the subtleties of my experience for the sake of being understood, hoping the listener fills in the gaps with their own interpretation once they decompress the message.

Same with an abstract concept like ‘technical debt’. For each engineer, it means different things, based on their own experience. What you try to transmit during that important architectural meeting might be completely different than what the other side receives.

You can think about it in circles: the center represents core experience (raw information). Within it, the information is rich and multidimensional. As you move outward from the center, the message becomes distilled and simplified, making it less accurate, but easier to transmit:

But why do we do that?

1. Cost

Describing the raw data of every experience or technical concept would take an enormous, possibly infinite amount of time.

At higher resolution (closer to the center of the circle), more information is available, but the cost of sharing increases due to the volume of data. At a certain point it becomes inefficient - the benefit of extra information no longer justifies the cost of transmitting it.

But what if I’m willing to pay the price? If I have all the time in the world?

2. Confusion

More information is not always better. At first, that’s true - understanding rises as you add context and detail.

But there’s a sweet spot where the idea fully “lands.” The recipient gets it.

In some cases, like the ‘R’ above, the understanding will keep rising. But in others, beyond that point, adding more information doesn’t just fail to help - it actually reduces understanding. Extra details blur the core message and introduce noise and confusion.

Draw me a sheep

In those cases, the curve doesn’t rise forever. It rises, peaks, and then drops once you cross the threshold where clarity starts turning into overload:

As engineering managers, there are 2 skills we need to master:

1. Compression

This is my weaker one. Being able to take the ‘inner circle’ of your experience/feeling/thought and compressing it into the right few sentences. Articulate yourself so the other side fully gets you, while in parallel:

• Minimizing the cost (needing a few minutes instead of 1 hour meeting)

• Avoiding confusion (understanding what exactly the other side thinks)

There are different ways to achieve this skill - some do it with great storytelling, but others achieve the same result with dry explanations full of facts. No matter which way you choose, you have to be at least a 7/10 in this skill as a manager.

You use it everywhere:

• When giving feedback (what do you mean by ‘more ownership?’)

• When pushing for your agenda (why ‘supporting scale’ is important?)

• When mentoring an engineer

When you improve at it, you start to notice when you reach that tipping point, or what else you need to say to bring the other side to that ‘aha, now I understand’ moment.

Getting there takes a lot of practice. A good way to start is to ask the other side to explain back what they understood from your message.

Wes Kao has a couple of great articles on the topics, I’d start with how to be concise and Technical leaders make these 4 common storytelling mistakes.

2. Decompression

Being able to receive information effectively - get as close as possible to the ‘inner circle’ that the other side tried to transmit. Make the other side feel heard, and walk out of conversations feeling that both sides understood each other.

This requires shutting up and listening. Not jumping in to provide your opinion, or share your own experience in a similar situation.

This one is very underrated - as many managers think they are good at it, but are actually terrible. I feel the more sure you are that you fully understood the other side, the more likely you are to be wrong.

How it looks like in the day-to-day

I first encountered this problem as a newly-promoted first-time Engineering Manager. My own manager was the most tech-inclined engineering director I’ve seen. He didn’t care about customers at all - only about building technically excellent products. I’m on the opposite side - I care much more about our customers than the tech debt we create.

On paper, it could have been great balance, but we just couldn’t find the right words to use. He hated my approach, and gave me the worst performance review I ever got.

In hindsight, I can assume he was burned by too many rushed projects and wrong decisions.

Since then, I continue to encounter this gap almost every week. Just this last one, I’ve been working on a new project with 2 super talented principle engineers. And still, they struggle to explain their vision in a way that’ll bring everyone on board. We are slowly getting there, after 10+ hours of meetings and a lot of mental effort and exhaustion from all sides.

It both of those cases, all sides could have tried harder to imagine themselves in the other side’s shoes.

I’m not very communicative. In my personal life, I prefer reading a book to meeting people. This mental model of ‘compressing’ and ‘decompressing’ information helps me think about communication in a slightly different way, more suited to how my brain works. I feel I improved just by holding this concept in mind.

I hope it’ll help you too!

Discover weekly

1. Slow down to speed up by James Stanier.

2. Claude Cowork Might Be the Most Consequential Piece of Software You're Not Using by Eric Porres.

3. Avoiding a Culture of Emergencies by Stay SaaSy.

   
   

For most of 2025, I worked for myself, at home. My wife and I are not very good at resisting tasty food (opening the fridge just to see what’s inside is a habit of mine), so we just don’t buy junk. A side benefit from working from home was that I actually ate pretty healthy. I also trained for a marathon, so I was in pretty good shape and happy with my body.

(Getting to engineering in a second, promise)

At the end of last October, I started a new hybrid job. There are many benefits in my workplace, one of them being a crazy breakfast. And I’m the breakfast-kind of guy. When I’m in hotels with buffets, I eat so much that I’m barely hungry at dinner.

It was fun at first, but very quickly I started to gain weight - 3 kg in the first month(!). I tried setting up rules for myself: not touching the snacks drawer, limiting myself to one plate at breakfast, not eating sweets.

But nothing really changed, which didn’t make any sense! I’m eating one plate of breakfast - some salads, cheese, and bread - regular lunch, and a light dinner. I’m running almost every day, and I STILL somehow keep gaining weight.

One day during breakfast, I complained about my first-world problems, and a coworker suggested the very sensible idea of just tracking what I eat, something I’ve never really done (I’m 30, so I felt there was still time until I had to fight nature).

I first tried by opening a WhatsApp group with myself, but after a couple of days, I downloaded cal.ai to give it a try (not connected to them in any way).

I found the 2 culprits:

• My breakfast plate was way more calorie-heavy than I expected. The cheese, salads with mayo, bread, etc, added up to 1000+ calories. Shocking, right?

• I was snacking on salty things much more than I expected (I love those damn salted cashew nuts). It was not sugar, so I felt like I’m not ‘violating my rules’.

Now, to engineering.

Engineering Bodies

The math of our bodies is simple: eat more calories than you burn → gain weight. Burn more than eat → lose weight.

Imagine your product was a human body. Your input is code, and your output is feature adoption. And like me with my “healthy” breakfast, most companies have no idea what they’re actually putting in (more on that in a moment).

Whether you need to gain or lose weight depends on where you are. Some companies (like young startups) are skinny teenagers, they genuinely need more input. But most companies are just getting fatter - every CEO wants to move faster, pushes for more code, more features. More weight should mean more strength, like in judo. A 90kg fighter will crush a 60kg one. But if you reach 400kg, a 50kg kid will beat you (even if it’ll take them a while). Some products would genuinely be better if half their features were deleted.

Examples of how I imagine some company bodies to look like

No matter where your product sits, it can only absorb a certain amount of calories while staying fit. Google does this very nicely. You rarely see new features in Gmail or Calendar - but that’s how I want them. It’s a battle-tested fighter that knows not to gain weight to win. I don’t see anything replacing Google Calendar anytime soon.

But for companies that do need to gain weight, the question becomes: how do you even know how much you’re eating?

So what are engineering calories?

Yes, the code is your input.

But measuring lines of code is like counting bites. There might be some correlation between the number of bites you took in a day and your calories, but it’s super low. You can bite empty air and it’ll count.

A bit better approach is the number of PRs. I’d say it’s like counting the number of servings you ate, more servings usually means more calories. This is better than nothing, but what’s the actual caloric value of each PR? A one-line config change and a full architecture refactor are both “one PR,” but they’re not the same meal.

That’s what Weave does - using ML to estimate the real caloric value of each piece of work.

For newer readers: I consult for Weave, so I’m not objective here. But I’d encourage you to plug it into your GitHub - it takes 2 minutes, and the data is often surprising.

Now, I know that some of you are thinking this is about managers hiding in dark rooms figuring out who to fire. It’s not. Obviously coding is just a small part of an engineer’s work, and a lot of it is invisible.

Look at how PostHog does it (from their public operating docs):

They give ALL their engineers access to data about everyone else. If someone produces less input, it doesn’t mean they’re a bad developer. Maybe they’re reviewing everyone’s code. Maybe they’re mentoring. Maybe they’re stuck in meetings explaining to everyone else how to work better.

Sometimes, as an Engineering Manager, you feel like things are moving well. Meetings are happening, engineers are busy, PRs are opening. But when you look back, you feel like you barely delivered anything this quarter. The problem in 99% of the cases is not your engineers, but the systems your company has in place.

The goal isn’t a perfect measure. Cal.ai couldn’t see fat cheese hidden under a salad leaf, but it was at most 10-20% off, which is much better than hunches.

When you actually measure the inputs to your product, you see what’s holding you back:

• If a specific repo has much lower input, maybe it needs some love.

• If your strongest engineer has lower-than-expected numbers, they’ll be happy to explain what shit they’re dealing with.

• If someone is super productive, they’re the ones who can share their system with others.

A note of caution

Most of you reading this work in companies that don’t actually need to gain weight. They need to start by exercising more - increase current feature adoption, or delete useless features.

For those who actually need to gain weight, remember that not all calories are created equal. 1000 junk food calories are very different from 1000 healthy meal calories. You might not notice it in the short term, but over time, your body will feel the difference.

The same goes for code. If the input to your system is tons of garbage AI-written code, it’ll come back to bite you (even if you don’t notice the difference yet).

I’m still taking photos of my meals, by the way. I look ridiculous doing it, but I’m down 4kg :)

Discover weekly

1. Revenue addiction kills companies by Elena Verna. It was always a bad habit. But in the AI transition, it has become deadly (in all weight categories).

2. Your manager is already investing in you by Wes Kao.

3. Avoiding a Culture of Emergencies by Stay SaaSy.

Last April, I wrote a well-received article about the 13 software engineering laws - Hyrum’s, Conway’s, Zawinski’s, and 10 famous others. The common patterns people noticed in software projects and decided to name.

But beyond the named laws, there are many unwritten rules every engineer who’s been around for a while just knows. You learn them by breaking things and swearing you’ll never do it again.

As everybody and their mother thinks they can build great software right now, I decided to help them avoid a bit of pain.

Here are 7 laws every engineer has broken at least once, learned the hard way:

1. It’s always related - first roll back, then debug

2. Backups aren’t real until you’ve restored from them

3. You’ll always hate yourself for how you write logs

4. Always have a rollback plan. ALWAYS.

5. Every external dependency will fail

6. If there is ANY risk - “4 eyes” rule

7. There is nothing more lasting than a temporary fix

1. It’s always related - first roll back, then debug

I lost count of how many times production broke right after I deployed something, and my first instinct was: “That’s totally not related to what I touched.”

Someone pings me: “Hey, this incident might be related to your PR.” My answer: “No way. Completely different area.”

Surprise… It’s almost always related.

It took me embarrassingly long to learn that when production breaks and you recently deployed anything, you shouldn’t spend an hour proving your change is innocent... You should just roll back immediately, stabilize, and then figure out what happened.

Instead of proving it’s not the problem, it took me a while to learn we should just rollback any change, stabilize, and then debug.

2. Backups aren’t real until you’ve restored from them

This is the one engineers fail at the most.

How many of you have actually tried the restore option on your managed database? Not “I know it exists” - actually clicked through, watched it run, and confirmed your data came back as you expected?

Because aside from the fact that someone might have quietly turned backups off:

Just knowing the restore process is critical:

• Do you have incremental backups or only full snapshots at specific times? What’s the gap between them - how much data can you lose?

• Who has the permissions to trigger a restore? Is it just one person?

• Where exactly do you click? Do you know the steps or are you ChatGPTing it for the first time during an outage?

• How long does it take? Hours? Will your app be down the entire time?

And this isn’t a one-time exercise. Processes change, infrastructure changes, and your data keeps growing (meaning restores that used to take 10 minutes now take 2 hours).

Even if you have a DevOps team that handles infrastructure, if you have write access to a database, it’s your responsibility to know how to restore it.

Thanks Unblocked for supporting today’s article!

A new unwritten law for 2026: AI-generated code is only as good as your context.

We all know garbage in, garbage out. But that’s not the problem anymore - agents today can get context through rules, skills, and MCPs. Yet teams still waste tokens on code they must rework. One culprit is satisfaction of search: agents stop at the first answer, with no way to know if it’s the right one.

Instead of duct-taping it yourself, try Unblocked. They build your org’s context from across code, PRs, docs, conversations and runtime signals so AI tools understand how your team works. It connects identities across systems, resolves conflicts, respects permissions, and surfaces what matters for the task.

3. You’ll always hate yourself for how you write logs

No matter how many times I started a repo with the intention of writing perfect logs, when an incident happened, something was always missing (or my json dumps were parsed incorrectly, causing messy info that is barely searchable).

Cursor & Claude cause the opposite problem - too many super verbose and confusing logs.

It’s quite tricky to hit the balance of:

• Have all the needed info

• In a searchable way, with a shared request/task ID across services

• Without too much info to confuse you

4. Always have a rollback plan. ALWAYS.

No matter how small the migration or how minor the DB change seems - if you touch data, you need a quick, tested rollback plan.

Adding a column? Have a migration ready to remove it, and a PR to revert the related code changes. Inserting data? Be prepared to delete the exact rows you inserted. Deleting data? Copy it somewhere safe first. Changing a column type or constraint? Know exactly how to reverse it without data loss.

The keyword here is tested. A rollback plan you haven’t actually run has a 50/50 chance to break.

5. Every external dependency will fail

A couple of years ago, a 3rd party api ruined my weekend. We started consistently hitting their rate limits, getting 429 errors, which escalated into a 2-week-long mess.

As an engineer in a small company, adding an external API is so easy. You log in, get an API key, boom - works, problem solved. In a bigger company, you might go through some security process and maybe even some basic architecture review. But rarely does anyone ask: "What happens when this thing goes down?"

And even is they do, the default answer of “5 retries with exponential backoff” is usually enough. But if your system has a 99.9% SLA and you add a critical dependency on another system with 99.9% SLA, you will DOUBLE your downtime, from 8 to 17 yearly hours (unless you are both down anyway because AWS/Cloudflare is down…).

Took me a while (and that incident) to learn which questions to ask:

• What are the rate limits? What happens when you breach them? How are you notified?

• What will happen to our system if the API is completely down? Is a feature degraded, or is the whole app broken?

• Have we actually tested in production how our app behaves when this API is unavailable? (I had cases where we thought it’d impact a single feature, and it crashed the whole app as the call to the API was not where you would expect)

• Can we cache responses, queue requests, or serve stale data as a fallback?

• Do we know in advance what to communicate to users when it happens?

• Who’s the contact on their side when things go wrong, and what does their support SLA actually look like?

6. If there is ANY risk - “4 eyes” rule

A few years ago, I destroyed the company’s DB, after a very stupid mistake.

As managers, we often have stronger permissions than we should - root access, production consoles, DB access. And after multiple incidents I've caused (both as an engineer and as a manager), this rule is burned into my brain:

If I have ANY doubt whether what I'm about to do is 1000% safe, I ask someone to look at it with me. Four eyes are always better than two. And honestly, half the time you catch the mistake yourself just by explaining what you're about to do out loud.

What if it’s late at night or a weekend, and you don’t want to bother anyone? That's the strongest signal you shouldn't be doing anything dangerous by yourself…

7. There is nothing more lasting than a temporary fix

As any developer knows, when your PM says "we'll address this later," what they mean is "we'll never do it."

Priorities change. New projects are always shinier than maintaining existing infrastructure. The tech debt ticket keeps getting pushed to the next sprint, then the next quarter, and then gets buried in the backlog graveyard.

So many times I implemented V1/MVP of a project, just the bare bones of it, with tons of hacks, planning to improve things in V2. 90% of the cases, the time never arrived.

My approach slowly shifted into acknowledging it instead of fighting, as in some cases, it actually shows a good product culture. So now, I try to push for a minimal solution that I’m actually happy with. It doesn’t need to support future scale, or be super robust - just not be hacky.

There's a big difference between “this is simple and limited” and “this is held together with duct tape.”

Discover weekly

1. The hidden danger of shipping fast in . Super relevant article, many parts resonated.

2. How to debug a team that isn’t working: the Waterline Model by . Loved this model, I wish more managers would use it!

3. 2 more gems by (who slowly becomes a favorite newsletter writer of mine): The Myth of Never Giving Up and The Most Underrated Startup Skill Isn’t Hustle. It’s Curiosity.

In October, I started a new role as an Engineering Manager of an established team (7 strong engineers).

6 weeks ago, my wife gave birth to our second child.

I can't stop thinking about how different it all feels compared to my first time, both as a father and as a manager.

My take on both:

• Who’s responsible? ME?

• Can I actually do everything?

• It’s hard… just not as hard as people say

Who’s responsible? ME?

I remember the day we got back from the hospital the first time. We walked into the apartment, looked at the mirror in front of us, and laughed at each other (that kind of nervous laugh). It felt so absurd.

Now what? What do we do with this little thing?

And it doesn’t get easier. You make decisions that impact your kid’s life forever. You’re afraid to fuck them up, but don’t want to coddle them too much. Never feeling like you’re investing enough time, never involved enough.

My first management role, 8 years ago, felt very similar.

One day, I’m the one making the hard decisions. And I’m not talking about only the classical ones - what tech to choose, what timeframe to commit to. Those are hard, but the people problems are the ones we obsess about.

Giving tough feedback, fighting for promotions, dealing with our own difficult managers. Letting people go - people with families. A decision you make that has a huge impact on someone’s life.

I remember many days when I just wanted to crawl into a hole and become an engineer again.

The second time around, things are much better.

Yes, I’m the one responsible. Me, the 30-year-old who feels like high school was not that long ago.

But after years of responsibility, it doesn’t feel that absurd anymore. Dan seems to be growing up ok - he’ll go to a psychologist in 20 years anyway, they’ll figure it out together.

Same with managing my 3rd team. Yes, I’m the one responsible. Yes, I don’t know everything, and I might make wrong decisions. But I don’t need to make all the decisions — I have a team I trust.

Having tough conversations is still… tough. But I know I’m just doing my best, and I don’t beat myself up about it.

Thanks Linear for supporting today’s article!

Since I started using Linear, my toddler listens to me, my newborn sleeps 8 hours, and my wife says I’ve never been more attractive.

…None of that is true (well, hopefully the last one is). But in my new role I’m using Linear for the first time, and boy, it’s a pleasure. The only thing in my life right now that works exactly as expected - offloading so much of my mental load.

You don’t realize how much a bad project management tool drains you and your team until you use an amazing one. There’s a reason OpenAI, Brex, and thousands more already switched.

Seriously, no excuse. Free to try, unlimited people, painless switch. What are you waiting for?

Can I actually do everything?

For 23 years, I had just my career, friends, and a couple of hobbies. Plenty of time for everything I wanted.

Then came my first serious relationship. Slowly slowly (but then quite suddenly), not all your evenings are free, and you have less time for your friends. Still, very manageable.

Then I started some side projects. Weekends got a bit more packed.

I also decided I want to do a Triathlon, so tons of training. Mornings got busy.

By the time our first child was born, I had: career, wife, hobbies, side projects. I’d probably need 30 hours a day to do it all… How the hell am I supposed to do everything?

Initially, I went for “super-efficiency mode”. Every time my wife replaced me with the baby, I immediately went to the computer. No sense in both of us being with the kid at the same time, right? (spoiler: not right)

Took me a while to figure out the balance.

As a first time manager, it was similarly hectic. I was a developer just a minute ago, super passionate about the projects I was working on. Now, on top of coding, I had 4-5 hours (best case) of daily meetings, and the needs of 5 engineers to take care of. And of course, urgent incidents I had to deal with, and support requests that still kept coming my way.

The only solution seems to be working more. And more. And more. Until you figure out it’s an endless pit, and you cannot do everything.

Second time around, I know I’ll have to drop some balls, and I’m ok with it. As I started managing an existing team, it’s also easier to achieve - they know the job much better than I do.

The challenge this time is different - figuring out where I’m actually needed, and how to invest my time. How to be relevant, and not fall into the “slow death of the hands-on EM” trap. But I’m in no hurry, I know I’ll slowly prove myself. Yes, I work in the evenings now and then, but because I want to, not because I feel I must.

As a second-time father, I don’t even try to do everything.

• There’s less quality time with my wife - that’s ok, we know the first months are hard.

• I also stopped running for a while, without feeling any resentment. I’ll get back to it once things stabilize.

• Two days a week, I finish work early. I don’t open Slack during those hours, and never schedule meetings.

• I post much less on LinkedIn, and I’m ok with skipping some weeks with the newsletter.

But I’m NOT stopping my life. I’ll have long days at work now and then, and we have a babysitter as backup. During the kid naps on weekends, I use the time to work on my business instead of resting (a very hard decision to make repeatedly…).

I have a simple weekly system to figure out my capacity (both mentally and time-wise), and adjust. And even if I plan something for the week and I don’t manage to finish it - I just let it go (it may sound minor, but I hate not achieving goals I set for myself).

It’s hard… just not as hard as people say

I don’t know who complains more, parents or engineering managers.

I remember when I started my previous job, there were 2 guys there with a young kid each. They loved to complain. How your life is basically ruined, you don’t have time for anything, how they sacrifice so much, and so on and so on.

As someone who was expecting a child, it was scary. Society keeps telling you how difficult and sleepless it is, and you brace yourself for the worst.

It’s similar with management - you’ll read everywhere how it’s a “thankless job”, how lonely it is, how you’re pressured from above and below. Every other LinkedIn post is about burnout, about how nobody prepares you for the emotional toll, about how you lose your technical edge and gain nothing but stress.

In both cases, I really wanted to prove them wrong.

Of course being a father is hard. There were moments I thought I would never sleep again. (Dan’s first full night sleep was at 1 year 7 months. And as my wife doesn’t function well when she’s tired, it was mostly me.)

You have small moments of despair, feeling like a black cloud covers your life. No mental energy for anything.

As a first time manager, I had similar despair moments. A critical deadline is coming, you’re trying to do everything yourself, afraid to ask too much of your developers, can’t say no. A shitty day full of meetings where nothing got done, and you hate your life a bit. Why am I not a developer anymore? You go to sleep thinking about work, mentally exhausted.

But - and it’s a huge but! - those moments pass quickly. You learn to use your support system. My wife and I have a deal: if one of us feels close to the edge, they give a sign, and the other takes over, no matter what. An evening off, or a few hours of sleep during the night.

As an EM, you learn you have a whole team that can support you, as long as you stop being stubborn. I don’t think it’s thankless at all - there are lots of fun and proud moments.

The second time around, I don’t even have those despair moments. I know that Alon will grow up, he will sleep, and he’ll be the cutest kid ever. When I’m awake since 3 am and need to go to work I’m of course tired, but I know that by 7-8 I’ll feel ok.

Just knowing that every hard stretch will end, and that I have someone to lean on from day one - that’s enough to avoid those pitfalls.

Starting this EM job was a different story too. Yes, it was hectic, tons of people to meet, a lot of work to do, lots of things to learn.

But I was never once overwhelmed. I know my capacity, I know what I can do. I’m ok with not knowing things, with looking a bit dumb. I focus on what matters, and slowly get on board.

I’m happy to go to work every day. I feel much more centered. It’s so much harder to get me frustrated.

Final words

For me, the main difference between the first and second time is mental resilience.

One trick I developed is to do a weekly mental scanning of the 5 areas of my life I currently care the most about: marriage, family, career, body, and business/side projects. I try to diagnose what bothers me now, and if there is anything I can improve there. It helps me treat hidden frustrations and put efforts where it matters the most.

For all the EMs, parents, and EM-parents - every bad stretch passes :)

Discover weekly

1. A child psychologist’s guide to working with difficult adults by .

2. Will Money Ruin Your Kids? by . One of my major worries going ahead - how to raise non-spoiled kids while giving them full support.

3. My SaaS crossed $100K/year. I've never been more anxious by . I’ve met Orel a few years ago, before he quit his job. We even collaborated for a few months on a project that didn’t take off. Since day 1, he told me he’s sure anybody can succeed in a side business, and he’ll prove it. Took him almost 2 years(!) to reach the first dollar, and I’m so happy he actually proved his point.

Over drinks a few weeks ago, a friend told me he'd been offered a promotion, to an Engineering Manager role. He planned to decline it, but wanted to hear my take first.

Until recently, my answer in such conversations was always “100% go for it”. My logic was that it’s a super valuable experience, even if someone is not looking for the management career path. I told every engineer that a couple of years as an EM would teach them valuable skills, and they could always go back afterward.

This time, we had a long discussion about the tradeoffs, and I finally agreed with him that he should not take that step.

Here are the main arguments from our conversation:

Thanks Unblocked for supporting today’s article!

AI coding tools are fast, capable, and completely context-blind. Even with rules, skills, and MCP connections, they generate code that misses your conventions, ignores past decisions, and breaks patterns. You end up paying for that gap in rework and tokens.

Unblocked changes the economics.

It builds organizational context from your code, PR history, conversations, docs, and runtime signals. It maps relationships across systems, reconciles conflicting information, respects permissions, and surfaces what matters for the task at hand. Instead of guessing, agents operate with the same understanding as experienced engineers.

You can:

• Generate plans, code, and reviews that reflect how your system actually works

• Reduce costly retrieval loops and tool calls by providing better context up front

• Spend less time correcting outputs for code that should have been right in the first place

1. It’s a bad time to move away from tech

WTF is OpenClaw? I’ve been on paternity leave for a few weeks, and another completely new project exploded…

The pace of change in the last year has been completely crazy, and it’s not stopping.

But even if you don’t give in to the constant FOMO - it’s impossible to argue that the way we worked hasn’t changed. Almost every part of our work looks different, and will continue to evolve.

You've probably seen this tweet - the creator of Claude Code answering why Anthropic still needs software engineers:

My friend was afraid that as a manager, he'd have less time to experiment and adapt. Especailly with a bigger team (he was offered to manage 6), you don’t have much time to play around.

I could definitely relate to his fear. There are so many ideas I want to work on, tech I want to play with, and so little time to actually do it.

2. The ladder is very competitive

The classic EM ladder used to look like: EM → Senior EM → Director → VP.

But companies have been flattening for two years now. Amazon increased its IC-to-manager ratio by 15%, and other companies followed.

This means there are fewer Director and VP roles to grow into (and much less Senior EM ones). You can be a great EM for years and find yourself stuck.

Companies still need someone to run teams, but from Senior EM upward, it becomes much more competitive. You’re competing with experienced leaders who were laid off from those ‘flattened’ companies.

Also, there is less opportunity for internal growth. As an EM, to get promoted, you mostly need to start managing more engineers, which might not be possible right now. It’s more likely you’ll just get bigger scope with the same team - not a feat worthy of promotion.

As an IC, being excellent at building things can get you much further.

3. The pay is lower

While my friend was offered a bump with the promotion to EM, the total compensation was less than the offers he received for Senior/Staff Engineer at other startups.

This surprised him. The assumption has always been that management pays more. It does, if you compare an EM to a Senior Engineer at the same company. But when you compare across the industry, being a Staff engineer is better paid. I believe it’s because those engineers are in huge demand (and will continue to be so).

For my friend specifically, staying on the IC track, becoming a Staff engineer and switching companies would have given him ~20-30% more than the EM promotion he was offered.

So why am I still an EM

2 reasons:

First of all, I’m very optimistic about experienced Engineering Managers (who stayed hands-on), as I wrote in Engineering Management in the Age of Agents.

While we are probably less sharp tech-wise, there are tons of relevant skills the job taught us over the years, that will still be relevant.

And while it’s hard, I think I’ll manage to keep up.

But the main reason is that I enjoy my job.

While rationally I believe that being an IC is a smarter choice in 2026, I know I would enjoy it less.

wrote a great article about what to do when the ladder disappears, to help you figure out where you should aim. I highly recommend the exercise there!

Final words

If you are a senior engineer, the bottom line is that I wouldn’t recommend the jump to management right now. I would wait a couple of years to see how things will look like.

BUT, and it’s a big but - if your gut tells you to do it (and not your brain), if it’s truly a path you want to pursue - then go for it!

Discover weekly

1. Even fewer middle managers and more flexible teams? by . I love Gergely’s weekly Pulse (I’m a paid subscriber), this one was especially interesting.

2. Being an architect isn’t the sum of skills. It’s the product by Gregor Hohpe.

3. The Product Velocity Paradox: When Your Engineers Outrun Your Product Team? by Sahar Carmel. An interesting article on the current reality in many companies.

“Aaaand... merge.”

Finally. Three hours on that stupid memory leak. I stretch and look around. Empty office, again.

A notification pops up:

+20 XP (Debugging)

Just twenty damn experience points. I still remember my excitement when fixing my first memory leak gave me 500. I was sure I’d reach staff by 25.

I grab my things and head out.

I turned 30 this year. Nine years already since I graduated college.

The first three were pretty amazing. Everything was new, the XP just flowed in.

And then I hit the wall.

I’ve been stuck at Senior Engineer for six years.

I pull up my stats while waiting for the elevator:

Thanks Linear for supporting today’s article!

Here’s the team version of the XP trap: sticking with a project management tool everyone hates because switching feels hard.

You know the symptoms: Engineers don’t update tickets, PMs chase people on Slack, work is invisible until someone asks about it in standup.

Teams that switch to Linear see the difference immediately:

• 5x more teammates create issues - Linear makes it easy for anyone to submit feedback or report bugs through Slack, email, or support tools

• 90% more issues logged - Engineers actually track their work because it takes seconds. The work that was always happening becomes visible

• Issues resolved 3.3x faster - From bug identification to feature shipment, teams move at higher velocity

Linear’s switch campaign runs through February. 2-way sync keeps your legacy tool updated while you try it, no big bang migration required:

The way leveling works is simple. Eight skills, four primary and four support. You grind XP, your skills level up, and your general level follows.

Junior to Mid takes about 10,000 points per skill. Mid to Senior is 100,000. Senior to Staff is a million.

Staff is where most people get stuck. You need your primary at a million, six others at Senior, and you’re allowed one stuck at Mid.

That wouldn’t be so bad if not for the fact that XP for doing the same task keeps shrinking, in parallel with the requirements getting harder. That’s so unfair.

Twenty points. Toward a million.

The drive home is quiet. Rush hour ended hours ago.

Somewhere along the way I convinced myself that reaching Staff level would fix everything. It's not rational, but I can't shake it. Better salary, letting me send more to my family. Finally buy a small apartment. Dates would go better. I’d finally be set for life.

917,200 out of 1,000,000.

It feels so close, just 83k points to go. But when I do the math (which I do every day), it’s still 10 years at the current pace.

I’ll be 40.

I scroll my phone in bed, not really looking at anything.

I never wanted to be a job hopper. I watched my friends leave every two years and thought they were doing it wrong - always starting over, never building real depth.

That wasn’t going to be me. I wanted to build deep expertise.

And it worked, sort of. Whenever something breaks in a way nobody understands, it ends up on my desk. The debugging guy. I like that. I’m great at it.

Just took me six years to notice it stopped teaching me anything.

I put the phone down and stare at the ceiling. Sleep doesn’t come for a long time.

The endless grind

Ok, back to (a much happier) reality.

In the last couple of months, I got addicted to reading the LitRPG genre. It’s a fiction genre that blends fantasy/sci-fi with video game mechanics, introducing elements like levels, stats (Strength, Intelligence), quests, and experience points (XP).

It got me thinking:

What if our software engineering careers were like a game? If we could quantify our experience based on something that is not just years on the resume?

In an RPG, the first levels are pretty easy. You kill some low-level monsters and progress quickly.

Slowly, those same monsters are not challenging enough. The XP you get barely moves the needle. You have to push yourself, going to more dangerous areas, fighting monsters closer to your level (or ideally, a bit higher).

It works as the “Zone of Proximal Development”, which is the sweet spot for progression (although that one talks about mentoring as a way to help others progress)

Tackling challenges that are too hard is just a recipe for failure (and for losing confidence in yourself).

But doing the same things all over again leads to stagnation.

It doesn’t mean you need to switch companies - in most cases, you’ll have a lot of internal opportunities. The problem is that those opportunities don’t just arrive out of nowhere.

Games are addictive because of the constant progression and growth.What if YOU as a manager, spent more effort to adjust the game difficult for your team? One of the biggest challenges of our job is to balance the needs of the company and the needs of our engineers, and finding growth opportunities is at the crux of it.

From what I’ve seen, most engineers will just leave if they keep doing the ‘known’ parts again and again, building feature after feature, with the same tech stack, serving the same scale.

If your engineers were characters in an RPG, what skills would they want to level up? In what areas are they stuck grinding? What can you do to help?

Final words

If you love reading fantasy, I highly recommend trying out the LitRPG genre, it’s pretty addictive.

Here are my recommendations:

1. Dungeon Crawler Carl - start with this one.

2. The Completionist Chronicles Series

3. All the skills - a deck building one!

4. He who fights with monsters

5. Chaos Seeds Series

6. Jake’s magical market

7. Defiance of the fall - currently reading, great so far!

I’d love any other recommendations! (Didn’t Dungeon Born, The Primal Hunter, and a couple of others).

I love Slack. And I also hate it.

It’s definitely better than any alternative (yes, I’ve had the misfortune to use Microsoft Teams).

Still, we spend an average of 2 hours a day on Slack. A big percentage of that time is spent scrolling, rereading the same messages, and trying to keep up with countless channels and threads (seriously, why isn’t there an easy way to browse threads??).

This creates an endless loop:

• People don’t get the answers they need

• They schedule meetings

• Which leaves us even less time to respond on Slack

Async communication is hard, I don’t think it’s a ‘solvable’ problem - there will always be friction.

I believe that not enough Engineering Managers spend time on optimizing their async communication environments.

Today, I hope to cover simple tips on how I try to use Slack more effectively, hopefully saving you tens of hours a year (and reducing your mental load).

If you use another tool - try to find similar tricks!

1. Unreads conversations only

A good first step is to reduce the noise. In every category (like channels/direct messages), you can choose to see only the unread channels by clicking the 3 dots and tweaking this setting:

The upside: less scrolling time, and less noise on the screen. You can clearly see where you have unread messages.

There’s also no real downside - you can easily access the channels by clicking the 3 dots, or pressing ctrl + k and searching for the channel name.

2. Categories

The next step is to categorize your channels and conversations by groups. My recommendation is to create a group for the people you talk to on a day-to-day basis, and to group your channels based on reading priority (you’ll see in the next section why it’s useful).

You can of course choose a different way - the point though is to choose something that is useful, not just makes sense. If you group the channels by topics - does it help you operate better?

Note that you can also move apps and external categories (and not just leave them in the default groups!). For example, I want to see GitHub notifications in the read-immediately group (to not be a blocker for PRs). For other external apps, I’ll user read-daily or even read-weekly.

3. Mute/unmute groups

Every channel has a different reading cadence.

For example, alerts: if you are a hotfixer, you need to read them ASAP. If not, you might want to read them weekly to stay in touch. Same for project-related channels: if it’s a project you are leading, you might want to read it immediately (to unblock someone else). If it’s more of an FYI, a daily or even weekly reading is enough.

The huge power of muting a group is that you can unmute it, and have it returned to the exact same place:

I’m mainly using this method for read-weekly. Every Friday, I have a scheduled 15-minute meeting to browse them. I unmute, read them, and mute again.

This way I don’t even think about them for most of the week.

4. Escape from threads

Someone tagged you in a noisy thread and it keeps distracting you? You can turn of the notifications:

5. Message reminders

The problem with keeping messages ‘unread’ is that it can become very confusing. Additional messages might be written in the same conversation, causing the original message to be ‘lost’. Also, it creates mental noise. Slack has a powerful ‘remind me’ feature (by clicking the 3 dots on a message):

I like to set reminders for next day 9am for non-urgent messages - letting me answer them quietly with the morning coffee.

 6. /remind

Let’s imagine you worked on something, and suddenly remembered you wanted to send a message to someone. You can write in any slack channel (nobody will see it):

“/remind me to send a message to Jack tomorrow at 12:00”.

You can also send a reminder in a specific channel (by default, if you don’t add one, it’ll send the reminder to you):

“/remind #channel-name to go over the messages on Wednesday morning”

The format is:

/remind [#channel] “[what]” [when]

It’s pretty robust, understanding human language pretty well.

 7. Edit all sections

To start organizing your Slack, the easiest way is to enter ‘edit mode’, by clicking ‘edit all sections’:

You can organize everything in less than 15 minutes :)

Final words

As managers, Slack is our main tool to get things done. Most of us spend more time in Slack than in our IDEs.

I believe it’s worth being intentional about it - spending the time to constantly improve your processes. Those small changes accumlate benefit throughout the years.

Discover weekly

• I’m Going to Dig a Hole - beautiful piece on supporting others without judgment.

• Stop Asking for a Mentor and You’re interviewing Backwards by . I first found his newsletter after reading ‘That Will Never Work’ (his view on founding Netflix), and I really enjoy his newsletter!

• Growth Is Now a Trust Problem by . I believe EMs will get closer and closer to the product (and growth) side - and Elena’s writing is a terrific resource on it.