Engineering Management : Lessons learned in first year
It’s winter season and am getting close to a year of full-time engineering management. So, I’m listening to some jazz house music and reflecting on what I have learned.
While I have done tech lead roles before, this is the first role I’ve been doing people management full time, i.e. not doing the tech myself.
Why did I take up this role?
(a) Every now and then in my career, I have experienced badly planned projects and, worse, disoriented teams, and I wanted to see if I could do it better. It was time for new kind of challenges.
From The Tao of Programming :
A novice asked the Master: “In the East, there is a great tree-structure that men call ‘Corporate Headquarters’. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying ‘Go Hence!’ or ‘Go Hither!’ and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity exist?”
The Master replied: “You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?”
(b) I was starting to wonder if my number of years of experience would start becoming a liability in my role as a developer, so I wanted to have experience in a different role where my impact and contribution can continue to grow.
(c) Once I became a parent, my people perspective changed so much, that I felt I can finally do a management role.
Fundamentally I believe managing is like parenting. You never graduate. You will continue to hone these skills for your entire career — delegation, patience, managing UP, building trust, etc. Even if you get decent at one in Q1, you may struggle in Q3 because the humans you are working with and for will evolve! They’re like moving targets. But with awareness and intention, commitment and a peer group of folks who are also managing alongside you, managing is incredibly rewarding and growing and the years of experiments and anecdotes they build up will make really fascinating and stretching careers for them all.
(d) I wanted to work on longer-term initiatives (as compared to individual projects). As the Ancient African saying goes:
If you want to go fast, go alone. If you want to go far, go together.
Take up this role only if you want to be people-first
This role is not about the tech. It is also about the tech. It is primarily about the people.
I used to remind myself of this everyday, first thing in the morning, for the first six months. I took it so much to heart that I actively avoided any coding, which was a stark contrast to me writing Erlang/Elixir code a few days before I started at my current job. I was actively avoiding doing the thing that I’ve been doing full-time for the past 13 years.
I was fighting my instincts. But I wanted to learn how to do this thing right. My puzzle was no longer technology. My puzzle was humans. I had to switch from “ignore-the-human, solve-the-problem” approach to “solve-the-human, ignore-the-problem” approach. So I reminded myself to trust my reports that they will solve the tech, the tech is not my job any more.
Caveat is that I reserved the right to veto anything or mandate anything that I felt was necessary. For example, yes, we are going to spend the time to upgrade our Python codebases to Python 3, it is necessary. But how are we going to architect this new microservice? That’s the teammate’s job. My job is to ensure they are unblocked in every step. My job is to combine my engineering experience with people-oriented focus to make the team more effective and productive, not do the engineering itself.
Remember, remember, management is not a promotion, it is a career change.
Only 2 things matter : Results & Retention
These are the fundamentals. Everything else is a distraction.
Results means ensuring projects are delivered on time and deliver the desired results, e.g. increased revenue for the company.
Retention means ensuring that teammates are engaged in their jobs, are unblocked in performing their tasks, and that they have challenging projects and career growth.
Retention also means hiring and expanding the team. What I wish I knew much earlier was that this should take up a lot of my time. This includes so many things such as capacity planning for next year’s projects, getting approvals for additional roles, actively reaching out to prospective candidates (not always possible), following up with internal recruitment team to make sure we are moving fast and discussing salary ranges and compensation, ensuring candidates are engaged during the interview process, if a good fit was found, ensuring candidates are engaged after the interview process, and so on.
From Liz Ryan :
If you’re having trouble finding great people, either your recruiting process is broken, your company culture stinks and the word has gotten around, or you’re not paying enough — or all three.
Of course, there is a balance to be maintained between ensuring results and ensuring retention, that’s part of the challenge of the job.
I like frameworks, like Modern Agile
I find a lot of good inspirations in engineering for a management role, it’s easier to relate to bottlenecks, for example, parallelization means more throughput, and so on.
My favorite engineering management framework (a.k.a. mental model) so far has been Modern Agile by Joshua Kerievsky. It most closely resembles my working style:
Learn more in this quick podcast:
Another way of explaining Modern Agile:
Always Be Learning, Trying, Reflecting
I have read and listened a lot to get a handle of engineering management:
- The First 90 Days book
- Leading Snowflakes book
- The Manager’s Path book
- Running Meetings book
- Amazon Leadership Principles book
- Manager Zine by Julia Evans
- Basecamp handbook
- GitLab handbook
- How to fail as a new engineering manager in 8 easy steps
There’s plenty more to read!
Some of my favorite learnings are from avenues such as Twitter meetup on Engineering Management and True University. There’s a lot to unpack from just these two events, let alone the books above, maybe that’s a blog post for another day.
I was able to collate many of these ideas and put the frameworks into practice by writing and referring to my own Commonplace book 😄
Remember, the whole point of learning frameworks / mental models is to setup repeatable healthy processes, i.e. good habits!
Communication is Hard
Communication is the hardest thing in our careers. Just accept it!
Other things to keep in mind is:
- Tailor communications to each person’s way of understanding and interests. Some people are text-oriented, some are verbal-oriented, some are visual-oriented, some are interactive, some take time to reflect, and so on.
- Attention is tweet-sized. Nobody reads longer than few sentences, unless it’s directly related to task at hand.
I strive to encourage specific questions and actionable discussions. But communication is hard. Sigh. Accept it.
As you can tell, I adore the Manager Zine by Julia Evans. Go buy it.
Anti-DRY
In engineering, DRY is valued. We talk about it in many different names – modularity, reusability, microservices, etc.
In engineering management, the opposite is required – Keep repeating yourself, because it takes reinforcement learning for humans to change their habits.
This was one of the hardest things for me to learn.
From “The Manager’s Path” book, chapter 8 – The Big Leagues:
Never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in. … You’ll also need to repeat information when you’re communicating up. When you want your boss to act on something, expect that you’ll need to tell him the same thing three times before he actually listens.
Roll up your sleeves and get to work
There has been many a time that I need to jump in to nitty-gritty tasks.
I ensure that I’m never writing code for the critical path of projects (that’s the team’s work).
But I do jump into tasks such as anything that is important for other teams but does not warrant disturbing focus of my team, such as writing a data export job.
I’m the “odd job janitor” in the team. Surprisingly, I’m comfortable in this role.
Oh, there’s more
- Regular 1:1 sessions with your direct reports
- Ensure engineers are in flow state
- Creating a Career Growth Ladder for the team
- Regular Feedback
- Formal Performance Reviews
- Salary Appraisal
- Project management
- Software development process
- Tools
- etc.
Phew!