My team and I are on the cusp of a significant new product release. Well…we are approaching a cusp and considering how to navigate it. (Looking at the definition of the word, I think we have to decide on our metaphor first). There is some considerable focus on how to handle the first release of this new way of offering our learning content. I confess to a little anxiety at times. No matter how well prepared a product development team is, user response is always unpredictable at some level or other.

Something will happen quite soon after the switch is flicked which will surprise us and from which we will need to learn quite rapidly. This is the way of software releases. There is a devil, of some size and ferocity, snuck away in one part of the detail or another. Usually it will be quite well hidden.

I struggle with articulating this as failure, however. Failure is a judgement laden word. It suggests (to my ear at least) omission and neglect. It suggests a lack of success. This, I fear, is enormously unhelpful. We are in a world of rapidly evolving tools and behaviour patterns where a confident offer of a definition of success is usually a mistake in itself. Anyone who confidently predicts what success will look like is likely to be stretching their credibility. We can describe and aim for improvement. We can plan for better outcomes and greater clarity. Success, though, will remain mercurial.

The “fail fast” mantra, or it’s success as a catchphrase, is largely attributed to the style and approach of Mark Zuckerberg and the early days of Facebook. Start ups, racing each other to economic value, would hire engineers to rapidly release and improve their tools and products. To iterate – the new panacea for the incomplete. Facebook’s buzz phrase was, in fact, “move fast and break things”. I suspect this was, at least in part, a swipe at established companies and their planning cycles and waterfall approaches. Zuckerberg had seen a new method at work and working much more quickly. He also saw that a succession of smaller bets in quicker succession (from which adjustments can relatively easily be made) is less economically risky than fewer, large ones which cost time and money to recover from. He was also smart enough not to espouse failing as an objective. Learning is the real outcome he describes.

Move fast with stable infra

As Facebook’s scale has taken the world by storm, the mantra itself has morphed. It now has a more grown up ring to it: “move fast with stable infrastructure”. This is much less pithy but unstable infrastructure will never be fast in the end.

None of this is about failure. It is about the quest for success, however, and about the definition of it as progress is made. Which gives rise to one of the words of our times: iteration. As with any over applied phrase, it has become twisted and bloated. The simple principle of adjusting and developing as a team learns is still a very useful guiding thought. It works best when a team is always applied to the management and development of a product. A good product team will study user reaction and usage, make good judgements of priority and apply development to small changes made quickly. All the time. This is not failing at all. It is learning from experience. This, in tun, is more like succeeding.

These new organising structures and teams have created a fascinating example of learning cultures and principles. Very much ‘learn as you work’ (rather than ‘stop and train’) and share your learning along the way. There are a variety of tools and services which are relied upon in this agile world. None of them are learning tools but all help teams and individuals to learn and develop. They support open sharing of status, information and problems (such as Trello). They support direct communication amongst a team/community/group (such as Slack). They record, through documentation, the principles and guides by which decisions are made (such as Jira) and the method of making whatever is being made (such as Confluence). All these artefacts are available to all participating in the work.

Not a tracking code, enterprise system or LMS in sight. These are all tools for productive working. For doing a job. They are strong learning tools because they are part of the work not separated from it in a special learning land.

Iterating can, though, be an excuse for never approaching a quality outcome seriously enough before the first release. (Hence my current anxiety). This is not really about learning though, it is more about managing expectations. The ability to improve as you go should not be an excuse for not doing things as well you can from the outset. There are other routes to a useful rehearsal space and practice arena. (A topic for another time).