The Curse of the Capable Engineer
Thursday, Mar 02, 2017

I started off my software career as a developer. Since then I’ve had a variety of roles. From devops/systems engineer to cloud architect, and lately to a management-style role.

The software development and systems engineering days bred a control mindset. I became the go-to, get-it-done-no-matter-what guy that everyone could rely on. It didn’t matter if I knew how to solve a problem, I knew I could do whatever it took to figure it out.

But as I shifted toward a management role, my control tendencies became problematic. I realized I had trouble letting go of responsibilities and trusting others to do the job.

Becoming the hero

As capable engineers, we usually end up as the subject matter experts on our aspect of the project or team. This is especially true as we progress through to the senior level.

We end up being one of a select few on the team who can keep the entire system/platform in our minds. We understand the pieces in detail, and how they fit together. The more we carve out our niche, the better we get at doing it.

As this happens, we find that others often consult us as the expert on problems they’re facing. We’re brought in on more meetings and architecture discussions. We get saddled with more advanced functionality to build. Before long, we’ve become a knowledge silo and a single point of failure within our realm of expertise.

Seduction

At first it doesn’t feel bad. Actually, it starts off feeling pretty great.

Sure, we end up working late a day or two, but we solved a critical problem. And the praise from our teammates is intoxicating. We start to feel like a warrior, like there’s no problem we can’t solve.

And the tricky thing is, none of these desires are inherently bad. We’re supposed to be tackling hard problems, figuring things out that nobody has yet.

We get caught up in the desire to prove our ability and win accolades, but forget to check our ego. We store up valuable knowledge and experience, but that knowledge stays in our head. We’re operating with a bus factor of 1.

Burnout

As we continue down this path, we convince ourselves that we alone are capable of solving this particular niche of problems. As a result, we tend to attract a lot of problems that need solving.

After awhile, we realize that we’re drowning in work. At this point, taking a break to offload our knowledge to someone else feels like the last thing we have time to do. And it becomes a vicious cycle.

And the weight of responsibility only increases. We soon find ourselves rationalizing unsustainable situations to avoid blocking our teammates.

"[Jane] is going to run into issues tomorrow with task X because my pipeline isn’t refactored for that yet. I’ll just stay up late tonight and knock it out so that she isn’t blocked."
—Me

Yes, that was something I said to myself not that long ago. And yes, I stayed up all night to rewrite the pipeline. The result? Lower quality of work. Feeling completely burnt out. And, on top of it all, feeling frustrated because the rest of my work suffered.

How to avoid it

Playing the hero, no matter how good it feels, is bad. It’s bad for the team, bad for the project, and—most importantly—it’s bad for you. Your work suffers. Your health suffers. You aren’t happy. We don’t want to end up here, so how do we avoid it?

Step 1: Document everything you know

We should be documenting anyway! When you’re done documenting everything you know, great! Keep doing it as you learn more stuff.

Step 2: Teach someone else how to do what you do

This can be a hard one, especially if you’ve got ego issues or you’re not secure in your abilities. Sometimes we don’t want to teach someone else how to do our job because we fear we won’t be valuable anymore. I have personally struggled with this mindset in the past.

The truth is, if you’re someone who brings value to the table, teaching others will multiply that value. Being a good teacher/mentor is more valuable than being a black box of problem-solving ability.

Tip: Use your documentation from step 1 when teaching others. It will help ensure that you’re actually creating useful documentation to begin with!

Step 3: Continually repeat steps 1 and 2

This isn’t a once-and-done affair. It needs to become a mindset. It needs to become a part of the team and company culture. Be confident enough to relenquish control. Be humble enough to be teachable. Be selfless enough to take time to teach and mentor.