Reflection on being an engineering manager, 1 year after (Part 1)

I’ve recently completed my first year as an engineering manager - specifically on the Site Reliability team for CloudVision as a Service at Arista.

In many ways I’m writing this for myself moreso than anything else - a way to reflect on this year that flew by so quickly, to catalogue what I’ve learned, to look ahead into next year. I also hope this helps anyone that is considering to step into management, not as a way to discourage, but rather to encourage by sharing lessons I’ve learned this year.

It would not be an exaggeration to say that this year as a manager and continued SRE team lead has been the single most transformational period of my life. In all honesty I’m truly grateful for this year as I never would’ve expected to have such a life changing, perspective altering experience.

Why I became an engineering manager

There were several reasons why I wanted to become a manager a year ago, but most importantly I wanted to become a manager because I was frustrated and wanted my team to change. My vision for the team conflicted with reality, and I saw manager title as a tool to help bring about the changes. A year later I would say absolutely, being a manager can help with such motives but I had failed to recognize the sheer insignificance of the title to do so. You can be a leader with any title - the title in itself does not give you leadership. Leadership is vision, dedication, passion, and relentless execution – none of which require titles. In fact, I would say titles are some of the most bogus concepts in our industry, but that is for another post.

What I’ve learned

🖼️ The other 2/3 of the picture

Projects with failing architecture design? Tasks slipping deadlines? Services being broken? Technical problems all around!

As an individual contributor I used to see most of any problem that existed as technical - someone wrote bad code (or I wrote bad code), sloppy design documentation, poor tools, you name it.

Now I see that technical challenges are only 1/3 of the picture. In fact, it’s the easiest set of challenges to fix because of the deterministic outcomes of technical solutions. The other components that are not as obvious are (1) failures in process (lack thereof, or having too much) and (2) people challenges. You manage the latter two as an engineering manager, in addition to the first.

Why are the latter two “hard” problems? Because they are incredibly difficult to validate, recognize, and may take a long time to see results, as well as not having any clear solutions. You can’t apply 1+1=2 logic to personnel challenges. Logic doesn’t apply to chaotic nature of human relationships and emotions. Finding solutions in such scenarios is your job as a manager. You’ll find yourself being forced to balance your intuition, common sense, and clear cut technical/logical reasons to find holistic solutions.

(I discuss more about this in Software: Looking Beyond Just the Technical).

🫶 Compassion

Engineers are people, first and foremost. Sounds obvious, right? Engineers get stressed; they cry when life and work becomes difficult; they celebrate when they just pulled off a big project; they are worried about their families; some are dealing with crippling aftereffects of COVID, etc –

– everyone has their unique story. See them as who they are, not headcount.

As a manager, you must become a ninja at reading people and being able to relate to how they are feeling. Nobody is slacking at work because they enjoy being a low performer. Nobody is a top performer because they are in love with working long hours. You must recognize what drives and motivates each person, which takes time and dedicated reflection to understand. Even then you’ll see that those motivations shift as people grow and change over time.

Of course, individuals must own their careers and their own personal successes themselves; but you are there to help motivate, plan/guide, mentor, and recognize what they cannot see in themselves be it skills, strengths, weaknesses, ways they can improve, etc. You’ll be required to tackle those red flags early, quickly, and discreetly. Maybe it’ll require you to tell them what they don’t want to hear, and trust me, it’ll be just as difficult for you as the person hearing it. It’s all part of the job.

⚓ If you falter, your whole team falters

If you’re unsure of the vision, your entire team will be unsure.
If your messaging is all over the place, your team will be all over the place.
If you don’t have a plan, then your team doesn’t have a plan (this doesn’t mean you can’t listen to other leaders in your team to help you plan).
If you don’t trust your team to succeed, they won’t.
If you don’t believe in your team objectives, your team won’t.
You lead by example.
You set the standard.

↔️ Management is a career shift

Management is not a vertical career growth. It is a lateral career shift, with your job function shifting drastically from an individual contributor role, and you have more responsibility than ever before.

Step into management because you want to lead, because you care about your team, because you are invested in how things are done, because you want to bring about change, because you want to solve complex problems –

– not because you just want a way to pad your resume, not because someone told you “it’s the next step”, not because “it’s an easy way to sit back and relax”, not because you just wanted that next promotion. Uncaring, unmotivated managers can do devastating harm not just to the team but to individuals, their careers, and business as a whole.

Ask yourself – What would you be proud of - being a manager who gives a damn about their team, or someone that just did it for the title?

– which leads to my next point…

⚓ You are there for your team, not for yourself

Attribute team’s success to the team and to the individuals on your team, not yourself. Any failures, you own it, for your team. Your team comes first, not you. This does not mean you should stop taking care of yourself, desires, or your own career goals. What this means is the success of the group comes first before the individual. It’s a subtle difference - learn to recognize it.

🧭 Provide the “Why”

Hone the skills to be able to tell a clear story on why for your team. Why does your team exist, why does the team work on X,Y,Z projects and why at this particular moment in time? Why are the processes structured this way and why do we keep them (or change them)? Why did we make these decisions? Etc. It’s your job to be able to provide a clear, concise narrative.

🌐 Broaden your view

Analogy time –

As an individual contributor, your view is like having a view of the city. You architect and understand deeply how that city works. You know the roads, how traffic flows, the people that live there. You might spend time building just one building even, and work with a team of others help create the city.

As a team lead, your view would shift to being able to see at a country level, with individual cities being connected.

As a manager, your view shifts to seeing entire continents at once while also seeing how continents interact with other continents at a global scale. You gain this view so that you can help those above you manage at planet level where business decisions are being made, and so that you can also explain to your team what is happening in the grand scheme of things - this will help explain the “why” (see point above).

🗺️ Decision making and leadership

You will become your team’s de facto decision maker for hard and hairy problems.

While ensuring your team members have agency in making their own decisions and personal ownership, you will be that person to whom decision making escalates to when nobody else knows the answer. You’ll have to create and destroy projects, negotiate, manage moods, direct, and decide when there doesn’t even seem to be a clear path. You’ll have to decide when others couldn’t and they come to you for help. You’ll become incredibly good at being able to identify benefits and risks of situations and make both short term and long term decisions - quickly, and often.

However, you must manage without getting in the way of those you manage. Step in when you are needed, not to override. Do not become the blocker for your team members. Trust them, which might seem super scary when you become responsible for success at entire team/org levels. Trust people will do the right thing.

🤔 Ask for advice

Every manager’s managing style is different. Ask other managers how they would manage a situation. It’ll help you see different perspectives, methods, and approaches. You’ll find your own style through this process.

👩‍💻 You will miss being an individual contributor

I became a software engineer because I like building systems. I’ll always love it, no matter the role. Some days I definitely miss being an IC, with my nose deep in coding and debugging, and that’s all I have to think about.

As a manager, make sure to make time to stay hands on. Continue to code, continue to debug, design, build. Keep learning, go to conferences in your field, and continue growing. You can do all the things you love and what made you become a software engineer in the first place while still being a kickass manager.

Have a good day! 😊 - Ren