![]()
Reshaping work processes and changing stuck habits
// By Jake Knapp
When changes come in life, you often find that previous processes no longer work and have to be redesigned. How do you do this?
When work no longer works
My way of working just didn't work. In 2003 my wife and I had our first child. When I returned to work afterward, I wanted my working hours to be as meaningful as the time I spent with my family. I checked my work habits and found that I wasn't focusing on the most important tasks. So I started to optimize my way of working. I read books on improving productivity, created Excel spreadsheets to see if I was working more efficiently when I exercised in the morning instead of at noon, or when I had coffee instead of tea. In a month, I experimented with five different to-do lists. Yes, all of this analysis was weird, but gradually I became more focused and organized.
And then, in 2007, I found a job at Google, where I found the perfect culture for a litigation freak like me. Google encourages its employees to experiment, not only with products but also with the methods that individual employees and teams use. Optimizing team processes became an obsession for me (yes, that's strange too). My first attempts were in brainstorming workshops with technical teams. Group brainstorming sessions, in which everyone simply brings out their ideas, is great fun. After a few hours we had a pile of sticky notes and everyone was in high spirits. But one day, in the middle of a brainstorming session, an engineer interrupted the process by asking, “How do you know that brainstorming works?” I didn't know what to answer. The truth was rather embarrassing: I asked the participants if they liked the workshop, but I failed to measure the results. So I checked the results of my workshops and I noticed a problem. The ideas that were finally implemented and succeeded didn't come from the interjections during brainstorming. The best ideas came from another source.
Where do better ideas come from?
But where did they come from? Each workshop participant came up with his or her ideas just as he or she always did - while he or she was sitting at a desk, waiting for an order in a coffee shop or taking a shower. These ideas developed by individuals were almost always superior to group ideas. After the enthusiastic mood of the workshops had subsided, the brainstorming ideas could not keep up with the individually developed proposed solutions. Perhaps there was not enough time in these sessions to really think deeply and thoroughly about the problem. Maybe it was because the brainstorms ended up with solutions that were nothing more than paper sketches instead of anything realistic. The more I thought about it, the more weaknesses I found in my approach.
I compared the brainstorming sessions to my own daily work on Google. I achieved the best results when I had to master a great challenge and was under time pressure. One of these projects took place in 2009. A Gmail engineer named Peter Balsiger came up with an idea how to organize emails automatically. I was excited about it - the method is now known as the “Priority Inbox” - and brought another engineer, Annie Chen, to join the team. Annie agreed, but she only gave the project a month. If we couldn't prove during that time that the idea was feasible, she would switch to another project. I was sure a month wouldn't be enough for us, but Annie is a great engineer, so I decided to give in to her condition.
How is work optimally divided?
We divided the month into four weekly segments. Every week we developed a new version. Annie and Peter made a prototype and at the end of the week we tested the version on a few hundred users. At the end of the month we had found a solution that was understandable and that users would surely be happy to apply. Annie stayed and ran the priority inbox team. And somehow we managed to get the development done in a fraction of the usual time. A few months later I visited Serge Lachapelle and Mikael Drugge, two "Googlers" who worked in Stockholm. The three of us wanted to test an idea for browser-based video conferencing software. I had only come to Stockholm for a few days so we worked as fast as we could. At the end of my flying visit, we had a working prototype. We emailed it to our colleagues and started using it for our conferences.
After a few months, it was used across the company. (An improved and fine-tuned version of this web-based app was later released under the name "Google Hangouts".) In both cases, I realized that I had worked far more effectively on these projects than in my daily work routine or some brainstorming workshop. What was the difference?
First, you had time to develop ideas freely, unlike the interjections in group brainstorming. On the other hand, you didn't have too much time either. Approaching deadlines forced me to focus. I couldn't afford to dwell on details or be distracted by less important things, as I often do in my daily work. Another key element was the people. Engineers, product managers, and designers all worked in the same room. Everyone solved his or her part of the problem, and everyone was always ready and able to answer each other's questions.
With team workshops to success
That made me think again about the team workshops. What if I added these other magical elements to the workshops, the time to solve individual problems, the time to develop a prototype and an immovable deadline? I decided to call this process a development "sprint". Once again, the Google teams willingly accepted the experiment. I ran sprints for Chrome, Google Search, Gmail, and other projects - and loved it. The sprints worked. Ideas were tested, implemented, introduced, and best of all, they often succeeded in the real world. The sprint process spread like wildfire from team to team and office to office. A designer from Google X became interested in the method and ran a sprint for a team in Google Ads. The Googlers from the Ads Sprint told their colleagues about it, and so on. I soon found out about sprints from people I had never spoken to. I made mistakes too, of course. There were forty people in my first sprint - that was way too many, of course, and it nearly blew the sprint before it even started. I adjusted the time for developing ideas and prototypes. I figured out what was going too fast, what was too slow, and finally what was exactly the right time.
A few years later, I met with Bill Maris to talk about sprints. Bill is the CEO of Google Ventures (GV), a venture capital company that Google founded to invest in promising startups. Bill is one of the most influential people in Silicon Valley. One would not suspect that from its external appearance. He wore his signature outfit that afternoon: a baseball cap and a t-shirt that said something about Vermont. Bill was interested in the idea of running sprints in the start-ups in the GV portfolio. Startups usually only get one chance to develop a successful product before the money is turned off. Sprints provided a method for these companies to quickly find out if they were on the right track before taking the risk of implementing and marketing their product ideas. Running sprints could save a lot of money and make a lot of money at the same time.
The test on the customer
To do this, however, I had to revise the sprint process. For years I had focused on individual and team productivity, but knew next to nothing about startups and their specific business problems. Still, Bill's enthusiasm convinced me that Google Ventures was the right place for sprints - and the right place for me. "Our mission is to find the best entrepreneurs on the planet and help them make the world a better place," he said. I could not escape the fascination of this message. At Google Ventures, I joined forces with three other development partners: Braden Kowitz, John Zeratsky, and Michael Margolis. Together we started running sprints with the startups, experimenting with the process and examining the results in order to optimize the process.
Braden Kowitz added story-centered design to the sprint process, an unconventional approach that relates to the entire customer experience rather than individual components or technologies. John Zeratsky helped us start from the end - that is, the long term goal - so that each sprint would provide the answers to the most important business questions. Braden and John had the start-up and business experience I lacked, and they re-engineered the process to better focus and make decisions with each sprint. Michael Margolis got us to end every sprint with testing on real customers. He's doing customer research, which can sometimes take weeks to plan and execute, and he found a way to get clear results in a single day. That was a revelation. We didn't have to rely on speculation as to whether our solutions were good or not. At the end of every sprint, we had clear answers.
The acid test for new ideas
And then there is Daniel Burka, an entrepreneur who founded two start-ups himself before selling one to Google and moving to Google Ventures. When I first explained the sprint process to him, he was skeptical. As he later told me, "that sounded like a lot of management gibberish." But he was ready to try it out. “We cut all the nonsense up in that first sprint and got a really ambitious goal in just a week. From then on I was convinced. «After we had won Daniel, his practical experience as a company founder and his zero tolerance for nonsense helped us perfect the process. Since the first sprint for Google Venture, we've continued to tweak and experiment with the process. At first we thought that rapid prototyping and customer research would only work on products for the mass market. Would we move forward just as quickly if our customers were medic...
