HN Books @HNBooksMonth

https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...

If you'll be managing a technical product and other developers I'd recommend reading 'Managing Humans' by Michael Lopp (aka rands) - https://www.amazon.co.uk/Managing-Humans-Humorous-Software-E...

Short chapters so you can read it in chunks, its entertaining and based on his experiences.

Included it in this list of start-up books I wrote ages ago but you've reminded me its worth re-reading - https://medium.com/@KatAlexPas/an-hour-and-a-half-a-day-of-r...

Contrary to what many people think, few of us have managers who can consistently and successfully lay out the optimal career path and help us achieve it. I'd say there are three main reasons:

1. It's really hard to do.

2. Few people have themselves been trained on management.

3. Faced with 1 and 2, people focus on their own, more familiar personal deliverables.

Therefore, if you want things to change, you'll probably have to make some specific suggestions. And to do that, you should do some homework. I highly recommend starting with Managing Humans by Michael Lopp (http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...) or maybe The Hard Thing About Hard Things by Ben Horowitz (http://www.amazon.com/Hard-Thing-About-Things-Building/dp/00...). Spend an hour or two with each book and you'll have a better idea what can be done, and why.

What you're finding is that working as both a full-time manager and full-time engineer is very difficult, borderline impossible. Eventually, you'll have to choose. An increasing number of small companies are starting to understand this reality, and allow their top people to grow into either technical leadership or management leadership roles. Expecting both, simultaneously, is not realistic.

I liked Michael Lopp's (also known as Rands, from Rands in Repose) book, Managing Humans, when I first became a team lead 18 months ago.

http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...

As a manager, 1-1s should not just be considered status reports. They are a way for you to build trust and communication with your staff, and to give them a chance to talk about anything: problems, work on personal development, or feedback about you as their manager.

1-1s are probably your most valuable tool. Often, you will discover problems and info you would have otherwise not known - "our lead developer seems depressed and was talking about quitting", "did you hear about that other project that started? It's in direct conflict with our plans...", "there's a conference coming up, we should present at it", and so forth.

An effective manager should, in my opinion, spend 50% or more of his time with his team. Working on the same topics, talking to them, helping to plan, fixing problems, finding resources, and doing 1-1s. It's no surprise that teams with the most problems often have a manager who is just not around enough.

For new managers, I always suggest the following resources as a great starting point:

- "Team Geek": http://shop.oreilly.com/product/0636920018025.do - "Managing Humans": http://www.amazon.com/Managing-Humans-Humorous-Software-Engi... - Manager Tools podcast: https://www.manager-tools.com

⬐ quanticle

>1-1s should not just be considered status reports.

And scrum standups should only take 5 minutes. Theory is one thing. Reality is another. It's even worse when you have a team that does scrum, and also schedules regular 1:1s with the boss. I'm expected to give my status every day, and then summarize a week's worth of status at the 1:1 meeting. It's a colossal waste of time, and I don't know how to "take charge" of my 1:1 (or even if I'm supposed to take charge) in order to refocus it onto what I want it to be about.

⬐ dreamfactory2

that's just poor execution and as you point out, can suck the value out of anything

⬐ foz

When 1-1s become the weekly status report, your manager has failed you. Your manager should know what's up because he is around, uses the team's tools, and asks questions.

You should definitely take charge of 1-1s. Maybe try bringing a list of non-status related issues and hand them over. The problems you see, ideas you have, off-topic things. Make it clear to your boss that things aren't working.

Hi there, I'm quite new to engineering management as well, with approximately one year of experience. I've had some great mentors, as well as a reading list passed down to me. I'll highlight those I found as having the most impact for me.

At the top of the list is "Managing Humans: Biting and Humorous Tales of a Software Engineering Manager" by Michael Lopp[1], which was recommended to me by a manager who helped me get my start in engineering management. This book touches on a lot of the nuances in dealing with people and, as an introvert, I found this really helpful. The same author blogs under "Rands in Repose[2]" which has much of the content from the aforementioned book available for free.

While in the people category you'll also get a lot of recommendations for "Drive!" by Daniel Pink[2], which is a book about intrinsic motivators (autonomy, mastery, purpose) and how they are more important and effective than extrinsic motivators (e.g. money), particularly for knowledge workers. My personal advice, however, is to watch his TED talk[3] which is a great summary of basically the entire book. In this same category I could also recommend "The Great Jackass Fallacy" by Harry Levinson[5].

Now on the wall between people management and engineering/project management is "Slack" by Tom DeMarco[6], which is about how organizations and managers tend to run their staff at 100% capacity. As the book points out, however, this is a good way to not only burn people out, but it also sends response times through the roof (from queuing theory), and stifles change ("too busy to improve"). You can read this one on a plane. For some shameless self promotion, I've also written a tiny blog post relating Slack and the need for upkeep (software operations and maintenance)[7].

Next, fully in engineering/project management, I have to recommend "Waltzing with Bears" by Tom DeMarco and Anthony Lister[8], which is specifically about managing risk on software projects. The authors highlight the common practice of project/engineering managers communicating their "nano date", which they point out is typically the lowest point on the uncertainty curve. In other words, the project has the lowest possible chance of shipping by this date when you look at the possible timeline as a probability distribution. This book changed the way I talk about projects and the way I manage my team's various risks and I have been more successful as a result.

One final recommendation I'll make, since you're in the midst of a transition, is "The First 90 Days" by Michael Watkins[9]. It's a wonderful book that outlines how and why one should develop a transition plan in order to hit the ground running - and in the right direction. For my last engineering management opportunity, developing a preliminary 90 day plan as part of a "starter project," was a major factor in being given the job.

I believe that a subset of these will give you a great start. After that, you should read on the areas you feel the need for the most amount of help with or the areas that interest you. If you are avidly interested in project management, for example, you should read books on various methodologies, particularly the one that you or your organization practice.

[1]: http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...

[2]: http://randsinrepose.com/

[3]: http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...

[4]: http://www.ted.com/talks/dan_pink_on_motivation?language=en

[5]: http://www.amazon.com/Great-Jackass-Fallacy-Harry-Levinson/d...

[6]: http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

[7]: http://www.charleshooper.net/blog/on-slack-and-upkeep/

[8]: http://www.amazon.com/Waltzing-Bears-Managing-Software-Proje...

[9]: http://www.amazon.com/The-First-90-Days-Strategies/dp/159139...

See randsinrepose.com - blog by Michael Lopp and his book Managing Humans - http://amzn.com/1430243147

I'm currently enjoying "Managing Humans" by Michael Lopp - http://www.amazon.com/Managing-Humans-Humorous-Software-Engi.... You can also read his blog entries on management here - http://randsinrepose.com/archives/category/management/.

The reality of people management is that books and articles will only take you so far. They can build a good foundation, but nothing cements the lessons like making mistakes, recovering from them, and learning how to avoid them in the future. Keep an open mind, don't be afraid to experiment, and look out for your team. Everything else will come through experience.

He did a great job, and I definitely recommend the book: http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...