Welcome to being a manager! Did you think it was a promotion? It’s going to be hard, lonely, and emotionally exhausting for a while.

Why?

Because you have to figure out your social support. As an IC (Individual Contributor), you had teammates, and these were your peers. As a manager, you now have a new set of peers (hopefully, unless you’re one of the first managers) but with less clear cut ways to build relationships with them. There is no management daily standup, and no code review. You will be dealing with things that can’t be discussed openly – or perhaps, at all.

Why is it Hard?

People will tell you things. They will tell you about health problems, divorce, loss, and whatever other chaos is going on in their life.

Or they won’t tell you, but you’ll notice things and wonder, try and create space for them to tell you.

Or there isn’t anything, but things are still not right and you’ll try and figure out what will improve things, what will help, and deal with the uncertainty and the guilt if you… don’t.

Being an IC was much more about showing up and caring about code, or product. Being a manager is about showing up and caring about people, the code they write and product. It means caring about people you don’t personally like, and not being too swayed by the perspective of people you do personally like. It means hearing about pain, and sympathising, but as a supportive manager rather than an untrained therapist.

Why is it Lonely?

It’s lonely because you now have vastly fewer people – or maybe no-one – to talk to. HR may (if you’re lucky) give you logistical support, but they won’t give you emotional support. You’ll be representing what’s best for the team and the person against someone whose job it is to represent the company (and ensure the company doesn’t get sued).

It’s lonely because there is no stack overflow for people, and so you will live in the grey area where you have information but few clear recommendations.

It’s lonely because it’s fine not to know a programming language. But admitting you don’t really know how to be a manager when that’s your job – with no unit tests, no code review is terrifying. You’re conducting experiments on people’s careers; there are no AB tests here.

Why is it Exhausting?

Some months into my first year as a manager, I realised that my focus was the maintaining and recharging of emotional energy. From a WTHIC letter…

“My friend Diana and I had a long phone call the other weekend, and she asked me “what’s your current project right now?” My response was: the maintaining and restoring of emotional energy. This is my observation about becoming a manager. If being a manager is emotional labour, then the challenge of management is the source of emotional labour – emotional energy. As an IC it was much more about creative energy. Or just sheer bloody-mindedness.”

At least for me, I found that the ways in which I needed to recharge from the deep focus of an IC were different from the shallower and shorter focus and interruptions of management.

I just had less emotional energy on a daily basis. I was prepared to use what was left on close friends, less so on people who weren’t – and who maybe I never got closer to as a result.

As an IC my excuse for not dating was that I spent all day surrounded by men, I didn’t want to spend my evenings with more men. As a manager it became more that I didn’t want to find myself 1:1 with someone I barely knew, getting to know them and pretending to care about things that are of little (or no, formula one – yawn) interest to me.

What To Do?

As an IC, I had so many people I could talk to about my frustrations. We’d commiserate about XCode, or Eclipse, or Android Studio. About the state of testing, poor project planning, and bad managers.

As a manager, it’s amazing how often I’ll express some vague complaint to a friend, maybe mention that my day was exhausting because of some random thing I’m worried about, and get a response of “you need to fire that person”.

That’s not… how it works? Firing people can be necessary for medium or long term intractable problems. It’s a terrible default.

When two libraries don’t interact well together, the context of that is usually a straightforward description of the environment and dependencies. The description of the team and company environment will be really long, even if you fully understand it yourself, which you probably don’t.

The answer is:
1. People to talk to.
2. Ways to talk about things.

1. People To Talk To

Your manager is hopefully someone you can be really open with (one of my first observations as a manager of managers is that I spend energy supporting people on things they haven’t got anyone else to turn to on). If your manager is good, building this kind of relationship can be invaluable. It’s often helpful to be clear what you want advice on, and what you want to talk through.

A coach. Working with a coach has been really, really helpful. As she puts it, “I’m a vault”. Because we talk 3x a month, she has a lot of context on what’s going on with me. She’s also a non-judgemental space where I can be honest about the stuff I find really hard.

Trusted friend-mentors. My preference is to have one specific question and go deep on that rather than trying to talk about everything.

Peers. This is why we created the New-ish Eng Manager Slack. We operate under Chatham House Rules and it’s a place to discuss things that we don’t always feel we have other people to turn to about. When I was an IC I could just tweet random questions but it’s often not a great idea to do that as a manger. Aside from the impact on your team, it can be something you need to explain when you try to recruit.

2. Ways to Talk About Things

Complaining

If you have a bad day writing code, it’s fine. Everyone understands. If you have a bad day running a team… it’s harder to explain and riskier to express. Sometimes we all just need to complain. This is part of why we have a “no unsolicited advice” rule in the Slack (see also: The Gestalt Protocol). Obviously we need to take productive action on the things that stress us out eventually, but sometimes we just need to vent.

Gathering Information

This is good for getting a bunch of information about how other people solve things that you can then use to generate more ideas for things that will work for you. The thing is to make the question specific enough, and to frame it so you’re inviting people to share their experience, rather than tell you what to do.

How do I do 1:1s? -> Do you have any questions you like to ask in 1:1s (and why you find them useful)?
How do I onboard a new manager? -> Do you have a process for onboarding new managers? In particular are there any resources you share, or extra things you do for managers in their first 3-6 months, year?
How do I fix this project that I think might be failing? -> What early warning signs of failure do you look out for in projects?
I’m worried my team doesn’t communicate. -> What do you do to foster communication amongst your team?

Going Deep

Above I mentioned picking one question and going deep on it. This is good for example when you have an idea of a pressing thing that you need to solve for your team, but little insight into how to solve it. This is best for 1:1 conversations.

When I’m thinking about what to talk about, ahead of time I’ll think through three pieces: Question, Constraints, Observations.

Question: What do I need to do? E.g. create a roadmap. Assess a project that seems like it might be failing. Resolve a conflict.
Constraints: What constraints am I operating under? What do I not have control over? What about the wider organisation or team effects this? E.g. “The ratio of designers to engineers is really low.” “The culture of the server side engineers seems really different, and I’ve noticed resistance to planning or regular status updates.”
Observations: Things I’ve noticed that seem pertinent. E.g. “I’ve noticed that people don’t seem to push back enough on things that get introduced later that are a lot of extra work – some of these really don’t seem worth the time spent on them.”, or “I’ve noticed that too often when I follow up on things they are untracked or progress hasn’t been made on them.”

This is part 2 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.