“You did a great job as a senior engineer. You are now promoted to a manager to lead the new team that we just formed. Congratulations on your new role!”
It is something on these lines that most people get promoted or at least that is how I remember when I was promoted to a manager. There is nothing fundamentally wrong with promotions such as this. The key though is in recognising that the expectations change when this happens. As we moved up the individual contributor (IC) ladder we learnt to solve harder technical problems. This change in role, though changes the operating field a little. It is in this context that I am listing out a few things that would have helped me transition into my role as a manager better, when I started out.
Transition from a maker to manager schedule
Staying hands on — in other words writing production quality code is a reality for most first time managers making this transition. It is also likely the first time where you end up navigating both kinds of schedules on a daily basis and it is a hard thing to do. Learn to be protective of your calendar. You could do this by:
Blocking your time in the calendar where you need to stay heads down. I’d suggest at least 3 hours at a time and then adjust up or down depending on what is an ideal chunk of uninterrupted time for you to get something meaningful done
Being ever more mindful of how you now schedule time with your direct reports. Just because you have moved onto a different schedule does not mean they should have to. If you are conscious of how you set up these meetings, that is one more thing you are doing for your team
Doing what you can to string your meetings into one contiguous block. Better yet, define your meeting times and agree with your peers. With a little back and forth, this usually works well for everyone and is another barrier for folks who gatecrash into your time with unplanned meetings
If you want to know more about different types of schedules, Paul Graham’s article explains it quite well.
Stay hands on
You are most likely a manager of a team with highly opinionated ICs. You need to be able to have a conversation with them, ask the right questions, pressure test their approach.
Pressure on your time as an IC will only increase as you grow and if you don’t strive to stay hands on, very soon you will find yourself too far from where the action is. You don’t necessarily have to pick up the most critical problem to solve but do what you must to stay relevant and make a meaningful contribution.
Impediment remover, not always a problem solver
After years of being an IC where you are used to solving problems yourself, it can be hard to take a step back.
Be the person who helps your teams get over the hump even if you are not the one who identified the problem or fixed it. Serve the team in the capacity that is best needed at the time and avoid being a seagull manager. With a young team, it could mean leading with a solution while with more mature teams, it could just be about asking the right questions. And in some other cases, maybe it is just carrying pizza!!
Carve out time for career development
A key reason you choose to be a manager is that you genuinely believe that you can have a greater impact on your purpose by developing a strong team. Be interested in each member’s aspirations, be on the lookout for their strengths and biases. Provide timely feedback. Help identify opportunities that will help them hone their newly acquired skills. These are all things perhaps any standard course on “New Managers” will refer to. There are many talks and articles out there to drive home the point that when you can align aspirations with the organisational goals that is when you are likely to have the most impact, but also derive personal satisfaction. Do the most you can to make this a practice.
You have to do this at every opportunity you get, not just when hiring someone into the team. You have to be the cheerleader during your team’s journey towards excellence. Raise the bar when it comes to technical excellence; be the torchbearer when it comes to upholding your organisations credos and values. Often in the quest for an organisation’s immediate imperatives culture takes a back seat. Protect, sustain and improve your organisation’s culture like your organisation’s life depends on it; because it actually does.
Manage upwards and sideways
Managing upwards or to the side is typically seen by engineers as an ugly part of organizational politics. Other than the typical activities that are required to manage information, the biggest reason to do this is because software development is a collaborative activity. Managing in its purest sense is about aligning priorities across teams. You will be able to achieve your goals better if you can influence your peers to row in the same direction and are aligned with the direction your manager has in mind. At the same time, this is also about course correcting if need be and ensuring people on the impacted teams understand why a correction is better for everyone.
Doing some or all of these things will not turn you into a super manager overnight. I like to compare this to going to the gym. You will not notice any change after your first day at the gym, but keep at it long enough and the results will be clear for all to see.