u/zaidesanton

In my first couple of years as an engineering manager, I took my PM’s word as given. They told me what to do, and I made sure the team did it. Nothing felt weird about it - they know the customers better, they understand the product better, and they have good ideas, right?

It took a few terrible calls by the PMs before I stopped working that way. Once I got into the details, I understood that in many cases product management is broken. So I slowly started to involve myself and my engineers on the product side.

For me, it was about 3 main things:

1. Be much closer to the data and metrics
2. watching user sessions and discovery calls
3. Actually talking with customers

I feel that even though it's not strictly my job, when the PMs are getting 'free rein', bad decisions are made.

I'm really curious if other EMs feel the same, and how did you get involved in those areas.

I feel one of the worst causes for bad AI-related moves (like counting tokens, doing 'transformations', mass layoffs because AI will replace engineers, etc) are senior ENGINEERING leaders.

I mean, I can understand the CEO getting swept by all the hype on Twitter and LinkedIn, but a CTO/VP should be the one to stop them, as they understand the reality.

But what happens is that EMs at various levels, who stopped doing any meaningful hands-on work, have false views on what's possible.

I always believed every engineering managers, at any level, should spend at least some time doing actual work - similar as I'd expect a sales leader to still do sales calls, and a customer support leader to handle support cases now and then.

I know many people didn't agree with me, and I could see the other side (you have higher leverage in non-coding tasks, improving the whole team and company), but I feel that this debate is completely over.

And it's not about 'being able to do more with AI, freeing you to code'. I'm a first-line EM, and I feel that to actually support my team and understand what's going on, I just have to experience the same challenges as they do.

Otherwise, it's to easy to drop directive such as 'you should parallelize more', or 'we all need to manage swarms of agents'.

Curious if other EMs feel the same, or do you code just because it's expected from you? (or you somehow manage to not code and keep your job)

I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?”

To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly.

A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?”

Huh.

I’ve been struggling to explain this, until I almost bought a house. Shared in the article why I feel the analogy works well.

Curious to hear how other EMs approach this difficult explanation to non-engineering stakeholders.

For 15 years in tech (and especially in 7 years of managing teams), I heard the same argument again and again: "Let's just ship it quick and dirty" vs "We need to build things properly". It was mostly PMs vs engineers, but sometimes also PMs vs PMs and often devs vs devs.

Somewhere in 2023-4, the fight started to escalate, as the builders discovered guns (aka LLMs).

On one side, you have the builders. Those are the engineers who get their dopamine hits from customers and the usage of the product they build. A refactor without any customer impact doesn't excite them.

On the other side, you have the keepers. Those are the engineers who enjoy writing well-built systems, purely for the technical challenge. They hate sloppy code.

There is no clear division, but every single person reading this leans a bit more toward one side.

In politics, 90% of people lean either left or right. When you meet someone holding an 'opposite' view, most likely you'll both end up frustrated and angry. "How come they don't get it??"

But what happens when you meet someone from the "same side", but much more extreme than you? Suddenly, they might label YOU as the 'wrong' side, because your opinions are not extreme enough.

So your political orientation is not just about your opinions, but where they land in relation to others. Same with builders vs keepers.

Shared my full take in the article, curious to know how people resolve those fights.

Back in August, during a job interview, the interviewer asked me how many people I managed in my last Director role:

"So it was around 10, in 2 teams, but I did many other things too, and bla bla bla”

I felt the need to apologize for that empty title.

Four years before that, I read An Elegant Puzzle by Will Larson. He had a specific section about why experienced EMs get stuck, and trap number one was “mistaking title for impact”.

Looking back, I’ve fallen into most of the traps, even after being aware of them:

1. Mistake title for impact
2. Mistake team size for impact
3. Do what worked at your previous company
4. Abscond rather than delegate
5. Confuse authority with truth
6. Don’t trust the team enough to delegate
7. Only see the problems

Looking back, that title was meaningless. I just spent a year doing boring work and being out of touch with engineering.

Nobody really cares about your past titles, only about the scope and impact involved.

I ended up back in an EM role, which I’m currently very satisfied with.

