Hacker News Reader

Comment by spenczar5 | Hacker News Reader

How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.

Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward.

I learned those rules from observing the behavior of group leaders I've worked with/for. There have been a few times (over many years) when I've thought to myself, "My boss is fantastic! I am so amazingly lucky to be working for this person!!" When that happens, I've asked myself, how does he/she do it? And tried to figure out the answer.

There also appears to be satisfaction in cultivating new talent and watching it grow. A friend of mine is at his most excited and animated when he is talking about the new ways his reports have grown as engineers, not when he's talking about this or that technology.

"Competence is it's own reward." Nicely said.

Well, if you keep working on shitty tasks (because you assign them to yourself) and keep being interrupted, only for your product to depend on the hazards of the market, you will get burned at some point if what you ship fails for reasons that don't depend on you or the team and people leave as a result.

I honestly hope it will not happen because you seem like a great Lead, but you can't say this scenario is not a possibility.

Burnout's likely whenever you work really hard on a product that nobody uses, regardless of what your role at the company was. It sucks to sacrifice hard for something that doesn't pan out.

The solution to that isn't to only work on the stuff that pleases you, though. It's to only work for companies that have traction or at least demonstrated consumer demand. It's the founders' job to validate that there's a reason for the company to exist; make sure they've actually done their job before you entrust them with yours.

This happened to me, and is one of the reasons I quit being a manager and went back to being a developer. The product didn't actually fail, but the daily stress of constant interruption and long hours of slogging through thankless shitty tasks eventually wore me down.

Also, I regret not having delegated some of those boring and shitty tasks, since they would have developed skills in my staff (like debugging under difficult environments) that would have made them stronger and more independent developers.

If you don't derive satisfaction from helping your team, absolutely do not become a lead. Between meetings, planning overhead, interruptions, team communication, documentation, and so on you'll never reach the kind of individual productivity you could alone.

Definition of shitty task varies greatly.

A personal anecdote: I have recently discovered I was bored on a job because the tech lead, after working with a dozens of engineers who considered cleanup and simplification tasks boring and wanted to implement new features, stopped parcelling out those and kept them to himself, while distributing new functionality tasks (which I don't personally enjoy doing 40 hours a week) throughout the team.

There's some amount of zen to it. Your job is no longer to be the best coder yourself, it's to make everyone else the best coders they can be. I don't have kids yet, but I can imagine some similarities.

On the other hand, once a month or so I hide from the office for an afternoon/night and replace some infrastructure or build an internal tool that's never going to get prioritized. Everyone's happy about it, and you get to feel like a bit of a hero :)

There is so much zen to it. I've gone from being the single developer sitting in a room with the founder and the creative director building a product from scratch to managing a technical team of 15 at the same company, with another couple dozen employees in other departments.

The difficulty of running a large technical team is all about managing coordination and communication overhead. You need to build a culture where interruption is frowned upon, but at the same time you need to ensure that knowledge isn't siloed. The balance is very very important, and the means of achieving it are much more art than science. I suppose I could throw up my hands and concede I'll never be able to regain the focus to be a good individual contributor, but I rebel against that inclination on the (perhaps selfish) belief that going full management would put me out of touch with the people I'm managing.

In any case, it is possible to both manage and write code, but it requires an incredible amount of discipline to truly embody the nature of each job and do them well side by side.

Be very judicious about how often you put your own delivery on the critical path of the project (or sprint, or other unit of work.)

It shouldn't be very often.

Yep. You should never ever be on the critical path

1. If you don't deliver and you hold up the schedule, you lose authority as a leader because really … if you can't, then you can't expect others. 2. You WILL be diverted to other tasks that will hold you up

Knowing #2 and still causing #1 is fatal.

My biggest energy expenditure is usually right at the beginning of a release cycle, or even a week or two before it when our process is working correctly (a good process means a boring release week).

We will have figured out some big infrastructure or design issue we need to fix and between requirements meetings we code like hell. Blocking people during week 1 or 2 goes a lot better than week 8 or 17.

I've found this to be the single greatest challenge I have as a tech lead. It's incredibly tempting to say "oh, I think I'll have time this week, so I can take that Trello card". If it's on the critical path, leave it for someone else. You won't have time.

If you are in a healthy organization, even though you verbally credit your team, etc., consistent successes will reveal that you are a good leader and mature leaders (above you) will recognize your value.

You lower your expected output.

For me, I get the satisfaction of solving the really crazy problems, and seeing how it affects team productivity. Every week you find a way to save the team a manhour or more of frustration, and it adds up quickly.

You also tend to fix bugs and perf issues nobody else is sanctioned to spend that kind of time to tackle.

Make sure you're getting compensated properly, and make sure it's work that's visible.

If you can't do those two things...well, enjoy your burnout. :(

I chuckled, then cried inside reading this, so true.

But there is something to add to this, I got burned out, took a mini-sabbatical and came back a rockstar with a pay raise.

I guess the invisible work became visible in my absence. :-)

An additional side-benefit, I became human again.

When my coworkers bitch about being underpreciated I tell them to take a week off and find out if they're right. if everybody isn't on the same page it's time to move on.

Reply on news.ycombinator.com