Rule 4.1 of the developer constitution
It’s the law. Software engineers have to hate meetings. If you’re caught enjoying yourself in a meeting you can get your dev card pulled. So be careful out there. And stay classy, San Diego.
We’re bad at articulating the negative effects of meetings
I knew right away as a junior developer out of college I was in too many meetings. Even though I had nothing to compare it to. As I took on more visible projects, the number of meetings went up. I felt the pain.
Three years into my career, I got promoted from dev to team lead and bam… not only was I in more meetings than ever but my team was also constantly complaining to me they were in too many meetings.
I remember being in product strategy meetings for hours. HOURS.
Join our mission to end useless status meetings.
Click here for free access to the dev team dashboard of the future.
Real-time progress on your features and bugs powered by Git data.
After I got comfortable with our product leaders and executive team, I would spin my chair around in circles as a (passive aggressive) way of letting them know I was ready to go.
Looking back on it, I wasn’t addressing the bigger issue. Another long meeting was right around the corner. And I wasn’t doing anything to help other developers in our org avoid meetings that were too long or had no value.
In general, I was good at translating between engineers and executives. But for some reason, when it came to meetings, I failed to find the words.
“Too many meetings” is not a complaint, it’s a cry for help
I’ve been asking developers why they don’t like meetings and what specifically they don’t like about them. The more I parse what I’m hearing and compare it to my own experience, the more I think “too many meetings” is a symptom of a bigger issue.
Most developers don’t arbitrarily dislike all meetings. When we say we don’t like meetings what we really mean is:
- “I dislike inefficiency”
- “I dislike poorly planned meetings”
- “I dislike poorly executed meetings”
- “I dislike not living up to my promises”
- “I dislike missing our team iteration deadline”
- “I dislike not getting enough time to do my job”
Developers are the most important asset innovative companies have. Instead of dismissing this feedback as “engineers just don’t like meetings”, we need to listen to them.
Maker’s Schedule versus Manager’s Schedule
When it comes to meetings, there is an inherent tension between developers and bosses. Paul Graham (pictured above), known for his work on LISP and for co-founding Y Combinator, explains the disconnect in his 2009 essay Maker’s Schedule, Manager’s Schedule.
Here’s a summary:
- Bosses (Managers) get stuff done through meetings – changing tasks every 60 minutes.
- Developers (Makers) and other creators need 3-4 hour blocks of time to get work done.
- Each way of working is perfectly fine by itself but problems arise when the two collide.
- For a Maker, a single meeting at the wrong time can disrupt their entire day of work.
- Powerful people on a Manager Schedule force Makers to “resonate at their frequency.”
We’ve all been there. Your VP needs an update on feature XYZ. They “have a call with customer ABC tomorrow” or they’re “presenting to the exec team this afternoon” so they summon you and the team. You share your status update. Or, worse, someone else talks and you just sit there. (Why did I need to be here??) Your boss asks a few questions. You leave.
And it’s not just your VP. Your team lead, your product owner, your project manager, your UX designer… they all want your time.
And it’s just not just meetings. The support person, the salesperson… they all have a “quick question” and it’s always “kind of urgent”. At least now they can’t walk by your desk when you don’t answer on Slack after 57 seconds. But you want to be helpful so it’s still a distraction.
Your boss goes on to their next meeting. The sales rep goes to their next call. For you, it’s not that easy.
You have to start your process all over. “Getting in the zone” takes time. And if you have another meeting in an hour you might not want to start something big or important. So you get up to date in Slack. Maybe pick up a friend’s PR and add some comments. Next thing you know the day is over and you didn’t get enough quality time into your big, important task.
Two failed attempts
When I was Director of Engineering (and later VP), I considered myself a “cool” leader. Not one of those out of touch suits. Not some MBA that talked about innovation but didn’t actually know how to code. (Python dice rolling simulator doesn’t count, Conner!) I was an executive but I still understood what it was like to be a developer. After all, I had just been a developer. I got promoted from dev to team lead to Director in a two-year span. I was not out of touch.
Yet I was the cause of many meetings and interruptions. What was my alternative? I needed updates so I could communicate with our VP of Product and our CEO. Jira was never up to date. Slack worked sometimes but not always in the timeframe I needed.
PRO TIP FOR MANAGERS: Beware of how you feel when you leave a meeting with your team. The meeting was for you and you got work done so you’re probably feeling great. Your team probably did not get work done and might not be feeling as great. Don’t allow your feelings to cause your mind to overvalue the meeting.
Eventually, I heard enough complaints and tried to do something about it.
Failed idea #1: No meeting Wednesday
We looked for a day each week where devs could work uninterrupted. After much negotiation, we picked Wednesday. We would meet up for the daily then no more meetings all day. None. No exceptions. I convinced the CEO and the whole company. Everyone agreed! It lasted about three weeks. By week four the “urgent priority” meeting requests started rolling in again. And by week five my own team had lost their resolve and we were right back to meetings on Wednesday.
Failed idea #2: Brazilian BBQ meat coaster
At Brazilian BBQ restaurants “Gauchos” bring skewers of meat to your table. If you want some, they cut a few pieces on to your plate. If you don’t want any of that particular meat, no worries. A few minutes later another pair of chaps will be by with a new kind of meat. (It’s amazing.)
How does the gaucho know if you want more meat? Your table has a little cube or coaster on it. Green side up means more meat! Red side up means I have the meat sweats and I’m taking a break. See where I’m going with this?
I gave everyone on our team a little coaster. Green side up meant I’m available to chat. Red side up meant please don’t interrupt. I sent an email to the whole company.
It lasted a brief time. But eventually, the shoulder tap interruptions resumed.
Why did these attempts fail? I didn’t explain the problem well enough. The “rules” we implemented seemed arbitrary to everyone else. We had a great relationship with our ecosystem so they bought in initially because they wanted to be helpful. But, in order for change to take hold, people need to understand the “why”. And the “why” in this case has to be more than just devs don’t like meetings and interruptions.
5 steps for reducing meetings and increasing focus time blocks
Dev team leads, scrum masters, product leaders, and business leaders can use these ideas to maximize the most valuable “resource” in your company – your developers.
Developers can use it too. If you’re like me – complaining about meetings but not explaining your “why” very well – this framework will help you articulate yourself better.
Step 1: Take a meeting inventory and establish a baseline
Are we really in too many meetings? As we start educating our company about “why” meetings and interruptions are bad for developers, let’s also make sure our premise is correct.
To start, let’s look at the recurring meetings we’re in:
Most reasonable developers are not proposing to get rid of these so this becomes your baseline.
Add up the total number of hours and divide by the total number of hours in your typical iteration. At LinearB, these baseline meetings take up 10% of our typical two-week iteration. Not bad, right?
Now look at your random meetings: update with your product owner for feature XYZ, check-in with the support department, technical design, UX design, emergency production issue, etc. These take up a lot more time if we aren’t careful. So, examine their value closely.
Step 2: Assess the value of your meetings
Are all of our recurring and random meetings providing value to attendees? It depends on who you ask. They’re definitely valuable for the person scheduling them like the Director, team lead or product owner. But are they valuable for developers?
The daily stand-up is our most important, most frequent meeting. And yet many developers don’t think they get value from it.
LinearB is reinventing the daily stand-up.
Free for dev teams.
At LinearB, we refactored our meetings and created two core tenets:
- Everyone in the room must get value – especially developers.
- No status update meetings are allowed.
For engineering leaders, if you listen to your team, you’ll quickly learn which meetings are not delivering value. But just canceling those meetings may be complicated. Other stakeholders may find them valuable. So, instead of canceling, ask yourself “how can I refactor this meeting to make it more useful to my team?”
Here’s an example:
Daily stand-up: Use a Slack message or data-driven dashboard to review yesterday’s progress and today’s WIP before the meeting. Then, when everyone is together, you can focus on unblocking teammates and discussing top priorities for delivering your iteration (instead of boring status updates). Your team will want to attend this meeting instead of just waiting for it to end. We call this Stand-Up 2.0.
If you’re left with any meetings that are truly just a status update and you can’t find a way to make them useful for your team, consider canceling them. But before you do…
Step 3: Position the true value of your meetings correctly
Getting back to “why”… From listening to devs talk about meetings, I definitely learned there is a disconnect when it comes to the true purpose of some meetings.
If we roll our eyes at the thought of the company all-hands, we’re missing the fact that aligning engineering work to company objectives is critical. There’s a strategic business decision behind every line of code. But we can’t think strategically without having all of the information. The all-hands can directly help us be better at our jobs.
Those “check-in” meetings with tech support aren’t just about sharing status updates. Even if it looks that way on the surface. They’re about building relationships. When something goes wrong in production, your relationship with the support team will help you communicate better and work faster to resolve it.
The support team can also help us understand where customer issues are coming from. This knowledge can help us proactively fix issues that will reduce support tickets and escalations and give us focus time back.
And these relationships could help you get promoted (if that’s your thing).
Not every engineer thinks this way out of the box. As leaders, it’s our job to translate the true purpose of meetings. Helping them see the big picture will shine a completely different light on the value of some meetings.
Step 4: Cluster meetings to maximize deep focus blocks
I love this passage from Paul Graham’s essay:
“I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition, there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.”
I feel the same way and I’m not being oversensitive!
We know we can’t cancel every meeting. But we can organize them to maximize the number of 3-4 hour deep focus time blocks we have in our work week. I call this clustering.
This is my real calendar:
Notice how the meetings are organized. They’re all clustered together at the beginning and end of the day. This ensures every day has at least one 3-4 hour block. If not two.
Once the week starts, my calendar gets much more full. But I only schedule random last-minute meetings within the clusters. Every Sunday I look at the week and block off the deep focus time blocks to make sure they show up busy. And it totally works. Think about it… instead of saying “I don’t do meetings on Wednesdays” I just say “I’m free at the following times…” You’re not saying no. You’re saying yes. Everyone has busy spots on their calendar so my co-workers rarely think twice about it.
Clustering has changed my life. I’m in roughly the same number of meetings as before but now I also have time to write code, write blogs, and work on strategic projects.
Our devs love it too. After implementing clustering (right after work from home started in March) our coding time and overall cycle time went down. More focus time equals more deep work which equals work flowing through the pipeline faster.
Step 5: Trade project transparency for fewer interruptions
There is one final complaint I always hear from devs… “So let me get this straight. I show up to the meeting. I give my status update. I listen to all of the other status updates. Then I still get pinged 9 more times that day for status updates?? What was the point?”
This is the last mile. If we don’t solve this one, regardless of how many meetings we cancel or how well clustering works, our devs won’t have the focus time they need.
And yet projects change throughout the day. Our stakeholders have legitimate reasons for needing updates.
I started a Reddit thread to get feedback for this article and a dev team lead named Netrok wrote:
“Typically, if there’s a meeting, it’s because a communication medium has broken down or doesn’t yet exist. I consistently tell my team that our status calls could be all but non-existent if they updated their tickets…”
I think this applies to ad-hoc updates too. The problem is, Jira is almost never updated.
Our business stakeholders want more features faster. And they are willing to trade a lot of things to get that. But loss of visibility is not one of them.
So now we have a hard question to ask ourselves and our teams:
Which hurts more… updating Jira or going to extra meetings and being interrupted all the time?
As engineering leaders, this is where we need to have a tough conversation with our people and ask them to “help me help you.” Let them know that we’re willing to protect them from useless meetings and disruptive interruptions if they’re willing to step up the visibility. It’s only fair for everyone to have some skin in the game.
Maybe there’s another way
Our team at LinearB is obsessed with using automation to solve this problem. Everything you need to know about what devs are working on is in Git. The problem is, Git doesn’t talk to Jira. At least not well enough for stakeholders to easily see what’s happening with specific features and bugs.
So we’re building the dev team dashboard of the future.
Imagine a world where you can see all of your branches and PRs together in the context of the Jira story they’re a part of. Just the most relevant facts. Everything updated in real-time. No more status meetings. No more interruptions.
That’s our mission and we need your help.
Join our revolution! Click to get free access to LinearB
and let’s end annoying meetings without spending all day in Jira.
