Leading Snowflakes Reading Notes

Leading Snowflakes — Reading Notes

“Leading Snowflakes The Engineering Manager Handbook” — Oren Ellenbogen

Entering a management position for the first time can be very confusing; the knowledge about management is only gathered from previous work experience, observations, or casual chats with colleagues, knowing what actions taken by a supervisor are viewed positively or negatively by subordinates. These experiences and thoughts are fragmented, lacking a systematic concept, so I started reading books and recording each author’s experiences. If I encounter similar situations, having this “knowledge confidence” will prevent me from being flustered.

Leading Snowflakes

Language: English
Author: Oren Ellenbogen
Publication Year: 2013
Official Website
Thanks to Hai Zongli for the recommendation

The author, with nearly 20 years of work experience, transitioned from a software engineer to a management position step by step; having served as a Technical Lead and Engineering Manager in both large companies and startups. This book details the bottlenecks encountered when transitioning from an engineer to a management position and the methods to organize and solve them.

I find my background very similar, having originally worked in software development and now exploring management. The key points mentioned in the book have taught me many methods on how to proceed!

- This article is merely personal notes mixed with some personal views. In this age of fragmented information, it is strongly recommended to read the original book to systematically absorb the essence.

- The significance of notes is to make it easier to quickly locate the points you want to review later.

- Some content is directly excerpted from the original text.

Lesson 1. — Switch between “Manager” and “Maker” modes

The transition from Engineer (Maker) to Manager.

Completing tasks well and even elegantly solving problems is the measure of an excellent engineer, but as a manager, it is no longer measured by the ability to complete tasks, which we have already proven, but by the team goals of leading, driving, and enhancing capabilities.

However, one cannot completely detach from tasks, as completely detaching from task details can lead to disconnection from team members, posing significant risks in terms of execution results, priorities, and trust in the long run.

So, it is not that as a manager you don’t need to do engineering tasks, but rather you need to balance between being an Engineer (Maker) and a Manager.

As engineers, we like to have uninterrupted time to stay in context and solve difficult problems; but as managers, we need to frequently step out to help the team and care for teammates, so interruptions are actually part of a manager’s job.

But how do we handle being both an engineer and a manager?

The author suggests creating two calendars, one as a Maker (engineer) and one as a Manager, and then spending 15-30 minutes every morning to organize thoughts and plan the day’s schedule, including what tasks to do, what meetings to attend, and identifying continuous time slots to solve tasks (as a Maker).

Author’s Calendar Template

We also need focused time

The author states that even as managers, we still need to handle tasks; the available focused time is more important to us than before.

The author mentions that during focused time, you can convey to teammates not to disturb you through certain actions!

Methods include: going to a meeting room, wearing headphones, or even buying an ON AIR! switch light to place on your desk.

If it is not an urgent issue, teammates can leave a message or compile information and email it to you, to be addressed after the focused time ends.

Evaluate the tasks you can solve as an engineer

Because I can no longer fully dedicate myself to development tasks as I did when I was purely an engineer (Maker), I need to choose tasks that I can personally execute based on the time available in the engineer’s schedule.

Do not become the technical bottleneck of the team. Our mission is to enhance team capabilities, explore new technologies, and improve the company’s technical vision both internally and externally. Tasks can include pre-researching technical issues and sharing them with teammates for execution, resolving the company’s technical debt, improving processes to increase development efficiency, using new technologies, open-sourcing company technology, opening APIs, participating in external hackathons, etc.

The most important thing is still balance

The author suggests starting with a 15-20% ratio. Originally, it was 100% as Maker, but now it might be 20% as Maker / 80% as Manager (though this depends on the actual team size and member capabilities; the author also mentions that 50% / 50% is possible). The key is not to be 100% invested in engineering development but to spend more effort on management.

Make good use of 1:1

Regularly have 1:1 meetings with teammates to provide mutual feedback and share what you’ve learned.

If management tasks consume all your time

The author finally mentions that if your management tasks are so overwhelming that you can’t do any engineering (as Maker) work and become disconnected from tasks and technology, you might consider working from home (WFH) a few days a week to isolate yourself from the company or participate in hackathons.

Lesson 2. — Code Review Your Management Decisions

Regularly review the decisions you make as a manager.

As engineers, we have many methods or tools that, if followed, can improve our abilities, such as pair programming, code review, and design patterns. But as managers, especially new ones, we often feel quite lonely.

We don’t want to admit our ignorance to our superiors or subordinates, fear being responsible for the team’s success, and worry about balancing technical debt and business needs.

