You don’t scale, so don’t be a hero

I’ve been writing code since 1999; professionally since 2009. For many years I put in 60+ hours a week at my job. I was young. I was committed. And most importantly, I was am passionate about programming.

Putting in extra time didn’t really seem like a big deal. I was doing what I loved to do, while helping my company at the same time. I’m a problem solver. I work on problems in my spare time, and research solutions. I enjoy staying up-to-date on new technology. My brain literally does not let me disconnect some days (to my wife’s dismay). While I would love to focus on personal project problems after hours, my work ethic and sense of responsibility often points me toward focusing on work related problems instead. And because I’m often online after hours already, responding to alerts or conversations that popped up after hours just happened naturally.

If this sounds anything like you, beware. In my years, I’ve been known as the office hero, and have won awards to prove it! The guy you come to when you don’t know where else to go. The guy where even if I can’t solve your problem, I can likely direct you where to go; and if I can’t, I’ll help you find out who to go to. This has all worked out well and good…..for me…..so far.

The problem is that I am not scalable; I’m just one person.

As our organization has grown, so too did the demands on my time. Over the years, what used to be one or two interruptions a day grew to 10+. Whenever somebody interrupts you it results in a context switch, which even if they just need your attention for 2 minutes, have been shown to reduce your productivity by much more. Even worse, what if they need something urgently after hours; you’ve become the go-to person so guess who they’re calling on that Sunday afternoon.

When you become that go-to person, it’s not good for you or the company. Don’t get me wrong, firefighters will always be needed; Those employees who you call in a pinch to get you out of a tough spot. The point is though, that they shouldn’t be relied upon. They should be the exception, not the expectance.

A coworker of mine once put it very nicely. I can’t remember the exact wording, but it went something like:

Unknown to you, your child is playing in the street and there’s a car speeding toward them. Luckily a stranger (the hero) happens to be walking by grabs the child and pulls him off the street just in time.

Are you simply going to rely on a stranger being there again the next time?

I would hope your answer to that question is “No”. However, every time you help somebody out with something that you are not directly accountable for, or with something after hours when you are supposed to be off, you’re implicitly say “Yes”.

I’m not saying that you should let the child get hit by the proverbial car. I’m saying that you should instead direct the people making the request to the appropriate team that is accountable for helping in the given situation. If no team is accountable, then make a point to raise it up the chain of command to determine who should be accountable, and make sure that team knows they are accountable for it. If that team is unavailable in the moment of a fire (such as on a weekend), then by all means help put the fire out, but make a point to follow up and ensure there’s a proper escalation policy in place for the next time it happens. Many teams actually get paid to be responsive after hours, so you shouldn’t be consistently doing it out of the goodness of your heart (which I did for many years).

Similarly, maybe there’s not an urgent fire that needs to be put out, but something that needs to be completed on a tight deadline. A project that your boss is hoping to have completed by Monday. Or perhaps a critical issue has been discovered and you need to find and fix the problem, so you work a bunch of extra hours. Or maybe you’re just very inspired by what you’re working on and put in a bunch of extra hours.

Putting in extra hours may be acceptable occasionally, and it may even reward you some well earned kudos and look good on a performance review. However, if working late hours becomes the norm, it’s not good for you or the team. It begins to look like your team is simply able to handle more work than it truly is. At that point, it just becomes you masking a staffing problem. If you are regularly putting in extra hours, you should be recording them and making sure to be compensated accordingly (e.g. extra pay or time off in lieu).

It’s in the post title, but I’ll state it again:

You don’t scale

The best thing to do in the interest of both you and your company is to ensure that proper accountability is explicitly assigned, and that there are enough people to handle the workload. If there aren’t enough people to handle the workload, then you need voice that and set proper expectations.

Hopefully by following my advice, you’ll be able to relax and enjoy your weekends, and the weekend fires will still get extinguished.

To recap, I’ve brushed over 3 types of developer heroism:

• Being the office go-to person; either the helper or the local switchboard.
  • This is bad because it causes a lot context switching for you, which means lost productivity.
• Putting in extra hours all the time without reporting them.
  • This is bad because it hides staffing capacity issues, and people may not realize when you are being overworked.
• Making yourself available after-hours.
  • There will become an implicit expectation that you can drop whatever you’re doing jump in at anytime. Make sure there’s an explicit escalation policy in place, and appropriate compensation.

You should be proud and feel good when you’re able to be the hero from time to time, but be very weary if it starts happening too often, and be proactive in finding and pushing for solutions to avoid it.

Happy coding helping :)