The Inspiration of Ownership

On the bus home from work, I was listening to this week’s On the Media. In particular, I was struck by a great interview with the man who designed the field-organizer and volunteer training programs for Barack Obama’s campaign: Marshall Ganz. If you’re at all interested in the political angle, I’d suggest you listen. If you’re at all interested in how I’m planning to apply this seemingly unrelated topic to the technical field of web development (et al), keep reading.

Ganz’s greatest accomplishment in this race was to empower a lower tier of volunteers to an extent that simply hadn’t been accomplished in previous elections. By exposing a breadth of information and actionable intelligence that went beyond what campaigns in the past had been able or willing to share, his team was able to create a wide-reaching group of volunteer leadership that came to believe that Obama’s campaign was their campaign too. This self-identification enabled Obama’s volunteer staff to develop individual personal narratives that were far more compelling than anything the campaign could have come up with on it’s own. Information lead to a feeling of ownership, which lead to acceptance of greater responsibility, and exhibition of greater creativity.

The thing is, this isn’t at all limited to the political sphere: software projects work exactly the same way. In particular, and regardless of the relative “objective” value, I’ll work harder on my features or fixes than I will on yours.

Fostering Ownership

Especially in a large company working on large projects with many layers of indirection, the importance of a particular bug or task to a project’s leadership is almost guaranteed to diverge in some (hopefully small) way from the dreams and desires of the team actually implementing the changes. Personal buy-in is simply hard to come by when tasks are handed down from on high, but that personal involvement is absolutely critical to a project’s success. What to do?

I have a few suggestions from my perspective, primarily as an implementor looking upwards:

Influence

Reduce the distance between decision and implementation. The more layers a task has to go through to reach it’s eventual executor, the less likely that it has any potential to inspire. Flattening the decision structure such that the implementing team feels like it has a hand in the project’s direction is one way to increase personal involvement, and to make the team feel that the project is somehow, for each of them, individually “mine”.

Moreover, bringing the decisions about priorities, and the rationale for the decisions, out from shadowy backrooms and into the harsh light of (probable) criticism is the single best way to make sure that the project is going in the right direction. If the product vision can’t stand up solidly in front of the team that’s meant to implement it, it’s not going to go anywhere in the market, even if it’s perfect in every way. The development team has to believe in what they’re building; they have to be in on decisions that they feel they are making.

Information

Share information, even if you don’t think it’s relevant. You’d probably be surprised to learn exactly what your development team actually cares about. Good (and bad) feedback from users or new data from Comscore isn’t something that you should talk about once a quarter in planning meetings, but could instead be a source of inspiration and innovation for the entire team, every day.

Campaign volunteers are closer to the voters than the campaign leadership, and look at the raw voter data differently. Unforeseeable (or simply unseen) trends might be easily explainable with the application of their local expertise. Likewise, engineers and web developers work right at the heart of a site or application. Flood them with up-to-the-minute information you consider relevant and irrelevant. They will draw connections you couldn’t anticipate, and fill gaps you didn’t see, and that creates visible success that inspires.

Innovation

Allow room for surprise and innovation. The products and applications that the development team builds are pure thought-stuff, forged and hammered through will alone. This has a few impacts on the project’s process, the most important of which is that the solution to a problem can almost never be specified at the same time the problem itself is confronted and documented, because the statement of the problem is never complete enough to illuminate a complete solution. Experimentation and innovation, and the feeling that both are allowed and encouraged are critical.

Obama probably didn’t tell each of his volunteers individually how they should campaign in their communities. He and his staff trusted in their ability to assess the general problem of increasing voter turnout, and turned them loose. In the same way, the development team shouldn’t be given detailed technical descriptions of solutions to implement, but instead detailed technical and nontechnical descriptions of problems to solve.

The code written must be based on their expertise, their choices, and their understanding of that problem. This personal involvement in the problem solving inspires a sense of ownership that can’t be created by mandate. If the final solution that’s written doesn’t address the issue at hand in a way that’s somehow surprising or innovative, then the development team is bored, uninspired, and uninvolved.

In a nutshell…

If you make me believe that a product, or a feature, or a fix is mine by giving me influence, information, and room to innovate, I’ll move mountains to accomplish more than you expect. If, however, my paycheck alone is supposed to inspire me to greatness on your project, then I’ll slowly stumble over every molehill on the path to mediocrity.