In the demanding realm of software development, maximizing focus and collaboration time for software engineers has become a defining factor in achieving success. This article aims to guide you through an efficient and effective approach, enabling creative individual contributors like software engineers and product designers to reach an impressive 92% focus and collaboration time.

If you’ve ever wondered how to attain this level of productivity, keep reading to learn how meetings can be minimized, schedules optimized, and collaboration maximized.

Preamble

Let’s first define the terms necessary for this article.

• Focus Time — Uninterrupted time dedicated to individual work and deep concentration on specific tasks. For example, when you write code to solve a customer’s problem.
• Collaboration Time — Periods for working together with team members on shared goals and projects. For example, when you pair-program with another software engineer to solve a complex problem together.
• Meeting Time —Time allocated for formal or informal gatherings to discuss, plan, review, or make decisions. For example, when you meet with the team to plan the next week’s work.

What Times Are The Most Productive?

Focus time and collaboration time is when the actual valuable work is done when it comes to creative ICs. This is also when the creative individual contributors (such as software engineers and product designers) are most productive, most valuable, and also, quite often, most happy.

Likely, you have noticed, that in your work you hate meetings, especially when they interrupt your focus or collaboration time.

But We Need Meetings!

Yes, of course we do.

Meetings are crucial for discussions, planning, review, alignment, and decision-making. Without these important touchpoints, it won’t be possible to deliver valuable outcomes for the business and your customers. No matter how productive you are. Does it mean that we should keep all the meetings that we hate, and tolerate them?

No.

Effective Meetings ⇒ Fewer Meetings

First, you should regularly perform a calendar audit, and determine which meetings are not necessary for productive work to reach valuable outcomes. If you find any, then cut them.

Second, you should run the meetings more effectively as a team. Once you do, you’ll find out that they can be shorter, and you need less of them. Here are the primary ideas:

• Effective meetings always start on time. If someone is not on time (more than 2 minutes late), then the meeting starts without them, or gets canceled if that person is required. Hard accountability here.
• Effective meetings consistently possess a predetermined agenda (for all discussions or decisions), or they possess a clearly defined and documented procedure (for workshops)
• A good meeting is run by a facilitator who keeps everyone on track and uses timeboxing when necessary.
• An effective meeting involves only the Minimum Viable Audience — the group that consists of the most necessary people for its goal, and nobody else.

Once you’re there, you’ll have much fewer meetings in your calendar, and they can be shortened.

The final piece is the team’s schedule.

Optimal Schedule For The Team

At this point, you have fewer meetings in your calendar, however, some of them might still interrupt your focus or collaboration time. What if we could optimize the whole software engineering team’s schedule to minimize the likelihood of this happening?

The following schedule is inherited from Extreme Programming (XP) and further optimized for collaboration and focus time:

Every team member starts their day at the same time

The team should have the same start time in the morning. For example, at 9:30 am. Note that this is a trade-off between individual’s flexibility and the team’s increased performance, and some individuals will not be happy with this.

This is important to maximize potentially available collaboration time for pairing, ensemble and other types of co-creation work.

Short daily planning meeting at the day start

The first meeting of the day starts exactly at the start time, and this is a Daily Planning Meeting (aka Stand-up). For a balanced team of appropriate size (5-7 people), this meeting should last 10–15 minutes. 

Members of the team should provide their essential updates, plan, as a team, what should happen today, and who will collaborate with whom and on what. If someone is struggling with anything, then they should ask for help, and another person should quickly step up to join them as a pair to figure the challenge out. Any discussions beyond clarification should go into collaboration time. 

This meeting must be effective: there should be a procedure, and a facilitator. The facilitator can, of course, be a rotational role.

Quick FAQ:

1. Isn’t a daily meeting useless and can be simply replaced by a Kanban board? 
   
   Yes and no.
   
   If you run this meeting improperly, focusing on status updates of the work items in progress, then you might as well just replace it with a Kanban board and ensure that it’s up-to-date. However, daily planning is not at all like scrum stand-up.
   
   The primary purpose of daily planning is to plan the day, which involves deciding who will pair with whom today and what are the most important things to do or deliver today. And it does have a Kanban board where everyone sees the status of items. 
   
2. Why should individuals wait to resolve a blocker until the next day if they can raise it early and resolve it immediately? 
   
   They should not!
   
   Usually, people resolve their impediments on their own, via collaboration, or by talking to people when these blockers arise. However, there is also a benefit to trying to fight with the challenging problem for a couple more hours and not calling for help immediately (that’s how people learn, after all).
   
   So, struggling with the blocker until the next morning can actually be beneficial in some cases.

