I understand it's tongue-in-cheek, but #2 is actually worrisome:
> There’s even a “no meeting Wednesday” meme in the company, which you might as well call a “failure to communicate” death wish. Software needs to be talked about and debated, not simply written. It’s lunacy to be writing and shipping code at a blistering pace, instead of letting things bake a bit in committees representing broad swaths of all semi-affected parties.
There are a lot of companies where failure of communication is a very real thing, and where semi-affected (or totally affected) parties are completely ignored. In my experience, ideas for code do need to be talked about and debated, not simply written. Facebook has had a lot of very public privacy/other failures that could probably have been avoided if there was more communication going on.
If you're just writing code at a blistering pace, without a lot of communication, there's a good chance you're not writing the right code.
Meetings are a very expensive way to communicate. A concise, well-edited email is more difficult to prepare, but cheaper for the company. If something takes you an hour to write but the ten recipients can understand it in six minutes, you saved nine hours of time over having an hour meeting. That's like having an extra person on your team, without having to pay them or buy them a computer!
(That's why a textbook costs $100, but a semester of class costs $2000. Economy of scale.)
Of course, if you anticipate the discussion to mostly be back-and-forth, then a meeting could be necessary. But have an agenda and stick to it. If you just want to socialize with your coworkers, duck out early and hit the pub.
An hour to write plus 10 * 6 minutes of reading time = 120 minutes total. That's an average of 11 minutes for each of the 11 persons.
It's very difficult to hold meetings that only interrupt employees for 11 minutes. In addition to this, emails are async so they have less interruption overhead.
So being able to write very well is important, it's a very underrated skill in many companies.
If your meeting absolutely positively must happen on a known weekly no-meeting day then there's really only three cases I can see:
1. You are bad at planning
2. You are bad at communicating
3. Something really, really bad happened and people will understand breaking policy
There's a big difference between "no meetings ever" and this.
Sadly there is a particular type of person who discovers the day that nobody is supposed to go to meetings is the day when everybody is free and the meeting rooms are available. And then starts scheduling meetings for that day.
This is the same kind of person who discovers that people, and rooms, are "available" from 12-1pm, and 6pm-
After too many days of back-to-back meetings from 10am to 3pm I've taken to creating a repeating lunchtime meeting with myself. Then I discovered the people who don't care if you're available or not...they consider themselves important enough that you'll drop everything for their meeting.
All meetings are optional - it just depends what you're prepared to pay for missing them.
In this case, I'd say there's no/negligible cost to missing the meetings on a no-meeting day, unless the entire group of people have decided that it is worth breaking the no-meeting rule. Of course, you should let people know that you won't be there in advance...
Engineers typically go the other way though: always write email and never meet. Then they wonder why their project goes south because the specs are incomplete or the users aren't happy.
I think it's largely a knee-jerk reaction against bad meetings - hour long no-point crapfests - but they don't have to be like that.
Agreed. On my team at Kabam, we have meetings, but
1) They are as small as possible, typically including just 2 or 3 people.
2) Are always optional.
3) Typically last around 15 minutes.
It helps to have plenty of space/rooms where you can just pull someone aside to hash out a quick issue, and a mature, responsible team that doesn't need baby sitting to get stuff done.
I want to take on of your points and go on a bit of a tangent about meetings. Specifically, this one: "They are as small as possible, typically including just 2 or 3 people."
I think everybody's goal should be to make meetings as small as possible. If you don't know why everybody there is there, then either they're redundant, superfluous, or lost.
One thing I like to stress in my meetings that I run is that everybody knows why they are there. Even if that's just to listen. Too often, people think that because they were invited to a meeting, they need to say something. This is what generates hour-long bullshit meetings. Sometimes, you just need them to shut up, listen, and take notes.
I've found that if, when you set the meeting, you send a note to them after the invite with, "Hey, I know you're busy, but I'd like you to listen in on this so you understand what's being discussed. I'll get your feedback on it after the meeting." Works wonders and keeps meetings short.
Some meetings useful, even helpful. But holding a useful meeting is not easy, which means there are many bad meetings. And that's what we should all avoid. Not meetings all together, but bad meetings.
I've been to great meetings that were facilitated well and had clear, productive goals. Those we should keep. And fortunately, when meetings are productive, there don't need to be as many of them.
But those hour long no-point crapfests, yea, no one needs those.
I haven't found a strict ordering, though, for which is better at tougher issues. Sometimes face-to-face is much quicker, especially if it's hashing out high-level disagreements or overcoming misunderstandings about motivations and general directions. Sometimes for architecture or deciding on features or cuts as well. But when arguing more complex technical points, I prefer LKML-style discussion, where you intersperse code and text, and have time to properly research a serious reply.
I work at Cloudera, and engineering has work from home/no meeting Wednesday. It allows people to work wherever they prefer and are most productive, and to have the whole day to focus with minimal distractions.
That said, we do still communicate as needed for the active work. But we do so in terms of emails, chat messages, and sometimes phone calls between only the necessary parties, without any long scheduled meetings or meetings that provide value in the longer term (eg. interviews or longterm planning meetings) as opposed to helping someone do the right work today.
It works great, we've been doing it for basically the whole life of the company, and I don't see it stopping.
I work from home / where ever every day. And, it is wonderful. I can even take as much unpaid time off as I want, whenever I want, as long there is no disruption of business services to our clients. This works because I get paid hourly (I don't work = I don't get paid) and we have very fine granularity in tracking what work was done when. There is also high trust amongst all the team members that everyone is being honorable.
It does work, but has its drawbacks, for one it's communication requiring extra skill (and effort) when people don't see each other frequently. Seems that way to me (I currently operate in an environment similar to yours).
You're referring to implication then, i.e. P => Q <=> !P || Q and in that case, I definitely agree. ;-) That's also why I started my comment with a propositional "if" on how one could define "no meetings" and "no communication" to show that there is something to be said for the P != Q interpretation.
In short, I believe neilk should have used => instead of !=. Or just plain english. ;-)
But in dealing with language here, there are subtle differences in connotation between the two options. Just like how saying "not bad" isn't that same as saying "good".
Meetings are fine if they have an agenda, someone to enforce the agenda, no extraneous parties, are timeboxed and have a predetermined outcome should no consensus be arrived at. "We're going to shelve this unless we can come up with an acceptable solution within 30 minutes"
> There’s even a “no meeting Wednesday” meme in the company, which you might as well call a “failure to communicate” death wish. Software needs to be talked about and debated, not simply written. It’s lunacy to be writing and shipping code at a blistering pace, instead of letting things bake a bit in committees representing broad swaths of all semi-affected parties.
There are a lot of companies where failure of communication is a very real thing, and where semi-affected (or totally affected) parties are completely ignored. In my experience, ideas for code do need to be talked about and debated, not simply written. Facebook has had a lot of very public privacy/other failures that could probably have been avoided if there was more communication going on.
If you're just writing code at a blistering pace, without a lot of communication, there's a good chance you're not writing the right code.