Management: what is it anyway?

Last updated June 15th, 2017

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.

Disclaimer: this is all my opinion, and informed only by my experience at Etsy.
Different companies have wildly different management practices and structures. Your mileage may vary.

Here are a few managerial words I'll use:

A report is a person who reports to a manager

An individual contributor (IC) is a person who has no reports

A manager is a person who can hire, fire, and determine the level and compensation of their direct reports

A person's level is their job title

A promotion is a change in a person's level, it may or may not have an impact on their compensation

A raise is a change in a person's base salary, typically the biggest portion of their compensation

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.

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:

Technical direction: being responsible for the technical success of the area of ownership of my team

Product management: determining and setting expectations with respect to what we were doing as a team

Project management: determining and setting expectations with respect to when we were doing it as a team

Program management: leading cross-functional initiatives to improve cross-organizational practices

Career development: helping my reports be successful in their careers—both during and after their time at Etsy

People management: determining compensation for my reports and advocating for appropriate leveling

Staffing/recruiting: growing the team in a sustainable way

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.

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.

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.

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.

Protip: disciplined test driven development is like autosave for the mind. Nothing is better than a
failing test case to help jog your memory of where you were when you had to change gears.

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:

Collecting feedback from my team in 1:1s to understand their progress, challenges, and roadblocks

Reading email/slack or grabbing coffee/snacks with others to collect problems from the grapevine that apply to my
team's domain

Translating those bits of information to language that makes it easy for stakeholders to understand the impact

Turning feedback from our stakeholders into a vision of what the team should be working toward

Communicating that vision to the team in a language that makes it easy for them to get on board

Giving individual feedback to a report based on my observations of their behavior

Setting (and re-setting) expectations outwardly of what to expect from the team

Prepping for any of the above meetings

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.

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.

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.

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.

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.

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.

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 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.

Do you want to learn more? Was something confusing? Was something insightful? In the NYC area
and want to grab a coffee? Feel free to drop me an email at
sufian@gmail.com or send a tweet my way
@sufianrhazi

Disclaimer: Unless stated otherwise, the above words are my own and do not represent the
opinions of any person or business but myself.