Makers time and collaboration time are two metrics that I have started using to help teams to measure the amount of quality time they have available to do their best work, and to make improvements over time. In this blog post I explain what they are and when/how to use them.
Problems these metrics are meant to solve
These metrics were born out of two frustrations I have faced working as a product / delivery manager in various UK public sector organisations:
- finding time to meet as a team, or do to things across multiple teams can be hard
- people often complain about there being too many meetings, and not having enough time to get into a state of flow and do their best work
They build upon some of the techniques I shared in my better meetings blog post, and explore how the timing of meetings and the structure of people’s calendars can affect productivity.
What it is
Managers like me are happy to break their day up into 30 minute slots. Makers on the other hand need large amounts of uninterrupted time (eg. 2-3 hours+) in order to solve a problem, get into a state of flow and do their best work. When makers are constantly interrupted it reduces their ability to do their best work. See Paul Graham’s blog post on Makers Schedules and Managers Schedules for more info.
How to measure it
Makers time is a block of time where someone can focus un-interrupted on one task, without interruption (eg. from meetings).
The metric is “In the average week, what % of time do team members have available for makers time.” See some of my example calculations below the notes.
Here are some guidelines I use to take the measurement:
- working as a group with other members of the team to solve specific problems does not count as meetings, and should be included in the definition of makers time (eg. pair/mob programming, developer and designer pairing to solve a solution, kick offs, whiteboarding, problem solving, 3 amigos, canvas board sessions, etc). Arguably some of these could disrupt a makers flow, but I want to avoid the makers time metric disincentivising these activities as they are things most teams I work with should try to do more of
- team ceremonies do count as meetings as they are not a time for making things, they are a time for planning
- for time to count as makers time, it needs to be an uninterrupted block of a minimum of 2 hours. Ideally it should be longer
- these metrics should be collected for key ‘maker’ roles in the team, such as designers, developers, analysts & QA. There is no harm collecting it for other roles too (eg. product or delivery), but as those roles are more manager than maker, there is less benefit in doing so
- metrics will be probably need to be collected by looking at a 2 or 4 week period (many meetings happen on a fortnightly or monthly cadence, and just looking 1 week at a time won’t pick these up)
- lunch time should be excluded from makers time, as this requires context switching
See the simplified examples below showing calendars with less and more makers time.
How to use makers time?
Take some time with each member of the team to understand what commitments they have in their calendar. Taking screenshots of their calendar and overlaying blocks of makers time where it exists is a technique that I’ve found works well, and allows you to come up with an overall makers time score (expressed as a percentage). Once you’ve got the data, you can then have a conversation with the makers about how to improve it, and repeat the exercise in the future to see how things have changed.
The three best ways to give people more makers time are:
- schedule meetings to happen close to each other (eg. all in one half day). This leaves the rest of the week free for makers to make. This approach also works well with hybrid working as you can do these meetings on the day you are all in the office
- schedule meetings to happen close to the beginning or end of the day, or close to lunch time. That way, they cause minimum interruption to potential makers time
- remove unnecessary meetings
As a maker, you should be encouraged to maximise makers time when scheduling meetings, and to push back on meeting organisers who try to schedule “just a quick meeting” in the middle of an otherwise free afternoon.
As a manager, you should be available to help with the above and have difficult conversations on behalf of your makers when needed.
As a team, regular meetings like standups, show & tells, retrospectives and planning sessions should be scheduled at times that minimise disruption to makers time (so all in one chunk, or close to the beginning/end of the day or to lunch).
As a team of teams, program or organisation, be mindful of how your meetings can impact makers time. Consider setting aside one half day per week or fortnight for things like all staff meetings, company announcements, show & tells, or other activities that involve all or some of the teams. Consult with teams to find times that works best for most. And record things so that those for whom the time does not work so well can catch up at a time that works better for them.
Not all makers time is made equal
People do their best work at different times of day, and some people have flexible working arrangements or other responsibilities (eg. school run). It is important to take all of this into account when optimising calenders for makers time. For example, if most makers on the team like to get their best work done in the morning, it is worth considering doing team meetings at the end of the day.
What is it?
Cross functional teams deliver value by bringing people together with different capabilities which leads to more effective problem solving and smarter decision making. For this approach to work, teams need time available to collaborate as a team and solve problems together as they arise – often at short notice.
How do you measure it?
The metric is: in the average week, how much time do the team have available to collaborate with each other.
Collaboration time includes:
- team ceremonies (standup, retro, planning, etc)
- any time every member of the team is free to work together if needed (they don’t have to use this time, it just has to be available if needed)
Two suggested ways to collect this metric:
- compare the calendars of everyone in your team. Any time where everyone is free or where the team have time blocked out together counts as team time
- maintain a miro board of team activities to calculate it
My suggested approach is to take a screenshot of the view of all the calendars compared and annotate it in Miro with collaboration time and potential optimisations.
How to use collaboration time?
For teams that feel like they struggle to find enough time to work together, I would recommend:
- setting aside some time every day for the team to collaborate. Do this at a time which minimises disruption to makers time for most, and that suits the working styles of most people in the team. At the end of standup each day, the team can decide to cancel the collaboration time if it’s not needed. This way, teams have time to collaborate if needed
- organise cross team meetings that only involve some team members to happen at consistent times. For example, most organisations I have worked in have communities of practice for each discipline. Once per week all the user researchers get together. At a different time all the product managers get together. And a different time again the developers get together. And so on. If all of these meetings happen at a consistent time each week, team collaboration time will increase. Even for teams that already feel like they have enough collaboration time, this can be a worthwhile exercise as it makes it easier to arrange ad hoc meetings that involve people from across multiple disciplines and teams. See the example illustration below.
Some other tips on using makers time and collaboration time
Allow teams to choose whether they want to use these metrics or not. They are best used as a part of the toolkit to help teams who think they have a problem with having too many meetings or not having enough time to get their best work done. I have tried this technique out with teams that don’t think they have those problems, and the teams did not got much value from the exercise.
The value of these metrics is more in the act of taking the measurement and the conversations it provokes, rather than the result itself. Measuring makers time and collaboration time encourages a switch in mindset towards valuing productive time, and seeing an empty calendar as something to be aimed for and protected rather than as an open invitation for catch-ups.
Avoid using this metric at the program level or to compare teams. I briefly toyed with the idea of benchmarking makers time on a few teams every 6 months and using that to indicate how much makers time teams had across a programme. This didn’t work because the act of measuring makers time usually leads to teams making improvements. It is also a very easy metric to game, so if teams are doing it to try to look good to senior management rather than as a tool for them to honestly self evaluate, the value quickly starts to diminish (as is the case with most agile metrics).
Use these metrics to put a more accurate economic cost on meetings. A meeting involving 10 people who are charged out at £100 per hour costs £1000. But if that meeting involves developers and designers who are having their productive makers time disrupted, the actual cost of the meeting is much higher. In the example above, a 1 hour meeting in the middle of the afternoon actually costs 4 hours of makers time for each attendee. Onto collaboration time, one of the big benefits of having cross functional teams is that they bring together people with the diverse range of skillsets needed to solve complex problems. If teams don’t have time to collaborate together at short notice, they can’t react to new information as fast, and they risk taking longer to change direction in response to new information than competitors do. Economic arguments like these can be used to persuade others in your organization to take protecting makers time and collaboration time seriously.
Thank you for reading this blog post!
If you have any feedback contact me on my website or connect with me on LinkedIn or Twitter.
Also, shout out to Gavin Cooke who worked with me to develop these ideas. Thanks Gavin!