Embracing papercuts

We’ve all seen “helicopter parents,” hovering over their kids to catch them at the slightest inclination they might fall. We swear we’d never do that, that we’d give our kids room to grow and learn from mistakes. Then we become tech leads and turn into the worst kind of “helicopter leaders.”

I was certainly guilty of micromanagement. It started with code reviews, commenting on every minor issue I could find. Hey, just setting a high quality bar. Then it moved to second-guessing every design decision in the team. Just making sure we’re on track! I probably should have noticed something was wrong when I started becoming the bottleneck for the team, but to be honest I didn’t really notice until some of my teammates started getting pissed off with me. We’re now great friends but it got a little tense for a while!

Get out the way

A team of strong engineers will outgrow you. If you’re involved in every minor decision then the team will end up being under-utilized. You want to have a team of engineers, not code-monkeys, so treat them as engineers and give them room to do their job.

The best way your team will learn and grow is for them to take ownership, make mistakes, and learn from these. These are far more valuable growth experiences than whatever they read about on some blog (cough).

It’s not just about empowering others though, you have shit to do yourself! If you spend 100% of your time on day-to-day decision-making then you’re spending 0% of your time on longer-term strategy. If you drop the ball on the latter no one is there to catch it for you, so don’t spend all your time on everyone else’s problems.

Raise your standards

Surprise! This is not the section where I tell you to just relax and let your team screw stuff up.

Don’t do that.

The point of letting your team make “papercuts” is to produce a net benefit to the company; we’re not running a charity here! Your people need autonomy so they can reach their full potential. They need room to make mistakes so they can learn, and they need the organizational air-cover from you to allow them to do so. No one is learning anything unless there’s accountability for quality and execution though, otherwise we’re just being sloppy.

Autonomy goes hand in hand with setting expectations, asking when projects will be completed, and reflecting on whether work was successful.

You’re not going to go far by bullshitting your team though, so no need to pretend you agree with them. Some of the most motivating phrases you can say to an engineer are:

I don’t know if I agree with you, but this decision is on you. You can do this. Roll with it, but this is what I expect...

or

Let me know if you need any input but otherwise I’m going to stay out of this one. You know what we need and when we need it by. You’re in charge here. Knock it out the park.

Say one of these and watch the output of your team members sky-rocket… well, hopefully. Engineering productivity is critically tied to motivation level. Autonomy coupled with high standards is a huge motivator to talented engineers.

Type 1 vs Type 2 decisions

This all seems like fine management mumbo-jumbo but where does the hard part come in? Just in case we got too touchy-feely for a minute there: If you give your team autonomy and disaster strikes then that is your fault. You are accountable for the direction and execution of the team, you can’t just take your hands off the wheel.

You take a risk when you give others autonomy. The safe option is just to micromanage the shit out of your team — you’ll get mediocre output from mediocre people, while your good people go work somewhere else. That’s not what you’re all about though right?

The real art to insightful technical leadership is figuring out which decisions might end up with someone losing a metaphorical arm or leg and which might just result in a papercut. Jeff Bezos calls these Type 1 and Type 2 decisions. Type 1 decisions are big hard-to-reverse decisions with serious implications for getting it wrong. Type 2 decisions aren’t such a big deal, you can back out of them or change course later. You absolutely need to be on top of Type 1 decision-making, just don’t go overboard worrying about the Type 2 stuff.

There’s no easy answer for what is Type 1 and what is Type 2. You’ll have to use your brain for this unfortunately. As some general guidance I tend to think of the following as Type 1 in the context of software engineering:

• External APIs, at least the major details.
• Distributed systems protocols.
• Standards for correctness, validation, and reliability.
• Security decisions.
• Whether to devote a lot of resources to a project, e.g., a major system rewrite.
• Long-term team strategy.

Other stuff? Well a lot of it is ok so long as a smart person is being held to high standards. Want to use library X instead of library Y internally in a project? Go for it, I don’t care.

If you’re a senior engineer in a design review, consider whether you should just be telling people something is a Type 2 decision instead of being too heavy-handed. If you’re a more junior engineer looking for feedback, consider first getting input on whether it’s a Type 1 or Type 2 decision. If you just go in asking for design feedback you’re probably going to get it, whether you like it or not.

You might be wrong

This post has already gone too far towards making the tech lead seem like some kind of special genius. You are probably not a special genius. One of the best things about allowing people to “experience papercuts” is that very often they don’t result in papercuts after all. It turns out you were just wrong.

There’s a good chance your engineers know more about their particular part of the stack than you, and there’s a good chance they’ve thought about a particular decision more than you have. Sure they might not be as experienced, but there’s a good chance they’ll prove you wrong. Usually what happens is just that the decision didn’t really matter that much after all — you were both right. Or maybe we wasted some time but the engineer worked much harder because they had ownership — it all balanced out.

Focus on the medium-term output of the team, not the short-term. Being proven wrong is a great way to achieve more as a group than you ever could by yourself.

Crawl before you ball

This is hopefully obvious but this is all about empowering people who are ready for that responsibility. Junior folks are going to need some hand-holding even with Level 2 decisions. This also doesn’t absolve you from responsibility for giving advice and guidance on issues both large and small.

If team members are feeling overwhelmed then you’ve gone too far. Don’t throw your intern to the sharks.

Summary

Give your team autonomy for decision-making and allow them to accumulate some “papercuts” but hold the team to high standards. Exercise your judgement to figure out which decisions are critical and which are reversible. A team will grow faster and be more productive when people are given ownership and accountability.

If it turns out we screwed up a little and wasted some time? Well we’ll just have to step it up more next time.