[mikeg8]

Again, you continue to describe the role of a FOUNDER, not an employee.

Your use of words like “blow up” and “duty” need some serious reflection. One of the biggest failures of or modern corporate culture is the mindset that we should live to work instead of work to live. A vacation requires disconnect to be truly valuable, if your brain is still in work mode, you may as well have stayed in the office.

[setr]

I'm describing the role of a manager, versus a contractor/leaf-resource.

A vacation is valuable, I agree, but your position within a company is a reflection of our position within it's operation -- the higher you are within it, the more people you screw over when you say "it's 5pm goodbye" and don't have things setup to handle it. Your power, and pay, is a reflection of that: you have less and less leeway, as you have greater impact, to screw around.

It would be a very poorly run company that allows everything to shutdown because a VP (key: not founder) went on vacation -- the same is true of a department head, and his department, and a team lead, and his team. But it's also the CEO's job to make sure he picks VP's who ensure this not the case within his domain, and the VP must pick the department heads, and the department heads their team leads -- if you are willing to allow, or unable to prevent, such scenarios to bust forth, you really shouldn't be managing that particular domain.

The more important you are, the less freedom you have, because the greater the impact your choices will have.

And to be clear I'm not using duty as an implication of loyalty or whatever -- I mean that a manager, or manager of manager's job really boils down to one thing:

Ensure productivity within your domain

Not letting your team implode in two weeks of your absence is part of that

[guitarbill]

> the higher you are within it, the more people you screw over when you say "it's 5pm goodbye" and don't have things setup to handle it

disagree. in fact you should be doing this, especially if you're in a higher position in whatever hierarchy. because you then have more power to dictate culture, and properly set boundaries.

all these arguments have been mentioned before. it can be seen as a mini-drill/game day to see how the business copes when you're gone (for whatever reason). if you've set up/helped set up a robust business, nothing bad will happen. if not, you've already failed the business. i guess that requires trusting your employees though.

being liable to burn out is also a risk to the business, not an asset. if you are a knowledge worker, not unplugging and coming back refreshed is also a risk to the business, not an asset.

[setr]

My key requirement is that you need to have things (processes, roles & responsibilities) setup to handle it.

I'm not arguing whether its good, or bad, to setup such a culture -- go ahead, I won't stop you; hell, I'll enjoy it. But things need to be setup to actually survive that model.

If things are not setup properly, and you try to enforce your hardline stance anyways, regardless of how it impacts your domain, then you are operating as very poor manager. You can't just randomly drop the ball like that -- if you want a strict 8-5 working culture, or a 100%-offline vacation culture, you need to do the preparation for it.

And if it can't be done, because of whatever local constraints, then it would be absurd to go forward with it anyways; then your goal should be to find some reasonable alignment with those constraints. The same way that a programmer can't simply decide that functional programming is THE ONE TRUE GOD, and inject haskell into everything when no one else knows it, and then rewrite everything, when no one else can participate.

You can't just go ahead with it randomly, and say it's not your responsibility (it's your domain: it is your responsibility), and really, its the FOUNDER's fault for allowing this situation to occur, I'm actually not involved anywhere in this -- because then the FOUNDER should, and hopefully will, execute according to his responsibility: replace you with someone who does realize he's responsible for his domain, and set things up to run efficiently/effectively within the culture he chooses to instantiate.

That is, from the corporate perspective, the culture really doesn't matter -- as long as it works. The criticized culture is simply the common, default, good-enough solution that works just about everywhere (and features the IBM property: no one gets fired for buying into it); another culture is fine, as long as you do the prep work for it.

But if you don't, and try to enforce it without preparing for the consequences (both to extract the good and mitigate the bad), then it's entirely your own failure.