Generally these fail when nobody believes the rationale. So in the 'work from home' example, everyone will believe that management doesn't think people are working hard enough and so they want people at the office where they can watch.
I watched a number of these types of emails get sent out at Google while I was there, changes in 'policy' which were really reducing the kinds of things Google used to do that cost money and they didn't want to spend that money any more. Nearly everyone I queried 'read between the lines' and picked up a 'your screwing us and trying to make it look like your not' message, even if the Eric and the others didn't think that was what they were saying.
Perhaps only way to message this is in the results direction. Something like:
"Hey Team, we need to ship the X project because its vital to the company, That means we're going to meet every day at lunch time (we'll provide lunch) to make sure everyone has what they need and are getting stuff done. See ya there."
Then let people work around the requirement to suit their needs.
> "Hey Team, we need to ship the X project because its vital to the company, That means we're going to meet every day at lunch time (we'll provide lunch) to make sure everyone has what they need and are getting stuff done. See ya there."
Thanks Eric. Just to clarify for everyone, as per California State Labor law, you are entitled to a 30 minute lunch break free from work responsibilities. Meetings are not free from work responsibilities, so just so everyone is clear, legally everyone can still take their normal lunch period after this all hands meeting. Any problems run into, email me and I'll put you in contact with my attorney, he's really good at resolving labor law issues. Also, I'm going to have a meeting about whether we should organize a union here, if you're interested the first meeting to discuss this will be right after the first all hands meeting, in the same location in the cafeteria.
I see from your email to everyone in the company that you are interested in the California State Labor Law. I've sent Janice over, she is your Business Associate from People, Places, and Things. She is coming over to explain the part in California State Labor law that defines 'At Will Employment', she should be there by the time you read this. Oh and don't worry, she has a box with her.
We're being pedantic here of course, Google has a wonderful mandatory training course called "Keeping it Legal" which our employee would have attended so that he could attest to that fact when he signed his personal copy of the code of conduct, and it would caution you against firing folks for reporting violations, however Random Worker here didn't report a violation, no, they played the 'labor law' card without ever having gone to a meeting where lunch was provided. And none of the mythical company behavior had any impact on their ability to take a 30 minute break. So really it what was happening here is that a mandatory meeting was called, and this employee decides to be rebellious (which is totally within their rights of course), and the company can sever their employment relationship with this person which is totally within their rights too.
No what Random User did was self-identify as someone who wasn't really signed on to this whole "The guy who pays you is the same guy who gets to put requirements out there which you have to follow to collect the pay." part of the equation which is where the 'at will' part of the law comes into play.
I realize that droithomme was just being snarky but if you're thinking about sending this kind of message to everyone in the company, even if it is in response to what you think of as a morale killing policy change, I would advise against it. That was the point I was trying and failing to make (and be clever at the same time, which perhaps is the root of the failure).
The "at will" statues are really broad, and as most employment lawyers will tell you, once you are actually suing the company you work for, you probably don't want to work there anyway, so just quit.
The bottom line is that if you feel compelled to threaten to unionize or quote labor law at your manager, you really should think about working somewhere else. Those are big warning flags that you are not a good fit for the company.
Absolutely true that 'tight deadlines' and 'meetings' are anathema. After all you're not working if you are 'meeting'.
That said, the thing that most affects delivery schedules are communication delays between inter-dependent people or groups. I really got to appreciate this at NetApp when a project was spread across two teams, one based out of Bangalore India and the other in Sunnyvale California. The 12 hr delay that occurred during non-overlapping sleep schedules tripled the length of time the project took.
The mechanism is a variation on the makers schedule / managers schedule problem which pg discusses nicely in his essay on the topic [1]. The essence of that is that "makers" have a synchronization time, when they change gears. Think of it as a 'makers near / makers far' issue and it has properties that are remarkably similar to computer memory synchronization issues. Engineer is cranking along on some part of the project and hit a problem in some other engineers part of the system. If they can turn/walk over and start talking to them they carry their context in their heads, discuss, resolve, and keep cranking. If on the other hand the other engineer is 'far' and not immediately available, they have to stop, create an imperfect summary, message it out, and then wait. The 'far' engineer gets the message, reads the summary, then responds with questions (generally the first engineer who has the whole picture in their head leaves stuff out of the summary) and those go back, which then interrupt the first engineer in what they were now doing so they task switch back into that original problem, add additional detail to the summary and respond, maybe at that point they can pick up the phone and call (not often to India but certainly for a remote office in the same time zone that works). And the process continues. The problem gets resolved and our original engineer is off and running again. Often times people won't even really realize how much time they are spending synchronizing as opposed to working.
The more intertwined the system these folks are working on is, the more these synchronization points occur, and the more they risk slowing everything down.
So if the problem is 'things are not getting done in a timely way' and the cause is engineers being spending time being stuck waiting for some time with another engineer who knows the part of the system they are stuck on, the solution is more rapid communication between engineers. You can focus on fixing that issue. Sometimes just having an IRC channel where folks can talk is enough, sometimes you need something more. Sometimes a sync meeting is the correct answer.
I agree with both you and ChuckMcM that occasional meetings, carefully targeted and run, can help. But he was describing having meetings every day, which I think is completely nuts. If you decide to have one meeting to figure out where communication needs to happen, that's fine, but regularly scheduled meetings without even having something specific to meet about are crazy.
I watched a number of these types of emails get sent out at Google while I was there, changes in 'policy' which were really reducing the kinds of things Google used to do that cost money and they didn't want to spend that money any more. Nearly everyone I queried 'read between the lines' and picked up a 'your screwing us and trying to make it look like your not' message, even if the Eric and the others didn't think that was what they were saying.
Perhaps only way to message this is in the results direction. Something like:
"Hey Team, we need to ship the X project because its vital to the company, That means we're going to meet every day at lunch time (we'll provide lunch) to make sure everyone has what they need and are getting stuff done. See ya there."
Then let people work around the requirement to suit their needs.