At our Silicon Valley Field Study earlier this year, Mark Randall, Adobe’s VP of Creativity, discussed a simple set of legal guidelines that had been created for employees who participate in Adobe’s Kickbox ideation and prototyping process, which we wrote about in 2014.
“They fit onto two sides of one page,” Randall said. “It’s twelve bullets. Anybody can read them, anybody can understand them. Legal says, ‘Look, if you don’t like these, [or] you have trouble with one of these, just call us. There’s only been a handful [of Kickbox participants] that needed to go to Legal for further help… People are able to self-gate, self-qualify, and self-manage to prevent disaster.”
Since many companies deal with the need to create clear legal boundaries for innovators that don’t totally stamp out any and all risk-taking, we asked one of the members of Adobe’s legal team, Donna Kolnes, to share some background on the thinking behind the guidelines.
• • •
The Adobe Kickbox program teaches innovation techniques that allow our employees to originate a new concept, and then publicly test out their theories using a fail-fast concept validation methodology. Innovation is very important to Adobe. Enabling rapid experimentation serves real business purposes as well as enhancing morale; it rekindles our employees’ passion for creating software that our customers want. The benefit of having inspired and excited employees who are eager to innovate is priceless.
We were challenged to find a way to balance the legal risks of this type of development with the benefit of employee-driven innovation. It wouldn’t scale to have Legal involved in this development process and we didn’t want to get in the way. We created a short, one-page set of Kickbox Legal Guidelines. So long as employees follow the guidelines, they do not need to consult Adobe Legal as they build out their project.
The Adobe Kickbox Legal Guidelines are for internal use only; we don’t share them publicly, despite the fact that we have open sourced the Kickbox program. Having said that, we can share how we approached the risks related to the Kickbox development methodology when crafting the guidelines. One disclaimer: If you are applying the Kickbox development methodology, we strongly suggest you obtain your own legal counsel, as this article does not provide legal advice and is not a substitute for proper due diligence. You will also need to determine for yourself what is a high risk, a medium risk, and a low risk for your particular business.
Our approach was to identify risks that had severe consequences and then to have the employees avoid them altogether. We didn’t want to dampen anyone’s vision, but in order to scale the program, we thought it was important that the program not require legal intervention. However, since Adobe is a publicly-traded company, we thought this was an appropriate limitation. One example is that we asked employees to avoid developing products and services directed towards children or heavily-regulated industries such as the financial sector.
Since our primary customers are creative professionals and people who use enterprise analytics, we thought this was a minimal intrusion on our employees’ innovation while addressing the issues that would bring the highest legal risk.
For medium-risk legal issues, we provide reminders such as honoring the IP of others and suggestions on how they might run certain tests in a manner that mitigates legal risk further. For example, providing a multi-screen purchase workflow that stops short of collecting credit cards is a way to test whether users would pay for the product or service, while avoiding the risk of actually collecting sensitive personal information. Lastly, we thought that a geographic limit (like North America only) and a short duration for each experiment provided the right balance to mitigate legal risk, while allowing for public tests of rapidly-developed innovative concepts.
We’ve now distributed over 1,000 red boxes — the starter kit for Kickbox participants — to our employees. Without the right legal framework, that scale of internal innovation likely would never have been possible.