I first heard about the term Engineering Manager when I was offered that role at Grofers. I had heard about Product Manager, Project Manager, Tech Lead and Account Manager. But "Engineering Manager", that was the first time I was hearing 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 Engineering Manager Role?

I used to joke that Engineering Manager is one who is neither good at engineering nor good at managing people. https://twitter.com/gokulnk/status/1317095411329363968 But jokes aside an Engineering Manager is one who is moderately good at engineering and managing people(especially engineers). Today this role is well defined but was not the case always.

I think I was the first(or at-least the first few) in Grofers with the actual title of Engineering Manager. When I started to talking to people I realized that there was no clear cut definition of 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 :P

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 spent between the engineering and people management.

The questions and the self doubt

I have been a delivery manager for the whole web practice in my previous company, co-founder in my previous startup but I was never part of a growth phase startup. So naturally when I joined Grofers 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 out.

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 of 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 all of these questions and I have realized that I keep getting better clarity around each of these questions organically with time.

Each of these questions merit a separate blog on their 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 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 Grofers should be from 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 guess. I know of the blind spots which I had faced as an Engineer and I try to highlight these to my team regularly.

Also I feel that those who are from engineering background can appreciate the complexity of the problems, understand why some tech solutions take time, can make other stake holders understand why addressing tech debt is important and can better empathize with the engineers when things don't go as planned.

Getting Clarity

In a fast growing startup being comfortable with lack of clarity and having mental toughness to navigate chaos are important traits for managers and leaders.

Most of the things we pick up may not have full clarity. The framework that I follow

Get the clarity for myself.
Pass on the clarity to the team.
Help the teammates to find their own clarity.

If you are in a rapid growth and experimentation mode you might end up shelving many of the experiments as you decide the 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 that will not change. For our team store live optimisation, product live optimisation and moving price/inventory data to the respective names services were the common things.

Asking the right questions

In a recent conversation the other day with a friend of mine I was telling him that "we engineering managers get paid to ask the right questions". I think this is broadly true for many leadership roles. It is just that engineering managers also need to follow through and are responsible for implementing the changes that are mandated by the answers we reach by asking those questions.

As I mentioned before 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 sometime tough 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 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 in the team are blocked on something and what can I do to unblock them. While I unblock them, I make it a point to highlight what I did to unblock and how they can do it on their own from next time. Being blocked on something and not being able to deliver in the short term can quickly frustrate engineers and so generally I try to concentrate on this first and get them sorted out.

While I looking at Unblocking as a short term thing, I look at unlocking as the long term lever. During my one on ones 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 all I can do to unlock their true potential by any help that I, team or the org can do.

We all know that most of our effort should go in unlocking the potential of the team but most of the times we are bogged by unblocking them for the short term. A proxy I have for this how much of my time is going in Hustle versus Strategic activities. Of late I am asking the same question to the team so that they are also aware of where their energies are being spent. Sprint Retros are a good time to do this. We do sprint retros along just before sprint planning so that we can also implement the suggestions right away.

Another hack we are trying to use of late is have one person work on short term things(on calls, ad hoc feature requests) completely, one person work on long term things(clearing tech debt, changes for future) while the rest of the team works on the current sprint goals.

One on Ones

As an Engineering manager 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. I used to get them all done in on one single day.

As the team started getting bigger this was practically not possible. 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 2 one one ones I was not able to connect completely with the people I was having one on ones 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 so that I can completely immerse myself in the conversation. Today I can say that this is the favourite part of my job as an Engineering manager.

Incentive Alignment

When incentives are aligned we need very less external motivation. The problem with external motivation is that you need a constant supply of it and that is generally not the case. So it is always better to count on internal motivation and I strongly feel that internal motivation comes from 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 ones with my team I try to identify the individual interests and see how we can overlap them with the team and company goals.

https://i.imgur.com/ptunoVx.png

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 interest will drive what we are doing at work and the time they spend on work will further push their curiosity. In past we have made use of individual interests like Exploratory data analysis, 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 which was a critical part of the most critical flows, which had less visibility within the org and also was not actively maintained. We definitely needed heroes to even pick up the project, which we had in the form of Ishaan. But very soon we realised that he was the Single Point of Failure for our team. So we started working on building redundancy for him. Today we are at a better position but we still have a long way to go where we can completely rewrite this system 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 stake holders and devs.

Three hooks in the chain visibility problem

For the first couple of quarters we were pretty much blinded by the issues and we were busy in keeping the lights on mode. We majorly interacted with the business team and our roadmap was pretty much driven by their immediate needs.

Post that when we started talking to different stake holders, one challenge we faced was that most of the 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 the workflow end to end which highlighted the scope for improvements which are not local optimisations. 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 which are based on the insights that such teams provide.

Export this to - https://docs.google.com/document/d/1ugpZxBlYwYbMyFTfKvRb01Uv6HWoFKXYgrd38KG4pM8/edit

Meidum link on Blinkit - https://medium.com/groferseng/what-does-it-really-mean-to-be-an-engineering-manager-2661cd11a384

Referenced in:

All notes