The author mentions stepping out to seek ways to improve management skills, openly soliciting feedback, and enhancing management skills; being a manager can be as passionate as being an engineer.

Record & Review Decisions

Colleagues and bosses are powerful resources we often underestimate. We can quickly learn from their feedback. Establishing a habit of recording and reviewing decisions can help us get better feedback.

The author mentions:

“There is no one right way, there are only tradeoffs.”

I agree. If it weren’t a dilemma, you probably wouldn’t ask. If you ask, it means teammates don’t know how to decide.

We can list options and provide decisions to teammates, but at the same time, we should also note the decisions made.

Sample record sheet provided by the author

Develop the habit of recording and ensure the content is memorable for later.

The author suggests reviewing monthly, sharing and discussing decisions with your boss, other managers, or colleagues (at least half of the issues), and listening to others’ opinions. You can anonymize to protect individuals, focus on issues, not people, and record them.

Key points for review

Regarding the problem:

How many technical issues did it cause?
Is it a personal issue?
Is it an isolated issue for a particular member? (Is it simply because they don’t understand the goal?)
Will this issue recur in other teams?

Regarding the decision:

Does this issue really need a manager’s decision?
Have you asked teammates for suggestions?
Is there someone more experienced who can provide advice?
Would you make the same decision upon rethinking it now?

Lesson 3. — Confront and challenge your teammates

Encourage teammates to step out of their comfort zones and avoid becoming a jerk or falling into traps.

The author mentions initially feeling uncomfortable because colleagues who were friends now became subordinates. He feared damaging the original relationship, so he took on all the finishing tasks himself. But eventually, he found that the more he protected, the more distant he became from teammates because he kept working hard alone, sharing less, and causing teammates to lose faith.

Looking back, the author says it’s better to express your true thoughts rather than fear hurting teammates’ feelings. “Fear of hurting teammates” is simply a selfish imagination, unnecessary. Moreover, it’s the manager’s responsibility to lead the team to grow and move forward, to see the big picture, and control risks.

Sharing true thoughts is difficult for both sides, but it’s the manager’s responsibility.

We need to show empathy, not sympathy. To make their work truly outstanding, they need our objective opinions.

The author provides the following three points to help balance emotions and behavior:

Am I showing empathy?
Have I clearly stated my expectations?
Am I leading by example?

“If you want to achieve anything in this world, you have to get used to the idea that not everyone will like you.”

If you want to achieve something, you must get used to the fact that not everyone will like your ideas.

Four common pitfalls:

Do I openly share my failures instead of covering them up? (This can be done by writing articles or sending emails to everyone)
Forgetting to summarize discussion results (Get used to recording 1:1 and discussion outcomes)
Using the wrong feedback medium and not getting to the real issue (Find the appropriate feedback channel according to team culture, e.g., 1:1)
Not providing timely feedback We need to be aware that engineers like to challenge themselves, improve their skills, and also want respect and feedback from their supervisors. Our mission is to lead the team to grow, so we should not delay any opportunity for feedback. Not making a decision is also a decision, and once the culture of feedback weakens, it becomes harder to reignite.

Summary

Spend time writing down ways to motivate teammates and ask supervisors if they are being too protective of the team.

Lesson 4. — Teach how to get things done

How to complete tasks with lower risk.

Leading by example is a good method. Occasionally participate in the team’s development to demonstrate how to plan and produce good features, showcasing the principles we want to convey. Additionally, focus on explaining the “Why?” (Why do it this way) more than the “How?” (How to do it).

The author mentions a culture of extreme transparency, allowing team members to have complete context, which can enhance decision-making capabilities.

Reducing risk

To reduce the risk of output, the author suggests breaking down requirements into many small iterative features and sharing this idea with other teams.
Scale and performance — always have a backup plan Will this feature affect performance (or cause other issues)? Can we know in advance? Is there a backup plan (a switch)? Without a backup plan, it is better not to implement it, as it can affect team confidence.
Break tasks into smaller tasks to reduce deadline risk It may be difficult at first, but it can be trained and learned.
Utilize peer pressure Break tasks down for teammates to collaborate on, working together (Code Review is also part of this).
Continuously communicate internally and externally Internally: Ensure expectations, synchronization, deadlines, and resources. Externally: Communicate, and if time is tight, push back on unimportant meetings.
Support, fix bugs, and document It’s not just about releasing features; you also need to provide customer support, fix bugs, and document.
Conduct reviews and delegate tasks, providing leadership opportunities for others.
Select a few tasks to lead by example.
Ask teammates what they have learned, what motivates them to be more proactive, and what they dislike.

