Developer-turned-manager?

Four mistakes to avoid

Photo by Maarten van den Heuvel on Unsplash

So you have been writing code for a while. You are a decent communicator and as you rise through the seniority levels in the team, you find yourself taking more and more responsibility to talk to different stakeholders, defining the technical vision of the product while balancing it out with the needs of the business. You find yourself taking the lead in defining processes in the team and coaching other junior members. For some people, the logical next step would be to move into a more full-fledged management role where you take on a bigger team and also own a larger chunk of the delivery responsibility. As a new developer-turned-manager myself, these are some of the mistakes I have made in the last months, which I have recognized and learnt from. While I am still new, and still a work-in-progress, I am attempting to record my journey and hope that it will help some of you in a similar position.

  1. You don’t learn to prioritize by value

As a developer, it is seldom your responsibility to prioritize what needs to be done when. Admittedly, as any senior developer worth his salt would, at some point in your career, you have been responsible for advising key stake holders on the criticality or feasibility of a technical approach. However, the decision of when to do it is largely not up to you. Your role there as to add your subject matter expertise and step back and let the stakeholders decide.

As a manager, however, you have an almost infinite list of priorities, with all of them shouting for your attention. At such times, it is easy to do a great impersonation of Mr.Bean and wring your hands and try to do everything at once in the order that they come in.

The trick is to realize you can’t. There will always be more tasks than time, resources and people to do it in. And your only job is to try to order it by priority. Sometimes this is simple. A security threat or a production issue is easy to prioritize over feature development. Some other times it is less obvious. If you have a great product feature you want to implement vs. implement a new tool/methodology/architecture. The key is to try to collect data points to help support your decision. If I implement this feature, I increase traffic by x% vs. if I implement this tool, I reduce runtime errors by y%.

And sometimes it is still not obvious because data collection in some cases is not as obvious. During these times, you need to go with your instinct of what could work. This needs time, practice and awareness, but eventually, your instinct does get honed to a point where you can make the right decisions about priorities most of the time.

2. You don’t learn to delegate

As a developer, you are used to being the executor. You get a task, you have to figure out the best how and execute it. One of the biggest challenges I had, and still do, is thinking that I need to do it all. I have spent long hours into the night reading up on a particular technology or tool, trying to see how we can implement it and already planning the execution in my mind. As I worked myself to exhaustion, I realized that the only way I can continue to function is to find the right people and delegate.

The trick is to understand that you, in your new role, are expected to add value by distilling the ‘hows’ into key decision points and prioritizing them rather than spend time in getting to the how. The ‘managerial’ knack here is to identify the right person to delegate to and then remove distraction for them by prioritizing their list-in-waiting well. This nicely brings us to the next point of how to communicate the priority to the team member.

3. You don’t learn to create SMART goals for your team members

So you have finally decided to delegate. You put on your managerial hat and assign the task to a team member and in your infinite wisdom, just assume that they will pick it up and run with it. Wrong. Many times, this is where things start to break down. It is important to create a framework where you communicate the ‘why’ clearly to your team member and ensure that they have all the tools and expertise that they need in order to deliver. Once this is in place, the next task is to ensure that you set some mutually agreed upon goals for them to get to the goal. Fail to do this, and you will have different team members adrift along different trajectories with no clear end at sight.

4. You don’t learn to enjoy the ride

This is possibly the most important, but also the most difficult one. It is very important to realize that this is more than a role change. It is a change of career. And it is easy to expect too much of yourself and get shattered when you fall short. But, like most things, this is a journey, and the ride matters. Celebrate your failures and learn from them. Laugh at your mistakes and own them. Be mindful of the changes in yourself as you grow into your role. Ask for help when needed and keep learning. With the new role, you are moving into a territory with a lot less binaries than in your previous role as a developer. Learn to embrace the glorious technicolor of uncertainties and enjoy the journey as you increase in confidence, little by little, day by day.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store