Iteration Planning Meeting on Monday right after Daily Planning

On Monday, at the beginning of the 1-week iteration, right after the daily planning, there is an Iteration Planning Meeting. This is a 55-minute meeting, the goal of which is to review prepared work items, align on the understanding of the problem, value behind it, and definition of done. And estimate them and plan them to be worked on in the current iteration.

Needless to say that this team must be effective as well.

Quick FAQ:

1. How do we make sure that the work items are prepared enough for this meeting? 
   
   There is a smaller meeting on Friday that is joined by non-individual contributors, such as Product Manager and Engineering Manager, and sometimes (on demand) by a designer, QA, or other specialists. This meeting is called Pre-Iteration Planning and follows the practice of Minimum Viable Audience, which requires that only an absolute minimum number of people join that is sufficient to make effective decisions in this meeting.
   
2. Are individual contributors completely out of the process of preparing the work items? (That can’t be good, right?) 
   
   Yes and no.
   
   This works because the PM and EM are also both collaboratively working with the team on the ground as ICs. Their percentage is just a bit different; for example, EM’s distribution is 60% IC work and 40% management work; this is because there is a limit to the maximum number of direct reports = 6.
   
   EM that works with the team on the ground is most effective because they have significantly more knowledge than EM that is “in the clouds or in the ivory tower.” Furthermore, the teams have the autonomy to adjust this blueprint via the retrospective (aka reflection workshop) to their process and way of working. What I’ve seen often happen is that another developer joins pre-IPMs together with the EM; that developer is usually the person who is pairing with the EM on that day.
   
   The benefit of this is that everyone gets to participate in the process of refining work items. However, it still maintains the concept of a minimum-viable audience wasting the minimum possible time. On top of this, some refinement of known and unknown unknowns is actually done via work items, such as exploratory charters and spikes, by the team itself. It’s just done, not in a meeting, but as normal focus or collaborative work. Based on that, appropriate work items can be created to deliver the desired and valuable outcomes.

The team goes to lunch at the same time

The lunchtime is fixed for the team. This ensures that the collaboration time isn’t affected by the unavailability and inconsistency of this break time.

One-on-one with the manager doesn’t break focus or collaboration time

Each individual contributor, once a week or bi-weekly, has a 30-min or 60-min one-on-one session with their direct manager (in the case of software engineers, this is the engineering manager). 

The engineering manager should be working inside this team, and have only reports from this team, making it possible to schedule these one-on-ones effectively. By effectively, I mean here that these meetings won’t cause significant interruptions to the focus and collaboration times of the individual contributors. 

This is workable when the number of direct reports of the engineering manager is no more than 6 — which is an optimal number of reports anyway.

Furthermore, in this case, the engineering manager has to also participate on the individual contribution level, and often collaborate with their reports. When this is true, the one-on-ones can be so short because the manager has a lot of context already about the work of their team members.

Final meeting of the day on Friday — Reflection Workshop

The Reflection Workshop (aka Retrospective) should be the last meeting of your iteration, and it closes this iteration. This meeting is 55 minutes long, and has all the usual properties of an effective meeting.

The most necessary company level meeting

All-hands meeting is important for company’s cross-team, cross-department and cross-unit alignment. Usually, one meeting per month of 55 minutes length is sufficient. This meeting is also an effective one.

Meet Alice and Her Calendar

Alice is a software engineer on one of the teams that has optimized schedule. This is what her calendar looks like (on the week that has the monthly all-hands):

In text:

Monday

1. 9:30am-9:40am — Daily Planning
2. 9:45am-10:40am — Iteration Planning
3. 10:45am-12:55pm — Focus or Collaboration Blocker: this blocker and all like that are reserved either for collaboration (e.g., pairing) or solo focus. How they are used is decided by the team collectively in the Daily Planning Meeting.
4. 1:00pm-1:55pm — Lunch
5. 2:00pm-6:30pm — Focus or Collaboration Blocker

Tuesday

1. 9:30am-9:40am — Focus or Collaboration Blocker
2. 9:45am-12:55pm — Focus or Collaboration Blocker
3. 1:00pm-1:55pm — Lunch
4. 2:00pm-4:55pm — Focus or Collaboration Blocker
5. 5:00pm-6:30pm — Focus Blocker: this blocker and all like that are reserved for pure solo work. The reason is that this day has no meetings, and there is plenty of time available for collaboration on this day already, so some time can be specifically reserved for solo work. The reason is that in highly collaborative environments like this, individuals still have tasks that they need to do alone, be it some kind of research, or even reading their emails. And they are easy to forget to do when you collaborate the whole day. This is what these solo blockers are for.

