If I could only reread 5 books for the rest of my career as an Engineering Manager, I'd choose:
1. Become an Effective Software Engineering Manager - @jstanier (2020)
If you read one, make it this one :)
Covers almost everything you need to know, at every level.
2. An Elegant Puzzle - @Lethain (2019)
Deep and practical, with real examples from his career. No surface-level tips.
3. The Manager's Path - Camille Fournier (2017)
More basic, but covers the whole ladder: tech lead to CTO.
4. Peopleware - DeMarco & Lister (1987)
40 years old, and still super relevant!
It's where "jelled teams" comes from, a concept I really believe in.
5. Extreme Programming Explained - @KentBeck (1999)
5 values, 14 principles, 26 practices. Most of them are truer than ever, even in our crazy AI world. It's not really about management, but it actually is.
I limited myself to 5 per category, and did the same for articles, newsletters, and podcast episodes.
The full list:
https://t.co/Y3jhnO8od7
Man, I really like your crusade. So satisfying to see all those ‘blocked’ comments.
And really appreciate the packages for everyone, definitely not trivial :)
That requirement of using zero AI was quite hard, especially for the length required. I’m used to dictating my thoughts and then Claude organizing them a bit, or helping me by asking some questions, etc. complying required zero of that too, and to actually type 5k words (in my case).
But it was very satisfying when pressing submit, like I earned the right to press that button :)
Anyway, great competition, and thanks for raising the bar on engineering writing quality! Very much needed
12 things I miss since coding died https://t.co/4Qf1iNZ8pR < I miss that rush of making something work after hours of labor, or finding that obscure issue and resolving it. @AntonZaides calls out other areas of satisfaction that don't hit the same way with AI.
Your team is exhausted after 3 long weeks of work for the new release. The codebase is a complete mess, as you had to cut many corners to make it on time.
The feature gate was opened only for 5% of users, but you already got some complaints, and a bug had a severe impact on one customer’s business. This quarter’s deadline is in a week, and to hit your objective, you need to open the feature for everyone ASAP.
What bothers you the most in the paragraph above?
What would you fight for?
Some EMs will fight for their team (Umbrella)
Some for the codebase (Gatekeeper)
Some for the users (Crusader)
And some for the business goal (General)
That's the 4 archetypes of EMs I've seen the most often.
Here's a bit more detailed article about it:
https://t.co/11e97Ujo06
Which one are you? :)
In my opinion, it's the 'broken codebase' problem of coding with agents.
So you have code that feels ok, but you don't review it thorougly, and you merge it. Maybe a minor bug that you caught and fixed, but the code is there.
Now, new agents treat that ok-ish code as golden truth - and write even worse code.
We can see it with antrophic too - claude code is much more painful to use. No matter what I do, I can't make it write less verbose comments. Sometimes it's 60(!) lines of comment.
They might have done it in purpose, to waste tokens, but I think there own speed is biting them in the ass.
I don't think it's a coincidence that 3 months after Meta laid off 700 engineering managers, it's facing a serious resignation wave:
Every time I read about another company laying off managers and ‘running flatter’, I think about how absurd it is.
I can’t understand why senior leaders don’t see the harm they inflict on their own companies.
This trend of getting rid of managers has been tried before, by multiple companies:
In 2002, when Google had ~300 engineers, Larry Page and Sergey Brin tried to completely remove all managers. It failed after just a couple of months:
“They relented when too many people went directly to Page with questions about expense reports, interpersonal conflict, and other nitty-gritty issues. And as the company grew, the founders soon realized that managers contributed in many other, important ways - for instance, by communicating strategy, helping employees prioritize project, facilitating collaboration, supporting career development, and ensuring that processes and systems algiend with company goals" (hbr article: https://t.co/DOYUmF3ajp)
It's trendy today to treat managers as a 'necessary evil', needless layers that AI can replace.
But when you expand an EM’s role to both be more technical and have more reports (by laying off their peers), something has to give.
You are basically saying that all the 'people' side doesn't matter.
And then what happens is that companies start to accumulate relational debt - strained, neglected, or transactional relationships where trust and psychological safety erode.
There’s more negative behavior turning into toxic behavior, more conflicts, and less collaboration.
Yeah, you can run ‘flat’ for a while.
It takes a few months or years before companies experience the impact and the pendulum begins to swing back.
@suzanbond wrote a great guest article in https://t.co/jO6PPkc0Nh on the topic!
https://t.co/7F8pQslvmx
P.S.: I don't think Meta's problems are just because of laying off managers, they are many bad decisions in the mix. Worth reading @GergelyOrosz's article about it: https://t.co/MFeWAmfNLa
@mercury@dhh haha thanks :)
Been using you since day one of https://t.co/qtnILXiKSg, from 0 to $8k/month now!
The best banking experience of my life :)
@GergelyOrosz Even when there is code review, I see very often it's Claude's talking with each other..
Each dev just send their claude to the PRs.
Quite a mess