Management: what is it anyway?

Last updated

After about 8 months at Etsy as a software engineer, I became an Engineering Manager and acted in that role for just under two years. At first, it wasn't that great. Having never been a manager before, I really had no idea what managers did and to be honest, I didn't really know what I should be doing. The change was stressful. I didn't even understand what to look at in order to assess the impact of my work.

Unsurprisingly, it took a long time (and a lot of missteps) to get comfortable and feel effective in that role. Think of this article as a bit of advice to my former self about what to expect when you're expecting to be a manager. Management is a very different career path, so if you're thinking about making the transition, consider if starting on a new career path is the right move for you.

What does a manager do?

Let's start from the beginning. What does a manager even do?

If you don't know, this may be disappointing: we manage.

I mean this both sincerely and literally. Managing is like when you ask someone, “how are you doing?” and they say, “eeh, I'm managing.” Management is about doing the things that need to be done in order to achieve what you set out to do. It's not very glamorous, it's not about being a boss or being bossy, it's not necessarily about being a leader, and it's certainly not all fun and games. I personally think it's about providing the structure and environment for your team to be successful. Someone needs to provide that structure, and if you do it with honesty and dignity, there's a chance you'll do some good.

But what do we really do?

In short, my job was to help my reports, team, organization, and business become more successful.

In an infrastructure-oriented engineering organization at Etsy, this involved wearing a whole lot of different hats, including but not limited to:

To be frank, it's really easy for managers to be dehumanizing. This is by design: a huge portion of our job is to somehow quantify human effectiveness, strengths, and opportunities at their jobs. We hold the responsibility and burden of hiring, firing, promoting, determining compensation, and laying off people. All of these are stressful and dehumanizing processes.

That being said, that stressful and burdensome responsibility is half of the story.

We also help teams work through intractable problems, help lead by communicating a shared mission for the team, help cut through the sometimes frustrating bullshit of the daily churn, help coordinate efforts to work on improving areas across the organization, and fight for the time and space for you and your teammates to grow in their careers.

It's extremely gratifying to see someone you've hired grow and succeed in their role. It's heartening to see your team gain alignment, support each other, fill in the gaps, and achieve what they set out to do.

What's different about management?

At first, I really didn't like being a manager because I didn't think of it as being that different. I couldn't find a way of getting gratification from the work, and I think that's because the job is extremely different in two ways: timescale and context switching.

A radically different timescale

When I was an IC at my previous two jobs, the engineering organization was optimized for continuous deployment. In practice, this meant that I had the capacity to create a change, deploy it to production, ramp it up to a fraction of users, and monitor the impact of that change in the timespan of an hour or so. Depending on the traffic and nature of the change, it's possible to get statistically significant results on key business metrics within a work day.

This short timescale is empowering and addictive. I fill my bucket by knowing the value of my work, so having a very short timescale means I'm happy. However, the timescale of management is completely different. It takes quarters to see the results of strategic management work. Sure, you may see one of your reports take some advice and apply it the next day, but to really know if a person or team has grown based on your influence takes a shockingly long time.

Let's go through an example to demonstrate.

Say you're introducing a new biweekly process to a team's rhythm. People are creatures of habit. It will take several runs for the initial excitement/dread to fade. If you don't apply an even coat of communication and repetition during this beginning period, the process just won't stick.

To make matters worse, you'll most likely need to adjust this process to meet the particular needs of the team. This will take several more iterations filled with trial and error. Keep in mind that this is a biweekly process, so every two times is one month. This means we'll have to wait a few months before we can confidently say the process has been internalized.

Now, if the goal of the process change is to improve the efficiency of the team, it will take a few more months for the team to be able to compare its output to how things were before. At the very least, it'll take 3-6 months after kicking off to see any real progress that isn't anecdotal. All of this while business realities are impacting your team! By this time, enough variables have probably changed in the business and organization that it's almost impossible to attribute the team's changes to your effort introducing and applying the process as a manager.

This is why managers talk about quarters and years.

If you aren't used to operating at the same timescale that it takes trees to change color through the seasons, you probably aren't going to enjoy management. So for the first year or so, I didn't get much of any gratification out of being a manager.

However, if you trace your steps backwards in quarters and years, you'll probably surprise yourself with what you've accomplished (as long as you can live knowing that it could all just be chance). This is where the job satisfaction kicks in.

Context switching

