Thoughts on Meeting Architecture: Protecting Engineers’ Thinking Time

A no-meeting day can help. But it may be more helpful to design the full week.

I have seen organizations introduce no-meeting days to give employees more time for focused work. The idea is reasonable. Yet a meeting-free Wednesday does not solve much if meetings are scattered across Monday, Tuesday, Thursday, and Friday.

Consider an engineer with a standup at 9:00, a one-on-one at 10:30, a design review at 1:00, and a product meeting at 3:00.

The calendar still shows several open hours. But those hours are divided into short periods that may be useful for email, Slack, or a small review; not for understanding a complex problem, testing an idea, and following the work through to a meaningful stopping point.

Open time is not always usable thinking time.

That is why organizations need to think about meeting architecture, not only meeting reduction.

Meeting hygiene is not the same as meeting architecture

Meeting hygiene focuses on the quality of an individual meeting:

• Is the purpose clear?

• Does everyone need to attend?

• Could the update be written?

• Is the meeting longer than necessary?

• Did it result in a decision or clear next step?

These questions matter.

Meeting architecture looks at the full schedule:

What does the combined arrangement of meetings do to people’s ability to complete their work?

Each meeting may be justified on its own. A standup helps the team coordinate. A one-on-one supports the employee. A design review improves a technical decision. Product and engineering need to discuss priorities.

The problem is not any single meeting. The problem is how they are distributed across the week.

Three 30-minute meetings scheduled consecutively use 90 minutes. The same meetings scheduled at 9:30, 11:30, and 2:30 can make most of the day less efficient.

The total meeting time is the same. The effect on engineering work is not.

Why placement matters

Software development requires engineers to hold several connected details in mind.

They may be considering:

• How the system currently behaves

• Which services or components may be involved

• What they have already ruled out

• Which assumption they are testing

• What the logs or test results suggest

• What they should try next

It takes time to build that understanding.

Research on attention residue, led by Sophie Leroy, found that when people switch away from unfinished work, some of their attention may remain with the previous task. This can reduce the attention available for the next one.

For an engineer, the effect can happen in both directions.

They may leave an unresolved technical problem to attend a meeting while part of their attention remains on the code. After the meeting, they may need time to reconstruct what they knew, what they had already rejected, and why the next step made sense.

Microsoft research on developer productivity has also found that engineers often associate productive days with making meaningful progress without excessive interruption or context switching.

This does not mean meetings are inherently unproductive.

Software development depends on collaboration. Engineers need brainstorming, decisions, review, product context, mentoring, and access to other teams.

The practical question is not whether a meeting is useful. It is also whether the meeting is scheduled at a time that unnecessarily interrupts complex work.

Why one no-meeting day may not be enough

A no-meeting day is simple to understand and easy to communicate. It may create one useful period for focused work.

But it has limits.

A full day without meetings does not automatically produce a full day of sustained concentration. Complex engineering work is mentally demanding, and people cannot maintain the same level of focus for eight hours. They also need breaks, lower-intensity tasks, and occasional discussion. Creative work may benefit more from several substantial thinking blocks across the week than from concentrating most focused work into one day.

Meetings may also move to the other four days. Tuesday and Thursday become crowded, leaving little time to complete the work discussed during those meetings.

Different functions may choose different protected days. Engineering protects Wednesday. Product protects Friday. Cross-functional teams continue making exceptions because their schedules do not align.

Some teams need a short live standup every day. An onsite team may use it to coordinate shared work, raise operational concerns, or resolve dependencies before people begin. Production incidents and customer escalations will still occur.

A single protected day may also work better for some people than others. Some engineers do their best analytical work in the morning. Others concentrate better later in the day. Distributed teams must also work around limited time-zone overlap.

Something to think about:

Instead of protecting only one day, could the organization create several substantial and predictable work blocks across the week?

One possible weekly structure

There is no single schedule that will work for every team. The team’s responsibilities, time zones, customer commitments, and release practices all matter.

The following is only an example.

The specific days are less important than the structure.

The organization protects several substantial blocks, including both mornings and afternoons. Recurring meetings are grouped into defined periods. Employees also have time to answer email and Slack. Some meeting capacity remains available for issues that could not be planned in advance.