Lesson 5. — Delegate tasks without losing quality or visibility

Delegate tasks while maintaining quality and visibility.

As a manager, you must delegate tasks properly. The author believes that delegation should involve setting expectations and trusting that the assigned teammates have the ability to execute, learn, and have room for mistakes. Managers should also protect teammates from company pressure.

The author uses the following table for recording:

This mainly records tasks that are important to team goals, not daily work.

Must write down the task content

When deciding whether to delegate a task to a teammate, the author first asks if the task is something only they can do and if it is a managerial task. The second question is whether the task is a long-term leadership task. If neither, then delegate it to a teammate.

For tasks to be delegated, evaluate the teammate’s experience and skills to find the right person.

External: Resources expected from outside or above (Feedback/Tool)
Delegate

For the delegation part, we can provide a one-page paper explaining our expectations and simple examples.

Lesson 6. — Build trust with other teams in the organization

Collaboration and mutual understanding between teams.

The author explains that organizations split into many small teams for quick decision-making to accomplish more. Defining the direction of each team is not difficult (e.g., iOS team works on the iOS app), but aligning all teams’ goals is challenging.

The more teams there are, the harder it is to unify everyone’s values, expectations, priorities, and implicit expectations.

We should focus on the reasons and motivations for splitting teams rather than the output, as this can lead to contradictions.

The author believes the following methods can align the direction of each team:

Teams should have a vision, not just handle tasks.
Managers need to distinguish between needs and wants.
Optimize the team to complete the right things faster, not just more things.
Establish good communication with other team managers. The author suggests sharing the team’s status, obstacles, pains, and upcoming major tasks and reasons in bi-weekly manager meetings.
When there are differing opinions on priorities with other teams, explain and bring up other factors (e.g., this will reduce CS complaints, be a one-time fix, have a multiplier effect, etc.).
First, understand where external teams need our help and actively follow up.
Then, bring up where our team needs help from external teams.
List the items that need confirmation to ensure they are discussed in the meeting. If not, follow up with relevant managers afterward to see if there are other possibilities.
If not possible, weigh the potential delays or alternative solutions and inform stakeholders (to prevent backbiting).
Everything is a trade-off.

Additionally, here are 5 ways to help teammates build close relationships with other teams:

Simple thank-you notes (expressing gratitude for assistance)
Team work exchange
Internal tech conferences to share knowledge
Observing user behavior together and brainstorming optimization ideas
Inviting a teammate from another team to join our work

Summary

“Imagine that someone from Team A drops a feature that Team B needs, due to an urgent support issue. Without communicating this priority change to Team B, trust will be decreased even if it’s a justified priority change.”

“difference between transactional trust and relational/emotional trust”

Understand transactional trust and relational trust.
Transactional trust — whether people will fulfill promises and complete tasks
Relational trust — whether people act in ways that build and protect relationships

Lesson 7. — Optimize for business learning

Build a culture of business learning rather than a culture of building, optimizing throughput, or optimizing value.

Premature optimization is a disaster
Focus on optimizing current problems, not optimizing for the sake of it
Even if not responsible for the entire project, we can still optimize internal operations; big successes often come from the accumulation of small optimizations
As managers, we must demonstrate the motivations behind decisions
Establish a culture of business learning (value) rather than a building culture (focus on solving business problems rather than just building solutions)
Optimize efficiency vs. optimize throughput:
- Optimize efficiency: solving a single task’s time
- Optimize throughput: how many tasks can be solved within a time frame (e.g., a quarter)
Know the impact of each optimization
The importance of automation (saving time in the long run)

Use the AARRR principle for value optimization:

Acquisition: How to attract more users
Activation: How to guide users to complete tasks that help them understand the product’s value (e.g., an alarm app guiding a new user to set an alarm)
Retention: Increase return visits and usage frequency
Referrer: Let your users and content bring more traffic
Revenue: Quantify the revenue generated by users

These five aspects are closely related. If Retention is low, adjustments can be made to Referrer and Acquisition simultaneously.

As engineering managers, our job is not just to code or fully immerse ourselves in technology; we should periodically realign with product value.

When the product is in its early market testing phase, focus on optimizing efficiency (quickly solving tasks and releasing) by repeating the following process:

Feature improves Retention -> Release feature -> Learn -> Adjust & repeat.

Evaluate each stage from feature to release for optimization opportunities (spending too much time on design? Discussions?).

Can we invest 20% of the time to reduce 80% of development time? Especially painful points.

Can we experiment or release to the smallest audience first? Avoid large features that end up unused.

