Comment on page
Overview
Learn what to expect and strive for as a developer transitioning into Engineering Management.
I was an engineer for most of my career and one day I became a manager and I was quite lost and afraid in the beginning, I realized I hadn't shared my experiences from back then. I've been doing engineering management on and off for the past couple of years and I decided to share a short summary of what I learned.
A lot of this is stuff I learned from books, articles, websites, and some of this is stuff I learned on the job. Full credit to all the resources I learned from is at the bottom in the "Great resources" section, and I heavily recommend exploring them if this article captured your interest. I like to use the term "Maker" (engineer, designer, or anyone who makes stuff) and "Manager", both of which I learned from the book Leading Snowflakes. I wrote this from the perspective of someone who has been a Maker for most of his career and transitioned to Management a couple of years ago.
Meeting notes, peer feedback, feedback to you, documenting a task before you hand it to an engineer, and so on. Think of yourself as the standard for documentation in your organization or team, because you kind of represent that now. You'll get so much in your plate that it's impossible to remember it all, writing is your best friend.
Management is all about people interactions, you'll be dealing with people a lot more than before and that means meetings. Too many meetings for your team is a productivity killer and that's also something you'll need to figure out how to cut down if it becomes an issue.
When I started being a leader I was used to measuring myself as an engineer or as a "maker" (measuring by what I make). When I first started being a manager I used to feel like I haven't accomplished anything in my day and this was difficult.
You'll see a lot of conflicts between people, sometimes over very small issues. A lot of your time will go towards handling them. This may not be the case for every manager but it was the hardest part of the job for me.
You're gonna have to let some people go, you're gonna have to step in to break up conflicts, and sometimes you'll have people who are trying their best but still hurting teammates. This isn't an easy path and it's full of people issues and conflicts. Even if you have a great hiring process, it won't be perfect and you'll hire the wrong person sometimes. There's no right or wrong answer in almost any situation, you need to have peers and mentors you can trust and ask for guidance. Don't make hard decisions alone, and definitely don't make them when you're not calm.
Improving code standards, bug report structures, doing some things manually until they're automated, improving communication between your team and other departments, and so on. Your goal is to keep the team focused and removing obstacles from their way, and those obstacles are often easy/boring tasks that no one wants to do.
Regularly sit down with your team mates, connect with them, understand their goals and what they want to achieve and learn, understand what's troubling them. Put this on a schedule, it's extremely important to do this regularly. Write down the main points that go on in your 1:1 meetings, it's important for everything you need to do on this job.
You need to help your teammates get better, sometimes in what they want to get better at, and sometimes in things you believe they need to learn for the sake of their team. This can be accomplished by pairing them with someone more experienced in an area they want to get better at, getting them access to websites like PluralSight, etc. Sometimes by mentoring them yourself. You have to give them goals, ask them to experiment with new things, help them write articles, give talks, and so on.
You'll probably be in a lot of meetings and people need an easy way to sit down and talk with you. Have an easy way for them to book some of your time, Google Calendar, Freebusy.io, Calendly, etc. are all great tools for this.
You also need to learn to switch between your Maker and Manager modes, it's good to regularly have this scheduled either some days of the week or some hours of certain days. You need time to hop on in and review some work (pull requests, designs, etc.) and contribute to them too.
You won't have as much time for "Making" as you used to before, and you might get rusty. Take the time to keep yourself up to date with what your team is doing, and of new developments in your field. You need to be able to understand at a general level what your team does so you can help them prioritize.
Don't forget anything. Write things down. Anything anyone asks of you, jot it down on some app and slap a due date on it (I use Todoist). This list is also great for delegating. Got a complex task coming up that you'd like a teammate to have experience in? Delegate it. Got a lot of meetings today and your teammate asked for access to something or to try out a new tool, write down the task, don't forget them.
The first thing you need to look at when hiring is whether these candidates will fit in with your team or not. Sit down with your teammates and peers and decide what's a must-have and what's a nice-to-have for your workplace. Do you care about about writing well in your organization? Are you ok with people learning it on the job? Or is it a must-have to even join?
Avoid brain teaser interview questions, avoid theoretical scenarios and whiteboard questions that people will never have to do on the job, and make sure your hiring process involves the most real scenarios as possible. Get the candidate to work with your team on an actual task, and compensate them for it. Microsoft's new process is my favorite way to hire, I highly recommend reading it. Not all organizations have the resources to do all this stuff and that's understandable but try your hardest to accomplish these two things when hiring:
- 1.Get the candidate to do some real work.
- 2.Have your teammates and the candidate interact when doing real work.
Too often organizations only look for people who already know most of what they need and don't hire enough juniors. Juniors are great to have in any organization because they want to learn and there's a lot of them. A lot of the time after juniors grow and gain more skills within your organization, they'll start to get better offers from other places so some think this isn't a good investment, but I believe this is something organizations must try their hardest to do, especially in developing countries, because those juniors need to grow and they need help and training, and because you'll have more manpower to deal with the many small bugs that are often overlooked.
As a manager, you need to delegate. Jumping into Maker mode to get something done is something you were probably used to before but you now need to let your team be responsible for most of the "Making".
Learning by doing is the best way to learn. If there's an area you're an expert in as a Maker, don't immediately jump in to Maker mode and try to do it, let your teammates experience it and grow. Write them a short guide of what needs to be done and things to look out for and trust them to get it done.
Ensure your teammates have an accessible place to find and share lessons learned, no matter how small they are (Something like StackOverflow for teams, etc.). Ensure that nobody on your team is afraid or embarrassed to ask questions, regularly encourage your team to ask anything they can think of, and make sure your team is composed of people who are ok with that.
I like to have a GitHub repo in my organization for everything related to how I do management, how 1:1 meetings are run, what I strive to do as a manager, what teammates can expect from me, what I expect from them, and so on. I put it in a GitHub repo because engineers are generally used to working with GitHub and are used to changing things with pull requests, so I wanted to be like that. Make a pull request to change how your manager does something 😛
This isn't to say that you're supposed to be useless or make yourself obsolete but that you should not be a blocker for your team. Imagine yourself going on a vacation for a month, what would go wrong? What tasks are you a blocker for? Will the person leading in your stead know what to do? Have you left them the necessary information? Does the team know what to work on? Do they know what to do or who to talk to if some disaster happens? Try going on short vacations every once in a while and see what goes wrong. At the beginning you'll most likely find that a lot of the things you handled as a "Maker" aren't being done anymore and you need to both make the team aware of them and delegate them.
The Manager's Path - A guide for tech managers going through increasing levels of management complexity.
Software Lead Weekly - A weekly email for busy people who care about people, culture and leadership.
Last modified 4yr ago