Alone.

If I had to choose a single word to describe how I felt in my transition from an engineer into a manager, that would be it.

As much as I was excited, I was also terrified. We were never taught the dark art of building a team or leading people. As if this isn’t enough, these unique individuals in our team tend to be incredibly smart, analytical, opinionated, self-driven, and ambitious. Engineers.

- Oren Ellenbogen, in Leading Snowflakes

Every engineering manager can relate to that.

In his short-no-nonsense book (~100 pages), Ellenbogen covers the 9 main lessons he learned along the way. He was a developer, a founder / CEO, a founding engineer, a head of engineering, a VP, and now the SVP of engineering.

Today I’m going to cover my 5 favorite lessons from the book, and Oren will share the 2 missing parts he would have added to a 2nd edition. Worth reading till the end :)

For a deeper dive and the other 4 great lessons (like scaling your team and teaching how to get things done), check out the book. You can use the CRAZYWEEKEND code for a 50% discount. (Not sponsored and not affiliated!):

Check out Leading Snowflakes

Oren also writes Software Lead Weekly for the past 12(!) years, a Friday newsletter that curates the best engineering management articles.

Alright, let’s dive in:

1. Switching between “Maker” and “Manager” modes

When we go from a “Maker” into a “Manager” role, we often fall back to our comfort zone. We’re neglecting managerial responsibilities working to complete yet another task instead.

It’s much more fun (and immediate!) when getting the work done is completely in our own hands. But let’s face it - no one is being promoted to a managerial position to increase their own productivity. Our job as managers is to amplify our teammates.

The tip

A small trick I found useful is to visualize my calendar using different colors. I use 2 colors – one for the Manager (blue) and one for the Maker (yellow):

I’ve blocked specific ‘Maker’ hours during the week in advance so no one else could set a meeting for me at that time.

I make sure to keep my tasks small (<4 hours) and not on the critical path.

I usually chose one of the following:

1. Boosting my developer’s velocity - reducing tech debt or maybe creating a tool to cut down needless work. I find this approach both fun and valuable - I feel productive both as a Maker and as a Manager, plus I win my teammates’ appreciation.

2. Exploring a new technology or process that my team recently adopted.

3. Boosting our company’s ability to attract and retain talent - like creating a website that would show how awesome our team or company is.

Anton here - this tip was HUGE for me! Choosing what tasks you work on is critical when you have so little time to code.

2. “Code Review” Your Management Decisions

Engineers are taught how to make technical decisions. You first participate in design reviews of senior engineers, and then you start to lead them yourself. You get feedback from more experienced people, and develop your own system of assessing the tradeoffs and reaching a decision.

Engineering management is NOT like that.

You are expected to make most of the decisions yourself. You don’t want to admit that you don’t have a clue to your boss or teammates. you are afraid to show how frightening it is to be responsible for someone else’s success.

The tip

Start by writing down your decisions. Any time you have a dillema, just note it in a spreadsheet.

Then, in your next 1:1 with your boss, pick 2 dilemmas from your list and conduct a “code review” on your decisions. I recommend that you start by describing the dilemma (not the decision!) and let your boss say how she would handle it.

Only then, share the decision you’ve made at the time, and see how she reacts to it. Have an honest discussion, and talk about the tradeoffs as you see them.

Another great option is to find a fellow Engineering Manager in the organization you trust and do that exercise in turns. Sometimes just the act of presenting our dillema to others will be a huge step forward, even without the feedback.

3. Confront and challenge your teammates

When I was promoted, I was doing everything within my power to avoid hurting my team and remaining their friend:

• “This is not the way to write maintainable code, should I tell him that?”

• “This estimation sounds wrong, should I say something?”

• “We need to stay more hours this week, should I force everyone to come earlier or leave later?”

The tip

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.

Anton here - this is my eternal struggle. I covered my own experience in the article:

4. Build trust with other teams in the organization

Once we start building better communication with other managers, how can we build trust between our teammates and other teams in the organization?

Here are a few ideas that could help with this effort:

• A simple “Thank You!” email - during one of your team’s meetings (e.g. Sprint Retrospective), try to come up with one individual from another team that helped the team to achieve its goals. At the end of the meeting send an email with a simple “Thank you!”.

• Internal tech talks - hearing what engineers in other teams are passionate about or dealing with can have long-term affects, as people will feel more comfortable reaching out to each other and exchanging ideas.

• Cross-team exchange program - it can be as small as a single task, or even a few sprints. There are triple benefits here:

  • Your developer will get to know the other team better.

  • She will share with them what things your team is doing and can help them.

  • She will come back and share with you what THEY do well and you can do better (happened to me!)

5. Optimize for business learning

As Engineering Managers, it’s up to us to protect the team from investing in the wrong place. While we may feel this is the CEO’s or the Product Team’s responsibility to make such decisions, it’s our job to make these tradeoffs visible. We cannot afford to bury our heads in the code, hoping things will be fine.

Technical Debt is less scary than getting out of business - optimizing code or scaling up components that may or may not be used is sticking our heads in the sand.

I love to use the famous Pirate Metrics (AARRR) framework for that:

• Acquisition – Figure out how to bring more users to our application.

• Activation – Make sure the user enjoys 1st time experience.

• Retention – Increase repetitive visits to our application.

• Referrer – Incentivize your users to bring their friends.

• Revenue – Monetize our users.

If our retention is pretty low and our visitors do not come back to use our application, then we shouldn’t invest money in acquiring more users just yet.

Or, if our activation is poor and almost no one completes the task we believe represents best our value, then investing time in improving retention would probably be a complete waste.

Anton here - this was my favorite part of the book. It falls to us, the engineering managers, to ask the PMs the hard questions. We are the final gatekeepers of the business.

The missing parts - by Oren

Ten years have passed since I published Leading Snowflakes.

If I had to go back and work on a 2nd edition, I'd cover two more areas I found foundational:

1. Helping managers to develop mental toughness.
   Leadership is lonely, we need to carry the expectations of our teammates and help them shape up bigger dreams. Building mental resiliency is a critical muscle - it's very hard to build a sustainable team that delivers well where managers struggle to keep up emotionally and technically.

2. Paying more attention to the words we say and the stories we tell.
   ”Burnout”, “Clean Code”, “Teams need to be more autonomous!”, “We have too much Tech Debt!” and so on.

   It became too easy to overuse simple words to describe a complex reality. This approach adds nothing but a false sense of curiosity and intelligence - and as leaders, it’s part of our job to ‘unpack’ those phrases.

I'm excited to see so many great resources becoming available to engineering managers - books, newsletters, conferences, and workshops. Our world is changing faster than ever, and I'm certain that the needs of managers will shift with it.

What I enjoyed reading this week:

1. What I Gave Up To Become An Engineering Manager by Suresh Choudhary

2. Why End-to-End Ownership Is Your Competitive Edge by Samuel Kollát

3. Complaint Filed About People Complaining by Michał Poczwardowski