The last 2 years have felt like every company on earth just tries to run as fast as it can.

The problem in my opinion is that running a software company is much closer to a marathon than a sprint.

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. (Last April 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.)

I've been training with a running 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.

I believe that 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.

Does anyone share my feelings?

I feel one of our most critical jobs as EMs is to somehow slow down that pace without being seen as 'AI skeptics', just so we'll be able to run faster in future.

Code review became a real pain in the ass for us.

Non-engineers vibe-coding and expecting you to review and fix their mess, and capable engineers producing more code than ever..

More code means more reviews, more context switches, less patience, and more shitty code slipping through. This results in more bugs, conflicting standards, confused LLMs, slower dev speed.

Last month, a staff engineer at my company took a genius but simple approach to improve the situation, but using the thousands of existing PR comments in github history.

Here's the open source repo, and in the article we shared together how you can easily do it for your own team.

This approach of course doesn't solve 100% of our code review problem. LLMs are good at basic patterns, but the most useful code reviews challenge the actual decisions made, not just implementation details.

Still, even catching basic patterns helped reduce the cognitive load on reviewers, leaving more of it to focus on bigger issues (as all the basic things are caught before the PR is reviewed by another human).

Curious to hear how other teams deal with this problem (and please don't tell me to stop doing code reviews. I care about production quality).

something that started to happen to me quite a lot recently:

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

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

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

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

This can drive me crazy. My take is that YOU wrote this, Claude is just a tool.

Shared my full take in the article

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

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

Signs of a Jelled Team

A few very characteristic signs indicate that you have got a jelled team:

• There is a feeling of joint ownership of the product built by the jelled team. Participants are pleased to have their names grouped together on a product or a part of one.
• There is low turnover during projects and in the middle of well-defined tasks. The team members aren’t going anywhere till the work is done.
• There is a sense of eliteness*, team members feel they’re part of something unique. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren’t part of the group.*
• The final sign of a jelled team is the obvious enjoyment that people take in their work*. Jelled teams just feel healthy. The interactions are easy and confident and warm.*

You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling - but you can’t make it happen. The process is much too fragile to be controlled.

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

Here are the 7 differences I noticed. Sorry for the short-but-meaningless-titles, I have a deeper take in the article (linked above):

1. Okay teams patch. Excellent teams know when to fix the root cause.
2. In okay teams engineers DO things. In excellent teams engineers OWN things.
3. Okay teams unblock themselves. Excellent teams unblock others first.
4. Okay teams execute the roadmap. Excellent teams shape it.
5. Okay teams stick to the plan. Excellent teams are willing to kill it.
6. Okay teams launch features. Excellent teams land them.
7. Okay teams treat tech debt as a 20% tax. Excellent teams treat it as product work.

Curious to know what are the small behavioral differences you've seen in the teams you were most excited to work with.

Until 4 years ago, I believed there was no such thing as "too much responsbility". Then, I took a full month of vacation, and I needed to decide who will take my place for that time.

My team was relatively junior, and my manager thought it should be either he or a peer EM.

I disagreed - I felt it was a great growth opportunity, and I trusted my team. So I picked one of the junior engineers to take my place.

The result was... Not very good. The team was in chaos, The junior's confidence in himself really dropped, and my manager was not happy at all.

I always judged such situations by the "what would I have wanted in their place" exam - I was always liked to be thrown into the deep water and figure things out.

Think then I'm much more careful (and probably err on the side of not giving enough responsibility).

Curious: when you have an opportunity to give someone a big responsibility, but you're not sure they're ready for it, do you take the risk? Or do you usually play it safe?

btw - I asked that junior engineer, and he said he was fully ready, so I don't think a pure discussion is the solution.

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).

Here's a case that happened to me a couple of 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.

It's not just about layoffs - it's about saying no to requests, denying promotion, making hard decisions.

But maybe I'm the only one who struggles with it 😅

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).

Here's a case that happened to me a couple of 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.

It's not just about layoffs - it's about saying no to requests, denying promotion, making hard decisions.

But maybe I'm the only one who struggles with it 😅

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.

I shared in the articles my expriences with trying to deal with it :)