Best advice I would have to give is to simply... be an engineer yourself before attempting to manage some.
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.
Maybes there's something in having to be brilliant in general but idk about this blanket statement. At least when I have had engineers turned manager as my manager, a lot of the time they seem to not be able to turn off the engineering. There's always something to tweak or be hands on with or experiment, except its not code they are messing with, but people. Our team structure, meetings, lets measure stuff, change our process etc.. and it ends up being a distracting drain. Engineers don't seem to be able to not mess with things. But maybe that goes with brilliant? Brilliant engineers know when to tweak and not to.
But that doesn't seem fair, yes brilliant people will always be good, you can't count on having brilliant people
> be an engineer yourself before attempting to manage some
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.
> 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.
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).
> they couldn't really attract engineering managers and they had to make do with the people they had.
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].
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.
MBAs make companies less competitive. When American companies were led by engineers, American companies were #1. Now, thanks to MBAs and decades of emphasizing short-term vision, every major American company is being eaten alive by the international competitors they helped create.
Seems like there would be a benefit to having a manager that is actually further from the problem itself. Less precious about details and more focused on universal principles.
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.
I used to assume that. Until I met folks who seemed to be able to switch from micro details to macro "big picture" rather seamlessly. The extreme example of that is a Gates review[0]. Maybe that's why John Sculley never stood a chance.
It's more than respect for the craft, it's understanding the problem space.
Strong disagree. Many hospital directors still have enough respect for themselves and their profession to see patients. Engineering managers should be no different.
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.
Funny you mention healthcare because I work in healthcare and you’ll be hard pressed to find a hospital administrator with a clinical background or one who still sees patients. Now medical directors sure but their patient load is minuscule and everyone in healthcare knows that the best care is from the person who does the procedure everyday vs once in a blue moon.
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.
I'd like to see what data you use for the claim that the very best engineering managers do not code any more. The idea the person who is chosen by the company to assess and compensate highest performers is also rapidly losing the ability to understand deeply the work being produced seems like a perfect recipe for producing random results.
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 used to think that. As long as I can write code when I need to and I can inform designs and architectures, my company gets all the benefit of my programming skills as well as my team building skills.
i actually this is also the most productive way to use a senior developer : have him focus on helping the team design and architect software instead of coding everything himself, and help other people grow to his level.
In my opinion for the majority of the cases you manage systems and lead 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.
Thanks for the list! The one that I've read (about half) are great, which makes me want to read the rest. (Just Culture and Accelerate, in particular, are so great I think I'm going to consider adding them to my list as well.)
I've read both a few of the negotiation books (Getting to yes, Getting past no) and Five Dysfunctions and I don't know that I'd recommend them, to be honest.
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.
Five Dysfunctions of a Team completely was absolutely revolutionary for me and my team. It's not about MBTI at all, but MBTI is just a tool it mentions to help with dysfunction one.
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.
As mentioned - I have read the book, and I'm not opposed to the some of the ideas in the book. However, the endorsement of MBTI is just really damn hard for me to swallow.
> 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.
I'm assuming the predictive power is in relation to fact the MBTI has been shown to have low repeatability in the test results, which undermines its ability to predict the actual personality of the individual in question.
MBTI and the dozens of alternatives aren't gospel, but they are a useful way of framing some conversations, especially when the people have no other shared framework to come from.
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".
Ha, I'd totally forgotten that Five Dysfunctions talks about MBTI -- I think I'd blocked it out. I completely agree that MBTI is total bullshit. Thanks for pointing it out.
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.
I’ve read five dysfunctions and can’t say I remember anything about personality types (MBTI). To me it was about persistence honesty and pragmatism. Loved it.
In my experience, most managers don't bother reading books. If they've read ANY books on management, that's above average. More than 1 in the past year, they're already highly unusual. Usually they get their position through knowing people or being slavishly obedient even in ways that are destructive to long term value.
> In my experience, most managers don't bother reading books... Usually they get their position through knowing people or being slavishly obedient...
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.
For engineers who become managers, manager tools is my first recommendation as well. It can be cringy from time to time, but it really focuses on things we are not used to think much as engineers. And it gives a lot of practical tips one can use right away. I think they apply to almost any type of organisation large enough to require management.
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.
“Making of a manager” by Julie Zhuo was great read for me. It covers the transformation of individual contributor to a manager. Well written. Give it a try.
I admit I haven't read many books on the subject but Managing Humans is the only one that was interesting/entertaining enough for me to recommend to anyone.
Any list of this sort should include "Managing The Design Factory" by Donald G. Reinertsen. A thought-provoking evaluation of what to care about when managing software teams.
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).
- 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.
I keep a Kindle and a physical book or two on my nightstand. I sometimes read before bed, and sometimes read once I've woken in the middle of the night. The Kindle also goes with me on any kind of trip.
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.
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.