Getting Real About “Experiments” and Learning

Elliott's Science Project

Part one of a three-part essay on facilitating group learning.

Last year, I went to Cincinnati to visit my sister and her family. My older nephew, Elliott, who was eight at the time, asked if I could help him with his science experiment. He was supposed to pick a project, develop a hypothesis, and run some experiments to prove or disprove it.

Elliott explained to me that earlier that year, he had participated in a pinewood derby and had lost. He wanted to figure out how to make a car that would go faster. I asked him, “What do you think would make the car go faster?”

He responded, “Making it heavier.” That seemed like an eminently reasonable hypothesis, especially coming from an eight year old. I helped him define the parameters of an experiment, and he constructed a car out of Legos and a ramp using a hodgepodge of race track parts to run his tests.

In theory, mass has nothing to do with the speed of the car. The only thing that matters is the acceleration of gravity, which is constant. A heavier car should go down the ramp at the same speed as a lighter one.

Except that’s not true either. Wind resistance counteracts the effects of gravity, which might make a lighter car go slower as a result. Then again, the aerodynamics of the car might have a bigger effect on decreasing wind resistance than mass. Then there’s the issue of both the friction and alignment of the wheels. And so forth.

Wading through all of these variables would require a carefully calibrated measurement system. Suffice it to say, Elliott’s system was not very precise. When he ran his experiment initially, the lighter car went faster than the heavier car. He dutifully proceeded to conclude that weight had the opposite effect on speed than he had theorized. I suggested that he try the experiment again just to be sure. This time, the cars took the same amount of time.

He was thoroughly confused. So was I, but for different reasons. How was I supposed to explain to him all the possible reasons for his results without delving into the intricacies of physics and engineering?

It was a ridiculous thing to expect an eight year-old to figure out, but it would have been fair to have asked of a high schooler. Science is clean that way. You can set up experiments and controls, you can meticulously account for variables, and you can repeat and replicate your experiments to build confidence in your results.

This is not the case with people.

It has become en vogue in the business world to frame knowledge work around experiments and learning. This is the essence of the Lean Startup idea, but it’s not limited to lean. I’ve been as guilty of this as anyone, and I’ve been doing it for a long time now.

But what exactly does it mean to frame people-work this way? Unlike science, you do not have laboratory conditions where you can set up replicable experiments with controls. Sure, you can come up with hypotheses, but your conditions are constantly changing, and there’s usually no way to set up a control in real-life.

How can you fairly draw any conclusions from your results? What are you even measuring? The realm of trying to assess “impact” or “effectiveness” or (to get very meta about it) “learning” tends to devolve into a magical kingdom of hand-waving.

The reality is that experimentation without some level of discipline and intentionality is just throwing spaghetti against the wall. The worse reality is that — even with all the discipline in the world — you may not be able to draw any reasonable, useful conclusions from your experiments. If your ultimate goal is learning, you need more than discipline and intentionality. You need humility.

In The Signal and the Noise, data analysis wunderkind Nate Silver points out how bad humans tend to be at forecasting anything reasonably complex — be it political elections or the economy. There are way too many variables, and we have way too many cognitive biases. However, we are remarkably good at predicting certain things — the weather, for example. Why can we predict the weather with a high degree of certainty but not things like the economy?

There are lots of reasons, but one of the simplest is accountability. Simply put, meteorologists are held accountable for their predictions, economists are not. Meteorologists are incentivized to improve their forecasts, whereas economists generally are not.

What does this mean for groups that are working on anything complex and are trying to learn?

First, be intentional, but hold it lightly. Know what it is you’re trying to learn or understand, and be open to something else happening entirely. Measure something. Be thoughtful about what you measure and why.

Second, be accountable. Track your learning progress. Review and build on previous results. Be transparent about how you’re doing. Don’t use “experiments” as a proxy for doing whatever you want regardless of outcome.

Third, be humble. Despite your best efforts, you may not be able to conclude anything from your experiments. Or, you might draw “convincing” conclusions you might validate again and again, only to discover that you are totally, entirely wrong.

See also parts two, “Documenting Is Not Learning,” and three, “The Key to Effective Learning? Soap Bubbles!”

Organizational Development as Product Design

Startup Habits Workshop at Code for America

I got my start in the tech industry. Even though that was a lifetime ago, I’ve carried over many lessons from that experience, and I like to keep one foot in that door. One lens I still carry with me is that of product design.

I’m currently embarking on an experiment with Dharmishta Rood, who runs the incubator at Code for America. The gist of the experiment is this: Changing organizational habits is hard. Starting new habits is easy. If you want to build a high-performance, collaborative organization, the best thing you can do is instill good habits right from the start. Incubators are in a great position to do just that.

