Cloud Hosting

Getting hired as an engineering manager for the first time means youve already shown you have the right mix of technical experience and people skills. But there are certain things to keep in mind that will help you start on the right foot and avoid some pitfalls of management. Here are five to get you going.

Why its important: Knowing your organizational preferences will determine how successful you are at leading a group of people to get things done in a set amount of time (in other words, your job).

Ask yourself how much organization you need to be comfortable with your team. How organized do you need your team and its processes to be in order to be confident your team can achieve its goals?

Take sprint planning, for example. Will you run that loosely or tightly? I've worked with folks who were way more organized than I am, and their sprint planning was driven off of the Jira board. Everything was story pointed, and they knew they would do A, B, C, all the way through to Z.

Ive also worked with looser approaches. These managers approach sprint planning with, What are we getting done this week? What's going to come out the other side? They might know the functionality itll have and a general sense of how to break down the work, and thats enough for them to feel confident in getting the work done.

Theyre very different styles, and both can work.

The point is, I havent seen many managers succeed in adopting something that doesn't fit their natural tendencies. More often than not, they fail when they're trying to emulate somebody or a process that doesnt align with their preferred working style.

The engineering manager is the one taking on the responsibility to organize a group of people to get things delivered. As the new person coming in, you have to figure out what works for you and your team.

All this is going to determine your satisfaction and confidence in the way your team works. Its your team, and you need to be comfortable with how they operate so youre not second-guessing things. You need a process that allows you and your team to thrive.

Why its important: Your manager judges your success on what information you give them and how you present it.

Whereas the first tip is about your working style and interactions with those who work below you, this tip is about acknowledging your managers working style and how youll conform to it while maintaining your own.

Figure out how much reporting up your manager wants -- are they a details person, a big-picture person, or (hopefully not) a micro-manager?

The reality is, their style might be very different from yours. You might be very organized, but your manager is very loose. You might show them the sprint board, but they only want to know how its all going, what youre delivering, and where you are in the process.

Your level of organization will likely be able to produce that information; you just need to present it differently. If your organizational approach doesnt easily produce the information your manager needs, you need to adjust your process -- but you can still do that in your own way.

I've had direct reports who were more organized than I was, and I had to tell them that their sprint board didnt mean anything to me. I could tell the team did a lot of work, but I wanted them to zoom out, give me a sense of where they were at, and if there was risk involved in that project.

Heres a reality check, though. You'll switch managers, and all of a sudden you have a totally different universe.

For example, I reported to a very hands-off, trusting manager at Bitbucket. I was enjoying the autonomy, until my manager changed, and then I hated my job. The new manager was a micromanager who wanted to know details 10 layers in.

I was on top of all of those things, but he was stressed because he didnt know the answer to everything. It meant I spent more time documenting what I knew so that he could know them too. If I didn't do it, my life was going to be even more unenjoyable than it already was reporting to this guy.

Coming from an individual contributor role, you might not be used to reporting up much. Understanding who you work for is hugely important. Even if you don't like them much, you have to figure out how to work with them. They're your boss.

Why its important: The expectations will create the landscape of your job, and you have to be able to meet them.

Every company does things differently, but the lowest common denominator typically is that engineering managers have responsibility for both the personal and technical sides of things -- but the emphasis can be quite different.

There's a big debate in the industry about whether engineering managers should code or not. I think EMs should focus on doing impactful, useful things. Coding is a distraction. But some organizations want EMs to spend a percentage of their time coding, which creates a very different job layout.

This ties into how technical youre expected to be. I've worked at places where they wanted EMs to have a nuanced understanding of how to build and grow teams, make them efficient, and use the roles on the team, while also having enough technical acumen to know whats BS and whats legit, but not necessarily have to answer technical questions.

At other places, they want you to be able to do the technical work if you had to and have technical conversations. Likely, youll know this before getting hired into an EM role, but its important to know what mix of expectations will make you satisfied in your job.

Why its important: Getting hiring wrong is hugely expensive, time consuming, and frustrating.

I entered management not realizing that hiring can be 50% or more of the job, and not understanding what it meant to be good at it.

I went through a phase where I figured the organization would ultimately handle hiring. Only after messing it up for many years did I realize that not taking it more seriously led to big problems.

Even if you work for a giant organization that has a robust hiring process, if it's not doing what you need it to do, youre not going to get a great squad.

So, figure out what you and your team need to do to hire well. This means many things:

Own your candidate pool and hiring processes such that your team can be successful.

I never really wanted to know how to hire well, but when I realized I wasnt very good at it, I thought, How do I get better? I read some books, took ideas I liked, and came up with a structure for what to test for in interviews.

If your team says a candidate seemed good but nobody was really thrilled with them, then you don't hire them, because youve agreed you're the type of team that's looking to be thrilled.

Understand the hiring expectation, too. Is your team growing? Whats the right configuration of who you have and what you need? Determine what skills youre missing and what skills would augment the team.

I've interviewed people who were brilliant, but Id never hire them because they werent team players and theyd destroy the team's cohesiveness.

I was interviewing a manager who seemed great to all of my other managers. But our most senior engineer, who is the nicest guy on the planet, had nothing good to say about the candidate because of the way he asked about things. That told me something wasnt right with this candidate.

So, be intentional about hiring. You might think theres some degree of trial and error -- you hire someone who checked all the boxes but they end up not performing well -- but thats an expensive experiment.

You're hiring because you're behind, and you need somebody to help you get ahead. If you mis-hire, now instead of having somebody who's helping you get more done, you have somebody whos a problem and takes up 50 percent of your week. You want to be fair, so you spend time meeting with them more often, trying to help them succeed.

But often it doesnt work out. So bulletproof your hiring process.

Why its important: Its the best way to improve and be effective.

You can keep all of these tips in mind as you start your new role. But the best advice is to jump in and do the work. Get your hands dirty. Make mistakes and learn from them and make fewer mistakes next time. The worst thing you can do is aim for perfection -- the enemy of good.

Run an experiment for a process change. If your team shows up to the retro and says the system you came up with is garbage, change it again.

Set a goal to change something at least once a month to zero in on whats working and what isn't. Even if everything seems to be working, there's always one thing to do to be a little bit better.

If all the devs complain about something that you don't think is a big deal, but it's affecting their morale, shake up the process and see what works better. The best managers who have worked under me do this in real time, all the time.

As with any role, itll take time to figure out what processes and dynamics work for you and your team. But for engineering managers in particular, the faster you do this the sooner your team will run efficiently, be happy, and be a source of your satisfaction.

The rest is here:

5 Tips To Crush It as a First-Time Engineering Manager - InformationWeek