It's been several years since I've come off of my former role as an engineering manager, and with enough humble introspection I've had several insights into the mistakes I've made, and how I'm integrating those learnings into my teams nowadays.

How it all began

Five years ago, I first inadvertently found myself in engineering management. My manager sat me down in a room and told me he was leaving, and that he wanted me to take his place. Would I be up for the challenge?

I told him I’d think about it, then went home and started freaking out. He had been so critical to the company was walking off with so much in-house experience, relationships, and domain knowledge. Was everything going to fall apart without him? Would I be able to fill his shoes? What if I couldn’t?

I came back the next morning and told him I was up for it. A few days later, I was on my own. There was going to be a steep learning curve and plenty of bumps on the road. Sure enough, I made more than a few mistakes.

1. Trying to build silos and defenses

The company at the time was in a pretty bad spot. Revenue was plateauing, and morale was kind of meh. The organization had gone through a high amount of turnover, and things weren’t looking like they were getting better.

At the time, the project management team had a reputation for being pretty heavy-handed with Project Managing™️ and had clashed my boss. Hard. I knew where my boss was coming from and agreed with his approach, but his personal style had burned a few bridges.

One of the first things I did as a manager was to start the team doing retrospectives, but doing so apart from the rest of the product delivery organization. I honestly felt like our working relationship was not in a productive place, and I feared that my team would not be able to honestly voice their opinions out in the open. So I told everybody - we would be doing our reflections and retrospectives on our own. Closed doors. It felt like the right thing to do at the time, with the uncertainty of transition, I just didn’t trust other people to be able to hear my team out.

The problem with huddling in a defensive posture is that I didn’t end up trusting other people to be present in the room, give people the space to voice their opinions, and become an improving organization. I had also projected my internal beliefs and (mis)understandings of the rest of the product delivery organization and assumed the worst intentions from them rather than offering them the benefit of the doubt.

Lesson learned

Overcome fear by posturing the team with a learning mindset and a framework for honest communication.

Always assume the best intentions from others, especially when relationships haven’t formed yet

2. Overlooking the traits (beyond seniority) for great hires

Hiring was (surprise, surprise), one of the most challenging aspects of management. Collectively, our team and I decided on some criteria we wanted for prospective candidates, which kept a pretty high bar. They had to excel at data structures, have a great nose at OO design, understand best practices of software development, and all that jazz.

Of course, these are important skills for a senior software engineer! But once in a while, we’d come up against a candidate that didn’t really have the skills to qualify for the role in our job description but had a fantastic personality or a curiosity to learn.

When trying to make the hiring decision, I oftentimes found myself picturing this candidate in the mindset of “could this person kick butt tomorrow on my team?” In my mind, this would be the domain of the grizzled software veteran.

But what I wasn’t asking was: “given 6 months on our team, could this person really grow into (the engineer I’m imagining)?”

I did once hire a junior engineer fresh out of boot camp who later went on to become one of our most effective engineers on the team. It was a credit to her teachability, curiosity and collaboration skills that gave her a career trajectory far higher than I originally estimated for her.

Lesson learned

Hire for the engineer you may have six months down the line, not necessarily the engineer you see now. Prioritize empathy, curiosity, and teachability - not just career experience.

3. Delaying direct feedback

I had an engineer on my team who was, from my perspective, underperforming by not staying on task for much of the workday. When asked to do work, he’d crank out some code (that was pretty decent), but it would lack tests or would be overlooking some key requirement in the story. He had a reputation that was unbeknownst to him, but obvious to everyone else that worked with him.

For some reason, I kept feeling like I needed to sugarcoat my feedback. In our one-on-ones, I would dance around the topic. “You do good work, but you missed some requirements here and there”. “Good job on delivering X. I hope we can give you a big project Y, but I think that PR stayed out a bit too long. Let’s keep our eye on the ball.”

But it wasn’t working. Fellow engineers would acknowledge his lagging contributions in vague, general terms, not wanting to come off as mean or underhanded. Product owners would turn to me after sprint planning and ask what they could do to help.

Truth of the matter, the responsibility for his performance was mine, and I needed to give him more critical, crucial feedback that would open to his eyes to the reality of his situation.

What I needed to tell him was, “Hey, you’re underperforming and people are noticing. I need you to rein in your web surfing and pitch in with some solid work. I know you’re capable of doing this - let’s focus on testability this week…”. Because if I didn’t give him this feedback now, he’d just end up hurting our team’s morale. I was doing him no favors by shielding him from hard feedback.

Lesson Learned

Direct, actionable feedback from a place of genuine care is a crucial component of great management (see Kim Scott’s excellent book, Radical Candor).

Great management is hard work!

After about a year and a half in my position, I decided to move back to an individual contributor role - the next four years of my career were happily spent in software consulting at Carbon Five with the most fantastic people I’ve ever worked with. The lessons I’ve learned from my first stint in management were hard lessons to learn, but they’re mistakes I hope I’ll only have to make once.

In a future post I’m going to write about the great experiences I did get to have in software management, and why I think it’s something worth doing.