Good data tracking is essential to understand the effectiveness of efforts

“If you can’t make engineering decisions based on data, then make engineering decisions that result in data.”

Although “not implementing this feature will bankrupt the company” is scarier than “this feature will lead to technical debt,” as managers, if we can secure more time to address technical debt, we should do so. We must communicate and manage well.

Optimizing code that might not be used is meaningless.

After the initial experimental phase, when the product model stabilizes, it is more suitable to optimize throughput (e.g., given X resources, achieving Y output)
Provide predictability for business needs (as above)

Track team output (e.g., “01/01/2013–14/01/2013: 2 Large features, 5 Medium features, 4 Small”), and through long-term statistics, provide forecasts.

Identify & resolve bottlenecks:

Synchronous communication: For example, in the product development process, design resources are needed; when entering the engineering development stage, do we have clear specifications ready for development? Are we waiting? Is there anything we can do first?
Infrastructure: Make the code extensible and maintainable
Automation: Use automation to handle tedious manual operations, saving time and avoiding errors

Since business strategies are constantly changing, we should maintain a more open and flexible mindset towards optimization strategies, with the summary of optimization still focusing on business needs.

Lesson 8. — Use Inbound Recruiting to attract better talent

About Recruitment.

Start doing the following tasks regularly to prevent a sudden shortage of talent. If you wait until you need people, you’ll have to revert to traditional methods of constant interviewing, which makes it hard to find suitable candidates.

Internal:

Cultivate a good engineering culture environment (e.g., Code Review, annual meetings…)
Create an attractive work environment
Manage like a brand
Team members work together
Strengthen personal connections (e.g., birthday celebrations)
Make team members proud of the team first

External:

Internal team regularly answers community questions (e.g., Stackoverflow) to increase exposure
Hide recruitment Easter eggs in the code (e.g., web developer tools)
Share the problems and solutions our team encounters with the community (articles or talks)
Host hackathons
Establish side projects (e.g., open-source projects)

Assign the above tasks to team members so everyone contributes to finding good talent.

Lesson 9. — Build a scalable team

Building a scalable team.

Creating scalable programs has been our responsibility as engineers, but now the challenge is to build a scalable team.

Unlike programs, people have expectations, needs, and dreams to consider.

The author wants to create a happy work environment where teammates understand task expectations and new challenges, and maintain this enthusiasm.

Align goals Align personal vision with company goals. If the current company goals are not understood, it can cause team dysfunction.
Align core values This is about consensus and tacit understanding regarding ways of doing things and what is important. Team core values are not static and should evolve with time.
Balance Balance the skills and growth of team members, assigning different visions, autonomy, and ownership. Collaborate and grow together (e.g., newcomers expect to understand company processes, veterans should do Code Reviews and mentoring). Everyone should have growth potential.
Team core values over individual This may lead to some people leaving, and it requires time and patience to achieve. There are many challenges (e.g., questioning core values when someone leaves).
Sense of accomplishment Results should bring a sense of accomplishment. As a manager, you cannot let teammates burn out their enthusiasm.

Implementation

Define team vision For example, the author’s team is doing web scraping, and their team vision is “To build the largest, most informative profile-database in the world.” Note that this is a vision, not a short-term goal or something you don’t want to do.
Define team core values When selecting core values, ask, “Is this value important enough to fire someone over if they lack it?” Write down the core values and reasons. The author provides the following core values:
- Don’t let others (other teams) clean up your mess; take responsibility for your (team’s) mistakes.
- Maintain loyalty and respect for all team members. With core values, recruitment or firing decisions have clearer criteria, and there is a better basis for doing things.

Define member expectations of the team and managers

Provide a productive and happy work environment
Understand the “Why” of tasks, not just the “How”
Receive genuine feedback
Have opportunities to lead other members
Share work results

Define expectations for team members

Basic expectations:

Complete tasks
Maintain a passion for learning
Maintain a passion for sharing and teaching
Understand the baseline sense of doing things

Personal expectations:

Set expectations based on ability
Have the ability to train others to change
Drive change rather than complain

We are a team. Team members have their responsibilities and deliverables, and they must also collaborate with others, help each other, and grow together. Defining expectations is like a contract, transforming the original colleague relationship into a managerial relationship, leading more purposefully. Defining these items is not easy and requires time and patience to iterate.

“You can’t empower people by approving their actions. You empower by designing the need for your approval out of the system.”

If you have any questions or comments, feel free to contact me.

===

本文中文版本

===

This article was first published in Traditional Chinese on Medium ➡️ View Here