You've been promoted from developer to manager. Congratulations! But you're slightly uncertain whether you're up for the job. After all, it's quite a big jump. While you've probably spent years studying and practicing to become a developer, you've not been formally trained to become a manager.
Allay your fears. Firstly, it's important to recognize that it's in the best interests of the people who promoted you that you succeed in your role. The fact that they've chosen you means that you already exhibit some important managerial qualities.
Secondly, those who are formally trained for managerial roles (e.g. through an MBA) don't necessarily make for good managers and those who aren't formally trained for management can be phenomenal managers.
The uncertainty that you might feel about the transition from developer to manager is because you want to know what you need to learn. You're asking yourself what the most important aspects of your new role are. That's what this article will answer. It should be read in conjunction with "How to Lead a Remote Development Team."
Satisfaction Will Come From a Different Place
As a developer, job satisfaction usually comes from squashing bugs, implementing new features, and solving tricky problems. You've likely felt this visceral sense of satisfaction a few times a week, if not more.
As a manager, this will change quite drastically. Job satisfaction will come from seeing your team get better at what they do, from the professional progress of individual team members, and from finishing projects successfully.
It's a different kind of satisfaction, and you'll feel it less than when you were a developer. Additionally, it'll feel softer, fuzzier, because being a manager means dealing with people inherently more complex than code.
While anticipating this change will go a long way in dealing with it, tracking and managing your emotional state will also help. Every day, it's worth checking in with yourself to see how you feel and why you're feeling that way. Write down those feelings. Then, focus on tackling the challenges of the day in a practical, positive manner.
The Team Comes First
It shouldn't come as a surprise that you'll program much less as a manager. And that's okay. You needn't worry about your personal productivity anymore; the number one focus of your role is now your team. You need to create an environment where your people can code happily and productively.
This means that you need to set crystal clear goals and a path for your team to achieve those goals. Additionally, you need to remove the collective and individual roadblocks that might slow down your team.
You can do so by talking to your team in an honest and, more importantly, a kind way. The latter is important because there's inevitably, whether you like it or not, a power imbalance between you as the manager and the developers on your team. If you're not kind, you'll be seen as a threat instead of someone who's there to help.
When talking to your team, you'll quickly notice that people will tell you their frustrations, their complaints, their dilemmas, etc. Some will do so diplomatically, while others... not so much. It's vitally important not to take this personally. It's your role to remove these frustrations in a way that will move the team and the company forward.
There Will Be Good and Bad Employees
This is the Anna Karenina principle of employees: All good employees are good for the same reasons, while all bad employees are bad in their own way. Here are the traits that most good employees will share: honesty, dependability, integrity, humility, excellence, generosity, proactivity, and intelligence. People who exhibit these traits are golden and will contribute positively to everyone else in your team.
Bad employees, however, will almost always be bad for a particular, unique reason. While you won't ever be able to avoid having a few difficult people on your team, there are steps you can take to mitigate their impact on your team.
Firstly, it's worth creating an employee handbook with a clear code of conduct. Examples of rules could be: communicate respectfully and clearly, share the credit, and have good intentions. If you're looking for an example, have a look at Chapter Two of X-Team's Remote Team Guide.
Secondly, create an environment where people can communicate freely and without fear. This way, you'll quickly hear your team's frustrations about a particular someone. It's your role to determine the validity of those claims and to properly give feedback that informs that person of the impact of their behavior.
Learn to Let Go
As a manager, you'll have an almost continuous stream of information coming your way. You need to be able to filter through that information to determine what's most important. From the chaos, you need to create a coherent story.
As such, there's no need to tackle every single problem. Instead, you'll need to learn how to rely on your team to solve many of the smaller problems. This ties in with a lesson reinforced in many engineering management books: Don't micromanage. There's no worse sign of trust than a manager who hovers around their team and corrects them on the many small decisions they make every day.
You're there to guide your team in the right direction and provide the right working environment. The people on your team are capable enough to take it from there.
Transitioning into a managerial role is a big, exciting move. You're now responsible for a group of people and your ability to manage them will have a significant impact on both their job satisfaction and the quality of the software they're creating.
In summary, as a first-time manager, it's important to realize these 4 things:
- Job satisfaction will come from a different place;
- Your team's productivity takes precedence over your productivity;
- There will be good and bad employees no matter how good a manager you are;
- Your team is capable and shouldn't be micromanaged.
