1–10 of 38 posts
Can anyone recommend a good read on how to conduct a meeting, or (if I could be so lucky) give me some advice on the subject?
As an aside, we are a small group, only 4 people.
Just cover what needs to be covered and allow people to get to their work. Fast paced.
And have people stand if possible, not sit. And no laptops or cell phones in the room. They'll pay attention in both instances.
Also, make it clear what the meeting covers and stick to it, this lets people who aren't stakeholders in the current topic leave and get back to work.
Long answer: work in the same room together for a few hours a week (10-20). This way as questions come up they will get resolved in context. Announcements, presentations and other broadcast-type things can be made at coffee break. Start having meetings after this model stops scaling.
Short answer: don't have meetings. Long answer: work in the same room together for a few hours a week (10-20). This way as questions come up they will get resolved in context. Announcements, presentations and other broadcast-type things can be made at coffee break. Start having meetings after this model stops scaling.
We are having weekly meetings to get everyone back on the same page as the work is largely independent at this point.
Meetings have a secretary who writes down decisions. The referendum is available as quickly as possible. The same day or the next. Meetings have a speaker who conducts the order in which people are speaking. For each agenda-point, you have 2 rounds of discussion. After that, you must cast a vote on the point or make a decision.
Ok, that was the extreme version. But it is either that or "till the coffee cup is empty" meetings. The advantage of having some rules is that you will actually get something done in the meetings. If you can't get something decided, voted in or otherwise actionated, don't hold the meeting.
Remember: If there is 8 people in a meeting, each minute in the meeting takes 8 minutes of work. Also, there are 8*7/2 relations between these people. This leads to the conclusion that you must keep the number of people down in a meeting.
Finally: Get consistency in when meetings are held. In my former code-job I hated getting in to work in order to do some great coding, just to be shown off into a meeting. All productivity that day was totally gone afterwards. Do that 3 days a week and you have cut your productivity of your developer to 2/5. Do it for all of the 6 person staff and you lost about 2.5 persons in productivity a week.
Do I sound bitter? I probably am :)
Short answer: don't have meetings. Long answer: work in the same room together for a few hours a week (10-20). This way as questions come up they will get resolved in context. Announcements, presentations and other broadcast-type things can be made at coffee break. Start having meetings after this model stops scaling.
I also disagree with your long answer. It's not necessarily productive to work in the same room. That's why God invented cubicles! In all seriousness, though, a lot of people -- myself included -- work best in isolation. The bottom line is that you should get the people together in your group and figure out what will work best. Some people prefer working in the same room, some people get distracted because of that, etc. Find our what works best for you and stick to that.
Try sending out an email detailing the meeting's goals, agenda, and any preparation you expect from the participants. This is sometimes called GAP and I had a coworker who was a bit of a task master who'd come from a company with the policy that you didn't have to go to any meeting that didn't provide this. I like the sentiment, at least, that meetings require preparation.
So for a weekly meeting you might send: Goal: To assign work responsibilities for the week Agenda: * Keeping our promise to deliver X to customer Y * Assigning bug #123 * etc. Preparation: Could everyone come prepared with the state of their work?
In my experience, the preparation part is the part most likely to fail. Either the meeting planner isn't the type of personality to enforce it or the meetings aren't important enough for the participants to actually do the prep. In either case, you can drop it as just having a clear goal and agenda will make any meeting better.
Also, forcing yourself to be clear about the goals and the agenda will help you see ways that you could eliminate parts of your meetings.
Another idea (for engineers) is setup an IRC server and have everybody run a screened (as in the screen utility) client on a stable UNIX machine in a common channel. Screen on a stable UNIX machine provides persistence, IRC provides real time ability. 37signals campfire provides the same functionality (real time, but also persistent chat) for less technical people.