On becoming a Manager
Ironically, the move from an engineer role to a manager role is both aspirational and disconcerting. It is also one that usually comes with very meager preparation or training. Over the years, I’ve had the opportunity to stumble, learn, be guided and guide others through this process. Here, I draw from these experiences and hope that this is a helpful start for anyone making this journey.
First, the challenging shifts in mental model: #
1. Getting Things Done #
The move from being responsible for actually doing things to getting things done is a huge mental shift. Suddenly, what you do individually is a lot less important. You are now accountable for the failures of your team, but more importantly you are responsible to bring them success and work satisfaction.
Contrary to popular FUD, this doesn’t mean you need to be less technical. In fact, many a time its quite the reverse. As an engineer you only need deep context and understanding for your piece of code or at most your team’s piece of code. As a manager you need to have the technical chops to understand how your team’s work fits together with the work of other teams and the overall architecture.
You not only need to understand the technology & architecture of other teams that from a part of your organization but also need to understand the structure & various other roles (SMs, PMs, RMs, etc) and how you could leverage those roles for the success of your team.
2. Meetings! #
One of the first things that bites an engineer in a new manager position is the sheer number of meetings. 1:1s, staff meetings, org meetings, firefighting meetings, brainstorm meetings, HR meetings and so on. “Why do we have so many?”, “What purpose do they serve?”, “So many useless ones”, “We’re not getting anywhere.” - these are common and understandable refrains.
As an engineer, meetings are a waste of time. Its time away from coding, away from productive work. As a manager though, this is how you gather and contribute to the rich context of what is happening in other related parts of the company and how things are delivered as a whole. It is also a way to learn what is important to other parts of the org and to the org itself. Its how you learn to set a direction for your team eventually leading them (and thereby yourself) to success.
Once your teams own a couple of important/central services, you also want to insert yourself into as many outside-the-team meetings as possible that directly or indirectly relate to the services you own. You want to be leading the direction for your services, not taking direction from others on what your service should look like. (sidenote: inputs != direction)
3. Everything is Broken #
As a manager you now get exposure to so many things about other parts of the company that at first everything looks imperfect and broken. This is normal. Its the same as how a new entrant to the company can see many issues that have become normalized for people long within the company.
This is your opportunity to shine and shed a light on important things that you could fix or influence. The operative word being “important”. In most companies, there are always plenty of gaps and imperfections. Its important not to get overwhelmed nor mistake everything as important. This takes time and patience. In reality, things are generally not that broken as one would initially be inclined to think.
4. Shift in Time-scale #
As a developer, you come across a bug or user-story, you work on it and fix it. Its probably a day’s work or 3 days work to fix a bug. A story or product capability is probably two weeks work, but generally no more than a month or two.
But as a manager, the kind & magnitude of issues and initiatives you are responsible for are typically much longer in the time-scale and on the order of quarters or a year! This change in time-scales requires a major mental shift. Simply becoming conscious of this change avoids the frustrating feeling of “we’re wasting time” or “things move too slowly around here”.
5. Perspective of benefit #
As a representative of your team & product/service, you will probably want to or be called upon to put across proposals to other people, both inside & outside your team. While you may believe that what you are proposing to them is a well thought-out technically-sound objective proposal, what they are actually hearing is a blend of your proposal in conjunction with unsaid things such as “what work they will have to do” or “how this proposal benefits them”.
This is an important shift and can sometimes be frustrating to an engineer’s mindset of “but this is the technologically best option” and “why should anything else matter”. It is not that they don’t see the technical objectivity. In the real world, many other “human” factors come into play such as a incentives, emotions, work-loads, culture, reporting structures, co-ordination challenges, etc. Re-framing things to cover other people’s interests is a hard thing and you need to give it time & practice.
6. Delegation #
As a new manager, half the time you’re probably thinking “doing this myself will take 2 hours, by delegating it will take 2 days! Might as well finish it myself”. This is natural. After all, you probably have more experience and skill than your engineers which is likely one of the key reasons that brought you to this new role. And since you’re used to having complete control over your work as an engineer, its hard to pull away from this “engineering mode”.
But if you don’t, you would not only be doing a disservice to your team by not letting them try/fail/learn/do, but you would also be doing a disservice to yourself by continually loading yourself with work which ideally should be handled by the team. The sooner you get comfortable with losing some visibility and trusting in the ability of your team, the sooner they start stepping up.
No matter what you do, you’ll take a short term hit in enabling your team. The key is to manage outwardly expectations while you’re getting them ramped up. One trick to start with is to shift your mind into a “reviewer” mindset. Whatever you do, don’t burn-out your team trying to match “your pace” and don’t get burnt out yourself!
And now, some practices to help you on this path: #
1. Preparation #
Prepare for every meeting, whether it be a 1:1 or a group of people. Review the agenda or topics of the meeting. Think through what different audiences in the meeting want out of it. Reflect on what kind of outcomes might be desirable or possible. Write down points, questions or ideas. Sometimes you only want to listen, absorb, learn and make notes. Even so, preparation helps. If you are in a meeting, make it count!
Otherwise, the meeting can probably proceed without you. In such situations, either decline the meeting or delegate it (up or down) or forward it to a more relevant party. Once in a while, a high-level meeting may not make much sense but trust that no one wants to waste their time either. In situations where you can ask someone about the purpose, ask. In other cases, you may learn over time especially in case of non-obvious outcomes.
Either ways, if you are attending a meeting try to spend at least 10 minutes preparing & thinking. If you are consistently unable to find the time, read on.
2. Protect your time #
One of the biggest challenges you face as a manager is the contention on your time. There are many symptoms of this: your direct reports cannot find time on your calendar for 3 days or more, you find yourself working extra hours on a regular basis, you are continuously switching contexts multiple times a day with no time to reset or think, you’re jumping from meeting to meeting in one long meeting haze with no time to prepare, and so on!
Pause, reflect and reset. Once every few days, review your calendar to see if it needs some de-cluttering. Block time out for yourself to get some work done or to read. Postpone meetings that no longer seem as much of a priority. Delegate where possible. If you are unable to delegate because of the lack of a solid team member, prioritize developing someone at the cost of other things. And without hesitation, pro-actively cut back on your scope or initiatives. You don’t need to be everywhere nor get somewhere superfast. Make your time worth it.
3. Recruitment #
The time you spend on ensuring to recruit a high-quality team member is the single biggest investment you will make for yourself and your team’s future. This is not something to be left entirely in the hands of your capable recruiter. If you are in recruiting mode, ask yourself how much time per week you are investing.
Pushing aside recruitment related tasks or spending less bandwidth on it at the cost of other short-term priorities is the single biggest disservice to you and your team. Excuse yourself out of other things, but not this one. After all, once you hire someone you will be working with that person on a day-to-day basis and hoping that the person will add value contributing to your team’s success. Plus you will be asking your team to work with that new person. The cost of a wrong hire is extremely high and usually hard to reverse. Recruitment is not a chore but an investment into your team’s success (and thereby your own success).
If you are recruiting a direct report, be the first to meet with the candidate. Understand the background, experience & cultural fitment. No one else can do this as well as you, and there is no need to ask other people on your team to waste their time interviewing if you are not happy in the first place. Their time is worth more in code!
4. Draw hard lines #
One of my earliest managers once asked me: “What is it that if your team violates or misses would be unacceptable to you? Does your team know it?” . This is an important question to help establish your brand of leadership. Think about what is important for your team and what you place a high-bar on. You can only place a high-bar on so many things at a time without stressing out your team. Is it quality metrics, diligence, punctuality, scientific temperament, growth-mindset, efficiency, integrity, curiosity, or any one of so many other possibilities. You know your team best, but make sure they know your mind on this one. Draw hard lines on things that are unacceptable and make them known through your actions.
5. Feedback #
This one bites most people but goes mostly unsaid. Everything seems ok but a nagging doubt starts creeping in the mind: “am I doing ok?”. Continuing to work with such a doubt is detrimental to your own peace of mind and productivity.
Take a step back, ask yourself what specific areas should I be working on and write down your assessment of those. If it satisfies you, you’re good and should be able to get back to work without the nagging doubt anymore. If you’re still unsure or unsettled, its time to share your assessment with your manager. Ask for feedback on a regular basis - both general and specific. Seek clarity on assumptions that might be made. Try to obtain objective points to focus upon.
While you are doing this, keep in mind that the same kind of feedback is important for your direct reports. In this case, they might not even be able to see what the specific areas of assessment should be. This calls for investment into some level of guidance and mentoring. Establish short regular feedback time (maybe as part of your 1:1s) and in case there is something hard to say, say it. Don’t avoid critical feedback, it will only make the situation worse and you’ll have to deal with it later anyway.
6. Bring user perspective #
An unsaid part of your job is to know what your users think of your team’s product or service. Are users happy or frustrated? Spending some time interacting directly & regularly with users may not officially be a responsibility of your role, but at the end of the day no one wants to write code that is sitting in the closet unused, or causing users to spew out swear words everyday!
Once you have sufficient context around this, start providing your team members with as much understanding of this as possible. Be cautious, if things are very broken and you vent out user frustrations on your team, your team members may not understand why after having done so much hard work! Trickle in just enough information until everyone has built up a solid sense of user-orientedness. And never fail to mention user delight in a big meeting in the presence of your team members. Nothing can bring more purpose & satisfaction to your team than knowing that they’ve served & delighted another human being!