Join 31,816 readers for design news, cool links, and updates from Jake & JZ every... once in a while.
This summer I got to do a super fun project, and I thought I’d write it up. It started several months ago, when I got an email from Laura Prah, who leads culture and engagement at The New York Times.
Among other things, Laura is in charge of an event at The Times called Maker Week. Maker Week is like a hackathon. For one week every summer, folks are encouraged to step away from their regular work (as much as humanly possible at a newspaper) and experiment with new projects. They start on Monday, and on Friday they share prototypes with the company.
Laura was considering integrating the design sprint into Maker Week and she wondered what I thought. Well… I was stoked. I mean, first of all, it was The New York Times! I figured if I played my cards right, they might even invite me to visit. (Spoiler: this actually happened!)
Second, the design sprint seemed like a good fit for Maker Week. The design sprint is a step-by-step process for starting new projects — a sort of recipe for team problem-solving. In a design sprint, the team creates competing solutions, decides on the best, then builds and tests realistic prototypes, all within a single week. It was quite easy to imagine overlaying the design sprint steps over the top of what The Times was already doing.
And there was one more reason I was excited. This idea of a “Maker Week Remix” offered a chance to tinker with the traditional hackathon, which is a format I both love and hate.
Hackathons are awesome because they offer protected time, an artificial deadline and an experimental mindset that can stick in the team culture long after the event is over. In fact, hackathons were one of my inspirations when I created the design sprint (back in 2010 while I was at Google).
But hackathons are also not awesome. Without a clear game plan, newly-formed teams can waste time and lose their way. Many hackathon projects go nowhere when the event is over. And people often exhaust themselves working super long hours — as Jason Fried noted, you might be better off with a sleepathon than a hackathon.
By combining design sprints with Maker Week, Laura and I figured we might highlight the good stuff in hackathons while fixing some of the trouble spots.
Design sprints typically have five to seven people, but Maker Week would have 65. So I had to “scale up” the design sprint to work with several teams at once. I had a few ideas, because for the last year, I’ve been running design sprint workshops that often have 100 or more people. But those workshops use a “canned” project so that every team is working on the same fictional challenge. Multiple teams working on multiple real projects is much more complex, so I was a bit stressed out.
In the end, it worked out even better than I hoped. If you’d like to run a similar large-scale event with lots of teams, try making these six modifications to the normal design sprint process — they really helped me.
The design sprint is intended for one small team with one facilitator leading them through a checklist of activities. For Maker Week, I had 13 teams all together in one big room. There was no way I could rotate and coach each of the teams, so instead, I treated it like a big workshop (or yoga class) with me at the front talking everyone through the steps.
With so many people, I needed more than verbal instructions. I’ve developed a slide deck for my training workshops, and I adapted those slides for Maker Week. With them, I had a visual cue to go along with each step. This helped teams move super fast and stay focused.
Normally, the design sprint process takes five days. On Monday, the team creates a map of the problem and chooses a target; on Tuesday, they sketch solutions; on Wednesday, they decide which solutions are best; on Thursday, they prototype; and on Friday, they test the prototype with customers. But — knowing that not every team could take all five days off — Laura and I decided to compress Map, Sketch and Decide into just two days.
To tell the truth, I was apprehensive about getting all these different teams through the condensed schedule. I put together this spreadsheet to plan the activities minute by minute, adjusting the times as we went:
For Maker Week, I used the checklist from the Sprint book along with two improved techniques: the Note-n-Map (from Stéph Cruchon in Switzerland) and Storyboarding 2.0 (from AJ&Smart in Berlin). These techniques provide extra structure for the mapping and storyboarding activities, which normally require a lot of hands-on facilitation. Both worked like a charm. Even though they didn’t have dedicated facilitators, the Maker Week teams quickly created maps and storyboards without a lot of discussion.
I brought my buddies Jonathan and Luke to roam around and help if teams were confused about a specific step. As a bonus, Jonathan — who has run more design sprints than I have — watched the energy level of the room and helped me figure out when to speed up and when to slow down.
Many of the activities in the design sprint require silence, but it’s hard to enforce silence with 65 people in the room. And once one group starts murmuring, the broken focus quickly spreads. So I played some ambient music to remind people when to stay quiet and focused. (My playlist includes instrumental music by Marconi Union, Jamie xx, the Beastie Boys, Kamasi Washington, Chromatics, Dave Brubeck, Daft Punk, and others — and I used this tiny bluetooth speaker which projected sound throughout the space remarkably well.)
Remember how I was nervous about squeezing three days into just two? Well, at 2 p.m. on the second day the teams were already finished with three days worth of work! So we moved on to what is normally the fourth day of the design sprint: prototyping.
From 2 p.m. to 5 p.m., the teams put their heads down and cranked out their prototypes. Then, at 5 p.m., we shared progress. This was amazing: almost every team was finished with their prototype. They had done just 15 hours of work (seven and a half on day one, seven and a half on day two) and they were already done with what normally takes all of Maker Week.
I think there are a few reasons why the teams were able to sprint and prototype so quickly. First of all, because the hackathon projects were all new or speculative, there wasn’t a lot of background knowledge to share or politics to work out. Part of what takes time during the map step of a design sprint is working through the messy details of real, long-term projects. For better or worse, a hackathon environment avoids those details and starts with less information — so day one was a breeze.
The projects were also fairly well scoped. Laura and her colleagues Kelci Shipley and Jody Mak had supplied each team with a “How Might We?” question to seed their design sprints (for example, “How might we allow subscribers to engage directly with editors?” or “How might we allow users to track the physical delivery of their paper?”). These questions had been carefully phrased to keep the scope appropriate to Maker Week.
It also helped that the people in the room knew the app, website and editorial tools inside and out. I’m used to working with startups, who might try to define a brand and a marketing plan and a technology stack all at once. The New York Times has been around for 167 years (really) and they’ve had a website for about 142 years (not really, but it seems like it). There’s already a strong foundation and many components to work with, so when it came time to build the prototype the teams could really fly.
Finally, and I think this is important, everybody came in with the right mindset. In a design sprint, part of the facilitator’s challenge is to help a team move quickly, forget about being perfect and get into an experimental mode. Maybe it’s because Maker Week is already an institution at The Times, or maybe it’s because the digital team is used to quickly experimenting with new ideas and technologies.
In the end, even a design sprint-ified Maker Week was still a hackathon. The projects were all explorations — answers to questions that the Times is curious about, but perhaps not quite ready to act on. When the dust settled, everybody went back to their real work and had to catch up. Most teams didn’t test their prototypes with target customers, and most didn’t plan to take their prototypes anywhere.
Normally this would absolutely kill me. I hate it when the projects go nowhere. I crafted every step in the design sprint to be pragmatic, each one making progress toward building something real.
And yet… fundamentally and intentionally, the Maker Week projects are short-lived experiments that are never intended to see the light of day. Laura was explicit about this from the very beginning: Sending new projects to production is not the goal. Instead, Maker Week is about practicing exploration.
So I’ll add one more suggestion for multi-team sprints:
Decide in advance whether the goal is launching or practicing. And be honest, because it’s very hard to keep hackathon projects alive, and very frustrating to be told something has a chance to launch only to watch it go nowhere. If you decide to make it practice, do what Laura did and be very clear at the beginning, and remind people over and over: This is practice. The point is to flex our experimentation muscles.
It’ll take some time to know if the design sprint-ified Maker Week was a success, but I have a good feeling about it. With a little luck, The New York Times will use design sprints on more real projects (they already started last year) and… who knows, maybe one of the Maker Week experiments will defy the plan and catch on? Either way, it was good practice.
If you try a large-scale design sprint/hackathon at your company, let me know how it goes!
Photos by Jonathan Courtney and Luke Knapp
