I suspect that the reason for the perpetuation of this myth is that, if a manager is doing their job really really well then all of that stress and BS is hidden from their directs.

Indeed. The best managers I've ever had were the ones that completely shielded the rest of us from the absolute BS that always exist. Go figure, those were the companies where the rank & file didn't think political BS existed - surprise, your manager was protecting you from that!

So essentially managers are people sysadmins. They make sure everyone is working, try to resolve conflicts and ideally make sure that everyone is running the right tools. What would be a people engineer in that vein?

Yes. Although in my case when I was talking about my 'best managers', they were also the people who were brilliant and were really good at the tech side too. These people all just had a natural ability to navigate through the political BS while still being extremely competent software folks.

Looks like those people were truly "full stack". From the tech layer to the interdepartmental layer.

Yes, as much as I hate that term it really does apply here. And I'm really only thinking of 2, maybe 3 folks. These were the people who managed to be the most productive members of the team while dealing with all of the manager BS. When you find one of those you do what you can to stay under them.

Mentors and leaders.

HR.

Nope. Those would be teachers and trainers.

So to continue the IT parallel, that'd be setup (hiring and training) and maintenance/debugging (hr complaints and problem resolving) imo. My personal hunch would be that viewing the whole thing in a systems context, the EOs would be engineering. After all, they decide how the company is run at a top level, and either assemble a functioning "people stack" or set guidelines for doing so. In that vein, components/prospective employees are churned out by the education system as a broader whole, and the raw material for that...alright, i think that's taking the metaphor far enough.

Managers create the BS, so they can hardly be credited with shielding people from it. They also create a lot of BS for their own reports such as playing the "your job is to make me look good" game, or having devs do a bunch of leg work so they can present everything as their own ideas.

Those are stereotypical bad managers, not ALL managers. I know a lot of great managers who are not like that. And even the ones that failed didn't fail due to malice or vanity. Most people I've encountered want to build cool things, even the managers, and they often know their strength is not in coding.

Bad managers, sure. Not the sort that I'm talking about.

> As a programmer, let me tell you: people who have only ever done programming for a career have no clue how relatively easy they have it.

As someone who was a banquet manager before switching careers I can assure you that you are 100% absolutely correct. My most stressful days (of which there are very very few) as a developer don't come close to my least stressful in my previous career.

To add some more details - being a good manager can be a delicate dance. When you are a manager, you start to become responsible for high level tasks that have huge impact to a company. However, if you micromanage too much, you create an awful culture of fear and hamper developer productivity.

So how do you inspire developers to execute in a timeframe dictated by others? You have to be a leader who inspires the engineers to complete the task, even if it requires putting in extra hours. This means setting the example, looking out for your engineers' welfare, being able to provide answers and not problems, and being someone who can be easily approached.

The moment something goes wrong, the burden is on the manager to make the right decision - the wrong decision can have negative ramifications over months, if not years. The moment you micromanage, something is broken in your process, or with the people involved.

I recently had to start wearing a technical lead & director hat - the intense pressure of the startup world bore down on my whole team in order to get a working product in order from scratch in about 1 1/2 months of coding. The resources became scarce since the technical lead got sick & had a family death, while two other senior engineers had babies in the time period. It then was left to two junior developers and me to do the lion's share of work until the other engineers could get back to work. I let the junior engineers work mostly normal hours (until close to our deadline) - I ended up taking the burden largely on myself, with mostly 75 hour weeks (even after the other engineers were back as well). During regular hours, I did some work, but was more focused on mentorship and any tasks that were blockers. The early and late hours were when I busted out complex code.

At the engineering level, good management shows as incredibly important, especially for startups. Pressure deadlines on engineers are taxing for all - good management by top level engineers is vital for preventing burnout in everyone else, which can make it easy for people to decide to leave a company, especially when compounded by salary that does not match what the free market has to offer.

Thanks for sharing your story. This is part of why I love HN: I can learn from the experiences of people who're interested in similar things to what I'm interested in, but who're much further along in life.

Also wow, well done on shielding your junior engineers from the worst of the death march. Did you suffer much from burnout during your heroic effort? How did you cope?

I have a lot of resilience from a lot of life experiences. This not having been my first crunch time also helped me cope - I focused on getting as much of a good night sleep as I could (typically 6 - 7 1/2 hours a night, usually ended up closer to 6 - 7 1/2 is my optimal amount), and dosed on lots of caffeine if not well-rested. Exercise is also important.

I did have to sacrifice all other interests thought during the time period though. All I know is, I'm definitely taking a vacation in two months.

Not the OP, but similar situations. My coping strategy involved vitamins - a generous dosage of B-complex, and a mandatory eating and sleeping regimen. Survived potential burnout myself, and won concessions for team recovery. I've done this a few times now, difficult, but still works.

I've only done programming and research for my career and shudder when I look at my boss's job. Heck, I get stressed just being assigned an intern. People management isn't for everyone.

Not really, it just depends on where you've worked in the past. If you came up under a decent management structure, you've had it easy. If you didn't, you get all the BS in addition to trying to solve potentially complex tasks.

I've had 1 good manager who I was too inexperienced to appreciate. Beyond that, the better managers I've had was too soft that the other departments were able to play politics with or hijack their staff and the worst did their best to keep you ultra stressed 24/7 because they thought you'd deliver more work that way.

We've all came up in different ways, unless you've had multiple lifes experiences, it's really hard to decide that's the way it is for everyone.

I don't think you can make that kind of generalization. It really depends on the organization. Ideally neither position will pull an unequal amount of weight.

Remember that in many cases, the software developer has the same kind of weight on his shoulders; some bugs and errors can cause huge amounts of lost revenue, lost jobs, etc. Software plays no small role in the day to day operations and programmers carry a lot of weight on their shoulders, especially in companies that don't have strong testing and review methods (read: almost every company in existence).

This is definitely true. I recently made the transition from full time Engineer to Engineering Manager, and there's a lot more stress involved. It stems from a few different things:

* In most cases, the Manager acts as the communication layer between different departments. They abstract all that stuff away so developers can write code without being interrupted by various people. They then have to communicate that information back down to their team when needed (and in the right way)

* As a developer, you have a deadline, but missing it is often just a "Well, we didn't have the time" or "We tried, but just couldn't quite get there". As a Manager, it's your responsibility to explain why something was late, how it can be remedied in the future, and answering the inevitable "Well when will it be done then?". You're responsible for the overall project, including deadlines.

* Meetings. Not only are there a lot more meetings, they're often made for the schedule of other departments who don't have "the zone" in the same way that developers do. I still write code in my day-to-day, but a 60% reduction in programming time ends up being an 80% reduction in output because you get interrupted, side tracked, and generally don't have time to "ramp up" for >2 hours at a time.

There are many more reasons, but the stress level in the Management role, in my opinion, is a bit higher.

I'm technical and I'm not that naive. The good bosses pull way over their weight in gold in what they do. Its not for everyone though.

Thank you for posting this. I do think some companies undervalue their engineers, but it's crazy how frequently managers are disparaged on this site.

ive done both and the stress depends on where you work a lot.

Note that this include the "tech lead" stuff. That said on average for me and my close colleagues its largely always been easier and less stressful as a manager or director.