Leading Snowflakes — Reading Notes
“Leading Snowflakes The Engineering Manager Handbook” — Oren Ellenbogen
As a new manager, everything felt confusing; my knowledge of management came only from past work experience, observations, or casual chats with colleagues. I knew which actions by supervisors were seen positively or negatively by their teams, but that was about it. My knowledge was fragmented and lacked a systematic framework. So, I started reading books and taking notes on each author’s experiences. When encountering similar situations again, having this “knowledge confidence” helped me stay calm instead of panicking.
Leading Snowflakes
-
Language: English
-
Author: Oren Ellenbogen
-
Publication Year: 2013
-
Thanks to Prime Minister Hai for the recommendation
The author has nearly 20 years of work experience, transitioning step by step from a software engineer to management roles; having served as a Technical Lead and Engineering Manager in both large companies and startups. This book details the challenges engineers face when moving into management and the methods to organize and solve them.
I find it very similar to my background, starting as a software developer and exploring management roles; the key points in the book taught me many practical methods to apply!
- This article is a personal note combined with some personal opinions. In this age of fragmented information, it is highly recommended to read the original book yourself to systematically grasp its core.
- The purpose of notes is to make it easier to quickly locate key points for review later.
- Some content is directly quoted from the original text.
Lesson 1. — Switch between “Manager” and “Maker” modes
Transition from Engineer (Maker) to Manager
Completing tasks well and elegantly solving problems are measures of a great engineer, but as a manager, success is not measured by task completion ability—that has already been proven. Instead, it is judged by the ability to lead, drive, and elevate the team’s goals.
However, you cannot completely detach yourself from tasks; fully distancing from task details can cause disconnection from team members, posing significant long-term risks to execution outcomes, priorities, and trust.
So being a manager doesn’t mean you stop doing engineering work; you need to engage in both and find a balance between the Engineer (Maker) and Manager roles.
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 being interrupted is actually part of a manager’s job.
But we also need to be both engineers and managers, so what should we do?
The author suggests creating two Calendars: one as a Maker (engineer) and one as a Manager. Each morning, spend 15–30 minutes organizing your thoughts and planning your day, including what tasks to do, meetings, and continuous free time slots that can be used to tackle 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 focus time is more important to us now than before.
The author mentions that you can signal to your teammates during focused work time with certain actions to indicate, “Please don’t disturb me for now!”
Methods include: going to a meeting room, wearing headphones, or even buying an ON AIR! switch light to place on your desk.
If it’s not an urgent issue, ask your teammates to leave a message or compile the information in an email for you. Then handle it after your focused time is over.
Assessing Tasks You Can Complete as an Engineer Within Your Time
Since you can no longer fully focus on development tasks as when you were purely an engineer (Maker), you need to choose tasks you can personally execute based on the time available in the engineer’s calendar.
Do not become the technical bottleneck of the team. Our mission is to enhance the team’s capabilities, explore new technologies, and broaden the company’s internal and external technical vision. Possible actions include researching technical issues in advance, sharing findings with teammates and letting them execute, resolving company technical debt, improving processes to increase development efficiency, adopting new technologies, open-sourcing company technology, providing open APIs, hosting external hackathons, and more.
The Most Important Thing is Balance
The author suggests starting with a 15–20% allocation. Originally 100% as a Maker, it could now be 20% as Maker / 80% as Manager (depending on the team size and members’ abilities, 50% / 50% is also possible). The key is not to spend 100% on engineering development but to invest more effort in management.
Make Good Use of 1:1 Meetings
Regularly have 1:1 meetings with teammates to give mutual feedback and share what you’ve learned.
If Management Tasks Consume All Your Time
The author finally mentions that if you have too many management tasks and cannot do engineering (as a Maker), losing touch with tasks and technology, consider working from home a few days a week to isolate yourself from the company or join 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 can improve our skills if followed, such as pair programming, code review, and design patterns. But as managers, especially beginners, we often feel quite lonely.
We don’t want to admit that we know nothing about our superiors or subordinates, fear taking responsibility for the team’s success, and worry about not balancing technical (debt) and business needs properly.
The author mentions stepping out to seek ways to improve management skills by openly requesting feedback and enhancing managerial abilities; being a manager with the same passion as when working as an engineer.
Documenting & Reviewing Decisions
Colleagues and bosses are powerful resources we often underestimate. We can quickly learn from their feedback. Establishing good records and regularly reviewing decisions helps us receive better feedback.
The author mentions:
“There is no one right way, there are only tradeoffs.”
I think so too. If it weren’t a dilemma, you probably wouldn’t ask me; asking means the teammate doesn’t know how to decide.
We can list options and provide decisions to teammates, but at the same time, we must also record the decisions made.
Template of the Record Sheet Provided by the Author
Develop the habit of documenting, and ensure the content can be recalled later.
The author suggests conducting a monthly review, sharing and discussing decisions with your boss, other managers, or colleagues (sharing at least half of the issues). Listen to others’ perspectives; anonymity can be used to protect individuals, focusing on the issue, not the person, and keep a record.
Key Points When Reviewing
About the Question:
-
How many technical issues does it cause?
-
Is it a personal issue?
-
Is it an isolated issue with a specific member? (Is it simply that they don’t understand the goal?)
-
Does this issue recur in other teams?
About Decision Making:
-
Does this issue really need a manager to decide?
-
Have you asked your teammates for their advice?
-
Is there anyone more experienced who can offer advice?
-
Would you make the same decision if you reconsider now?
Lesson 3. — Confront and challenge your teammates
Encourage teammates to step out of their comfort zones while avoiding becoming a jerk or falling into traps.
The author mentioned that at first, it was hard to get used to, since colleagues who were once friends became subordinates. He was afraid of damaging the original relationship, so he took on all the finishing tasks himself. But eventually, he realized that the more he tried to protect, the farther he distanced himself from his teammates. By repeatedly burying himself in work without sharing, he caused his teammates to lose faith.
Looking back, the author says that instead of fearing hurting teammates’ feelings, it’s better to speak your true thoughts. The “fear of hurting teammates” is simply a selfish imagination and is unnecessary. Moreover, it is the manager’s responsibility to lead the team forward and grow; you must keep the big picture in mind and control risks.
Sharing honest thoughts is difficult for both sides, but it is the responsibility of a manager.
We need to show empathy, not sympathy. To help them truly excel in their work, they need our objective feedback.
The author provides the following three points to help us balance emotions and behavior:
-
Did I show empathy?
-
Did I clearly state my expectations?
-
Do I lead 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 accept that not everyone will like your ideas.
Four Common Pitfalls:
-
Compared to covering up, have I openly shared my failure experiences? (This can be writing articles or sending emails to everyone)
-
Forget to consolidate discussion results (Get into the habit of recording 1:1 and discussion outcomes)
-
Using the wrong feedback medium can prevent you from identifying the real issues (find the appropriate feedback channel based on team culture, e.g., 1:1).
-
Delayed Feedback
We need to recognize that engineers enjoy challenging themselves and improving their skills, while also wanting respect and feedback from their managers. Our role is to lead the team’s growth, so we should never delay giving feedback when the opportunity arises. Not making a decision is also a decision. Moreover, once the culture of feedback weakens, it becomes much harder to reignite.
Summary
You can take time to write down ways to motivate teammates and ask your manager if you are being too protective of them.
Lesson 4. — Teach how to get things done
How to Complete Tasks with Lower Risk.
Leading by example is a good approach. Occasionally participate in the team’s development to demonstrate how to plan and deliver quality features that reflect the values we want to convey. Also, focus more on explaining the Why? and less on the How?
The author mentions that an extremely transparent culture, where team members have full context, can enhance their ability to drive decisions.
Reducing Risk
-
To reduce the risk of deliverables, 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 (toggle)? If there is no backup plan, it’s better not to implement it, as it can impact team confidence. -
Break down tasks into smaller tasks to reduce deadline risks
It may be difficult at first, but it can be trained and learned. -
Leverage Peer Pressure
Break tasks into parts for teammates to collaborate on and work together (Code Review is also part of this). -
Continuous Internal and External Communication
Internal: Ensure expectations, alignment, deadlines, and resources.
External: Communicate clearly, and if time is tight, skip non-essential meetings. -
Support, Bug Fixing, Documentation
It’s not enough to just release features; you also need to provide good customer support, fix bugs, and maintain documentation. -
Conduct effective retrospectives and delegate tasks to provide 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 without losing quality and visibility.
As a manager, task delegation must be done well. The author believes delegation should involve setting clear expectations and trusting that the assigned team members are capable, have opportunities to learn, and room to make mistakes. On the other hand, managers also need to protect their team members from company pressure.
The author uses the following table for recording:
This section mainly records tasks important to the team’s goals; routine work does not need to be documented.
- Must write down the task details
When deciding whether to delegate a task to a teammate, the author first asks if the task truly can only be done by themselves and if it belongs to the manager’s responsibilities. The second question is whether the task is a long-term leadership task. If neither applies, the task should be delegated to a teammate.
For tasks to be delegated, assess teammates’ experience and skills to find the right person.
-
External Resources or Expectations from Above (Feedback/Tool)
-
Delegate
For the Delegate part, we can provide a one-page paper outlining our expectations and simple examples.
Lesson 6. — Build trust with other teams in the organization
The rapport between teams and cross-team collaboration.
The author explains that organizations split into many small teams to enable faster decision-making and execution; defining each team’s direction is actually easy (e.g., iOS team focuses on iOS apps), but aligning the goals of all teams is the difficult part.
The more teams there are, the harder it is to align everyone’s values, expectations, priorities, and implicit assumptions.
Focus on the reasons and motivations for splitting the team rather than the output, as otherwise it may lead to conflicts.
The author suggests the following methods to align the direction of each team:
-
The team should have a vision, not just focus on completing tasks.
-
Managers Need to Distinguish Between Needs and Wants
-
Optimize the team to complete the right things faster, rather than doing more things.
-
Establish Good Communication with Other Team Managers
The author suggests sharing your team’s status, obstacles, challenges, upcoming key tasks, and the reasons behind them during bi-weekly manager meetings. -
When there is a difference in priority opinions with other teams, explain by bringing up other factors (e.g., completing this will reduce customer complaints, provide a one-time permanent solution, or have a multiplier effect…).
-
First understand where external teams need our help and proactively follow up closely.
-
Next, outline the points where our team needs help from external teams.
-
Make a checklist to confirm that all items are discussed during the meeting; if not, follow up with relevant managers afterward to explore other possibilities.
-
If it is not possible, weigh the potential delay or alternative solutions, and inform stakeholders (to prevent gossip behind the scenes).
-
Everything Is a Trade-off
Additionally, here are 5 more ways for teammates to build close relationships with other teams:
-
Simple Thank You Letter (Thank You for Your Assistance)
-
Rotating Team Work
-
Internal tech annual meeting, sharing with each other
-
Observe user behavior together and brainstorm optimization ideas collaboratively
-
Invite 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 decrease even if the priority change is justified.”
“difference between transactional trust and relational/emotional trust”
-
Understand transactional trust and relational trust.
-
Transactional Trust — Whether people will keep their promises and complete tasks.
-
Relational Trust — Do people act in ways that build and protect relationships?
Lesson 7. — Optimize for business learning
Building a culture of business learning instead of just building culture, optimizing throughput, and the value of optimization.
-
Premature Optimization Is a Disaster
-
Optimize current problems first; avoid optimizing just for the sake of optimization.
-
Even if you are not responsible for the entire project, you can still optimize internal operations. Major successes often come from the accumulation of small improvements.
-
As managers, we must demonstrate the motivation behind our decisions.
-
Build a culture of business learning (value) rather than just building solutions (the focus is on the business problems we aim to solve).
-
Optimization of Efficiency vs Optimization of Throughput:
Optimization of Efficiency: Reducing the time to complete a single task
Optimization of Throughput: Increasing the number of tasks completed within a time frame (e.g., a quarter) -
Know the impact of each optimization.
-
The Importance of Automation (Save Time Once and for All)
Optimize Value Using the AARRR Framework:
-
Acquisition: How to Attract More Users
-
Activation: How to guide users to complete tasks that help them understand the product’s value (e.g., Alarm App, onboarding users to set up an alarm)
-
Retention: Increase return rate and frequency of use
-
Referrer: Let Your Users and Content Bring More Traffic
-
Revenue: Digitally assess the revenue generated by users
These five factors are closely related. If Retention is low, Referrer and Acquisition can be adjusted simultaneously.
As engineering managers, our job is not to bury ourselves in coding or focus solely on technology; we should periodically realign with product value.
When the product is still in the early market testing stage, the focus should be on optimizing efficiency (quickly solving tasks and releasing), repeatedly following the process below:
Features can improve retention -> Release features -> Learn -> Adjust & repeat.
Evaluate areas for improvement at each stage from feature assessment to release (spending too much time on design? on discussions?).
Can you invest 20% of the time to reduce 80% of the development time? Especially the painful parts.
Can you first experiment or release it to the smallest audience? This avoids having a large feature that ends up unused.
- To do effective data tracking, you must understand the impact of your efforts
“If you can’t make engineering decisions based on data, then make engineering decisions that result in data.”
Although “the company will fail without this feature” is obviously scarier than “this feature will cause technical debt,” as managers, we should strive to secure more time to address technical debt when possible. We must communicate and manage it properly.
Optimizing code that may never be used is not very meaningful.
-
After the initial trial phase, the product model tends to stabilize; at this point, it is more suitable to optimize throughput (e.g., given X resources, achieve Y output).
-
Provide Predictability for Business Requirements (Same as Above)
Tracking team output (e.g., “01/01/2013–14/01/2013: 2 Large features, 5 Medium features, 4 Small”), based on long-term statistics; this can be used for forecasting.
Identify & Resolve Bottlenecks:
-
Synchronous Communication: For example, in the product development process, design resources are needed; when entering the engineering development phase, do we already have clear specifications to proceed with development? Or are we still waiting? Is there anything we can do in the meantime?
-
Infrastructure: Making Code Scalable and Maintainable
-
Automation: Use automation to handle tedious manual tasks, saving time and reducing errors
Because business strategies change constantly, we should maintain an open and flexible mindset toward optimization strategies. Ultimately, optimization should be driven by business needs.
Lesson 8. — Use Inbound Recruiting to attract better talent
About Recruiting.
You should start doing the following regularly to avoid suddenly facing a talent shortage. Otherwise, you’ll have to rely on traditional hiring methods, conducting endless interviews but struggling to find the right candidates.
Internal:
-
Foster a positive engineering culture environment (e.g., Code Review, annual meetings…)
-
Creating an attractive work environment
-
Like managing a brand
-
Team members working together
-
Strengthen human connections (e.g., birthday celebrations)
-
First, make team members feel proud of the team
External:
-
Internal teams regularly answer community questions weekly (e.g., Stackoverflow) to increase exposure.
-
Hiding recruitment Easter eggs in code (e.g., Web Developer Tools)
-
Share with the community the problems our team encountered and the solutions we implemented (article or talk)
-
Holding a hackathon
-
Create side projects (e.g., open source projects)
Assign the above tasks to team members so everyone can contribute to finding great talent together.
Lesson 9. — Build a scalable team
Building a scalable team.
Building scalable software used to be our responsibility as engineers, but now the challenge is to build scalable teams.
Unlike programs, people have expectations, needs, and dreams to consider.
The author aims to create a happy work environment where teammates understand task expectations and face new challenges, while continuously maintaining their passion.
-
Aligning Goals
Align personal vision with company goals. Not understanding the current company goals can lead to team dysfunction. -
Align Core Values
This refers to consensus and tacit understanding regarding ways of working and what is important. Team core values are not fixed and should evolve over time. -
Balance
Assign different visions, autonomy, and ownership according to team members’ skills and growth; collaborate and grow together (e.g., newcomers expect to understand company workflows, veterans handle code reviews and mentoring); everyone should have opportunities for growth. -
The core values of the group outweigh those of individuals.
This may lead to some people leaving and requires patience and time to achieve; there are also many challenges (e.g., when someone leaves, the core values may be questioned). -
Sense of Achievement
Results should bring a sense of achievement. As a manager, you must not let your team members lose their enthusiasm.
Practice
-
Define the Team Vision
EX: The author’s team works on web crawlers, 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 they want to avoid. -
Define Core Team Values
When choosing core values, ask yourself, “Is this value important enough to fire someone for not having it?”
Write down the core values and the reasons behind them.
The author provides the following core values he wrote:
-
Don’t let others (other teams) clean up the mess; your own (team’s) mistakes must be owned by yourselves.
-
Be Loyal and Respectful to All Team Members
Having core values provides clear criteria for recruitment or termination and sets a standard for how to get things done.
Defining Members’ Expectations for the Team and Manager
-
Provide a productive and happy work environment
-
Understand the Why of a task, not just the How
-
Be able to receive genuine feedback
-
Opportunity to lead other members
-
Able to share work results
Define Expectations for Team Members
Basic Expectations:
-
Task Completed
-
Maintain a Passion for Learning
-
Maintain enthusiasm for sharing and teaching
-
Know the bottom line sense of getting things done
Personal Expectations:
-
Set Expectations According to Ability
-
Ability to train others to change
-
Drive Change, Not Complaints
We are a team. Each member has their own responsibilities and deliverables, while also collaborating with others, helping each other, and growing together. Defining expectations is like a contract; under the shift from colleague to manager relationships, it enables better and more purposeful leadership. 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.”
Comments