Engineers Spend 10 Hours Per Week in Meetings? I Wish!

Photo by Malvestida on Unsplash

Time is important as a software developer. Giving us time means we have the ability to perform in our job.

In my exploration of the Internet, I found a fun site explaining where the time is spent for software developers. I want to align this to my experience and explain where things might be going wrong in the tech industry.

Focus Time is Important

Intuitively I’d say that software engineers invariably hate meetings as it eats into their time to produce solutions and focus.

And it does turn out that focus time is important, and research shows interruptions incur costs of higher stress, frustration, workload, effort, and pressure.

Engineering teams also place high value on focus time in terms of time and productivity.

I’m in agreement with this. I need to refactor a whole section of work and need a day or two of focused concentration. Unfortunately, I have two standup meetings (30 minutes apart) and duplicate Agile ceremonies — I have no idea when I will be able to focus and deliver my work as promised.

Focus Time is Insufficient

From the same research software engineers spend nearly 20 hours in focus time.

I have to say I have no idea where that average is from unless (as I suspect) the company I work for packing my time with unnecessary meetings.

Put it this way. Today in an eight-hour workday I have 5 hours+ of meetings. Tomorrow I have a light meeting day of 4 hours, and Thursday another 5 hours. On meeting free-Friday, I have 2 hours of meetings. TBH it’s tricky to get any work done at all.

Is the Size of the Company at Fault?

Perhaps. There is some evidence that the size of the company affects how much time developers get to work on code? 

It appears this is true.

Actions We should take

I need to work through most of my pointless meetings, but that means I’m part of the problem of disengagement and quite frankly not performing to my potential at work.

I think it is important for all software developers to be engaged, and I guess I’m lucky that our cameras are switched off during meetings at work. The last thing I would like is to need to act engaged during meetings at work.

So I should be in a company and a position where naturally I feel engaged in what is going on and want to do my best for the company.

Action — Software Developers should be engaged in meetings

This alone is not enough. Those facilitating meetings should notice whether participants are engaged (including body language, keeping camera off and contributions).

On review (and collecting data as necessary) they should analyze:

  • Was the meeting necessary

  • Were the participants required

  • Is there an issue with an individual disengaged employee (probably needs communication)

Of course, many organizations have unnecessary meetings. The point is to review what happens and look to see where we can improve.

Much of the time I notice that people who are required meetings become disengaged (at all levels) and this isn’t acted upon and seeps into the culture.

Action—analyse the effectiveness of meetings and improve what we actually do.

Conclusion

I think the solution to many problems at work is looking at evidence, and data and then improving things and seeing if it works. If it does, keep doing it. If it doesn’t look again try something else.

We don’t have time for that in my company as we have too many meetings.

Previous
Previous

Inside Programmer’s Mind

Next
Next

The Red Flags I Ignored Before Starting a New Tech Job