Thanks Unblocked for supporting today’s article!
"You're absolutely right, I shouldn't have done that." If you've spent more than ten minutes babysitting your coding agent, you know the frustration. It writes code that compiles, but ignores decisions your team made months ago.
Here's why: every agent you spawn in a terminal is like a new hire on Day 1. Technically sharp(ish), but with no idea how anything at your company actually works. So you burn review cycles, time, and tokens teaching it what it should have known.
Instead of connecting a dozen MCPs and hoping your agent knows which to call for each task, you can use Unblocked to give agents the organizational knowledge synthesized from your WHOLE stack. Their customers like Codat see 30% more PR throughput and a 92 NPS from the engineers.
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 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.
I hope today’s article will help you avoid a similar fate.
If you are an EM in your first couple of roles, I also wrote an article about why first time engineering managers get stuck.
1. Mistake title for impact
Titles are arbitrary social constructs that only make sense in the context they’re given. Titles don’t translate across companies meaningfully, and they’re a deeply flawed way to judge yourself or others.
I was very proud of that director title.
In reality, I managed ~10 engineers (8 most of them time) split into 2 teams. That's barely the scope for an Engineering Manager role in most companies.
A year later, I quit to build a startup. After failing, and looking for another job, it became clear there was no way I would land a director role. Looking back, that title was meaningless. I just spent an 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 at an EM role, which I’m currently very satisfied with.
Peter Bailis’ and Mike Krieger’s journeys are great recent examples of not caring about titles:
2. Mistake team size for impact
Managing a larger team is not a better job, it’s a different job. It also won’t make you important or make you happier. It’s hard to unlearn a fixation on team size, but if you can, it’ll change your career for the better.
For years, the main way to get promoted was to manage more people.
But today, it’s purely about impact. When you manage more people, they can achieve bigger things, but you personally have less time to be involved.
3. Do what worked at your previous company
When you start a new job or new role, it’s important to pause to listen and foster awareness before you start “fixing” everything. Otherwise, you’re fixing problems that may not exist, and doing so with tools that may not be appropriate. Spend too much time building relationships. This is particularly common in managers coming from larger companies into smaller ones, and it creates the perception that the manager isn’t contributing anything of value.
When I started at HoneyBook, my instinct was to dive deep into the code. In my previous role I was a developer before I got promoted, and I couldn't imagine how to lead without deeply understanding the technical side.
It wasn't the right decision, as it wasn't what the team needed.
4. Abscond rather than delegate
Delegation is important, but it’s easy to go too far and ignore the critical responsibilities that you’ve asked others to take on, only to discover an easily averted disaster later on. Become disconnected from ground truth. Particularly at larger companies, it can become frequent to make decisions that appear to be fundamentally disconnected from reality.
A few weeks back, an engineer gave some great feedback:
"Anton, I appreciate your trust in me, but sometimes I just need your advice. When I ping you for a question and your answer is 'whatever you think, I trust you', it's not helpful at all. I pinged you for a reason, and I need you involved deeper so I could brainstorm with you."
There's a version of trust that's actually you still being involved.
5. Confuse authority with truth
Authority lets you get away with weak arguments and poor justifications, but it’s a pretty expensive way to work with people, because they’ll eventually turn off their minds and simply follow orders—if they’re in a complicated compensation or life situation, that is. Otherwise, they’ll just leave.
A few years ago, a senior engineering leader who hadn't been in touch with coding (or any tech work) overrode a technical decision I made. I still remember the frustration.
Of course, sometimes the manager need to make the final call. My guideline: the more disagreement there is, the better I need to understand all sides of the decision, to make sure I'm not missing anything.
6. Don’t trust the team enough to delegate
You can’t scale your impact or engage your team if you don’t give them enough room to do things differently than you would. Many organizations become bottlenecked on approvals, which is a sure proxy for lack of trust.
Let other people manage their time. Most managers have significantly more work they could be doing than they’re able to do. This will probably be your status quo for the rest of your career, and it’s important to prioritize your time on important things, and not simply on whatever happens to end up on your calendar.
Well said 👌
7. Only see the problems
It can be easy to only see what’s going wrong, and forget to celebrate the good stuff. Down this path lie frustration and madness.
This is the manager who only tells you what you need to improve, and never gives compliments.
This doesn't come naturally to me. I don't compliment people much. I was told this in a feedback talk too, an engineer said she'd appreciate knowing what she does well, not only what she needs to improve.
Same with your own manager. If you complain in every 1:1 and never mention what works or what you appreciate, you'll get a name as a complainer.
My favorite reads of the week
Don't Stack Weaknesses. What happens when you and your manager have similar weaknesses.
WTF are loops, why is everyone arguing about them, and why do they actually matter? Another great read from PostHog. The only use case we were able to execute so far is migrating tests infra.
Why the best organisations write to decide, not just to document. The world is suffering from text-pollution. Have a great writing culture (where other people will actually read what you right) is crucial.
