The mighty meeting, great time suck or critical ally in staying a project’s course?
As a junior employee at my first job after college I was rarely, if ever, invited to meetings. After a few months of work this changed. First, it was the morning meeting. This meeting ensured all team members were focused on the goals for that day.
As my responsibilities changed from daily work to long term / special projects I started attending kickoff meetings and project status meetings in addition to the morning meeting. For the most part, these meetings were necessary to keep management apprised of my status. Around the same time, co-workers started realizing I could help them get their ‘pet’ projects into production, which brought on more meetings. These extra meetings, often called by one co-worker that I didn’t directly report too, usually consisted of a lot of “what-if” type comments and “wouldn’t it be neat” ideas.
After a few of these meetings, the manager I reported to called me into his/her office and informed me that I worked for him/her and not to spend my time on requests that did not come from him/her. This made sense, but it didn’t stop the extra meetings.
A manager told me at a later job, “Meetings are a tool for people to justify their existence”.
By the end of my tenure at my first job, my calendar contained many meeting requests, which I always attended, but they didn’t do much to enrich or enlighten me.
As I moved into my second job, I tried to stay off the meeting radar as much as possible. I had an amazing manager who asked his team to attend project kickoff meetings in person and take additional ones over-the-phone. Brilliant, I could tune into the meeting when needed and focus on coding the majority of the time. Sadly, this made meetings longer. Co-workers asked me questions, but I would be only halfway listening. This necessitated that the question be repeated, which slowed the meeting’s pace.
After a marathon install call of 9 hours, the over-the-phone meetings fell by the wayside. My company was trying out a new way of practicing agile development. It was called the scrum meeting. The idea was short daily meetings to keep the team on the same page. The new meeting format also came with a new practice of product management writing brief project requirements. The real beauty of the meeting, developers could ask senior product managers exactly how they wanted specific features to work.
For instance, when we were building the comments module, we asked simple questions. How should the comments be sorted? Should the newest be at the top or the bottom? Should comments be threaded? Should character limits be enabled on comments? The development staff had the ear of the product lead and our questions could be answered in seconds.
When primary development ended, and went to Quality Assurance [QA], the meeting dynamic began to change dramatically. QA had bugs we needed to fix, developers had questions about bugs and the product team needed to make sure the project was on schedule, which makes sense. The meetings were painful, but they were critical to a timely launch.
The real issue was when these scrums went on for months. It formed a long term pattern that began to wear on all parties involved.
After a few months, meetings had become so numerous and long people began proposing ideas to curb the sheer number of meetings. My favorite suggestion was the monthly meeting budget. The project management team and product team would be allowed a certain number of hours for meetings per employee. Obviously management and upper management would need larger allocations than developers and junior employees, but it’s a sound concept.
Other ideas included meeting length limits. Meetings could only be 15 minutes long. Many employees were willing to try anything in order to avoid 2 hour long meetings where they were only needed or engaged for 3 minutes.
As you probably guessed, these ideas were never implemented. Within a few months, I decided to leave corporate life in favor of a startup. Startups are nice, if you only have 3 employees in your company, meetings are very short and informal. If you work for an organization larger than 15 people, meetings are going to be a necessary evil, but how do we keep that evil in check. The following are some of my thoughts.
Untie Employee Value from Meetings.
As I wrote earlier in this piece, some employees use meetings as a way to justify their existence in the company. In quarterly reviews, total meeting time should be treated like a golf score, the lower the better. Now, this won’t always help to alleviate lengthy meetings, but it will keep employees attending as few meetings as possible. Meeting times should also be cross referenced with the number of project launches an employee has had over the previous quarter. If the number of successful launches is low and the number of meeting hours is high, something is dysfunctional.
Keep Required Attendees At Meetings Low.
Everyone and their mother does not need to be at project meetings. More people means more chit-chat. Meetings aren’t the time to catch up with friends, save that for lunch and happy hour.
Embrace Web 2.0.
Use wikis to communicate project details. Encourage developers to share their work early and often. This mentality goes hand-in-hand with the “don’t worry, be crappy” and launch early-and-often development philosophies. The web is constantly changing. New web products need to be introduced to a community of users as soon as they are ready in order to get valuable feedback. Don’t allow teams to be a black box, transparency is important both internally and externally.
Know Your Employees, Know Your Project.
Project managers and managers should keep on eye on employee activity at meetings. If employees are bringing in laptops and ‘zoning out’ then they don’t need to be present. This doesn’t mean if employees don’t have something to say they aren’t needed, but if they aren’t listening and aren’t speaking they aren’t needed.
Trust Your Team.
This should go without saying, but I have seen inexperienced managers hovering over employee progress. If employees aren’t self-starters or aren’t living up to expectations it needs to be dealt with in other ways than micro managing. A manager’s greatest asset is his/her team. Let employees spread their wings and fly, good things will come or the unproductive employee will have to be addressed.
These tips won’t work for all projects. They are just a few ideas on making meetings less important than the projects. I have limited experience as a manager, but I have had plenty of managers and I know what I like and what I hate. What are your thoughts on handling meetings?
UPDATES:
The New York Times has written two pieces on this same subject in the last several months, both are interesting reads.
