As I close in on my first 90 days of being an engineering manager, I want to address the most common question I received since this state transition1:
What would you say you do here?
I’m not a boss, I’m a talent wrangler.
On film sets, talent wranglers manage schedules, handle logistics, and keep actors focused while coordinating between production crews and studios. Their job is to get the best performance out of my actors given the role they are playing in the movie they’re making.
Similarly, my job is to get engineers to perform at their best. I manage schedules, handle projects, maximize reports’ focus time, while coordinating between product, design, and stakeholders.
What does that look like day-to-day?
Many people misunderstand managers' roles, assuming we don't contribute much. When asked, managers throwing out vagaries like “unblock” and “liason” doesn’t exactly help.
To help answer this, I started keeping an inventory of the tasks I was doing from day-to-day:
Project management: - Creating tickets and project plans, and assigning tasks. Running kickoffs, retros, and syncs.
Switchboarding: - communicating across multiple slack channels and DMs, maintaining and index of resources so I can the right information to the right person at the right time.
Hiring: - writing job descriptions, conducting interviews, and coordinating with recruiting and finance to get resources.
1-on-1s: With my team, with my manager, and EPD2 peers, with my manager.
Performance management: Developing and enacting growth plans. identifying opportunities that align with team members’ goals. Asking other people “What would you say they do around here?”
Writing: PRDs3, SOPs4, agenda, TPS reports5, miniature manager manifestos. Especially working remote, written communication is a huge part of the job.
To summarize, my job is to do all the context-switching so that engineers don’t have to.
But don’t you miss writing code?
This is the second most frequent question. “Building is so fun! Why would you trade that for [shudders] meetings?”
There is still some “IC work” involved, at least for now. When I do I focus on work that unblocks and empowers my team: Reviewing tech specs and pull requests, taking care of the occasional urgent bug so my engineers aren’t interrupted.
Also, I get to do a more abstract, more fascinating kind of engineering. I am still working on a system. The system is made up of values, processes, goals, and plans. We are constantly designing, refining, and refactoring it. Instead of writing code for computers to execute, I write ideas for people to implement.
Engineering, Product, and Design
Product requirement document
Standard operating procedure
Office Space reference
This is really fun stuff Glenn. Not a techy here, and the things you write about are applicable to so many different fields. Nicely said.