It's been a bumpy ride...
At 40K, we never say that we have all the answers, but we're committed to asking the right questions, and seeking over time to build an authentically effective and working program. We are also committed to true innovation,and pushing ourselves as hard as we can to build a quality program, and take it to scale. In so doing, we've made a lot of mistakes over the years, and we're more than happy to share it publicly. We credit Engineers without Borders for the idea of publishing fails!
Failure One. Doing too much, and not doing any of it well
How we failed: When we first started 40K PLUS, we tried to do it all. That is, we tried to understand the community need, develop the content, build the technology, market & sell the program, run the program, and monitor & evaluate it. We also tried to do it all at the same time. As a result, our early pace of development was very slow, and was full of mistakes across the board.
Failure Two: Opening too many pods before we were ready
How we failed: When we first started, we were way too excited about the scale prospects of what we were doing, and were naive with our understanding of the community need. As a result, after only having a half-ready 40K PLUS program, we opened up 6 pods thinking that "anything for the community was better than nothing." How wrong we were. This put our team under enormous pressure: our field team were receiving very heated feedback from communities because we were not meeting their expectations as customers. Our research team were then required to spend a lot of time communicating with these communities, which slowed down their pace of development even further. Ultimately we made the decision to shut down 6 of our 15 40K PLUS pods. We were shattered. It meant that we had to make facilitators redundant, and turn over 120 children away from the pods.
What we learnt: Looking back at this episode, we cannot believe how irresponsible we were with opening pods before we were ready. We learnt the very obvious lesson that there has to be solid integrity in our program before we think about scaling it. As a result, we refocused our efforts on development rather than operations. We built a team we called "the Lab," who were focused on four pillars of development, and prioritised our effort firstly on content for beginners, then facilitator training and delivery. We also made a commitment that we would not become too risk-averse in the future: we should continue to push ourselves and push for scale: we just have to be responsible about it. As a result, in December 2015 we opened up 5 new pods in a new area, and have operationally handled it with ease.
Failure Three: Minimum Viable Product (MVP) Technology was not very good
What we learnt: Over time, we learnt that our role was to concentrate on the sweet spot between content, technology and delivery. That is, we chose to source content from third parties as a platform, rather than build it ourselves. We decided to contract technology developers to build the first Version of our technology system, rather than build it ourselves. And we decided to outsource critical functions of our teacher training. That meant that our role became packaging all of these elements together so that it worked in a village. This has now formed one of our core 40K PLUS principles of development: which is to hack together a solution, rather than insist on doing it all ourselves.
How we failed: Between 2012 and 2013 we learnt that technology was going to play an integral part of 40K PLUS. Our founding team, however, were not from a technology background. We did not know how to effectively select a third party developer who could build our technology system, and were not across the details of what they were building. We trusted the initial third party developer that we chose. Also, the technology at that time was a vision: not many people "got" what we were trying to do. As a result, when we got the technology code reviewed by our technology partners, Atlassian, the feedback was that it was not very good at all.
What we learnt: With Atlassian's assistance, we decided that "the plane could be fixed in the sky." That means we didn't need to take the MVP out of action- we could fix it over time. The key learning was about human resources: that if we were going to build a quality technology solution, there were certain functions that we needed to bring in-house. We made our first step into this domain, by hiring an experienced technical architect in March 2016, and we intend to bring the "building the core" in-house. Going forward, building the technology platform out to program maturity will require us to build the right team, which we have started doing.