Skip to main content

Are you running a SOLID Meeting?

Teams can spend a lot of time in meetings. Most meetings are held with good intentions and can lead to the desired outcome. However, I think most people would agree that they spend more time in meetings than they would like. I believe that the main reason for this is that too often a meeting is scheduled without having a clear plan or goal for the meeting.

The thinking seems to be that there is a problem that needs to be addressed so if we gather everyone together we can figure it out. Teams work to plan and organize their work before actually starting the work, so why would we think that putting together a meeting without preparing for it would lead to positive outcomes?

I think that a little work before a meeting is scheduled could go a long way to make meetings more engaging and leave the attendees feeling like it was worth their time.

Introducing the SOLID meeting

Developers use a mnemonic, SOLID, for describing how to structure good code.

Using these same letters with different meanings I think we can use SOLID as a template to plan a good meeting.

Single Focus
On-Time
List your Agenda
Involve Everyone
Decide or Deadline


S for Single focus. Often meetings take on more than 1 focus because the team is together so might as well cover as much as possible. The problem is this doesn't allow for a clear end to one discussion and conversations can find their way off track returning to earlier topics. My suggestion is that if you need to cover more than 1 topic, make it more than 1 meeting. Complete your first meeting on the first topic and then take a break. Allow people to reset, 5 or 10 minutes, and then start on the next topic treating it as its own complete meeting.

O for On-Time. Start and stop your meetings at the time they are scheduled for. Let everyone know that your intention is to start on time and hold to your plan. To be able to end on time, you will likely need to plan for some buffer time. If you expect your meeting to take a full 60 minutes, you are likely not going to be able to cover everything in a 60-minute meeting. Instead, plan for 45 minutes and either tighten your schedule or cut out steps. If you find your team unable to start on time waiting on another group to leave a conference room, book the room earlier than you plan to start the meeting to give them time to clear out.

L for List your Agenda. How can you keep to a schedule without first creating an agenda and estimating how much time each part will take? Creating an Agenda helps in multiple areas. First, you should share the agenda at the start of your meeting. Everyone now knows what to expect and will probably even help you stay on target. Attendees will be less likely to try to jump ahead and if they do you can remind them when they will get their chance to talk about that.

Just getting everyone in the same room and discussing something for an hour is not good enough, you need to have at least a rough timeline. The more meetings you facilitate with your team, the easier it will be to know how much time to give each step. You can also use the agenda to help steer conversations back on topic and guarantee you accomplish your meeting's goal. Ask yourself if someone else could successfully run the meeting if you were to give them your agenda.

I for Involve Everyone. Having one or two people dominate a meeting is a great way to have people check out and not care about your meeting. Start by being mindful of who is invited to a meeting, does everyone really need to be there? If someone isn't going to be participating why would they need to be a part of the meeting?

Next, make sure you give time and opportunity for everyone to be heard. One of the best ways to accomplish this is to have everyone write down their thoughts and ideas by themselves or in small groups before sharing with the larger group. This approach ensures everyone gets to be involved and will help them stay engaged throughout the meeting.

D for Decide or Deadline. Leaving a meeting without any sense of accomplishment will make your attendees feel like it was a waste of time. Your meeting should end by either coming to a decision or making a plan for what needs to happen next. Before ending the meeting reiterate what the outcome of the meeting was to give a summarised memory of the meeting.

When trying to reach a decision, you should try to involve everyone. Have everyone vote on the options in secret and then share their vote. This prevents people from being influenced by others and allows everyone the opportunity to share. If everyone comes to a consensus, congratulations you are done and can move on.

If you have a majority in favor of one option, you should probably choose that option and try it out. Spending time trying to get to a consensus can wear people down. Plan to move forward with the majority option and share back how well it goes. Worst case, you are learning about the chosen option and that informs future decisions. Best case, you have a working solution without spending any additional time in meetings.

The last option to end a meeting will be to create a deadline for the next steps. This means you should plan a future meeting on your topic while you are still in the current meeting. This gives your attendees time to research, think about, or experiment with options and a deadline to do it within. It could also lead to majority decision being made once people realize they are going to have another meeting on this topic.


Try using these ideas when planning your next meeting and see what kind of feedback you get from your team.

Comments

Popular posts from this blog

Gamify TDD

I like it when things that would not normally be associated with games add concepts from games as a way to incentives you to accomplish things. Why simply go for a run if you can have an app that will track you and give you a gold star if you do better than you did the last time? Why go to the coffee shop that only gives you coffee if the other one will give you points that you can redeem for free drinks eventually?

I was recently introduced to CodeSchool, an online training system similar to PluralSight, it has video courses and challenges you can take to prove that you retained what the video taught. CodeSchool also adds badges and tracks to your learning, so as you complete a video and its challenges you get a badge. Complete a collection of courses within a specific discipline and you become a master of that discipline.

Some of these incentives are not tangible and really don't mean much in the real world, but they tend to work for me. If I start working towards a large goal a…

Converting a Large AngularJS Application to TypeScript Part 2

In part 1 I was able to take an Angular controller written in JavaScript and convert it to a TypeScript file while doing very little to change the code. In this post I am going to explore transitioning that same controller to actually use the features provided in TypeScript. This is how I left off my controller:
declare var angular: any; (function () { 'use strict'; var controller: any = function($scope){ ... } angular .module('app') .controller('controller', controller); controller.$inject = ["$scope"]; })();
While performing the translation from JavaScript to TypeScript, I would make sure at every step that the functionality I expected still worked, so if anything I did broke the system I would change it back and try again with another approach. Also if something seemed like it worked too easily, I would break it on purpose to make sure I wasn't getting a false result through browser caching a previously working fil…

Converting a Large AngularJS Application to TypeScript Part 1

I work on a project that uses AngularJS heavily. Recently we wondered if using a preprocesser like CoffeeScript or TypeScript for our JavaScript would be beneficial. If our team is going to switch languages, we would need to be able to convert existing code over without much pain and we would have to find enough value in switching that it would be worth the conversion.

I had read an article that stated that because TypeScript is a SuperSet of JavaScript, you could convert a plain JavaScript file to TypeScript by changing the extension to .ts and not much else would need to change. I wanted to test out this claim, so I took a file that I was familiar with, an Angular Controller, and tried to convert it to TypeScript to see how much effort it would take and then try to figure out where we would benefit from using TypeScript.

This is what the controller JavaScript file looked like to start out with:
(function () { 'use strict'; angular .module('app') …