How I Got Here - I'm a Manager!

Who knew that documenting the vast majority of your life would require more than a couple of blog posts?  Not me, apparently.

At the end of my last post, I was desperately in need of a fainting couch, learning that, despite every secret blood oath I'd ever made, I was going to be a manager - at least temporarily.

My first few weeks on the job were overwhelming.  My inbox jumped from having, at most, 10 new emails per day to having 100 emails per day.  At the end of the first week, my boss informed me that I was supposed to provide a weekly "one-liner" that described the most important issues and accomplishments of my team for the previous 5 days.

Deciding I was going to go above and beyond, I wrote a short paragraph (probably the length of this blog post up to this point) and sent it in.  My boss pinged me on Saturday morning telling me it was too long.  

I edited the one-liner, sent it in, and then promptly updated my LinkedIn profile and my resume, figuring I was facing burnout if I stayed in this role longer than a month.

The flood of emails was an entirely separate source of stress.  Many of them were automated responses that I thought I needed to watch, eagle-eyed, in order to report on trends for software builds or other similar phenomena.  Others were status updates that I thought I needed to memorize, and yet others were urgent requests for my team's time to work on some particularly critical project or issue.  

And yet, when I would go into manager status meetings with my peers, and they would present flawless updates for their teams, while I tried to glue all of the incoherent pieces together.  I wondered how they were able to synthesize all of this information.

Now, long after my first day as a manager, I can say that learning to use "no" and "I don't know" has proved invaluable.  My more diligent peers employed this tactic to manage expectations for their teams.  The less diligent usually just spitballed through the updates, staying just far enough ahead that they couldn't be called on their bullshit directly.

If you're curious in the use of "no" and "I don't know," it goes a little something like this.

"Do you have an update on that?"

"No."

"What's the current status of this project?"

"I don't know."

"Can you commit to completing this project within 2 weeks?"

"Hah, hah.  Fat chance."

Doing so in an infinite loop will probably get you fired quickly, but if you filter on the key projects the company or your boss is interested in (and confirm that's what they're interested in, so if they ask you about some side requirement later you can always echo back to them that it wasn't important during the original briefing), then you reduce your own cognitive load and usually gain some admiration for your honesty and inclination against attempting to weave a wild tale of Arthurian software heroics against the Dreaded Timeline.

The other problem I faced that's extremely common among new managers (and some very experienced ones) was delegation.  I'd resolved to take on the menial tasks for the team, so they could handle the more critical and interesting projects.  In doing so, I'd decided to handle the menial configuration file updates that came to us, which didn't really require much effort, but were a general nuisance.  

The problem, though, is, as a manager, you're always context-switching.  Have a full hour to sit down and work on that config change?  Great, but an employee may need assistance with an issue, or a peer may need to work through the basics of project implementation that's about to kick off, or you may just zone out after 3 hours of back-to-back meetings.  55 minutes later you have to head off to your next meeting, leaving that config change abandoned.

This happened enough that something that required 30 minutes of my time as an engineer, now took 2-3 days.  I realized that, rather than being someone who was enabling my engineers, I was now a bottleneck.

So, I began delegating menial tasks as well as juicy ones.  In hindsight, even if I could've sailed through the configuration changes, this was (and is) the best course of action to take.  Engineers should learn how to navigate the novel and the mundane - it goes with the job.  Giving them the entire range of tasks also ensures they're not shielded from potentially broken processes (indeed, if memory serves correctly, one of the engineers on my team got tired of making manual configuration changes and found a way to streamline it - something I never would've seriously considered as a part-time contributor).  

That doesn't mean you should dump mounds of garbage upon them, but if the work task belongs to the engineer, give it to them.  If it's tedious and it's going to make them grumble, give it to them.  But make a good-faith promise to help fix the issue that's so tedious or, better yet, give them space to fix it themselves.

Also, distribute the load of tedious work, even if it means that the timeline is extended.  Continuing to rely on the same engineer for the same mundane tasks will not end well.  If you save time now, you'll ultimately pay for it when the engineer gets frustrated and quits.

I'll take a moment here to point out that - at least among line managers (i.e. those who manage engineers directly vs. middle managers of managers) there are still expectations at some companies that those managers will either continue to code as part of their duties or will be intensely involved in the team's code reviews.

This is a bad idea.

If you're still coding, you're (a) taking away opportunities from your engineers to grow and contribute to interesting projects (b) creating a conflict of interest if your ideas run counter to theirs (god-forbid there's something wrong with your code, which will make the conflict even more painful) and (c) you'll probably extend the deadlines more than necessary because of the context switching I mentioned above.

People often counter my statement with "how do you know your employees are writing good code if you're not reviewing it?"  First, as I've stated before, good code is highly subjective and everyone hates everyone else's code (as well as their own previous code), so you can't actually state whether anyone is writing good code in any given situation.

But, I realize that's a philosophical cop-out.  Luckily, there's a much easier way to determine if your team is writing good code: 

• Does it cause bugs?
• Are your team members able to review each others' code without abject looks of confusion or scorn?
• Are others outside of your team able to review your team's code without abject looks of confusion or scorn?

If your answers are no, yes, and yes, then you can be confident they're writing good code.  It may be the most horrendous, convoluted, confusing spaghetti in the face of cyberdom, but, if a good representative portion of your organization is fine with it - and it's functioning - then it's good code.

If that that doesn't convince you, then I will humbly beseech you to consider your own proclivities toward micromanagement, because no further argument will convince me that you need to get into the guts of the code.

Well, unless you're leading a team of exclusively junior engineers and are the de facto senior engineer.  But, if that's the case, you either need to get a senior engineer or two on your team right away or push the junior team towards independence as quickly as possible.

This doesn't mean that you're destined to let your technical ability atrophy.  A good manager needs to be aware of the space their team inhabits and needs to act as a referee when hype or pessimism rear their respective heads in project work to be the voice of reason or dissent.  I actually learned more about scalability and distributed systems after I became a manager than I did when I was an engineer.

Well, that's enough for today.  As usual, I thought I'd only have one post documenting my time in management, but it looks like it'll be 1 or 2 more.  Maybe I should write a book.

Until next time, my human and robot friends.