My First 30 Days as a Manager: The 3 Biggest Questions I’ve Asked Myself So Far
VP of Engineering @ Buffer
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.
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 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 who 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?”
Key takeaway: This is a solved problem — the help is there. I just had to ask.
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.
Key takeaway: 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.
How do I manage someone 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, and 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.
Key takeaway: I don’t have to be able to do their jobs better than them. They’re the experts, and they should be.
Over to you!
I still don’t know what my biggest rookie error is. I guess that’ll be a subject for another post.
If you’re a manager of people, what were your biggest lessons early on? And if you can share the best traits of managers you’ve had, I’d love to hear them! Grateful for all your thoughts and feedback in the comments!
Try Buffer for free
140,000+ small businesses like yours use Buffer to build their brand on social media every month
Get started nowRelated Articles
Nine years ago, we decided to launch a new free product alongside Buffer. We called it Pablo, and it was a huge hit in our community. Within just seven months of its launch, half a million photos were created using Pablo. Similarly, we had the initial ideas for Stories Creator and Remix many years ago now. All three of these tools have been an important part of Buffer’s story. They’ve taught us lessons and helped us connect with a wider audience. In Pablo’s case, the idea for this tool happene
If you use Buffer, you might have experienced us having more downtime than usual recently. We want to start with an apology for not sharing more transparently along the way what’s been happening. We’ve been caught up in the work and haven’t invested enough in communicating with our community, and we’re so sorry about this misstep. We know some of our customers have had a frustrating time using Buffer recently and we need to do better by you. This past August and September were the months we’ve
As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.