startups and code

Meeting Rules - Why are we working so hard?

← Back to home

The more I think about the companies I have worked at and the primary problems that I have encountered are not the coding challenges, are not the project features, but the process of delivering anything. I have attended meetings to plan for the next meeting that will prep us to talk to client during the next meeting to make sure we know what we are going to say at that meeting. I have had kickoff meetings that introduced everyone and led to nothing other than some good social time. I know I'm a developer and the social aspect of work is important and not always easy for some developers. There is always a biased, not everyone communicates the same. So let's talk about talking.

Communicate differently

I listen. I talk. I try to listen more than I talk. There are some styles of communication that I have encountered in meetings.

Here are a few styles:

  • The Listener - The person who listens, takes notes, rarely says anything in a meeting and then processes the information and sends an email after the meeting about what they wanted to say but couldn't process everything real-time and wanted to be sure to cover their points in an organized controlled manner and have it documented.
  • The Summarizer - They usually chime in after someone (the dominator) finishes and clarifies for everyone else, but really allows themselves to process the information and then respond after everyone is on the same page
  • The Devil's Advocate - This is the person that is the Eeyore of the group. They will produce every possible negative outcome and feel like they are being thorough and helpful. They are not. They are destroying the team morale and usually no one wants to work with them, because they rarely (I said rarely, not never) provide solutions, just problems with the direction.
  • The Dominator - This is usually the leader (or so they think) of the meeting. They want to make sure they are heard and will talk more and more if there is a lull in the metting. If this is you, stop... listen after 1 minute. Truly, stop talking and just listen for a minute.
  • The Story Teller - This person is my nemesis. They have stories, experience, and wisdom they need to share. I need to listen to them because they have valuable information, but they talk about back-stories and previous experiences and tend to chase tangents. They often battle with a dominator on controlling the stage, I mean meeting. You get the point

This is not a definitive list, but a few that I have encountered. You are probably laughing right now because you know who fits in one of the categories. You need to figure out what category YOU fit in. That is how you can communicate differently. You can figure out where you fit and try a different approach for one meeting, just to see.

One of the biggest things to help improve meetings is simply this:

Have an Agenda and Goal

If you are having a meeting to have a discussion, ask yourself why? Why don't you have a simple goal for the meeting? Why did you invite 10 people to have an open discussion about the project? Why are these 10 people in the meeting? Do each of them have an action item when they leave, or do you just invite people to increase your audience and you are the dominator of the meeting?

Meeting Rules Are Simple

  • Have a goal for the meeting
  • Have at least an action item for 50% of the people in attendence
  • If you don't have action items for 50% of the people, invite less people
  • Think of the best forum, could it be a 30 second slack message, a 3 minute email, or a 15 minute meeting
  • Never have an hour meeting, at most have 50 minutes. This gives transition time, bathroom breaks between meetings, and is just polite to the next meeting
  • No meetings scheduled at 5pm or before 9am (I love early morning meetings, but I'm not most people)

I am working on organizing my thoughts on meetings in a real downloadable pdf. I know I could talk about code practices, but it turns out that coding is easy and it changes a lot. Business process is always the hardest part of a project. I'm open to any suggestions/feedback.

Thanks for stopping by and feel free to ask questions.