As an IC, lengths of time are investments that give exponential returns. Our job is to solve problems in typically unfamiliar areas of complex systems. The gating factor is usually the time it takes for the unfamiliar to become familiar. The quicker we can turn assumptions into verified behavior, the more efficient we are turning these unfamiliar systems into ones we can reason about. We must be able to reason about a system in order to predictably change it.

It takes constant focus over long periods of time to get from the unfamiliar to familiar. This is why if you want to ruin an ICs day, be sure to schedule short meetings evenly over a day so that their calendar is filled with 30 minute gaps of time to do their development work. By the time they get to familiarity (where the exponential returns start kicking in), the next meeting will happen, destroying the mental constructs developed with their focus.

As a manager, things are different. Our schedules tend to be slots of time that can be filled with all sorts of activities. Paul Graham wrote about this much better than I possibly could in his essay, “Maker's Schedule, Manager's Schedule.”

The majority of my time managing was spent communicating. This is pretty easily distributed into 30 minute/hour-long blocks of meetings, email, and note taking. A typical block could have been:

A small portion of my time would be dedicated to longer periods of time which required focus. This would be dedicated to developing strategy, writing, putting presentations together, and gazing off into the distance to think about things.

A note about being organized

As a manager, I found it almost impossible to see the progress I was making on anything until I focused on being extremely organized. To be honest, I found most tools for this sort of organization were limiting (aside from those which kept data synchronized across devices/viewers).

Tools don't help you become organized. You must spend dedicated effort to become and stay organized. Here's what I found to be invaluable.

Keep a single, prioritized to-do list

I kept a running to-do list of things I needed to do in a text document on my computer. Whenever I agreed to do a thing, follow up with someone, send an email, or schedule a meeting, I'd add an item briefly describing what would need to be done and optionally include a link to the email/message/document it referenced.

At the start of every day, I would mark the completed ones as done on a certain date and re-prioritize the remaining items. This was extremely useful for making sure nothing got dropped and identifying things to delegate.

Brain-dump immediately after 1:1s, review before them

After having more than 4 reports, I found it difficult to keep track of everyone's mental state. After discussing work, life, and whatever in our 1:1s, I'd braindump everything into a living document by date. Reviewing these notes beforehand allowed me to be prepared to respond to questions as well as follow up on expectations, goals, feelings, feedback, questions I had, etc...

As an added bonus, this historical record turned out to be extremely useful when making the case for compensation adjustments/promotions or providing feedback.

Structure your day to avoid context switching

When managing multiple teams, the mental burden of switching context would be extremely exhausting. To counter this, I'd color-code my calendar for different kinds of meetings and try not to break streaks of color: Design Systems meetings were orange, Web Platform meetings were green, 1:1s with reports were navy, cross-organizational meetings were yellow, and dedicated “focus time” blocks were red. A quick glance at the calendar would help me understand what to expect.

Run meetings with an outcome and an agenda

The old adage of “you get out what you put into it” rings true for pretty much everything in management.

When preparing for a meeting, it's important to state the desired outcome of a meeting. It's no good to stick people in a room without a goal. But with a clear outcome, an agenda, and a list of follow-up/action items, meetings can actually be productive. The more you spend preparing for a meeting, the more value you'll get out of it.

Keep recurring meeting notes in a single shared document

For status meetings, I'd keep a living agenda document in google docs which would be updated during each meeting. In order to keep things on track, I'd spend time prepping the agenda with things I knew we would need to discuss, but also leave time (if possible) to have additional discussion points from the rest of the team. This ended up being great for a whole number of reasons: physical artifacts made it easy to remember what was discussed, we could add follow-up discussion items in the document for the next meeting so nothing would fall off our radar, and if anyone happened to be sick or unable to attend, the agenda would have a good overview of what was discussed and what decisions/action items were produced.

Management in a nutshell

Management is a balancing act weighing the needs of the company with the needs of the team with the needs of the individual. It's a completely different job from IC work, but can be equally challenging and gratifying.

A huge shout out to Lara Hogan for being an excellent boss who coached, mentored, challenged, and supported me while I was figuring all this out.

Finally, a thank you to all of my reports (Allie, Dan, Daniel, Jeremy, Jon, Katie, Takashi, Steffi) for bearing with me as I fumbled through being your boss. I couldn't be happier with all of you.

This is the first article of a pair talking about my experiences as an Engineering Manager at Etsy. If you'd like to read more, please read “Management philosophy and expectations.”