Business software’s increasing focus on real-time collaboration, activity streams and consumerization threatens what Paul Graham called the “maker’s schedule” in the workplace. Makers need long blocks of uninterrupted time to concentrate on ambitious, creative work. The result of always-on availability, random notification, and constant information deluge is a work mode of interruption-driven multitasking that’s antithetical to a maker’s needs.
Digital connectivity empowers managers to collaborate with makers in creating, but without regard to when. Because modern collaboration tools flow so neatly within their kind of schedule, managers often don’t realize the costs to the maker. At iDoneThis, we use a bunch of awesome collaborative tools including Asana, Github, Campfire, Google Docs, Skype, and Trello, and we’ve observed how those tools can disrupt a maker’s schedule.
For instance, in Github, we noticed that creating a bug ticket and assigning it to someone will often result in that person switching tasks to kill the bug, regardless of its urgency or assigned priority level — all because the ticket assignment triggers an email notification. We decided to avoid assigning tickets during work hours unless the ticket needs to be resolved immediately.
We use Campfire for group chat, but we saw how a scrolling chat format can be a visual distraction and group chat can devolve into one long, endless meeting. Plus, without extended time alone, work product can end up designed by committee, a problem of too many cooks. So instead, we have quiet time during the day when we work away from chat in order to focus without interruption.
Similarly, Asana’s comment threads are a great way to discuss projects and action items, but we try to batch these toward the end of the day. Otherwise, email notifications of comments get triggered and they disrupt and add to the multitasking that pulls your full attention away from the task at hand.
With iDoneThis, we aim to create a quieter frequency for non-urgent, unstructured communication at work. We’ve found that having such a communication channel is essential to creating a bubble that protects and enhances maker’s schedule without sacrificing open and transparent communication within a company.
The way we work is through an evening email that asks, “What’d you get done today?” Just reply. In the morning, everyone gets a digest that shows what the team got done—to kickstart another awesome day. Pesky status updates aren’t randomly interspersed throughout your day, they occur on a rhythm that bookends the day — reflect and jot down your dones in the evening and scan your morning digest to get up to speed.
iDoneThis becomes the place for recording the reflective thought that’s vital to evaluation and improvement but often gets ignored in the hustle and bustle. A valuable repository of little nuggets of learnings, notes, emotions, appreciation, and thanks gets built up, bit by bit. You can record any non-urgent communication during the day, and you know that you won’t be bothering anyone with it — they’ll see it the next morning when they’re sipping a cup of coffee.
At the same time, we’ve struggled with realizing our maker’s schedule aspirations real through the product.
- Notifications: We started with no real-time notification system, and when we implemented a feedback system of “comments” and “likes”, we built them into the evening/morning rhythm to avoid disruption. After running with that for a bit, our members told us that they expected the comments to happen in real-time. We found that people wanted to start a conversation about what had been recorded the previous day, and the lack of real-time email notification of comments made the conversation die, resulting in a failure to surface relevant knowledge at the right moment. No doubt, real-time email notification increases engagement with the product and that’s the primary reason for its pervasiveness, but engagement itself isn’t an end. We think we can look to the job that makers and managers alike wish to accomplish with the mechanics of iDoneThis to determine whether a notification should be turn-based or real-time rather than applying the real-time design pattern across our site without thinking.
- Privilege: We began by treating every user as exactly the same, no one having a privilege that others didn’t, because our gut told us that it was important for building credibility. We didn’t want people to feel wary about a lack of transparency, that the tool was actually more for monitoring and control rather than for sharing progress and celebrating it. feel wary for lack of transparency that the tool was for actually for monitoring and control rather than for sharing progress and celebrating it. Nevertheless, we’ve seen that managers have felt the most strongly about wanting their companies to adopt our product, and as a result, we’ve seen an uptick in user adoption by empowering managers with configuration options to help make iDoneThis work for the way their team operates. While we’ve given managers admin access that other members lack, we’ve done it through the lens of helping managers better serve their team, and we think that’s a distinction that will stick.
- Adoption: Where adoption happens through management, as it does for most business applications, the managers become your customers. Managers as customers inevitably request features that will help them do their jobs better, and who can blame them? We often receive requests for a manager’s-only view, which makes explicit who is failing to comply and provides mechanics to more strictly enforce compliance. When managers are the ones who are paying us, they become the people we want to please, but as the product’s creators, we also have a broader view on what works across companies. And the number one challenge for building open communication and a healthy work culture does not revolve around what the manager wants in the individual case, rather it’s getting trust and buy-in from everyone in the company. Armed with that knowledge, we try out best to focus on what’s best for makers and managers alike.
What’s at stake in developing business collaboration software is building and reinventing the modern office into the type of place we’d all like to work in. For us, that means ensuring alone time, maker’s schedule, and the quiet time we need to do our best, most fulfilling work.