Ever see sleep histograms like the one pictured below? There are levels of sleep, and the deeper you go, the better the sleep you're getting. But it takes time for you to get to the sweet spot of REM sleep and achieve quality sleep. And if the neighbor's dog barks (or, in my household, your toddler yells "mama!") and you wake up, the whole process has to start over. The same, it seems, goes for design.
An article I read a while back caused me to reflect on how we scheduled meetings at Adaptive Path and how that might affect my colleagues' ability to achieve quality design work. In the article, Y-Combinator advisor Paul Graham, describes the differences between a "maker's schedule" and a "manager's schedule".
Essentially, Graham describes a “manager's schedule” as hour-based and centered around switching tasks. Your calendar rules your day. He says “when you use time that way, it's merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you're done.”
Graham continues by saying that “there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.” He explains that disruptions to the flow can be disastrous for solving difficult problems.
I am definitely guilty of booking check-ins that work for my “manager's schedule” moreso than our teams' “maker's schedule.” I try to keep them flexible—weekly 30-min meetings that can be skipped if they are pushing toward a deadline or moved around as needed. But the meetings still break up the design day, and some days the teams might barely get into really deep design work where they have the time and focus to understand and solve hard problems before they'd have to attend a meeting.
Every year or so, someone seems to ask the group to articulate the purpose of a particular meeting. To remind us who it serves, to ask us if the format is right for the topic and group, to discuss ways we can make sure it continues to be relevant. This happened last year. We used to have two hour-long staff meetings per week, one for sales and one for the practice. After a bit of discussion—yes, at a meeting—about what these meetings were designed to accomplish—we decided to combine them into one weekly meeting where we focused on consulting discussions regarding current projects and potential work one week, and practice-related topics the next. It's been working well. And everyone appreciates the meeting-free hour.
Another meeting overhaul happened about a year and a half ago. We used to have monthly all-day company meetings that included rowdy debates on provocative topics, updates on financials, project status reports and sharing from teams, sales, events, HR, etc. We've cut that time back to 90 minutes (with breakfast!) keeping it very focused, while making sure it remains an opportunity to simply come together in the same place at the same time.
We don't agree that meetings are toxic. Meetings are necessary. Just not all of them. At Adaptive Path, being transparent about our business is a huge part of our culture. We know we need to make room for discussions about where we're headed, the kind of work we want to do and how we want to go about getting it done.Talking about these things is essential and can't effectively be conducted over email.
But, we can continue to push it even further! We need to stay conscious of giving teams even more unbroken time to be in maker mode and work deeper into the zone where they can tackle the tough problems and generate elegant solutions. And just this week, another round of poking holes in our meeting schedule has flared up, which again reminded me of Graham's article.
So I say by all means, meet! Just please make sure you leave the space for designers and project teams to dream deeply and for long periods of time. It's good for the makers, it's good for the business!
Thanks to Brandon Schauer for his contributions and quick diagramming skills.