What does it really mean to be an Engineering Manager?
I first heard about the term Engineering Manager when offered the role at Blinkit (formerly Grofers). I had heard about Product Manager, Project Manager, Tech Lead and Account Manager. But “Engineering Manager” was the first time I heard about the role. So naturally, I started Googling and reading up more about it. My initial sense of the role was “A project manager from Engineering Background.”
What is the Engineering Manager Role?
I used to joke that an Engineering Manager is one who is neither good at engineering nor good at managing people.
But jokes aside, I think an engineering manager is moderately good at engineering and managing people (especially engineers). A friend of mine suggested that engineering managers are better engineers than most managers and better managers than most engineers. I think that makes a lot of sense. Today this role is well defined but was not always the case.
I think I was the first(or at least the first few) in Blinkit with the actual title of Engineering Manager. When I started talking to people, I realized that there was no clear-cut definition of the Engineering Manager role, but everybody had a broad consensus on what an Engineering Manager should do.
The way I defined this role and responsibilities for myself was:
- 33% product management
- 33% engineering
- 33% people management
The remaining 1% was the buffer
This mental model worked pretty decently for me, and even to this day, this is what my idea of Engineering Manager is. Based on whether we have a dedicated product manager in the team or not, the split of product management effort varies, and the remaining generally gets split between the engineering and people management.
Starting out as an EM
The questions and the self-doubt
I have been a delivery manager for the whole web practice in my previous company and was a co-founder in my earlier startup, but I was never part of a growth phase startup. So naturally, when I joined Blinkit as an Engineering Manager, I had my fair share of doubts and questions.
These were some of the questions I had initially when I started.
- Am I good enough to be an Engineering Manager?
- Am I really adding value to the team that I am managing?
- Will I be relevant if I don’t code regularly?
- Should I do more stakeholder management/product management, or should I concentrate on the engineering side?
- Does my team trust me enough?
- Am I vulnerable enough with them so that they can trust me?
- Am I helping my team to reach their true potential?
The realization that you might never have definitive answers for any of these questions was a great unlock for me. I have learned to live with these questions, and I have realized that I will keep on getting better clarity around each of these questions organically with time.
Each of these questions merits a separate blog on its own. I will just leave them here so that you know that having these questions is normal and is, in fact, good because you have the right intentions and mindset.
Does Engineering background matter?
Engineers are some of the best problem solvers I have come across. So naturally, when I got to know that there was a restriction that everybody who manages engineers directly in a team at Blinkit should be from an Engineering background, it made a lot of sense to me.
Having empathy for the engineers and having gone through a similar journey as that of the engineers we are managing adds a lot of value. I know of the blind spots that I faced as an Engineer, and I try to highlight these to my team regularly.
Also, I felt that those from engineering backgrounds can appreciate the complexity of the problems, understand why some tech solutions take time, make other stakeholders understand why addressing tech debt is essential, and better empathize with the engineers when things don’t go as planned.
Important traits an EM should possess
Getting the right amount of Clarity
In a fast-growing startup, being comfortable with lack of clarity and having the mental toughness to navigate chaos are important traits for managers and leaders.
Most of the things we pick up may not have complete clarity. The framework that I follow includes:
- Getting clarity for myself.
- Passing on the clarity to the team.
- Helping the team to find their clarity.
If you are in a rapid growth and experimentation mode, you might end up shelving many of the not so successful experiments as you decide on the bets you need to double down upon. This happened with our team multiple times this year. One approach we took was to accept that all things we build may not be used eventually. So we started looking at artifacts from each experiment that we can use in the core priorities of the team which will not change over the time. For our team, store live optimization, product live optimization and migrating price/inventory data were such common tasks.
Asking the right questions
In a recent conversation the other day with a friend of mine, I told him that “we engineering managers get paid to ask the right questions.” I think this is broadly true for many leadership roles. However, engineering managers also need to follow through and are responsible for implementing the solutions gauged by asking those questions.
As I mentioned earlier, Engineering Managers are generally moderately good at Engineering and not necessarily the best engineering minds in the team. That is why we have SDE3s and Staff engineers whom we can consult before making the critical architectural decisions. Not being the best in engineering shouldn’t stop you from asking the right questions and sometimes challenging questions.
The same holds good for everybody else in the team. Even an SDE2 or SDE1 should be able to debate the approach we take. We try to build such a trust-based environment within the team.
Unblocking and Unlocking
This is Something that I ask myself each day. I try to start my day before my team starts. Slack notifications affect my thinking process. So I try to do the important things before my team starts working.
Each day I ask myself what are the three important things that our team is working on. I try to get clarity on these.
Then I ask myself who is blocked on something and what I could do to unblock them. While I unblock them, I make it a point to highlight what I did and how they can do it independently. Being blocked on something and not delivering in the short term can quickly frustrate engineers, so generally, I try to concentrate on this first and get them sorted out.
While I look at Unblocking as a short-term thing, I look at unlocking as the long-term lever. During my one-on-one, I ask my team what is stopping them from being their best version possible or doing their greatest work. Then I try to see what I can do to unlock their true potential by any help that I, the team or the org can do.
We all know that most of our effort should go into unlocking the team’s potential, but most of the time, we are bogged by unblocking them for the short term. A proxy I have for this is how much of my time is going in Hustle versus Strategic activities. Lately, I am asking the same question to my team so that they are aware of how much of their energy is spent on hustle versus long term. Sprint Retros are a good time to do this.
We do sprint retros just before sprint planning so that we can also implement the suggestions right away.
Another hack we are trying to use of late is to have one person work on short term things(on calls, ad hoc feature requests) completely, and others work on long term things(clearing tech debt, changes for future) while the rest of the team works on the current sprint goals.
Baggage that comes along as an EM and how to tackle them
One-on-Ones
As Engineering managers, we are directly responsible for the career growth of engineers in our team. I think that this is one of the most critical responsibilities of an Engineering Manager.
In the initial days, I used to club all of my one-on-ones to a single day as I felt that it should not affect my normal flow of the day on most days.
As the team started getting bigger, this was practically impossible. At its peak, I was managing a team of around 15 people, and there was no way I could squeeze them in a single day. I also realized that when I had more than two one-on-ones, I could not connect entirely with the people I was having a one-on-one with. So I started spreading them across the week. Nowadays, I try not to do more than two one-on-ones on a single day.
But as I progressed, I also realized that this was the most critical part of my role as an Engineering Manager. So now, I have distributed them across the week. I try to make sure that all my notifications are turned off during this call to immerse myself in the conversation altogether. Today, this is the favorite part of my job as an Engineering Manager.
Incentive Alignment
When incentives are aligned, we need significantly less external motivation. The problem with external motivation is that you need a constant supply, which is generally not the case with internal motivation. So it is always better to count on internal motivation, and I strongly feel that internal motivation comes from the right incentive alignments.
The way I look at this is higher the intersection of interests better the outcome for everybody. Three parts of this alignment are Individual, Team and Company. During my one-on-ones with my manager and Town-halls, I try to get a handle on the Company goals and try to see how we can overlap the company and team goals. During my one-on-ones with my team, I try to identify the individual interests and see how we can coincide them with the team and company goals.
People will be more inclined towards working on something they are curious about.
We try to figure out some scenarios where we can use that in the work we are doing so that their personal interests will drive what we are doing at work, and the time they spend on work will further push their curiosity. In the past, we used individual interests like Exploratory data analysis and Machine learning interest for solving some issues in our projects.
Process
People versus process is a debate I keep hearing generally. But I feel that they are mutual.
Good people help improve processes, and good processes help people work on high-impact stuff.
We inherited a system that was a critical part of the most critical flows, which had less visibility within the org and was not actively maintained. We definitely needed heroes to pick up the project, which we had in the form of Ishaan. But very soon, we realized that he was the Single Point of Failure for our team. So we started working on building redundancy for him. Today we are in a better position, but we still have a long way to go where we can upgrade the system to the latest tech stack as we intend to.
Three approaches we are planning to take for this are
- Removing the heroes: Rotate more often or make everybody a hero.
- Checklists: Have checklists for all critical actions we perform.
- Documentation: For Business stakeholders and devs.
Three hooks in the chain visibility problem
The issues pretty much blinded us for the first couple of quarters, and we were busy keeping the lights on mode. We mainly interacted with the business team, and their immediate needs drove our roadmap.
Post that, when we started talking to different stakeholders, we faced one challenge: most people had only three hook visibility. The hook they are responsible for, the hook that provides inputs to them and the hook that they provide their output to. After having calls with multiple stakeholders, we were able to draw up the workflow from end to end. This highlighted the scope for improvements that were not local optimizations. Cross-functional teams that are created have helped speed track some of these initiatives.
I personally feel that Engineering managers and above should spend more time getting this visibility and driving initiatives that are based on the insights that such teams provide.
