Setting up a lab in your agency

Jon Lax, the co-founder of Teehan+Lax, discusses why the agency built a dedicated labs group, how they chose to structure it and what they have accomplished in their first year

It’s become fashionable over the past few years for agencies to establish a Lab. In December of 2010 we decided to create a Labs group at Teehan+Lax. While to the outside it may seem like we have just hopped on the bandwagon, the truth is we spent a considerable amount of time designing and thinking about this group, its purpose, its operations and its mandate.

So after one year we thought it would be helpful to share why we chose to do this and what we’ve learned in our Year in The Lab.

The history

In the past we had tried to do a number of projects under the title “labs”. We tried resourcing projects in free time. We tried allocating 20 per cent time (a la Google). We tried scheduling them as projects. All of this was a complete failure.

Here is why these attempts didn’t work.

  1. There is no time. The idea that you can resource these types of projects inside existing client work is a pipe dream. Clients always take the resources.
  2. The desire to ship products. Whenever the team sat down to think of “labs” projects, they tended to think of products they wanted to build. You can see this evidenced in two “Labs” projects, ImgSpark and Paruba. These are startups. These ideas require significant resources and if you somehow manage to launch them then what? Is it a Lab project to manage them?
  3. No one is responsible. We learned that unless someone’s job is on the line, Labs projects just drifted. They had no focus or urgency to complete.

In November of 2010 Peter Nitsch came into my office with a proposal, actually it was more of a threat. He had been approached by another agency to establish a future technology group. While it was an interesting opportunity he said he would prefer if he could do something like this at Teehan+Lax.

Peter is a unique individual. He is an incredibly gifted developer with an insatiable curiosity. Geoff Teehan and myself knew that Pete was under-utilised at the company. The things he was interested in and his skills were well beyond what the client work was demanding of him.

I knew I didn’t want to lose Pete but we also needed to find a way to harness his skills better. This led me to ask him “So if you could design your job here, what would it be?” This begun a series of conversations that would eventually lead to us forming our Labs group.

The Teehan+Lax Labs blog reports on current projects and events like the recent hardware hacking workshop

Forming the group

The first thing Peter did was research at every Lab or R+D division he could find. He looked at agency lab groups, corporate R+D groups, government research projects. He tried to understand what value they brought to their company/organisation and what kind of problems they were solving.

He showed me a chart where he plotted the various Lab groups noting how much structure they had (did they have dedicated staff and process or were they essentially a blog for thought pieces). He tried to separate the companies who used their Labs for client PR versus those solving interesting problems. Which ones were theoretical versus those which where more applied.

We spent a long time debating and discussing the merits of these approaches. We needed to find an approach that would work for us. We eventually agreed on some principles that would shape the group.

  1. The group needed to have a dedicated staff. We knew that unless there was an investment from the company and people who’s jobs were dependant on the success of the Lab, it would fail. Peter was the first hire but he needed a team. We agreed to three people for the first year.
  2. The group would understand possibilities and the creative uses of technology. When you are working on client work, time constraints and client constraints often send you back to well worn grooves. When you are pressed for time we tend to look into our “toolbox’ for a solution to the problem. But when did we take time to expand the toolbox? I had seen in the company that after just exposing people to or discussing new technology we would suddenly see it appear in concepts. I wanted our Labs group to be the driver of helping to understand what is technically possible.
  3. It wouldn’t be billable. I removed all financial burden from the group from day one. I wanted a Lab group who’s only purpose was to make us, internally, better. They were there to inspire us, show us what was possible. I had faith that this would trickle through to clients but I didn’t require it. The Lab was not there to sell clients ideas or create products we would bring to market. I knew if we didn’t do this, Labs was doomed.

Financially I accepted it as a sunk cost. It's not cheap for a company like us to fund this. But I believed it would be worth it.

Peter spent a lot of time building up a vision for Lab based on these three requirements. Over the holidays we focussed on three things...

Values

What does the Lab stand for? What does it value? It has one main value “exploring the creative uses of technology” and a second value of “sharing knowledge and reducing complexity”. Both of these values are internally targetted, meaning we do these things for ourselves not directly for clients.

Sharing knowledge was very important and we wanted whatever we learned in the Lab to be shared with the company. Making that a core value really shaped how the Lab works.

Process

Once we had the values down, we had to figure out how to work. The process defined what projects looked like and how they were completed. Peter and I both agreed that we wanted to make projects very lightweight. In fact the first thing we did is stop calling them projects and started calling them experiments. Experiments could only be two weeks long. At the start of the two weeks the Lab would define a problem they wanted to understand better and then would take two weeks to experiment with it.

At the end of the two weeks we would document what we had and every month the Lab would share it with the company. We knew many of these experiments would go nowhere, and that was ok. We built failure into the model.

To begin, Peter created a bunch of experiments, but the idea was that anyone in the company can propose an experiment for the Lab to work on. For example, I proposed an experiment on “how we might use projection mapping to create UIs” that the Lab is working on right now.

We use an amazing service called Kindling to track these experiment requests.

Resources

The final piece was who would work on experiments. Peter knew he wanted a designer and a developer on his core team. After that people from the company would come into the Lab. By creating a core set of resources that weren't tied to client work, we knew Lab work would happen year round. I gave the company a goal, that's tied to their bonus, that they must spend a minimum of five days working in the Lab over a year.

The Touch Vision Interface is a tool the Lab created to enable touch interaction on many different connected surfaces through a mobile phones' camera view

The Touch Vision Interface is a tool the Lab created to enable touch interaction on many different connected surfaces through a mobile phones’ camera view

What we have learned after one year

Resourcing still an issue

Resourcing is still the most difficult issue we face. Getting people freed from client work and able to work in the Lab is still incredibly difficult. It will be a focus of 2012 to get better at this.

PR is a double edged sword

One of our experiments (TVI) was picked up by Engadget, PSFK and Creative Applications. This is great PR for the Lab and Teehan+Lax but led to a series of requests to buy or license the technology. TVI was a two-week experiment and not a product, it wasn’t something that was market ready. The Lab was designed to not work on client projects so accepting one of these requests would mean the Lab would turn into a client group or a product group, both would take them off their mandate. It’s a nice problem to have but we had to turn down these opportunities.

Create a hacker culture

Peter made this a mandate from the beginning. He wanted the Lab to instill a hacker culture at Teehan+Lax. We defined that as a culture of curiousity and making things. The Lab has run hack days here where everyone built Arduino projects. They have a physical workspace where you will see staff tearing down Kindles or soldering boards for experiments. They encourage everyone in the company to walk in and play with the experiments, ask questions and understand how it works. I believe this is a competitive advantage for us.

This is one of the horrifying results of the Arduino Hackday, a light introduction to physical prototyping for all Teehan+Lax employees

This is one of the horrifying results of the Arduino Hackday, a light introduction to physical prototyping for all Teehan+Lax employees

If you or your company is thinking of creating a Lab, don’t do it because its trendy or you think it makes you look cool. Do it in a thoughtful and purposeful way that helps your company, your employees or your clients achieve something. Look at the various models out there and find what works best for you. It’s an investment both financially and emotionally but one of the best things we’ve done here.