This article summaries my learning as I got comfortable into a manager’s position from being a developer. About 5 years ago, I switched from one company to my current job, just because they promoted me and made me a manager. I refused, and my then manager gave me a long talk on how I’ll get stagnant and go out of relevance if I continue to stay inside my comfort zone. I listened to him patiently, and then I quit. Now, after 5 years, I realise that I really can’t escape that fact. Except for very few careers, you do have to become a ‘manager’ (at least of sorts). Not because it’s compulsory, but because it makes more sense. After gaining enough experience, it’s simply better economic sense to lead (or train or mentor or manage) other people than contribute as a loner.
Even the senior people who claimed they’ve persisted to a ‘technical role’, are just under an illusion in my opinion. They are managing others one way or another. They just aren’t calling it management. Even hard core solo researchers have ‘research assistants’ – which does make it a management job in one way.
So I did commit to learning to become a manager. Don’t mistake me – I really don’t think it’s necessary for everyone to climb the corporate ladder to become CEO one day. I just think us developers need to step out of the comfort zone and learn to lead a few people because it has tremendous value to be able to do that, and opens doors which we might not even have considered before. This article records some of the things I’ve learnt from experience so far.
Lead the Project
You’re no longer an ‘executor’ who has to complete the tasks assigned to them. Management doesn’t work that way. It’s not another job where you get a to-do list. You need to lead. You need to know your project’s roadmap – even if there is a separate Product Manager or Architect who’s responsible for it. If you don’t know this, approach whoever is responsible and get to know it. Make sure you’re in the know when decisions are taken in the project. That’s what you need to be thinking about – Where is the project going next? Will it get there on time? Does it need to switch tracks? Are the initial assumptions still valid?
When you see a task, don’t think ‘I can just do this myself – it’s just a little thing’. That’s probably the worst and most common mistake new managers make. It’s tempting to believe that in the time it takes to explain to another person, review their work and accept it, we can just do it ourselves. That maybe true, only you have a different job now. Your job is not to finish that task – not anymore. Your job is to get a specific person/team to finish that task. So that’s what you should be focusing on. Get out of your comfort zone and start thinking about how you can get the other person to do it for you.
You might have thought so long that managing is just maintaining the to-do list. But you’re in to find out how demanding it is to maintain a to-do list. As a new manager you probably have only one project/team to manage so you’ll be expected to know the status of every single item in your project. You need to know how many bugs are there. How many of them are critical? What roadmap items are coming up in the near future? How occupied are members in the team? How spirited are they? Is any task running the risk of getting delayed? Can that delay be avoided? If not, who should be notified of the risk?
A developer who know how to write programs, can’t really earn his own living by sitting alone and writing programs. A large company can’t get their requirements met by a single programmer. Now that’s where you come in – the new manager. You take the output of several programmers, and consolidate them into a unit which is useful to the company. Most of the job of a manager is just this – to consolidate individual efforts and pass it on to your customer (or your superior). Other activities of a manager – such as appraising team members, reporting project status etc., are supplementary to that main goal. Although it doesn’t come out that much, it’s the fact – you are there to tie pieces together towards an ulterior goal.
This is something that we usually learn very late. This communication is important, and might be considered one of the most effective communication that can happen between a manager and their team. You should always be on the lookout for receiving feedback about how well you’re doing as a manager. You can succeed as a manager only if your team is committed to your leadership. But you might not be able to ask for this directly. It will put your team members in an awkward situation if you ask them to rate your performance. What your team thinks of you is as important as what your superiors/customers think of you.
You should be expressive in appreciating your team member when they do a good job. And you should not hesitate to (politely and discreetly) suggest that they need to improve on something. While for many managers it’s easy to appreciate, they try to avoid criticising. They don’t want to hurt another person’s ego. It is indeed a good motive, but not enough to completely avoid giving negative feedback. Learn to do it in a way that doesn’t hurt their ego. Think how to put it such that they take it in a constructive way. Do not shy away from conflicts – deal with them in a friendly and respectful way. Use your influence, not your authority.
Learn Emotional Intelligence
Even before becoming a manager, you should have put effort in increasing your emotional quotient. I remember it was a buzzword and all the craze at one point in the past, but has been forgotten a bit now – unfairly so. Emotional quotient is considered more important than intelligence quotient. It’s common for technical people to start putting up spreadsheet, project management software and all those kind of things – and they start relying on those things. They assume that if they maintain everything up-to-date in their project management software, things will be running smoothly. This is far from the truth. After so many years in software development, I haven’t come across even one strong example where a ‘management tool’ helped success of a project. It’s about how well you connect with people. How well you can influence them. How well you can understand them.
The biggest change when you become a manager, is this – you need to stop thinking about code, technology and programs and instead, start thinking about your project, your team and your customers (or superiors). Less working with computers and more working with humans. That jump is what I’ve seen new managers struggle with. You need to build up your communication, persuasion and networking skills. Start by getting comfortable talking with your team, and always have your project’s roadmap in mind, and you’ll be on track to become an awesome manager.