When starting something new, especially a new job, you tend to prepare yourself for it. You read up on the topic, watch videos, maybe ask friends about their experiences. All this is done to get familiar with the job and avoid “rookie” mistakes.
It’s also a good thing to do when you are about to switch from being a software engineer into management. As mentioned in my previous post, this is not a promotion, but a track change with new tasks and responsibilities. What you’ve done until now is vastly different from what you will be doing in the new job.
A large focus of management, compared to an engineering job, is the close and constant work with people. In those cases preparation is essential, as you directly affect people’s lives and there are no easy redos like fixing the code and running the tests again. Once you say or do something, it’s out there.
Regardless of how well you prepare, there will always be difficult tasks and demanding situations. Often, going through these teaches you more than studying extensively beforehand. Some situations might have simply not been considered in your preparation.
I myself switched from an Android Engineer into an Engineering Manager for a new team. Once I started, I needed to hire many new team members and set up processes, while making sure we delivered and produced real outcomes. Working with people and solving problems was always something I liked, so I started with the idea of being equipped with all I needed to succeed.
Months later, writing this and being a bit wiser, I would like to summarize a few things you should brace for and invest more time in preparing, that would make your work and your team’s work more enjoyable and prosperous. It’s not an exhaustive list, but rather things I consider the most important to get right for new managers.
Time management
Making the most of your time as a manager is of extreme importance. That’s the reason there is so much material on the topic, with many guides and tips to optimize it. Despite how well you prepare, there will be situations that put you out of balance, after which, getting back on track can be very difficult – you will be on the back foot, while new tasks pile up.
How you use your time is also a good indicator of how effective you are in your job. If done properly your schedule can accommodate internal team meetings, 1-on-1s, stakeholder syncs, company planning sessions, hiring, product discovery, and so on. This is partly decided by priorities, but the real challenge is dedicating enough time to each competing topic, where “enough” means that the tasks get finished and a real outcome is achieved.
If done poorly, you will always be chasing deadlines and leaving tasks undone, because there is just not enough time for everything. Or you will spend an unhealthy amount of hours chasing an equilibrium, where no open tasks exist. You won’t reach it, because it doesn’t actually exist.
Doing overtime here and there can happen as a manager, but doing this regularly should not. Eventually an urgent topic will pop up and need your attention, when your schedule is already full. This would mean delegating tasks or doing extra hours. While the former is desirable, it’s not always possible, thus making the latter necessary. Otherwise, things won’t get done (although, depending on the situation, this can also be a valid outcome).
Time management is a delicate topic and has no cookie-cutter solution. What you can do in your first months as an Engineering Manager is deliberately plan focus time to get things done. It lets you dedicate time to a single topic, ignoring all distractions. Additionally, you can leave a buffer between meetings, to reflect and act based on what happened and prepare for the next one.
Having those two options will let you study your situation and adapt accordingly, while not sacrificing your free time or mental health. There are many techniques for time management, but my main advice would be to take everything with a grain of salt and start slowly, while learning what works best for you.
Forging and improving processes
As an engineer, you could join a team with established processes and start working on your tasks, while leaving things as they are. Which meetings you have or how they are structured is not directly your problem. You could and should give feedback about processes, but your main goal is getting your tasks done.
As a manager, however, you need to constantly monitor the team’s output and evaluate the current state and possible improvements. And you need to do this while observing people’s behavior and steering clear of potential problems before they happen. When problems occur, you need to know how and when it’s the best time to address them. All this while also continuously delivering. It’s like repairing rail tracks, while the train is driving on them.
When things seem okay, ask yourself, are all your team members actually using their full potential? Are processes blocking or slowing them? Some might also be a bit shy and hesitant to speak up, although their points might be valid and crucial. Your job is also to spot those moments and act, while also making sure your team is still making progress. Being mindful of them and using your focus time to ponder these questions is a good starting point.
There is one fitting analogy here: forest vs trees. If you look from far away you don’t really see the trees, but only the forest, while close up – it’s the opposite. They are both interconnected and necessary for one another. Sometimes it’s better to focus on the forest and sometimes the individual trees, but you must never forget the other, otherwise you risk introducing an imbalance.
It’s very similar when thinking about processes as a manager. How you work inside your team and company changes based on many factors. You would need to adapt with priorities, processes and more. It’s important to keep people (trees) and the whole company (forest) in mind when designing your procedures and goals. People are different; processes and structures that have worked before don’t necessarily work for others.. Ignoring this might alienate your team or lead to a suboptimal company.
Changing processes can be disrupting and cumbersome. It needs to be done only after you understand all sides of the current state. It also depends on how willing your team members are to adopt the new ways of working. Sometimes a new structure might be more complicated and a bit slower, but lead to better documentation and communication, which eclipses the negatives. Conveying this clearly and supporting people through the initial change is a good strategy here.
All changes to processes should be decided and implemented together inside the team. While your job is to bring observations and ideas to the table, it’s their daily life that will be affected the most. Your aim is helping everyone speak up and be understood by others. Planning and moderating those process-change meetings is what’s expected from you. The only way for a manager and the whole team to figure this out is to start and improve as they go.
Sharing information
A big part of being an engineering manager is acquiring and effectively sharing information. While this was always part of your job as an engineer, now you’ll have a lot more knowledge about ongoing tasks and future plans, which you need to filter and appropriately distribute to your team and stakeholders.
You’ll often be the only engineer in discussions, providing enough distilled technical knowledge to go forward. The main difference for you will be that you won’t be coding anymore and have only second hand knowledge, which by itself might not (or probably won’t) be thorough enough.
It’s similar when sharing product and company knowledge with your engineers or stakeholders. They don’t need to know everything that product managers, user researchers and others talked about, but need to be familiar with future goals and user problems. If your engineers get predefined tasks and only write code, you are greatly missing out on what they can actually offer – a problem-solving mindset and ideas.
While acquiring knowledge can be sometimes difficult, sharing information is the tricky part and where the challenge of management lies. Depending on who you are talking with, issues that arise can be grouped in four categories: context, depth, overload and feedback. Based on these criteria, you can decide how to approach an interaction, making it beneficial for everyone involved.
Context
How much context do you need to give someone before you can actually start a productive discussion? It might be nothing (if they are already prepared through documentation and previous meetings), or everything (if it’s a new topic for them). In the case of the latter, what exactly do they need to know? Definitely not the whole story of how you got here – so be mindful of how you start, as it might bias or confuse them.
Depth
The person’s expertise and experience plays a huge role in communication, since you might either need to “just mention” or thoroughly explain various concepts. This applies to technical topics, but also to explaining product discovery, roadmap planning and more. Your team needs to know what the company and team goals are, without going through months of data analysis and how you got them.
Overload
Sharing everything with everyone all the time is an easy but bad solution. Your job is filtering the most important information from everything you learn and communicating it clearly, without overwhelming your team and enabling them to focus on their tasks. You can, and should, document things and enable people to pull information when they want, but you should not push tons of inapplicable data on them, diluting their focus and confusing them.
Feedback
After sharing information, you should always ask for feedback. Did you present things clearly? Did they miss something that needs repeating? Was there a knowledge gap that needs to be addressed? Without feedback, you’ll never improve your communication skills, and you also can’t be sure people understood what you actually wanted to say.
Summary
Switching into management brings many challenges, as it’s a new job with new requirements. Based on your personal and professional experience, you might be better prepared for some and not so well for others. Being aware of what’s coming can soften the blow, put things in perspective and validate that you are on the right path and just at the edge of your comfort zone.
The things mentioned above are derived from my experience and knowledge talking to other engineering managers. This article highlights topics where preparation alone cannot cover all cases, because working with people is generally more unpredictable than writing code. That’s one thing that makes this job so exciting, inspirational and diverse.
Things won’t be perfect in the beginning. In fact, they might never be. But that’s alright. You should aim to deliver value to your users and be aware that hiccups will appear along the way, but make sure issues don’t repeat themselves. As long as things work and information is shared in a convenient, timely and efficient manner, things will get done.
You might (and probably will) address some challenging situations in less than perfect ways. This is totally fine since it’s all a new job for you. You should be mindful, and reflect often. Ask for feedback and provide it yourself to others. Foster an open feedback culture, as it’s one of the best ways for a team to grow together.