Code for America is trying to help local government truly live up to its promise of for the people, by the people. Its central activity is a fellowship program that connects designers and developers with local governments for a year. Think Teach for America for geeks. On the surface, these fellows design innovative applications for local government. On a deeper level, these fellows help change the culture of local government. It’s an amazing organization, and I’ve been a proud supporter for many years now.

Sometimes, fellows want to continue working on their apps beyond the fellowship. Last year, Code for America started an incubator program to help their fellows do just that. One of the many things that Dharmishta does is find mentors and trainings to improve her startups’ chances at success. One of the services she wanted to provide for her current class — a great new startup called PostCode — was help with getting better at collaboration.

I’m looking for ways to scale collaborative literacy. Helping an incubator instill great collaborative habits with civic startups seemed like a wonderful opportunity to do exactly that. The twist was that I didn’t want to do the work. I know how to do that already, and I know that I’m not scalable. Instead, I wanted to see if I could create a toolkit that Dharmishta could implement on her own with some behind-the-scenes coaching on my part. Dharmishta and PostCode both graciously agreed to try this experiment with me.

This is essentially a product design challenge, and it’s been incredibly humbling. We whipped together a prototype in just a few weeks, but I based it on years of experience, and I thought it would be great. It’s been solid so far, but not great. Watching Dharmishta and PostCode work through the toolkit behind-the-scenes has been an exercise in frustration — not with them, but with my own work. It’s uncovered all sorts of flaws and faulty assumptions, and because I’m not the one implementing it, I can’t make adjustments on the fly, which I do regularly in my own practice. It’s providing value, but it’s not living up to my expectations.

Which is exactly the point. Unless you’re incredibly lucky, you’re not going to get it right on the first try. Good product design is about getting your best first guess out there as quickly as possible and learning as quickly as possible based on real world usage. You take your lumps early so that you have a better chance of getting to the right answer quickly (and cheaply).

I wrote in an earlier post:

In order to design an effective tool, [product designers] use powerful methods for understanding how their customers think and feel and for measuring the impact of their interventions. Most process designers would do well to learn the tools of product design.

Most process designers I know have a very limited toolkit. They are typically over-dependent on meetings to accomplish their goals. (The exception to this are folks I know in tech startups, who tend to have more of a — you guessed it — product mindset when developing their own organizations.)

The bigger problem is that most process designers do not spend enough time up-front thinking about how to measure success. This ends up being fine, because most don’t bother to assess their work afterward anyway, outside of a casual, gut-feel conversation with a very narrow set of people.

I can say all of these things without judgement, because I have been guilty of all of these things. Doing these things well requires a tremendous amount of discipline, practice, and boldness. Frankly, I don’t know many product designers who do all these things well either. But on average, I find that product designers have a very different mindset than process designers.

What exactly is this mindset? That you don’t know all the answers. That underneath your considerable experience lies a foundation of faulty assumptions. That the way to learn is to move forward constantly, but thoughtfully, to iterate rapidly, to assess obsessively, and to assume that you will fail many times before you succeed.

This is the approach that I’ve been taking with the “product” that Code for America and PostCode has been using. They are both tremendously busy, but they have been great about playing with the toolkit. PostCode is a company full of product designers, and that mindset is strongly engrained in Code for America’s culture as well. (Code for America is an ardent evangelist and practitioner of the Lean approach, whose chief evangelist, Eric Ries, serves on its board.) They understand the spirit of what I’m trying to do, which has helped me a lot in doing this experiment.

This shared understanding has also helped me explain some principles of organizational development with them. PostCode is grappling with the typical startup challenges — lots of opportunities, but also lots of uncertainty, the need to focus in light of this uncertainty, and the challenges of norming as a team in the midst of the thousands of other things they need to be doing. They need to go fast, but they also recognize the importance of slowing down.

We were discussing the challenges of deciding on decision-making processes, and I latched onto something very wise that one of them said: Sometimes, things will actually work themselves out if you just let them play out. You want to be thoughtful and reflective, but you can’t let that paralyze you. The value of actually trying something, then stopping to reflect, is that now you’re basing your decisions on real data rather than on a bunch of competing, subjective, abstract notions. That’s a product designer’s mindset, and organizational development practitioners would do well to adopt it.

The trick is finding the balance between doing the work and taking a step back, doing the work and taking a step back. That’s what I’m trying to help them do. It’s an incredibly hard balance to learn how to strike. Clients have been hiring me to help them with this for years, yet I found it extremely difficult to do myself when starting up my own company a few years ago. I continue to improve, but I’m still in that cycle of trying and learning.