From freeCodeCamp:
It’s a rare occasion that companies provide leadership training before you become a manager. A few days or weeks after what was probably one of the happiest days in your recent memory, the day you were offered a position outside of the individual contributor track, you find yourself with a million questions. You feel that you were tricked into signing something without reading the fine print.
That feeling you’re experiencing isn’t new, it’s just that you’ve all but forgotten it. It’s not knowing what you’re supposed to do. It’s being clueless. Because if you think years of writing software trained you to become a manager, research states the contrary. But it’s not the end of the world. Even though your company most likely doesn’t understand the need for formal management training, there is a plethora of information available to you that will make your job easier, and maybe even enjoyable.
When I became a manager I did what I typically do when faced with a challenge I know almost nothing about: I started reading. I’ve read a lot of books, some were good, a few of them were amazing. All of them shaped the way I do my job, and so I thought I would share them for other aspiring or active managers out there.
I’ve curated this list based on several factors:
- The books should cover a broad set of engineering management and leadership topics. It’s easy to find overlapping books. It is much harder to find a diversity of information when you’re very new to leadership.
- They should be written in different eras. The software industry is constantly evolving. It doesn’t make sense to only read about what was happening in the 1980s or 90s.
- Reading order matters a lot. Some books are more specialized than others. The information provided can be thought of as layers that stack on top of each other. If you’re inexperienced, you may start in the middle or the end, and that will basically ruin other books for you.
- Finally, I put a hard limit of 7, just because I think this list is enough to build a foundation layer on top of which you can continue reading and maybe even doing your own research further on.
. . . .
Peopleware: Productive Projects and Teams, by Tom DeMarco & Tim Lister
This should be mandatory reading for everyone. Period. No, not just everyone in software, everyone working in a private company should read this book. It’s amazing to me how pretty much all of the problems that people deal with it on a daily basis have already been solved. In the 1980s. If you read just one book from this list, let it be this one.
. . . .
Influence: Science and Practice, by Robert B. Cialdini
An engineering manager’s job is to ensure their team has everything it needs to succeed. This means managing the interaction between multiple groups of people towards an agreeable outcome.
If you’ve ever tried to convince a friend to move from WhatsApp to Telegram and failed, you’ve made an attempt at exerting influence. You’ll need to do that basically every day, and in my experience, this is a very hard skill to learn. It takes a lot of practice, and there’s really no sandbox mode in which you can fail and it’ll be OK. You will try to talk to someone at some point into doing something, and you will fail, and you or your team will suffer for it.
This book is the definitive guide on how to approach the problem scientifically. A lot of managers seem to think they don’t need to learn how to influence others, particularly their direct reports, as rank is the ultimate influencer. Thinking that will keep you from ever becoming a great leader, in my opinion. Yes, you will probably overrule someone at some point and it will feel terrific while you do it. But if that person ends up hating you for it, you’ve just lost their trust and you will see the consequences of that later on.
Link to the rest at freeCodeCamp
I started as an engineer, too (1970s coding). But this was in tiny companies which I helped build, and so I began to see companies as machines, too.
Ultimately, my career was in building small-medium software/consulting companies. As long as you were high enough and the firm was small enough, you really could influence and tune the “company” machine just like good software. Doesn’t mean your products & marketing were on the best path, necessarily, but at least it ran well.
You manage things. You lead people. –Amazing Grace Hopper
Thanks, PG.
Sent the list on to the two oldest Ehrhardt children, both deeply embedded in tech. The oldest does NOT want to ever be in management. The only problem with that is that you are then managed – sometimes by the wrong people.
You’re welcome, Alicia.
As an engineering manager, in my past, I found that it was more difficult than managing other departments. You manage engineers, educated and knowledgeable, and who will not respect you if you don’t have the technical knowledge they have. This would be similar managing doctors. If you’re not a doctor you have no business managing them. Most engineers are introverts and love being engineers, not managers who have to deal with people. A design on a drawing doesn’t talk back to you, and all is good.
I am an engineer, and when I became a manager, I had to learn quickly to be more extrovert, deal with people not things and abstract concepts, stop being an engineer and let the engineers do what they love to do. You must know how to ask questions, not provide the answers to technical problems, unless they’re stuck. My 1.999 cents worth of engineering manager experience.
You’re pretty much on the mark. The size and depth of the organization is the main complication factor.
I was on the management track for about six months…until I saw the crap my boss’s boss put up with. Stayed on the technical side afterwards, going as far as managing contracts. Much safer.
Learned to appreciate the virtues of an imperialist tools fan. Half his job was rainmaker, half facilitator. A bit of a micromanager but we never knew how good we had it until he retired. One particularly good trait: he never bought into management fads.
Saw it while I was in the Air Force, we had one great ‘tech’ retire early rather than be tied to a desk.
I always told them, “Why would I have hired you if I didn’t think you were a better XYZ than I am?”
That all fits with my experience working around good engineers (but not being one), Mit.
I saw some really excellent engineers who were promoted outside of their comfort zone. Almost all of them took an engineering job elsewhere in order to get back to doing what they liked the most and was the best use of their tremendous talents.
Peter Drucker said: the worst thing you can do is to take a good engineer and make him a manager, and when he fails he gets fired. Instead you should give him a raise and put him back to work as an engineer. That being said, there are a few good engineers who can be good managers, but they have to volunteer for the job, not drafted into the management job.
I have less stress since I have to manage only my writing, my music, my art and the marketing to sell the stuff.