From Developer to Manager

In early 2013 I transitioned from a developer to a manager of a team of 3 when my manager left suddenly. It took me over two years (and doubling the team size) until I felt like I really understood what it meant to be a manager and thought I was adding value. Here are a few things I’ve learnt and tips others gave to me.

By far the hardest thing for me to realize was that I needed to cut back the amount of coding that I did. There are only so many hours in a day and I was finding that I could either code or do other, more managerial things, without working a lot of overtime. This is something my boss kept mentioning to me and it was something I was extremely resistant to in the beginning. Since I’d been a developer for my entire career, and programming since I was 15, I thought the way I added value to the company was by writing more code.

It wasn’t until 18 months after I became a manager that I finally started realizing that I could provide value to the company by doing things other than coding. Things like investing my time in understanding my developers better, better planning out project timelines and figuring out where I wanted my team to head. These were all things I knew intellectually provided value but found very hard to feel accomplished with.

I still code every once in a while at work, especially when I need something out fast and all of my developers are focused on their own projects but it’s definitely something that I’ve had to cut back on. To make up for this I’ve found myself coding a lot more in the evenings for personal projects.

Your developers are the most important people for your success. Without them, you can only accomplish what you could when you were a developer. With them, you can accomplish so much more.

As I got busier as a manager and more and more things started competing for my time I always made sure to make time for my developers. This included carving out time for one-on-ones, being on time for meetings and in general just being available whenever they needed to talk. This may seem like a no-brainer but it can really improve your relationship with your developers when you show them basic things like this.

Each person requires a different type of leadership. Some will need more of a micromanagement style. Working closely with these developers to plan out what they’re working on will help them stay on track. I’ve found that more inexperienced developers generally fall under this style though I’ve also seen seasoned developers who required a more hands approach.

The reason you want to focus on your developers is that it’s extremely expensive when someone leaves. Not only do you lose all of the experience that the developer has accumulated you can also be in a position where you have to pay significantly more for the same experience if the market has been increasing lately. The best thing you can do to keep your developers is to respect them and pay them fairly.

A concept that I struggled with at the beginning was that my time is worth a lot of money, both to myself and my company. While it’s a fairly simple concept, it just wasn’t something I thought about at the beginning. This means that things like meetings, events and other things that take up your time cost money. I finally understood this when I started saying no to meeting requests that didn’t make sense for me to be there. Most people like to include as many people in meetings as possible, regardless of whether or not everyone is required or not. Say no to meetings religiously to keep yourself on track.

The other thing I started doing was scheduling time for myself. When my days started getting busy I would schedule my lunches, planning sessions and time to learn new things so that it didn’t get eaten up by meetings and other events. I remember one week early on when I had a meeting scheduled for every minute of the week and I barely ate anything. This leads very quickly to burnout. Schedule in an hour here and 30 minutes there for yourself.

There are a number of tools that I use every day to keep track of what my developers are working on. I’ll discuss three that I use every day.

Pen & Paper: One of the biggest changes I made over the past couple of years was switching from Evernote and/or Google Docs to a pen and paper for my note-taking. I found when I was using my computer my attention was never fully there. Using a pen and paper allows me to stay connected to the person I’m speaking with while still being able to take notes.

Trello I spend a large portion of my time in Trello. Whenever there’s a feature request it goes straight into a card. When I want to see what people are currently working on I go straight to Trello. When I want to discuss with other managers a larger project, those comments go in Trello. It’s a fantastic tool for keeping track of features and bugs.

Github: Github is the best tool for storing code and also a great tool for conducting code reviews. I spend my time in Github going over various pull requests, ensuring that there’s a common style of code that’s carried across all of my developers. We use Trello Cards instead of Github Issues but that’s just a personal preference.

Grammarly: Since becoming a manager I’ve spent a significant amount of time writing. Writing emails, documentation, PR reviews, performance reviews and more. My writing, as you may have noticed here, isn’t always the best but Grammarly helps me out by suggesting fixes and improvements.

I was recently reading Trello’s Blog where they discussed the “Rule of Five”. This concept is fairly simple: two tasks you’re currently working on, two tasks that you are planning to work on next, and one task that people might expect you to be working on, but you aren’t actually planning on doing.

This rule helps you from getting overwhelmed by the number of tasks on your plate by allowing you to focus on only a few things at a time. I’ve also found that this rule works wonders for your developers, allowing them to organize what they’re working on and making it easier for you to keep track of the progress of your team.

I hope everything I’ve written above can help developers turned managers from falling into the pitfalls I had. Let me know what tips and tricks you use in your transition.