When I first became a manager, two-thirds of my team quit within a month. This left me with one person on the team, which was extra embarrassing. I was especially sad because I had not taken that job lightly. I had read books about management and prepared for the new role. And yet, I clearly sucked at it. I don't know who needs to hear this, but here is what I learned from this experience. Becoming a manager requires you to unlearn everything you know: learn to lead instead of doing, learn to set an example of work-life balance instead of working your ass off, and learn to trust the process instead of worrying about your predefined plan.
The first thing you notice when becoming a manager is that you need to unlearn doing and start leading. Sounds fancy and trivial at the same time. This change is hard because your excellence at execution got you this job. Yet, your temptation to leverage that skill now by jumping in and doing the work yourself demotivates the team and brings poor results. It makes your team members feel like you are here to compete with them instead of using their talent. Nobody described this problem better than Liz Wiseman in her book "Multipliers: How the Best Leaders Make Everyone Smart." Transitioning to leading means letting your team do their best work. You can't insist on your ideas, but you can learn to present them in a way that inspires the team to come up with something better. It's hard! When your employee brings an idea, you immediately see ten reasons it won't work — because you thought about the problem long enough. And you are probably passionate enough to present your arguments and let the best idea (yours!) win. Great. Now you have a resentful employee and a product that is only as strong as you are. Learning to find nuggets of gold in every idea allows you to enrich your product beyond your own talents. So, here is the gist: stop doing everyone's work; otherwise, they will all leave, and you will be left alone with a sad product.
The next thing that was hard for me to learn was to set an example of work-life balance instead of working my ass off. As an IC, you saw your ability to work hard and overtime as an advantage, and it is part of what got you promoted. So, after the promotion, you continue to do it— especially because you want to prove yourself in the new role. Yet, here is your new challenge: while you would really like your team to be just like you, you cannot openly say that you expect everyone to work fifteen hours a day, including weekends. So you tell the team that they should be taking some time off and not overworking. However, you are not very believable when you say that; your team senses that you are not genuine because you keep sending emails at 1 am and mentioning that you "finished that deck over the weekend." So, people understand that they are expected to do that too, and they pretend to be okay with it while secretly interviewing for other jobs. The truth is: your project is not that important. Nobody will die if it gets delayed; most of your deadlines are self-imposed. Meanwhile, your family misses you, and your health is deteriorating. Genuinely accepting the fact that your product should not come before your health, family, and life will give you a stronger team and a better product.
Finally, the third lesson that was hard for me to learn was to start trusting the process instead of worrying about my perfect plan. As a new leader, you likely have a good idea of what needs to be done in your product and when. You spent a lot of time thinking about it and came up with a whole project plan with milestones defining who should finish what by when. You may even have presented it to the leadership, and it felt good. Unfortunately, as you start working with your team, you realize that they are deviating from your plan: they take longer to reach a consensus, they bring in new ideas to consider, and they propose validating something you thought was certain. All of it frustrates you because you are losing control. So you spend a lot of energy trying to regain it: rushing people to reach premature conclusions, re-iterating arguments supporting your ideas, etc. This effort is exhausting, but it allows you to bring the team back on your schedule. However, the disagreements you rushed to ignore and ideas you did not find time to explore will pop up later in the form of growing resentment and product mistakes. Rushing the team to pursue a direction they are unsure about will lead to low engagement and a standstill further down the line. So it is important to trust the process: the team is making progress, even if their milestones do not match yours. Step back and let the team have the discussions they need to have in order to reach a consensus. The result will not match what you had in mind because it will be better.
Thus, these were the key lessons I learned by losing two-thirds of my team in one month: learn to lead instead of doing, set an example of a good work-life balance, and trust the process instead of enforcing an arbitrary schedule. Does this guarantee success? No. With some creativity, you can find more ways to screw up.
Comments