A team whose members do their best work later in the day could reverse the pattern and schedule more meetings in the morning.

The schedule should reflect the team’s work rather than impose the same pattern on everyone.

Keep live standups where they are useful

Asynchronous standups work well for some teams. Other teams benefit from meeting live.

A short standup near the beginning of the shared workday may still leave a substantial period for engineering work.

The larger problem occurs when the standup is followed by several unrelated meetings throughout the day.

Teams that need live standups can keep them short. Detailed problem-solving can happen afterward with only the people directly involved, or during a designated collaboration period.

The objective is not to eliminate coordination. It is to avoid turning a 15-minute standup into the first interruption in a heavily divided day.

Schedule recurring meetings in defined blocks

One-on-ones, retrospectives, planning meetings, design reviews, and cross-functional discussions serve different purposes. But most of them are predictable.

That makes them easier to group.

A manager could schedule most one-on-ones during two afternoon periods instead of placing them throughout the week. The manager would still need time to prepare, listen carefully, record commitments, and follow up. Clustering one-on-ones should not reduce their quality.

Planning, retrospectives, demonstrations, and team discussions could share one recurring block during the sprint. They do not all need to occur every week.

Design reviews could be scheduled during one or two regular periods. The organizer should clarify the problem, the decision needed, the known constraints, and who actually needs to attend.

Not everyone needs to remain for the full meeting. Some people may be needed for only one agenda item.

Cross-functional partners also need access to engineering judgment. Defined collaboration periods give them reliable opportunities to work with engineers without requiring engineers to remain available at all times.

This requires support across functions. An engineering team cannot protect Tuesday morning if product, design, and senior leadership continue scheduling over it.

Set clear expectations for email and Slack

Engineers still need to answer messages.

Protected work time should not mean that colleagues cannot get help or that normal communication is ignored.

The organization should distinguish between urgent and routine communication.

A production incident or immediate customer impact should follow the incident-management process. The on-call engineer responds first and involves other engineers only when needed.

A time-sensitive question may use a designated team channel with a clear expectation for when someone should respond.

Normal Slack messages can wait until the engineer reaches a reasonable stopping point or completes a protected work block.

Email can be reviewed at defined times based on the team’s responsibilities.

The exact response times will vary. What matters is that employees understand what requires immediate attention and what can wait.

Everyone should not behave as though they are on call.

A rotating on-call or first-responder role can protect most of the team from operational interruptions. It can also reveal larger problems. If the on-call engineer is overwhelmed every day, the organization may have a reliability, documentation, ownership, staffing, or product-quality issue.

Constant interruption should not automatically be treated as normal collaboration.

Leave some meeting time unscheduled

Another common mistake is to define collaboration periods and then fill every available minute.

When an unexpected issue arises, the only remaining option is to interrupt protected work.

Some meeting capacity should remain open for:

• An urgent technical discussion

• A customer question

• An interview

• A delayed decision

• A sensitive one-on-one

• Follow-up from an earlier meeting

• Email and Slack

This may appear inefficient when viewed only as calendar utilization.

In practice, it gives the team enough flexibility to handle normal variation without disrupting the rest of the week.

When no urgent issue arises, employees can use the time for other work.

Allow time after demanding meetings

A meeting that ends at 2:00 does not mean someone is ready to resume complex work at 2:01.

They may need to record a decision, send a follow-up, update a work item, or regain their understanding of the task they were doing before the meeting.

A difficult performance conversation, incident review, or tense stakeholder discussion may require additional time before the next demanding task.

This is another reason to group meetings. Employees can complete several meetings, handle the required follow-up, and then begin a substantial work period without switching repeatedly between meetings and individual work.

A short transition can help people regain concentration before starting the next task.

Review the full calendar

Most recurring meetings are created one at a time.

Each invitation may be reasonable, while the full schedule still leaves too little uninterrupted time.

Teams could review their meeting schedules periodically, perhaps once a quarter or whenever responsibilities change.

A few questions may be enough:

• Are substantial morning and afternoon work blocks available?

• Which recurring meetings divide the day most severely?

