JUMPING INTO MANAGEMENT: LESSONS LEARNED SO FAR (PT 1)
About one human-baby-gestation-period ago, or 9 months in common parlance, I jumped into management. At first it started with a single human, then a few months later that escalated 400% to four (or a nibble of engineers, in non-common parlance), and now seven unfortunate souls have to sit with me in 1:1s every week.
While my efficacy in the role is still up for consideration, and maybe something someone else should evaluate, I have learned a few things in this time.
YOU REALLY SHOULD STOP/GREATLY REDUCE TIME SPENT ON TECHNICAL WORK
During most of my experience so far, I have spent significant percentages of my time doing technical work. This, more often than I count, resulted in me rolling into 1:1s saying dumb shit like:
“Well you know I’ve been heads down on this bug for the last week and haven’t given any thought to you followed up from our items last week”
A great way to show care!
If possible, you really should make strides toward reducing time spent on non-manager tasks to give people the time they need. This lesson has been reflected in pretty much every piece of beginner-manager advice I’ve read, but it’s also one of those things that can very easily fall under the “oh after THIS one time I’ll start doing my real job!”.
PEOPLE ARE NOT YOU
After spending many, many hours in talks with people about their work, how they operate, and where they want to go, I’ve come to the conclusion that other people are not the same person as me.
This has come as a bit of a shock!
- Where I may push back on every assumption or request on my time, others may not, and so working with them I’ve needed to keep that in mind when planning projects.
- Where I might hassle my manager every 1:1 about promotion or ratings leading up to PSCs, other people are less comfortable talking about this or are more passive about it, but still be stressed by the process and need to be talked to.
- Where I’ll want to know what I’ll be working on 13.5 weeks out, others are more flexible with their plans.
Finding those differences and framing conversations with them in mind is a muscle that is difficult to flex. This is should be obvious, but I’d say most people do a very poor job at this and it can be hard to be self-reflective enough to identify your own hidden assumptions and beliefs. These assumptions and beliefs you have are a key part of your ability to manage humans.
OLD CONVERSATIONAL HABITS LIVE LONG
I’m a very informal and often not-PC person. Pausing and thinking through what I’m about to say when a witty witticism pops into my mind has been a difficult habit to bring on. I find it a bit difficult to filter myself.
Beyond just non-PC things, talking frankly about opinions on projects, people, or ideas is more of a no-go area as well. If leadership comes up and says “For reasons, we are planning to put Porkchops into Meatsickles”, it’s part of my job now not to chat with the team and tell them how stupid the plan is in my opinion or otherwise colors their minds.
The reasoning is pretty clear about why not to do this, and I agree with the reasoning. If your team thinks you think the project is a waste of time and they’re working on it, the corollary is that you think they’re wasting their time. No one wants their manager to think they’re wasting their time.
I HAVE NO IDEA WHERE MY TIME GOES
As an individual contributor, I knew exactly where my time was going. Now, at the end of the day almost every day I think to myself “I was busy all day, what the fuck was I doing?”.
I can think back to specific things I did, like editing a wiki or talking to the seating captain about seating chart changes or meetings, but I entirely lack the plot arch to present as an engineer - at the start of the day X feature wasn’t complete, and now it is! Yay!
Maybe I should be better at this than I am, but from my understanding this is a pretty common situation.
FAKE IT TILL YOU MAKE IT DOESN’T REALLY WORK
A large portion of my team works in a codebase and in a world that I am still not entirely comfortable with. My background is in firmware, while the team I now manage is about half firmware and half more general software people working in an entirely different codebase than I have knowledge about.
Yet, most people wanting to interact with the manager of these engineers don’t know that, they just assume I know everything.
They’re wrong, I don’t know everything. Far from it. Solid 2/10 knowledgeable.
Telling these people coming to me time after time “I don’t know, I’ll get back to you after talking to the team” doesn’t breed much confidence in me from the questioner or the team. These aren’t answers I can “fake it till I make it”.
This hasn’t been an exhaustive list and I keep coming up with more as I write, but I’ve procrastinated enough. So I’m going to publish this after appending a “Pt 1” to the title and carry on with my other responsibilities.