One of the first things that I took on in my Shuttleworth open philanthropy gig was to help the team develop a ‘theory of change‘. The aim was two-fold: create a simple compass to guide internal decisions and develop a tool to help the rest of the world understand what we’re up to. Basically, we wanted a snapshot of how our collective brain works as a team.
Well, that was 18 months ago. We’ve had at least two all staffs, a dozen small group chats and countless online conversations since. And we’ve produced many iterations, at least one of which I have blogged about here. Not surprising. That’s how strategic planning-y things often go, especially when they are intentionally open ended like this one.
What is surprising was how useful all of this conversation has been in aligning our everyday thinking. Words that we didn’t have before — words we invented for the theory of change — have become a part of everyday thinking and decision making in the office. And, things we’ve believed in for a long time, like transparency and open licensing, have actually become a more real part of our work. Which, in the end, was probably the point.
As I leave the Foundation (last day 🙁 today), I promised to do one more iteration based on recent conversations. It looks like this [big version] …
The aim was to simplify as much as possible, just showing the essence. Also, there are lots of changes to some of the core language we are using.
Also, I agreed to write up a series of notes describing each element on the theory of change with a little more detail. I’ve done this as a (pretty ugly) slide deck …
In the near future, our designer Eugene Badenhorst will soon take a shot at making the above diagram real pretty and then doing a small booklet based on the slides.
In the meantime, I highly encourage you to start adding thoughts into the mix, especially if you work closely with the Shuttleworth Foundation. Are we on the right track? If we aren’t, what’s missing? If we are, how close is our theory to our practice? Where do we need to work harder? Where are we full of it?
The idea is that this snapshot of our collective brain will continue to evolve, even after the pretty design. Getting feedback — good and bad — from people who work with us is a critical part of this. Leave comments here, or send mail to Steve Song (the new lead on this), Helen and I.
Thanks for sharing this, Mark. I think that we at ccLearn (and Creative Commons), like many others, are looking to the experience at the Shuttleworth Fdn to understand better how what we do can match what we presume to be. There are two comments I would share, both of which also emerged out of conversations at Open Everything.
1. I think it is important for both people and organizations to have the support and encouragement to take baby steps towards openness. Sometimes this means making less ideal choices in any one area of interest, at least for a while. Sometimes this means enacting “open” in one space and not another, at least to start. Many organizations (and people) are going to be uncomfortable doing all of this in a self-promotional fashion, and yet it is exactly the recognition and accolades for the opening process that is likely to motivate further change. Perhaps there is some opportunity here for a coalition that can track progress, celebrate small steps, and just engage generally in giving recognition where recognition is due?
2. The various categories in your visual, especially the methods, suggests a proposal process for orgs like Shuttleworth that make grants. If each proposal was encouraged to capitalize on one or all of the methods as a design principle for the project, couched in the ethos and goals that underlie the broader vision, it might save a lot of time in having to figure out exactly how any given proposal advances the broader cause. For example, if someone is positioned to accelerate a specific idea, regardless of exact impact and how well defined it is as a “project”, that fits nicely into one of the key methods and should be recognized as such. Conversely, a proposal that describes something compelling but ultimately only tangentially related to one or more of the key methods would be downgraded. I’m not exactly sure how all of that would need to play out, but it seems to me to be a potentially interesting (and definitely different) method for determining funding priorities.
Good luck on similar work with Mozilla!