Transitioning to meta-management
Cate Huston’s post The Hardest, Shortest, Lesson Becoming a Manager recently resonated with me. She writes about the shift from day-to-day engineering to day-to-day management of engineers, and focuses on the reasons why it’s probably a smart idea to step away from coding as a manager.
In the last year+ I’ve stepped into a “meta-manager” role, meaning that I’ve started managing managers. Most recently, I transitioned out of managing the Performance engineering team, confidently handing the baton to an engineer who has been eager to learn about the people stuff. Moving away from directly managing the Performance team was a huge step for me; it was the final leap away from “the work”. I no longer sit in standups or see more than high-level strategy for the work; I have monthly skip-level 1:1s with engineers, but rarely talk about the day-to-day. I love my new responsibilities, but there’s been a lot of brain-readjustment through this transition.
Measuring success as a meta-manager
I’ve worked closely with many new managers, first leading a roundtable to help all new managers at Etsy through their first three months of management here, and now I’m directly managing two brand new engineering managers. I’m very used to having the “how do I measure my success, now?” and “how do I feel better about coding less?” 1:1s with newer managers (and love those conversations so much!). My personal experience has been that, over time, I grew to just intrinsically trust my own gut about whether or not I was successful at management. Sure, there are plenty of indicators, and regular 360-degree feedback helps triple-check that gut instinct. But I had learned to lean on an internal sense of whether or not I was moving in the right direction, accomplishing things, etc.
Suddenly, as a meta-manager, I realized I had begun to feel those new-manager unknowns again. At the end of the day I’d wonder, what on earth am I doing? Am I doing this right? How will I know? The amount of time between taking an action and finding out if it worked or not is substantial as a manager, and even larger as a manager of managers. The key indicators that I was doing The Right Thing each day were now even more faint. I am in new territory, and my gut hasn’t been calibrated yet to these new measures of success.
Cate’s post helped me realize how similar this transition is to transitioning into management to begin with. While she doesn’t focus on finding/feeling success as a new engineering manager, she does talk about how to step out of the way of the day-to-day engineering work. I think there are some clear parallels to meta-management.
How to scratch the itch
Cate writes about how to pick your coding work, if any. “If I’m trying to write code now, it’s something that me being slow to complete shouldn’t be blocking anyone. Cleanup tasks are a good place to start.”
If I feel the itch to do engineering manager work, there have got to be good ways to do this that are absolutely not a) going to intrude on someone’s existing work, and b) not eliminating an opportunity for the manager who reports to you to learn. I shouldn’t be stepping in and cleaning up a JIRA board. Instead, can I write up a proposal for a new process that could help a few teams? Or schedule some skip-level lunches with a group? How about I reach out to a few other managers and see if they need any help with anything?
Carve out space for someone new to learn and grow
Cate asks readers to gut-check stepping in, even if you know you can do the work exceptionally and quickly. “Even if you are genuinely the best and most effective person to take something on, does this make your team more effective 3 months from now? Unlikely.”
Even if I’m genuinely going to be better at stepping in and setting a project’s strategy, coaching an individual contributor, or doing some other IC-management work, doing so means that the manager who reports to me won’t gain that experience for herself. I’d effectively be removing the opportunity for her to learn and grow. The act of stepping out of the way allows someone else to step up and nail it. I need to actively look for the ways to facilitate this kind of opportunity.
Help your brain focus on what’s most important
Cate closes by addressing the drain of context-switching and focusing on what’s most important for you to get done. “As a manager I have this mental list of things about what does my team need. Things that I’m monitoring, things that I’m trying to fix, things that I’m trying to find for them. It’s my job to understand what is going on and what the team as a whole needs to be effective.”
As a meta-manager, I have this mental list of things about what the organization needs. Themes that I’m seeing within the Infrastructure org, ongoing coaching that I’m giving to a number of managers, the evergreen list of where the emergencies are in who we need to hire for all of Infrastructure engineering. There are my new responsibilities, and that means that context-switching to day-to-day engineering management would deplete my brain’s resources for these new kinds of work.
I’m still developing my intrinsic yardstick for success as a meta-manager. But I’m hoping that reflecting on what my job is, and what it isn’t anymore, will help me hone it.