Ask HN: What makes a good technical leader – any recommended books?
I just became a technical lead (spiced with a little product manager) for a team who is working with machine-learning/deep-learning technologies (I have ~6 years of background in this field). I feel like I am performing well, but there is a lot of room for improvement on: how to plan for the future, how to communicate success, how to assign engineers and researchers to tasks, how to define tasks, etc.
Do you have any recommendation on what should I do, read to become better and better every day? I want my team to be successful, and to show the improvements we make to the company.
115 comments
[ 3.6 ms ] story [ 174 ms ] threadThat roughly translates in my head to ‘terrible youtuber’
[1]https://www.amazon.com/Switch-Change-Things-When-Hard/dp/038...
Research. Why? Because this question has been asked dozens if not hundreds of times.
The sociology of software engineering biases the perspectives on leadership therein toward this kind of contempt for subordinates.
If the OP truly wants an answer they could have researched it, but as you stated the OP doesn't really want an answer, they are "seeking recognition"
Yawn.
That being said, really good book :)
https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
Does go off on a lot of tangents, but it's more interesting than books which keep rambling on the same idea chapter after chapter.
Don't be put off by the fact that his books are self-published, and the covers aren't great. He is brilliant.
For example, from the end of Chapter 1, 'What is Leadership, Anyway?': "Make a list of situations in which your presence seems to increase the productivity of others. Alongside this list, identify situations where your presence seems to decrease productivity. [...] What do these lists tell you about yourself and the environments that empower you?"
Weinberg has a way of getting you to reflect that I find profoundly valuable, if I am willing to do the work.
The best lesson I learnt on leadership is to listen to and believe in your team. They are the experts, not you anymore. Your job now is to clear the path to their success. Different people need different things to succeed, it's your job to figure that out and try your best to provide it.
What I recommend: Figure out what kind of leader you want to be. Read as much as you can and talk to other leaders inside and outside of your company to see what works and doesn't work for them.
Finally, make sure your team has a crystal clear definition of what success is and the milestones to get there. Ensuring this understanding will help your team move in the same direction.
Good luck!
[1] https://www.goodreads.com/book/show/23848190-extreme-ownersh...
None of those things exist in software engineering so there will be people that aren't motivated by the allure of moving up, aren't passionate about the product and maybe just want to do their job and go home. There is nothing wrong with that as long as they are doing their work.
As a leader, you may have peers that will like you to take extreme ownership because they can play politics and blame you for things. I don't think there is room for that sort of BS on a battlefield but I don't have first-hand experience.
There are also a lot of teams that don't have 'mission' like goals that are clearly evident (e.g. root out terrorists in Ramadi) but have a continuous flow of work to be done.
Like any books/videos/courses on leadership or self-help, take what you can from it an see what sticks in your world, don't take it as a prescription or steps on how to do something.
This question is addressed, if not in the book, at least in his podcast. Let me see if I can find it.
One day after a major release stuff broke in production. The company was losing customers daily. The "superboss"-es from HQ descended on our little dev team in a small midwestern city and ordered "Code Red".
What it meant to me as a new dev was that I can't go home and the whole team had to stay in the office until the problem was solved... A part of the team had to sleep in the office for a few weeks. (I still don't know if this is against OSHA.)
Many years later while I was watching the movie "A Few Good Men.", I learnt that "Code Red" was a military term. Suddenly, it dawned on me that my "superboss" was also an ex-military person.
Sleeping at work did not fix the issue, after many months of hiring help and bringing in more hands the outage was brought under control.
Did the ex-military "superboss" help the situation? I don't know...
Now I know that Military veterans in their enthusiasm to find work in civilian environments tout their ex-military skills as team building or leadership skills.
Skills learned in the military are for war, learned for conflict situations and applying them to civilian environments and bringing a war mentality or attitude to a workplace is toxic.
I don't have an answer to what makes a good technical leader but I know from experience that ex-military style leadership only adds to the toxicity of a workplace.
Sorry you suffered that experience though, hope you made it out of there.
The book is in my opinion a distillation of those skills, which -- maybe just so happen to -- come from military background. None of what is presented in the book come anywhere close to the situation you described. I would dare to say, quite the contrary. It is about listening, understanding, trusting and many other things, usually considered positive.
It had a great influence on me, though I have never even thought of joining the military.
I started practicing extreme ownership as a regular developer and made my way up to a team leader in about 6 months time. Now I double down as a fresh (and young) leader.
2. Common sense dictates that whenever one transfers skills to a new context, one assess the underlying assumptions and context of those skills to adapt them for use. I'm sure mistakes in that regard will inevitably be made, but I give most people more credit than to assume, a priori, that people will transplant those skills without any thought given to changing contexts. That seems like a very condescending assumption to start with, but maybe I'm misreading you.
> Skills learned in the military are for war, learned for conflict situations and applying them to civilian environments and bringing a war mentality or attitude to a workplace is toxic.
> only adds to the toxicity of a workplace
What exactly was the toxicity besides your choice to overreact (stay overnight) ? Why do you believe that leadership skills for war are not applicable to other domains?
It was not a choice. It was an order.
So it sounds like OP was coerced to do so and it was not a free choice or an "overreaction" as you characterize it.
"If I wanted the outcome I was aiming for I had to.... (workout?)" This is how I took the sentence. A totally volitionally accepted responsibility
The author was a submarine captain who turned one of the worst-performing boats in the Navy into one of the best.
https://www.kobo.com/ww/en/ebook/turn-the-ship-around-1
This is an excellent concept and an important one to really get. I go out of my way to never use the phrase “my team.” It’s not my team, it’s all of ours. I’m a member of it, too.
It’s my job to make sure they succeed. So instead of “my team” I always say, “the team I support” to reinforce that.
* https://www.hashtagcoder.dev/blog/director-of-engineering
* https://humanwhocodes.com/blog/2012/06/12/the-care-and-feedi...
1. The First 90 Days - a good reminder that when you transition, it's like starting a new job
2. Become and Effective Software Engineering Manager - a hands-on book for people transitioning to management, starting at a new company or looking to make more of an org-wide impact.
3. The Manager's Path - a short reference handbook for managers at all levels.
4. The Goal - written in the '80s, yet a timeless novel on what management is about, may that be a manager of a team, an organization or an industrial plant.
Also, I wrote a post about my learnings on transitioning from engineer to manager that has some good comments on HN[2]
[1] https://blog.pragmaticengineer.com/my-reading-list/#engineer...
[2] https://news.ycombinator.com/item?id=15326652
Each of these books is a bit utopian or idealistic. By doing what's suggested by the guru everything magically works out. But, while not magical, the ideas really do work and help operate and understand organizations. The principles are not complex, each book can probably be summarized in a 3-5 page paper. But the "case study" (quotes because it's a fictional plant/company, not just one obscured by pseudonyms) is good for illustrating the point and the path of process improvement.
There are other good books which can add to it like "The Manager's Path" by Camille Fournier.(https://www.amazon.com/gp/product/B06XP3GJ7F/)
I couldn't get on with it personally. While I like reading his blog, the book just lacked personality. Maybe I was expecting personal anecdotes to explain some of the ideas.
I don't have a specific book for you, so will link the wikipedia article as a jumping off point:
https://en.wikipedia.org/wiki/Servant_leadership
2. "The Phoenix Project", "The Unicorn Project" (novels), and "DevOps Handbook" by Eugene Kim, on how different parts of a tech + non-tech organization come and work together.
3. "High Output Management" by Andrew Grove on overall technical management.
4. "Measure What Matters" by John Doerr on setting objectives and measuring their progress.
5. "The Checklist Manifesto" by Atul Gawande on thinking through replicable processes.
6. "Who" by Geoff Smart on hiring.
7. "Start with Why" by Simon Sinek and "The Culture Code" by Daniel Coyle on creating culture and reasons for why people do the work. It's an important part of any management process, double import because of how often it is lost in technical management.
8. "The Mythical Man-Month" by Fred Brooks (still, IMO, one of the best management books ever, esp. for software and product development.)
9. Boyd: The Fighter Pilot Who Changed the Art of War by Robert Coram (OODA is the true core of agile thinking, and it works pretty much everywhere.)
For software and computers specifically, add:
10. Computer Lib/Dream Machines by Ted Nelson (Impossible to categorize - it's a hypertext book for crying out loud - but browsing it can change your thinking.)
11. The Soul of a New Machine by Tracy Kidder. (Good for new products in general.)
And for general management and leadership inspiration, two great autobiographies:
12. Mover of Men and Mountains, by R.G. Le Tourneau.
13. Rickenbacker, by Eddie Rickenbacker.
On that note, I would also add another book about organizational psychology - how people game incentives, how cya evolved, how people focus on short term thinking over long term investments, problems common across big businesses, written by a sociologist embedded for a few years in a corporation, but I can’t for the life of me remember it.
But also:
The Secrets of Consulting” by Gerald Weinberg on generally thinking through ‘solutionizing’.
“Systemantics” by John Galt as a short and fun intro to applied systems thinking and cascading effects.
“We Need to Talk” by Celeste Headlee on how to have difficult conversations.
“Never Split the difference” on handling and understanding negotiations both up and down the chain.
The book is an interesting read, but merely reading it won't do anything. There are one or two exercises per chapter, and you should work on them if you really want to see the benefits.
Also, if you want to do a little test before reading the whole book follow these tips from the intro:
> Three quick tips to boost charisma in conversation: Lower the intonation of your voice at the end of sentences, reduce how quickly and how often you nod, and pause for two full seconds before you speak.
From this summary: https://github.com/mgp/book-notes/blob/master/the-charisma-m...
To my knowledge the only book mentioned here that takes the time to define technical leadership and present models of leadership suited potentially to different circumstances.
I might add ‘The art and science of doing engineering’ by hamming and recently republished by stripe.
The more leadership or management books I read the more inclined I am to respect Taleb’s approach of looking for old timeless material rather than what’s new or hot.
Most of what Gerald Weinberg has written qualifies IMO. Tom DeMarcos books also.
I read it 8 years ago and it got me to consistently write everyday what I was thinking and feeling about my projects and team
Small Unit Leadership: A Commonsense Approach https://www.amazon.com/Small-Unit-Leadership-Commonsense-App...
The Five Dysfunctions of a Team: A Leadership Fable https://www.amazon.com/dp/0787960756/?coliid=I12MQNI6MIK6JR&...
High Output Management https://www.amazon.com/dp/0679762884/?coliid=I2G1Y1JLPP55SY&...
Measure What Matters https://www.amazon.com/dp/0525536221/?coliid=I1G6EQRC0QYPE1&...
Death by Meeting https://www.amazon.com/dp/0787968056/?coliid=I38A8AYMZGSLYZ&...
Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead https://www.amazon.com/gp/product/1455554790/ref=ppx_yo_dt_b...
The Hard Thing About Hard Things https://www.amazon.com/Hard-Thing-About-Things-Building/dp/B...
Start with Why (you can prob skip the book and just watch https://www.ted.com/talks/simon_sinek_how_great_leaders_insp...) https://www.amazon.com/dp/1591846447/?coliid=I2Q0IN84LJ230W&...
I think empathy and radical candor are the most important skills ! There’s a book called radical candor that I really recommend.
Other than those I recommend reading how very effective leaders did their job, Eleven Rings by the NBA coach Phil is absolutely amazing on how to build a winning team as is Leading from Ferguson (soccer). Turn the ship around is another great book by someone’s experience in the navy.
Creating a safe space where people know the goals clearly, communicate effectively and helping to unblock them are part of the goal !
- Out of the Crisis by Deming is useful for thinking about achieving quality by improving the systems rather than focusing on the individuals.
- Peopleware by Demarco for arguing the opposite.
- Everything ever written by Tom Peters for staying focused on customers and engaged in the game.
I also like to recommend Coders at Work by Peter Seibel (https://www.goodreads.com/book/show/6713575-coders-at-work). It's incredibly useful to read about just how different 16 ultra high performing software engineers are/were. Nothing prepares you for technical leadership better than understanding that.
EDIT: just saw that Mythical Man Month was added 1 minute prior to my comment.
Focus on the job at hand. Don't get into unnecessary political disputes. You're a tech lead, so keep it technical and focused on solving business problems.
Be kind and understanding of people's personal issues. It's a marathon, not a sprint, so it's fine if people's productivity goes up and down over time. As long as they contribute well over time, there should be no problem.
Make sure people take time off. Burn out sneaks up on people. Taking weeks off regularly is essential.
Do plenty of grunt work yourself, don't pawn it all off.
Write the most documentation and help your teammates write theirs.
Share the credit. Credit the team and individual team members frequently. Point out when people do well.
Downplay failures. Unless a mistake is malicious, you should blame the technology and the processes in place rather than the people involved. Humans make mistakes and it's through technology and process that we avoid them causing damage. Fixing the weakness in your technology or process is what really matters.
Most of all: lead by example. You should be an exemplar team member. Not perfect; no one is. Not an expert in every dimension; no one is. You should simply perform your duties in a way that your teammates could emulate with success.
There are a hundred other things, of course. That's just a few ideas.
Don't decide on your own if possible.
Decision coming from top? Communicate that. Otherwise, ask your team what it think is the best course of action.
Only decide on your when something would be blocked.
I always read about two sides.
"Managers are needed, because there are tough decisions to make and people need to be led!"
"Managers aren't needed, people can govern them on their own!"
I think the truth is in the middle.
[1] https://www.amazon.com/Agile-Conversations-Transform-Your-Cu...
The most important thing to realize is how success will be measured. It will no longer be your individual contributions. Instead, you will be measured by how successful your team is. So you need to use your time to make your team more effective.
So the most important thing you can do is prevent anyone from becoming blocked. The next-most important thing is unblocking people when they become blocked.
How do you prevent people from becoming blocked? Make sure that everyone knows where they are going, and they know what to do when they get there. Make sure everyone knows what they are working on, and what they will be working on next. Promote good practices, and ensure that processes have consistent documentation.
How do you unblock people? Review their code quickly. Learn to differentiate "I don't want you to submit this because I don't prefer this" (bad attitude) from "I don't want you to submit this because it's going to have a negative consequence"). Learn how to phrase that second sentence in a way that doesn't make your coworkers dread getting reviews from you. Spend your time fixing tech debt that's adding drag to the team.
As you do this more, you should also make sure that people on your team are growing. Give them harder tasks than they had before. Ensure that junior engineers are getting mentored. Correct imbalances: if a specific engineer is always taking notes in meetings, create a notes rotation so that everyone has to do it.
[0] https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/
I think this could be applicable in general sense too, so that your team understands the value system that you establish. People are smart, professionals are even smarter, so they figure out the incentive system quickly. Placing a right emphasis and staying consistent helps to communicate this.
Another thing that adds to the notion of unblocking is to establish a culture of "a long enough before calling for a backup", that is to try your best to crack a problem by yourself, but have a way to recognize a being stuck and allow to call for a help with no shame or sense of failure. In my view, this has both a culture and a protocol aspects.