3 Crucial Things I’ve Learned In My First 30 Days As A Manager

It feels ridiculous for me to write about being an engineering manager. It’s a job I’ve done for not even 30 days yet. But that’s what I want to know from others—how did you start? How did you make it through your first month?

No two first rodeos are ever alike. But they’re all rodeos, and falling off is falling off. There’s some kind of pattern. So here I am, writing the post that I want to read. And in my first month in a new management role, I’ve found these to be the three things I’ve had to sort out above all else.

1. What Is This Job, Anyway?

I had a rough idea what I was getting into from the internal job description, but there’s a chasm between “Help build deep fulfillment and ensure the personal growth of team members” and, well, doing that.

So I went on something of a crusade to understand what exactly I should do. I asked engineers at Buffer, “What do you think makes a great engineering manager (EM)? Where do you think I fall short?” I am so grateful for the honest answers of my peers—it allowed me to develop a clear sense of how I need to grow. I stalked people on Twitter and LinkedIn, cold emailed them, and asked them how they survived the switch. “What was your rookie error?” became my pickup line.

I’m continually astonished at how helpful the world generally is. I’ve met up with incredible people whom I’d thought wouldn’t give me the time of day. I’ve found this awesome Slack community where I can see, in real time, a smorgasbord of management scenarios unfolding and people of experience, the very kind of people I want to become, give their advice. There is such treasure, if you care to dig.

From my own experience, I certainly remember times when I knew what I wanted from a manager, but didn’t feel I could speak up and ask for it. So I’ve decided to ask a very simple question: “What is something that I can do for you over the next week to make your work life better?”

I quickly learned that this is a solved problem—the help is there. I just had to ask.

2. What Happens To My Old Work?

This is tough. When an engineer switches to management, the team loses an engineer. That puts a damper on team velocity and morale, but doing two jobs at once is infeasible. Having a handover and transition plan was my first task. It’s a real challenge to figure out who can take over the work you do in a team that’s already lean. And let’s face it, there’s never an “extra engineer” twiddling her thumbs.

I got really lucky here: Half my team (non-engineers) took a vacation as I made the switch, so there was a natural lull while I Googled “how to be an engineering manager.” Then I got another break: A product team happened to be disbanding, and there was someone ready and excited to take over. I dodged a very difficult quarter.

Think about your old responsibilities—don’t just walk out. If there’s really no one to step up, then schedules will slip. Realize this, and make sure others realize it, too.

3. How Do I Manage Someone Who’s Better Than I’ll Ever Be?

This was the scariest thing I had to do. Before jumping into a first meeting with an engineer whom I admire greatly, I was decidedly fretful, and definitely anxious throughout. What did he think of me? Was this a huge waste of time? I shudder at the opportunity cost.

After that first video call, it hit me that although I thought he was awesome, I’d given zero recognition. Realizing why I held back calling out good work was a key moment for me: I didn’t feel qualified to praise this engineer. I felt that my opinion didn’t matter; that he’d think I was an idiot for praising something he’d done that was no big deal. It would be like praising Dan Abramov for writing a todo app in React.

Once I understood and named that fear, it went away. If I was better at coding than the engineers I managed, then I’d be writing that code. But I’m not. That’s exactly why I’m managing!

I’m better at encouraging and unblocking. I think that’s when the idea of “servant leader” started to click.

I am there to sort out all the stuff that stops engineers from focusing. Make the processes smooth. Make sure they find their work interesting and challenging. Make sure they are having the biggest impact that they can. Understand who they are and what drives them, and line that up with what the team needs. Tell them when I think they did something great. Ask them why they did something that falls short of our quality bar—maybe there was a good reason. Maybe I can help. I don’t have to be able to do their jobs better than them. They’re the experts, and they should be.

I still don’t know what my biggest rookie error is, though. I guess that’ll be a subject for another post.

An earlier version of this article originally appeared on Buffer. It is reprinted with permission.