Leading Snowflakes: The Engineering Managers Handbook by Oren Ellenbogen
My rating: 3 of 5 stars
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)