Wednesday

1. 9:30am-9:40am — Focus or Collaboration Blocker
2. 9:45am-10:40am — Monthly All-Hands
3. 10:45am-12:55pm — Focus or Collaboration Blocker
4. 1:00pm-1:55pm — Lunch
5. 2:00pm-6:30pm — Focus or Collaboration Blocker

Thursday

1. 9:30am-9:40am — Focus or Collaboration Blocker
2. 9:45am-12:55pm — Focus or Collaboration Blocker
3. 1:00pm-1:55pm — Lunch
4. 2:00pm-4:55pm — Focus or Collaboration Blocker
5. 5:00pm-6:30pm — Focus Blocker

Friday

1. 9:30am-9:40am — Focus or Collaboration Blocker
2. 9:45am-10:15am — Weekly One-on-One
3. 10:20am-12:55pm — Focus or Collaboration Blocker
4. 1:00pm-1:55pm — Lunch
5. 2:00pm-5:25pm — Focus or Collaboration Blocker
6. 5:30pm-6:25pm — Reflection Workshop

Let’s Calculate Alice’s Weekly Time Distribution

• Meeting Time = Daily Planning (10-min * 5) + Iteration Planning (55-min) + Monthly All-Hands (55-min / 4.33, averaged) + Weekly One-on-One (30-min) + Reflection Workshop (55-min) = 50 + 55 + 12.7 + 30 + 55 = 202.7 minutes = 3.3784 hours. This is 8.45% of the 40-hour workweek.
• Collaboration & Focus Time = the rest =  40 – 3.3784 = 36.6216 hours. This is 91.55% of the workweek.

Essentially, this is an ideal schedule, almost reaching that elusive 92% target. The truth is that sometimes other alignment, review and planning meetings come up, and individual contributors need to join.

FAQ

1. Everybody has the same fixed start, lunch, and end times. How is this contributing to the goal of increasing focus and collaboration time? Will this not reduce the quality of the focus time, especially for creative work (because of reduced flexibility)? 
   
   The teams I’m dealing with are highly collaborative, which means that they pair or mob almost all the time. The reason is that their methodology is highly optimized for that (it’s faster to deliver something in pairs than to do it solo) (the methodology is XP and 10x SWE delivery).
   
   If the schedule isn’t the same for the whole team and people take lunch at different times, that significantly reduces the availability of people for collaboration, making the whole approach less effective.
   
2. How come there is so much focus on the synchronization of work instead of embracing asynchrony and letting team members own the work and the workflow? 
   
   The way of working for these teams (XP and 10x SWE delivery) is the absolute opposite of asynchrony—it’s embracing synchrony, collocation, collaboration, and co-creation. There are many more advantages when it’s done well, and sync and collocated work has a much higher maximum potential for valuable outcomes than async and non-collocated work.
   
   This is because it can remove much more wait times and work-in-progress waste from the system, and async, non-collocated work increases the number of these. They are detrimental to the flow of value and throughput.
   
3. Goodhart’s law claims that when a measure becomes a target, it ceases to be a good measure. It seems like setting a target of 92% collaboration and focus time will not provide the expected benefits, even if the target is reached. How do you resolve that? 
   
   The schedule described above is a starting point for any new team that is formed. Then, the team is empowered to adapt through regular reflection and continuous improvement practices. For this empowerment, most of the team members are required to have a good grasp of the Theory of Constraints.
   
   This is so that they can identify bottlenecks appropriately and apply improvements to control the throughput of their system (the team plus their methodology adaptation). This means that some teams will identify the bottleneck in delivery, and they’ll actually add one meeting to their calendars that will increase their throughput of value (because it’ll expand the bottleneck).

Conclusion

Your mileage may vary. However, it’s very practical to achieve 80-90% focus & collaboration time for software engineering individual contributors when you follow these steps:

1. Make your meetings more effective and delete unnecessary ones.
2. Optimize the schedule of the whole team and for the team.
3. Block focus and collaboration time in the calendar.

Thank you for reading. This is only a tiny part of how to get your software engineering into 10x realm of productivity and valuable output. 

If you are eager to learn more about 10x Software Engineering, then I urge you to sign up for my newsletter!