A reading list for new engineering managers
jacobian.org
jacobian.org
The best engineering managers I've met were simply brilliant engineers, that inspired devs around them and starting managing without having the official tittle: folks would naturally come to them for guidance. The hardest part was to get them to accept that the scope of what they were working on simply went beyond one human's ability to code it himself. But I've seen them break out debuggers and debug issues right in the middle of meetings.
On the other hand, I've met handful of "career managers" that weren't qualified as engineers and, well, frankly they didn't understand the engineering and got no respect out of the organization. No wonder Nadella, Pichai and Cook are all engineers.
What ex-engineer managers had was respect for the craft itself. You can respect the work of the team without doing it in the past.
It's more than respect for the craft, it's understanding the problem space.
[0] https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
That was a funny read, thanks.
Reality is not always equals to expectations
Those are ICs who are forced to take management roles for compensation increases.
The best managers haven’t coded in a long time and instead grew their management skills.
A manager who can't deeply understand what their team is doing has no business overseeing any work they do. They could be replaced with a non-technical BA who can do one-on-ones and approve vacations. The only way to deeply understand the work is to do it daily.
A hands-off engineering manager instantly starts to lose value as their skills degrade rapidly.
A hands off engineering manager is like an editor-in-chief of a newspaper who doesn't think they should have to read and write to be "an effective leader". That is the absurdity of an engineering manager who "stops coding to focus on management."
The idea that management is some higher calling beyond lowly technical skills is marketing sold by business schools to justify minting graduates completely unprepared for real leadership. It's a salve to tell their students it's ok they aren't willing to put in the hard work to become technical experts. I can't tell you how many former CS majors who, after switching to business, laughed that they'd be my boss one day, only to find themselves doing retail and office work while I was an becoming an engineering director.
You’re simply conflating project/product managers with engineering managers. The very best and highest compensated engineering managers do not code anymore and are excellent at managing people and making them productive.
An editor in chief who stops reading and writing to focus on "managing" a bunch of writers cannot effectively know which ones are producing poor work, other than by asking the rest of the writers in a Survivor-style "who gets voted off" competition.
Many times in my management career I've seen engineers who weren't really very well liked be my best performers, but I only knew that because I could actually understand exactly what they were doing and why. They weren't liked because they made everyone else look bad. Had I been code illiterate (a process that takes maybe five years, tops) my only option would have been to listen to the rest of the team and push them out. And this isn't about lines of code, or tickets finished, so it can't be easily measured with Jira.
If an engineering manager is spending so much time "managing" that they cannot write code to stay current then they are in crises: either inherited, self made as job security, or just lack of skill.
I honestly think this is a luxury for a lot of companies that are trying to transform themselves into a tech company.
When I took time off from my first failed startup attempt, I ended up working for a fintech and it was obvious that a lot of the "tech managers" were not technical people themselves. The challenge for this fintech, which had close to 1 trillion dollars in assets, is they couldn't really attract engineering managers and they had to make do with the people they had.
This is why "engineering metrics" is currently gaining a lot of steam. A lot of managers and organizations are suddenly finding themselves having to manage techies and they are desperately looking for ways to compensate for the fact that they aren't tech people themselves. This is why when companies see solutions like GitPrime, GitHub Insights, and other similar solutions, they get very excited because they feel they found that magical translator that can help them better manage tech employees.
How comes?
> A lot of managers and organizations are suddenly finding themselves having to manage techies and they are desperately looking for ways to compensate for the fact that they aren't tech people themselves.
There are now MBAs that are tailored specially for that [0]. If people think they can just eyeball it with "Engineering metrics", they should read this [1].
[0] https://cs.stanford.edu/academics/joint-degree-programs/join...
[1] https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Politics, workers rights and so forth. You really can't just fire hundreds and potentially thousands of employees without cause. A lot of companies will have to provide a career path for many of these managers.
> If people think they can just eyeball it with "Engineering metrics", they should read this
I think we both know this, along with many people here at HN, but HN doesn't reflect what I've personally seen. I'm trying to advocate for "Developer First Software Metrics", which is what my tool is focused on, but I've had far too many conversations with potential customers that wants to sum up a developers worth with a simple chart.
In the business world, we don't assume business intelligence will come easy, which is why we hire business intelligence specialist. However for engineering metrics, this attitude isn't quite there yet and many and I mean many companies with non-traditional tech backgrounds want to believe they can easily quantify a developers worth with superficial metrics. Because in a lot of ways, they see developers like factory workers, where their unit of work can be easily quantified.
If you promote people based on metrics from GitHub Insights you will end up with an awful organization. Employees are not stupid, they can manipulate any metric you use to measure their performance.
For example, if you promote the engineers that get the most commits, then people will conspire to delay code reviews so that only their friends get their commits merged in a timely manner. Or they will break their deliverables into an absurd amount of commits so that they get credited with the most commits.
> I honestly think this is a luxury for a lot of companies
No, it's not. The real luxury is hiring entire teams of capable people and then ask someone that has no clue about what's going on to tell them what to do. Not only it's a waste of time for every engineer, it's a waste of time for the engineers families and the education system that made their formation possible.
Learning about differential and integral calculus, differential equations, mechanics, electromagnetism, thermodynamics, discrete mathematics, theory of computation, compilers, databases, programming languages, data structures and algorithms, cryptography, information security, operating systems, networking, how to make a computer from scratch from logic gates, etc... only so that in the end you have to talk to a completely clueless guy that has no qualifications whatsoever but has "managerial soft skills" (psychopathic traits).
I've seen this. 90% of the time, the company loses a good engineer and trades him for a mediocre manager. It's a lose-lose situation.
Nowadays, managers are focused on 1on1s. Totally useless.
But that doesn't seem fair, yes brilliant people will always be good, you can't count on having brilliant people
Improving the organisational system so that the individuals can effectively do their job is an important activity. This requires collecting reasonable information to feed into developing your hypotheses on how to improve the system. This I feel is management.
Ensure that the individual team members can understand how they are contributing the overall company aim, feel motivate to learn and work, and generally understand how they are fitting into the organisational system is leadership.
There is an exception when an individual has deviated strongly from your average team member and that requires case by case analysis.
The distinction might seem a little pedantic and I'm continually evaluating my perspective on leadership but I do feel there is reason to make some distinction and that it might avoid some of the pitfalls of leadership such as micro management and individual demotivation.
Management of people requires a very empathetic, highly personalized approach. It's really all about motivation and the levers you can use are not always in line with the company objectives. High performance companies and teams are usually the ones that can find a way to sync up the people objectives with the company objectives for a long enough time to deliver products and services into a marketplace.
Meanwhile, organizational management is much more of a systems thinking approach that requires classical engineering skills. It requires technical and domain expertise plus intimate knowledge of the existing practices, processes, and environments.
Which makes sense as to why most managers in the software development field fail. They know the organizational side of things well but the people side is overlooked. And now the spectrum is swinging towards people managers without the requisite organizational skills and we're left with a new set of problems.
Technology Specific:
* An Elegant Puzzle: Systems of Engineering Management (Will Larson)
* Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Teams (Nicole Forsgren, Jez Humble, and Gene Kim)
* Team Topologies: Organizing Business and Technology Teams for Fast Flow (Matthew Skelton and Manuel Pais)
* Empowered: Ordinary People, Extraordinary Products (Marty Cagan)
* The Phoenix Project (Gene Kim, Kevin Behr, George Spafford)
General:
* The Goal (Eliyahu Goldratt)
* Turn the Ship Around! (L David Marquet)
* Just Culture (Sidney Dekker)
* Leadership on the Line (Ronald Heifetz, Marty Linsky)
* Emotional Intelligence (Daniel Goleman)
My beef with Five Dysfunctions is primarily the book recommending MBTI. MBTI has the predictive value of horoscopes, more or less. Really hard to take anything said seriously at that point.
The negotiation-series has some value, and has helped me succeed in some negotiations, but I'd honestly recommend Never split the difference as a substitute. Having read that book instead would probably have saved me more than a few poor outcomes in negotiations.
Finally I'd like to recommend Peopleware - surely one of - if not the definitively - best book I've read for professional purposes.
Here are the five dysfunctions:
The foundational dysfunction is a lack of trust -- trust defined as belief that your skill weaknesses and deficiencies will not be used against you. So people conceal weaknesses and don't ask for help from each other, etc.
This leads to fear of (healthy, productive) conflict -- you don't hash things out, but rather any meaningful discussion gets suppressed. Creates an environment where back-channeling and politics thrive, etc.
This leads to lack of commitment -- the team has not really had heathy, productive conflict/discussion so they don't buy into decisions. There is ambiguity about direction and priorities.
This leads to avoidance of accountability.
This leads to inattention to results.
Here's a high-level overview: https://www.executiveagenda.com/application/files/3215/6401/...
In your earlier comment you mentioned:
> MBTI has the predictive value of horoscopes, more or less
My understanding of MBTI is that it's not supposed to be predictive, but it helps you understand a different person's preferences or view-point. Preferences don't necessarily predict behavior.
Understanding the J vs P preference difference was revolutionary early in my marriage. I'm P and my wife is J, and our different preferences on that dimension helped explain much of our conflict. And understanding her preference helped me be more considerate and loving to her. MBTI helped me understand her (not predict her).
When I read a description of an MBTI type for someone I know really well, about half of it rings true -- but then reading and talking through it together sparks a great conversation where we learn a lot about each other.
The book does recommend using a qualified MBTI coach/trainer, so that it's not mis-used.
Hope this $0.02 is helpful.
I'm much rather someone tells me they are a an ENTJ than a Virgo. At least the ENTJ will understand sometimes they need to change their approach unlike the Virgo who (in my experience) says "this is how I behave and you can't do anything about it because it's the universe".
For anyone else not familiar with the acronym
I think this illustrates something about business books in general: even when they contain a really good idea, they often also contain other less-good ideas. I think I tend to read business books really critically, and am comfortable remembering the lessons that are useful and ignoring the ones that aren't.
But I should add a note to my reading list about MBTI, least others think I'm recommending it and take it seriously.
That's odd. I've spent much of my career in engineering leadership, and I'd estimate 75% or more of the managers I've worked with read books to a degree I would categorize as obsessive. This has been true across half a dozen companies. Do you usually work for software companies? Maybe outside the US? I'm curious how we could have such opposite experiences.
We certainly agree that it's a mark of a good manager.
Yes, I work exclusively with software companies, mostly in the San Francisco Bay Area.
The best book on the topic for me was peopleware [1].
Radical candor [2] was something I started but only got to the first 50 pages. Was also good.
===
[1] https://www.amazon.de/Peopleware-Productive-Projects-Teams-3...
[2] https://www.amazon.de/-/en/Kim-Scott/dp/1529038340/ref=mp_s_...
I find most management books to be useful in terms of thinking about general people management.
I had takeaways from An Elegant Puzzle that I could directly apply to my day to day work. That's more valuable than anything else.
One issue with giving tips about eng. management is a bit like giving tips about software engineering: it is very context dependent. Especially around the areas where you have agency. Do you have agency in hiring ? In the directions your team work on ? On head count ? On technologies ? On firing ? On promotions ? Depending on your levers, your management will have to adapt a lot.
It’s simply creating a habit of reading.
A bookstand such as https://www.amazon.com/gp/product/B00MVBDIPU/ref=ppx_yo_dt_b... is helpful to hold the book on the table where you eat. This way whenever you sit down, the book is open and ready to go.
Books are simply a media format like a podcast or a movie. The only difference is that, they are pure language, and it requires a bit more from you to read, than it does to listen or watch. Reading is a bit more "active." However the pure language, and the active reading, makes them really dense and effective for communicating ideas. The "ideas per minute" is very high for books.
If you are a software developer, you're already a writer in some sense. Books therefore I see as very familiar for developers.
Then I started using Kindle devices, which were a lot less enjoyable but more more convenient (can carry anywhere, get books instantly) and my reading time increased dramatically.
Then I started using the Kindle app on my phone, which was even less enjoyable but even more convenient and accessible, and now I easily do 30-60 minutes each day (time I could've easily spent lost in social media).
I also take time to read every morning. I wonder at people who find time to exercise, but I guess I shouldn't as the reading tends to take the place of exercise. Time is there, it's what we decide to do with it where the battle lies.
When that happens repeatedly, pretty soon it starts to seem like a good idea (and creates motivation) to read related books in advance.
- Audiobooks, while: - Exercising - Commuting - Performing mundane everyday tasks. My favorite is doing the dishes and throwing out the trash. - If your organisation values continuous learning, dedicate 30 minutes each workday for reading. It will pay off for the organisation, but not all organisations comprehend that, unfortunately. - Dedicate 30 minutes outside your workday for reading, if you think you can derive enough value from it to be worth it. This requires some personal evaluation, and is the last option on the list for good reason - it is easily the least good option in my opinion.