More a booklet than a book. 9 "lessons" (for Eng. Managers in IT) which all make sense, but are far from revealing. The framing of concepts is close to flawless - 100% clarity.
When it comes to non-fiction books I tend to rate their quality based on the number of notes I make during reading. In this case, it was only 3 ;/
Don't get me wrong, it's still worth reading, BUT I've expected much more (/better) content.
Even though it is targeted for engineering managers, it is a good overview of tools and behaviors someone at a leading role in a software engineering team should know.
Overall this is an ok book but there are a couple of nuggets in it which are quite useful.
Initially there is the highlight the difference between makers and managers – the role of the manager being to amplify the team. It highlights the importance of balancing making and managing and the need for concentration in the making zone. The key for managers is not to measure your output but the output of the team.
When making something we can review it quickly, such as by running unit test on our code. As a manager we rarely review the decisions we make to actively learn from them. The book highlights the importance of this and proposes a template to achieve this and get more continuous feedback. These decisions could be to postpone a decision, but this itself is a decision. There are no right or wrong just different takeoffs between different approaches.
The importance of feedback is discussed and this being hard as a transition from a team mate to a team leader. I diverge from the book here as we should not only be getting feedback from the leader, all members of the team should feel comfortable providing feedback but it might be that the team leader needs to deal with harder situations. Dick Costolo, Twitter’s CEO, uses the term “The Leader’s Paradox” – as managers and leaders, we need to care deeply and thoroughly about our people, while not worrying about what they think of us. It is key to share your own lessons learned, to summaries and share written feedback, using the wrong medium to present a message and delaying feedback.
Getting things done by extreme transparency, reducing risk (releasing smaller chunks etc), planning, leverage peer pressure, retrospect & delegate. Using the Must, Delegate and External lists – where Musts are absolute musts that as a manager we must do, if it is not a must then we can delegate it. External are things which are outside of your sphere which impact you.
When moving from maker to manager people approach it with a view of productivity. In reality building trust should be a higher importance, both inside the team but (crucially) with other teams.
Optimise for value. Depending on the product phase this could be focusing on Acquisition – how to bring in more users, Activation – increasing the usage of the product, Retention – keeping the users using our product, Referrer – having happy customers who recommend our product, Revenue – making more money or gaining more customers. When we are uncertain optimise for getting answers fast, “If you can’t make engineering decisions based on data, then make engineering decisions that result in data.” (Kent Beck). When we have business certainty, optimize for predictability and optimise bottlenecks. “Companies fail when they stop asking what they would do if they were started today, and instead just iterate on what they’ve already done.” (Aaron Levie) this statement is a bit contentious as there are many re-writes which have failed so this is not a proven answer but reviewing what you would do with what you know now is a very important task to undertake.
“Culture is to recruiting as product is to marketing.” (Dharmesh Shah). This is what attracts employees and keeps them. Building an inbound feed of candidates by showing what you are doing, exposing your culture and demonstrating your tech to attract people to work for you.
To build a salable team requires an alignment of vision (Will it move the company into a winning position? Is it big enough as an engineering challenge?), alignment of core values without which the team will self-destruct as such it might mean loosing some key individuals (e.g. Never let someone else fix our own mess, Loyalty to each other above all), distributed responsibilities (What can you expect of me? What can you expect of being part of this team?), sense of accomplishment.
You can’t empower people by approving their actions. You empower by designing the need for your approval out of the system (Kris Gale)
Direct and concrete book. First chapters were not so interesting for me, as I've dealt with topics like delegation of tasks, time management etc. for quite some time now, but next topics were amazing. I've received many concrete tips and tasks to do. This is really a Handbook for engineering managers, as the subtitle states. I'll add it to the books list on our roles page for engineering managers https://solvti.pl/our-culture/roles-a...
I really enjoyed the book. It has a structure that is very easy to follow and definitely a quick read. And even though I'm not a manager or planning to become one, there's a lot of actionable advice in there for me as an engineer.
[audiobook] Oren's newsletter is my default reading list for the weekend so I had high expectations. The book has some nice pointers but I've found it a bit too lightweight for my taste.
While not as comprehensive as other books I've read, it's quick to read and contains actionable advice. It covers an interesting range of topics for managers including code reviewing your management decisions, building trust with other teams in the organisation and using inbound recruiting to attract better talent. The content feels a bit patchy. There's not an obvious flow to the book. This means you can read the parts that are most relevant to you, but also means there are many topics it doesn't cover.
I would recommend The Managers Path or Become An Effective Software Engineering Manager instead.
Being an engineering manager, I got a few good ideas to implement on my own job, for example, about how to balance between maker and manager modes and how to set expectations. Having said that, I think it's not a comprehensive guide, but rather a list of useful suggestions Either way, the book is pretty short, so worth the reading
The book shows how to plan better your actions, how to organize better your day. If you are working as a engineer manager or tech lead for a while you probably follow already a few techniques but this book is still very useful.
Like many other reviewers I'm subscribed to Oren's newsletter, which always has some good reading recommendations. However, this book was a bit hit and miss for me, it feels a bit like a collection of blog posts on different topics assembled into a book. Not bad, but not groundbreaking either.
Excellent and actionable book with some great insight as to how to manage a team of engineers. Lots to take away for my personal endeavours, and lots to think about and work through.
Highly recommended if you manage/lead (or aim to) a team of engineers.
Really inspiring and helpful book for engineering managers. It contains useful hands-on advices and suggestions. The book is also well organised so that you can read every chapter separately without any prerequisites.
Pretty quick read with quite a few concrete solutions and actionable items. Especially liked the section on “5 tactics to involve our teammates in building trust with other teams” - I've seen many examples over the years where those actions solidify the culture of a team.
Leitura fácil e um bom equilíbrio entre profundidade e abrangência.
O foco do livro é no que fazer quando se ver em um cargo gerencial, mas não tem muito sobre o que fazer quando se ver em um cargo gerencial e as coisas não funcionam muito bem. Ou seja, é só o caminho feliz.