Four years ago CauseLabs started setting aside one day every two months for our team to build projects of their own choosing. Little did we know the impact these lab days would have on our company’s internal motivation, our employees’ skillsets, and our ability to work collaboratively in innovative ways. Now, four years in, we’ve broken down our insights into best practices for other companies to follow, to help them achieve similar success.
Innovation days go by many names, but the key elements are consistent: Bring together a few people, set up a basic process, and tackle acute problems. At its core, a “lab day” is any amount of time devoted to team collaboration on an agreed upon problem or project. Companies from Google to small start ups are finding that committing to lab days can make an immense impact on productivity and engagement in every other area of their business.
Lab days engage our imaginations, address our restlessness, and allow us to tinker. During a lab day the blinders are on to other projects, email, and all other distractions. Teams of one to three people build for a set amount of time, then join with other teams at the end of the day to demo and get rapid feedback for next steps. Any organization with design thinkers and makers can use time like this to solve problems.
Our path to lab days
At CauseLabs, a software strategy firm, we began lab days a few years ago after one of our staff members came back from a conference with the idea of doing an internal day of innovation. Nonprofits occasionally call this sort of internal day a “hackathon,” and we were familiar with other companies who used similar processes for innovation.
Google’s “20% time” is perhaps the most popular example of an internal innovation program, but 3M’s “15% rule” instituted in 1948 is the pioneering example. 3M encourages 15% of employee time to be spent on projects driven by their own insights. Similarly, at Google, the “20% time” egalitarian company policy served to promote Google’s innovative culture and produced business successes including Gmail, Google Now, and AdSense—and became so ingrained in the culture that Google ultimately removed the formal process, determining it was no longer necessary. Many other large technology companies such as Facebook foster rapid innovation, and we can draw on their strategies to begin variations tailored to specific companies.
The goals and features of an innovation program can vary and are highly dependent on an organization’s culture and values. Atlassian’s ShipIt Days are an interesting example of how culture influences efforts to set aside time for side project exploration and innovation. A ShipIt Day is 24 hours set aside once per quarter for developers to work on whatever they want, with a skew towards Atlassian’s products. At the end of the day, a trophy is awarded based on votes considering the criteria of usefulness, “shippability,” technical accomplishment, and flair. Results have included FishEye’s side-by-side diffs and Atlassian Invaders, all of which reflect Atlassian’s focus on fun and learning.
Because our team focuses on building tools that impact people, the vision for our program needed to be broader to ensure diverse outcomes. But perhaps more importantly, as we sifted through the variety of innovation programs, and experimented with what worked best for our team, three lab day must-haves emerged as principles.
Constraints for an effective lab day
The common theme of a lab day—or any innovation effort—is a constrained process to generate and capture new ideas. Constraints of time, money, and resources can be viewed as a barrier to creativity, growth, and development, but for innovation, they are a gift. Constraints helped Jason Fried and his team at 37 Signals create Basecamp. Limited time forced them to focus on what mattered in their product. Limited resources led to simpler solutions. Basecamp’s simplicity, a hallmark feature leading to its dominance among project management products, is the fruit of constraints. Lab days, likewise, breed simple and creative solutions.
Over the past three years we’ve found these three constraints to be crucial to making great ideas tangible in our lab days:
- Defined process
- Fixed time
- Small teams
Defined process
A “process” can mean nearly anything that is used consistently, but a lab day process needs to be a little more specific. Most importantly, it must include testing and prototyping, both of which help to quickly visualize and communicate ideas.
Our lab days last eight hours: one full work day. In the weeks prior to the actual day, we hold two drawing board sessions where teams hone their selected problem, conduct research, and set scope for a prototype. Ideas are shared and revised so that by lab day we’re ready to build.
On lab day no other activities take place, and we hit the ground running at 8am. Using the scope developed over the past two weeks, team members divvy up tasks and then quickly try to complete a rough working product by midmorning. Though crude, the first prototype is effective at drawing out the “gotchas” and content needs that will need to be addressed before day’s end. From there, they build and test as many iterations as possible before the end of the day, when we close with a show and tell.
We used the lab day process last year in Vietnam, where we helped an organization convert from paper to digital for field-based verification on the installation of 150,000 toilets in rural, poor households. The process started with observing the current paper-based process in the field, followed by rapid prototyping, and then testing and iteration, Finally, we wrapped up with a summary of learnings and identified next steps to get to a field-ready beta version of a digital process. The set process allowed us to accomplish in one week what could otherwise have taken two to three months. The constrained process surfaced must-have features via human observation rather than by requirements written down in a document by someone removed from the field. Without this constraint of process, we risked building the wrong tool altogether.
Fixed time
We set strict deadlines to force creative decisions and keep energy high, with 30- or 60-minute milestones racing toward the show and tell at 4pm. This ensures we don’t go down rabbit holes or take too much time on any particular idea.
An example of the benefit of a fixed windows of time is My Story, a storytelling app created during one of our lab days. It started as a line tracing concept to help children develop the motor skills fundamental to penmanship and drawing. After the first lab day, the team pivoted the concept, and My Story was born the next lab day. The two fixed eight-hour spurts served as drivers for the team to refine the concept as well as broader support from the company. Having the date of the next lab day in mind provided the impetus they needed to make things happen in their own time. After the second lab day’s show and tell, it was also clear we needed to get this tool into people’s hands. Without those fixed time units to establish a rhythm to our innovation, neither iteration nor launch would have happened.
On the other hand, but equally important, we have also found out the hard way that extending the time teams can work can make ideas suffer. At one point we were excited about early prototypes for three different projects and allowed those teams to spend an extra hour here and there “on the clock” to continue progress over the coming months. The result was that ideas suffered. The focus the team had experienced on lab day disappeared, leading to slow and stilted progress. My Story flourished because it only had eight hour spurts on the clock, and when we decided to take it to market, we made it our only such special project beyond our client work to ensure we did it right.
Small teams
Small teams – less than 4—are a good size for a lab day. We’ve found that two people with complementary skills are sometimes the most productive, such as a designer and developer. A third person can contribute many things, such as great content, testing, or a strategy for prototypes, but we’ve found that groups of more than three people begin to flounder.
In large part, the problem is a mixed blessing. The larger a group, the more ideas and connections are made. Ideas and connections are wonderful, but too many ideas can paralyze a team. Even within three person teams, one of those three must act as the “champion,” or final decision maker. With more than three people it becomes nearly impossible to choose one idea and carry it forward to execution.
One lab day project done by three people led to our building a web platform with Playing For Change Foundation. We were successful in large part because we had a tangible concept created by a small team to guide our work. Although many more people were ultimately involved, the small team shepherded the app through the process. The site has united musicians on one day for each of the past four years to help raise $500,000 for the Foundation’s schools. Three people with one prototype in one day meant decisions were made quickly, and ultimately this led to thousands of lives impacted for the better.
Lab days for everyone!
As a result of pioneering our own internal innovation, we have developed a special blend for our projects and partners that is strongly influenced by two schools of thought, which will benefit anyone beginning their own version of lab days.
- The Lean Startup methodology by Eric Ries. Lean principles help teams to operate in a capital-efficient way that reduces wasted time, effort, and money. Teams of two – and no more than three – lead our projects, which enables operational efficiencies.
By embracing the Lean principle of scientific methodology, organizations also take time to measure. This keeps us from getting caught up in only building cool things and helps us stay focused on developing a product that really and truly solves the problem at hand.
- The human-centered design principles developed by IDEO. HCD Connect—particularly the HCD Tookit—is a great resource. Human-centered design focuses on the people first: What is the human problem behind that list of requirements? We can then start to move away from our own assumptions.
This human-centered focus not only improves our lab days, it also makes us a better partner to the organizations we serve. They know that technology holds promise, and our partners want to use it to solve human problems.
The methodologies and principles behind our lab days infiltrate every element of our operations. As a result, we are an organization that uses nimble teams, fast cycles, small batches, minimum viable products, and a laser focus on the human problem behind any list of product or project requirements. We’ve been amazed at what a difference those mere eight hours has made.