Meetings are killing your company. Do you know how to avoid?

Mark
3 min readMay 4, 2021

When I first started as the corporate ladder as Senior Engineer, I was jealous of my CTO. I mean not the title, not the business people he met, not the business visits to other states, or not office space he uses. It was his calendar. Half of his daily calendar, from 1pm to 5pm was always empty, else was packed with back-to-back meetings. There was no way to pick a time from his afternoon by no-one.

Sitting in his lonely office space, he has energy, he was always dynamic and he was able to flourish the most critical strategic decisions on the tech division of the company.

He was the tech leader of the company, and urged all the tech staff to do so.

Today, I understand him better.

As I worked with many different companies, and started to receive meeting requests, I recognized that the meetings do not bring a real value that deserves the cost we pay taking the times of people.

In fact, in tech world, meetings are the most disruptive part of the business. It eliminates deep mental work on the code, on the solution design or any higher-value activities, you name it.

For the tech orgs, if the meetings occupy more than 15% of tech team, there is a real problem.

My name is Mustafa, and I worked as a developer, technical and solution architect on Salesforce technologies for many known end user brands. Whenever I lead a Salesforce project, my first job is to simplify the meeting calendar for all of the team. Every-one in the team should know the daily routine meeting schedule such as Scrum and Project at that certain time, flexible time frame for the ad hoc client meetings. All are organized in less than 15% time of team.

Meetings should be the time frame that produces an actual output.

Rule 1: Before the meeting, Ask: “Is there any commonly written tech document on the topic?”

Today, we have many collaboration tools to share ideas and technical details of the project. People have different A-ha moment on the piece of the project they work and when they have it, they can simply write down, and all else can read immediately. Most people are better reader than listeners. They can share, comment and everyone can track & lead in their favorite time in a day. Leading in such environment is easier during the short meetings. You may write your questions and get your answers ahead of the meeting time. And you get a real output during the meeting. Tracking the people is also easier, and they appreciate you because you respect their time.

Rule 2: “Let the people skip a meeting”

You know, many times colleagues spend time without saying a word during a meeting or doing their stuff in their laptop or reading critical emails. Let them to skip that meeting. They can send one or two sentence info note why they need to skip that meeting.

I worked with many developers, who attend daily meetings but they say a single sentence “I did exactly the same thing as the previous day, delivered the that part of the project, and today I will do the same for the other part”. When your developers interact every single minute of the day and they know each-others routine work, let that person to skip that meeting. They can simply send a sentence email on why they do not join that days meeting ahead of time. So, your daily scrum or project meetings turns to meetings where people share their actual problems, blockers, and share ideas.

Rule 3: Less people in meetings.

15, 25, 30 or more people in a meeting? Lets not say it a meeting. It’s something else.

Rule 4: “What is expected? A well-prepared person.”

I had many meetings that were full of people who has no idea, or what the meeting is about? Often people start to review materials in the meeting.

Use collaboration tools beforehand and ask questions to them there? 2 or 3 days before the meetings, bring the best results. Kindly ask them to share their ideas before the meeting for everyone’s preparedness.

Follow these steps, making these changes take sometime and needs some practice according to the company culture, but that’s why you work there, get the most out of your team.

--

--

Mark

I am working on Salesforce more than ten years. I worked as Salesforce Developer, Consultant and Architect. I aim to share my experiences with you.