10 Tips For First-Time Engineering Managers

Hi 👋🏻 I'm Erik.

I'm just a humble Frontend Dev Manager looking to help you grow.

This isn't meant to be a manual, but rather an outline, of things I've learned in the last 3 years as a Frontend Lead & Manager.

But enough about me! This is about YOU, my budding engineering leader!

So, let's jump right in...

---

1. Being a manager is hard.

Managing isn't easy. Period.

I wanted to get this out of the way to manage expectations (see what I did there 🤓).

The only people who say managing is easy are those who've never managed.

Being a good leader means the blame for an entire team falls on you. It means you're getting pinged at all hours of the work-day to answer questions and solve problems. It means a TON of meetings that you wish you didn't have to be in but are SUPER important to the success of your team and the project.

Your Slack, or Teams, has 100 notifications with 100 questions that each have no relation to the other.

Hey did you have a chance to...?

Do you have a minute...?

What do you think about...?

Did I mention meetings?

Yes. Meetings. All day. Everyday.

It's like a 5k marathon of meetings for a charity that your best friend begged you to join, at the last minute, knowing full well you just finished eating a whole pizza for breakfast (don't judge me just run with it 🏃🏽‍♀️).

---

2. Don't try to know all the answers

It's not possible.

Here's what you should do: know who to talk to, at the right time, to get the right answers.

Sometimes that person can be your very own direct report. Ask them for their expertise on a subject. It's a win-win.

Why? Because, you get the answers you need while making them an integral part of the project. And needless to say, DON'T STEAL THEIR SHINE. Make sure everyone knows where you got that key information and/or idea from.

Pro-tip: Say "I don't know, but I can find that out for you"

Bonus: Ask the "stupid" questions.

Most people don't care about the upfront ignorance, they only care about the end result. What you'll quickly notice, when asking these "stupid" questions, is that 5 other people were too afraid to ask.

Do this as early, and often, as possible to shore up any missed details.

---

3. You're not expected to be the best coder

You're expected to be the best leader.

if (isManager) {
   console.log('Coding is secondary, sometimes tertiary');
} else {
   console.log('Get to coding, Yo!');
}

Keep your skills sharp enough. The fact is, if you want to manage and code, you're going to burn out. Of course, sometimes you'll have to dive into a codebase to help your team. However, on most days you won't, and shouldn't be, coding.

There are so many other important things that you need to do, and get done, that coding will be the least of your worries.

---

4. Delegate! Delegate! DELEGATE!

Seriously. Delegate. You can't do everything. Trust your team to handle some work. If you don't trust your team, well then you need to train them up! The better your team is, the more comfortable you will get with delegating.

Repeat after me: Trust. 👏🏻 The. 👏🏻 Team. 👏🏻

Of course, you can't delegate everything. But when you feel that cup overflowing and that burnout creeping, just delegate!

---

5. Learn your team's communication & working styles

Everyone communicates, learns, and contributes differently. Some people need blunt feedback and a day to get it done. Others might need a more empathetic approach and a week, to nail it. Learning this about your team early on will make the road a smoother one.

• Dana might be a night-owl that wants few details and more autonomy
• Jared is an early-bird that requires a step-by-step live walkthrough of expectations before they feel comfortable tackling the problem.

No two people are alike. That doesn't mean that they both can't be effective and successful in the roles.

Pro-tip: Check your ego at the door. It'll only create problems.

---

6. Understand your team's goals

Large Goals

First, large goals should always be set by you as the lead. Those goals vary from project to project, company to company. But these are overarching team goals that don't focus on any one individual.

Example: "100% of team to complete the Intro to React course by End of Q1"

Personal Goals

Personal goals should start with you asking your direct reports what they'd like to accomplish. Many people have an idea of the path they'd like to take. Use that information to help build an outline for the year and break it down by quarter.

If your direct report has no idea, well, make a goal for them! You'll figure out how to pivot along the way.

---

7. Imposter syndrome hits harder

I'm sneaking this one in-between like a sandwich 🥪 because I didn't want to scare you!

But it's an unfortunate truth.

There are often days where you work hard. So hard. You're ready to have several drinks, eat a whole pizza, and go straight to bed -- hard. And it STILL feels like nothing was accomplished for the day.

There are weeks and months where it looks like you're not doing anything significant. Like you're not learning anything new. Like all you're doing is putting bandaids on cement cracks...

All of that will make you feel like an imposter. You'll ask yourself "Am I even a good leader?", "Will I get replaced with someone better, more 'technical'?", "Is my body really equipped for all these meetings?".

It's inevitable. You'll have to remind yourself that you're a badass. How? I personally like to list out all of my duties and accomplishments. It helps me put things in perspective.

Here's an example:

I led a team of 10 developers, in a cross-functional team, across 5 different timezones, to deliver a complete replatform of a multi-billion dollar e-commerce company's website.

That's me. I've done that and guess what? I still feel like an imposter at times 😅

---

8. Bring receipts

Look. Pretend like nobody will advocate for you but you. You have to keep and bring receipts when the time comes, and it will come, believe me.

Take note of all your team's wins and accomplishments. I don't care how you do it. Notion? Bear? Word docs? Doesn't matter. Keep track of it all. Dates and details of projects including what hurdles you had to jump, and how you came out on top.

But don't stop at successes. Keep track of losses and any of any contentious interactions (it happens, it's unavoidable, protect yourself). Do a self-retrospective / post-mortem often.

Stay prepared. Don't get caught off guard.

---

9. Your team's success is your success

The focus should be on elevating your team and getting them the W's (wins). All of YOUR primary W's should actually be their's.

If your team is winning, you're winning. It's as simple as that.

The saying is "We the best". Not "I'm the best" 🤔

---

10. Last but not least... Do some management training

Seek out knowledge because someone else probably already figured out how to do that thing you're trying to do. This applies to management as much as it does to programming.

A small bit of training goes a long way. We don't know what we don't know. A lesson here and there can make us more effective leaders.

Sidebar: If you have a favorite manager/leader, take note of all the reasons why you think they're amazing and copy those traits!

---

Whoa

That was a lot. I'm going to lunch, you should too so you can let it all digest 😉

Thanks for reading!