• Are some employees interrupted much more often than others?

• Are expectations for normal and urgent communication clear?

• Is some time available for unexpected work?

• Do employees have enough time to act on meeting decisions?

The purpose is not to measure every minute or require identical schedules.

It is to determine whether the current calendar supports the work the organization expects people to complete.

Test before standardizing

Meeting architecture should not become another rigid policy.

A team can test a proposed schedule for four to six weeks and then review what changed.

Did engineers have more usable work time? Were collaboration periods overcrowded? Were protected blocks repeatedly overridden? Did the on-call process handle urgent issues effectively? Did the schedule work across time zones?

A support-heavy team may need more operational coverage. A research team may need longer work periods. A distributed team may need two shorter collaboration periods instead of one long block.

The final structure should reflect evidence from the team’s actual work.

Something to think about

A no-meeting day can be useful. But thoughtful meeting architecture may protect thinking time across the full week.

Required live standups can continue. Organizations can schedule one-on-ones, retrospectives, team meetings, design reviews, and cross-functional discussions within a few defined meeting blocks. Teams can set clear expectations for when engineers should check and answer email and Slack messages. The on-call engineer can handle urgent issues first and involve others only when needed. The schedule should also preserve long morning and afternoon blocks for focused work.

The schedule will not look the same for every team.

That is not the goal.

The goal is to recognize that open time and usable thinking time are not always the same.

Before scheduling the next reasonable meeting, organizations should ask not only where it fits, but also what work it may interrupt.

Sources

Leroy, S. (2009). “Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching Between Work Tasks.” Organizational Behavior and Human Decision Processes, 109(2), 168–181. DOI: 10.1016/j.obhdp.2009.04.002.
Explains how attention can remain with unfinished work after a person switches tasks.

Meyer, A. N., Fritz, T., Murphy, G. C., & Zimmermann, T. (2014). “Software Developers’ Perceptions of Productivity.” Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering.
A study of professional developers that found they often associated productive days with completing meaningful tasks without significant interruptions or context switching.

Meyer, A. N., Barr, E. T., Bird, C., & Zimmermann, T. (2019). “Today Was a Good Day: The Daily Life of Software Developers.” IEEE Transactions on Software Engineering.
Based on 5,971 developer responses, this study examined what makes a workday feel productive and how the value of meetings depends on the development activity being performed.

Allen, J. A., Thiese, M. S., Eden, E., & Knowles, S. E. (2022). “Why Am I So Exhausted? Exploring Meeting-to-Work Transition Time and Recovery From Virtual Meeting Fatigue.” Journal of Occupational and Environmental Medicine, 64(12), 1053–1058. DOI: 10.1097/JOM.0000000000002641.
Examines the need for recovery and transition time after meetings, especially meetings that are ineffective or not relevant to the employee’s work.

Recommended Reading

Albulescu, P., Macsinga, I., Rusu, A., Sulea, C., Bodnaru, A., & Tulbure, B. T. (2022). “‘Give Me a Break!’ A Systematic Review and Meta-Analysis on the Efficacy of Micro-Breaks for Increasing Well-Being and Performance.” PLOS ONE, 17(8), e0272460. DOI: 10.1371/journal.pone.0272460.
Useful for understanding why a full meeting-free day should not be treated as eight continuous hours of high-intensity concentration. Short breaks reduced fatigue and increased vigor, although the overall effect on performance was less conclusive.

Sio, U. N., & Ormerod, T. C. (2009). “Does Incubation Enhance Problem Solving? A Meta-Analytic Review.” Psychological Bulletin, 135(1), 94–120. DOI: 10.1037/a0014212.
Reviews evidence that temporarily setting aside a problem can improve later problem-solving, particularly for divergent-thinking tasks.

Kumar, S., Goel, D., Zimmermann, T., Houck, B., Ashok, B., & Bansal, C. (2025). “Time Warp: The Gap Between Developers’ Ideal vs. Actual Workweeks in an AI-Driven Era.” Proceedings of the IEEE/ACM International Conference on Software Engineering—Software Engineering in Practice.
Examines differences between developers’ actual and preferred allocation of work time and the relationship of that gap with productivity and satisfaction.