Stop admiring the foundations and build something
Moving recklessly is dangerous. Moving so cautiously that the world changes before you’ve finished is dangerous too.
Header photo: Nihar Reddy Jangam / Unsplash I spend quite a lot of time working with organisations on digital things, which means I regularly encounter two competing schools of thought. The first wants to move at such speed that nobody has time to check whether the brakes work. The second is deeply concerned about foundations. Data foundations, systems foundations, process foundations, governance foundations and, if the meeting runs long enough, probably foundations foundations. The fast crowd can be terrifying. They want to launch on Thursday, despite it being Wednesday afternoon and nobody having established whether the thing is legal, secure or remotely useful. They regard testing as something customers can do for free and any suggestion of caution as the sort of negativity that kills innovation. This is clearly not an approach sensible people should copy. But the foundations crowd has developed problems of its own. The permanent building site “Build solid foundations” sounds indisputably sensible because, in normal life, foundations stop buildings falling over. Nobody wants to open a hotel and discover that the third floor has become unexpectedly acquainted with reception. If you’re dealing with decades of legacy technology, disconnected data and processes held together by spreadsheets, goodwill and one person called Alan, there is real work to do before you start adding more. The problem begins when “we need better foundations” stops being an engineering judgement and becomes an organisational hiding place. Years are spent mapping the old systems, designing the new systems, deciding how the two might speak to each other and forming a working group to agree what “speaking” means. More concrete is poured into more holes, but nobody ever gets as far as putting up a wall. Eventually, somebody declares that the foundations are nearly ready. Unfortunately, the technology they were designed to support has changed, the people who commissioned them have left and Alan retired eighteen months ago without anybody asking how his spreadsheet worked. The organisation responds in the only way it knows how: by beginning another piece of foundational work. You can’t build something solid on sand, but you can spend so long preparing the ground that the thing you intended to build is no longer needed. At the present rate of technological change, waiting two years before delivering anything visible isn’t caution. It’s a decision to solve yesterday’s problem extremely thoroughly. Photo: Daniel Sturley / Unsplash Pace doesn’t have to mean recklessness Building 42 Things To Do has made this tension much more obvious to me. We can now take an idea, test whether it’s useful, build a limited version, put it in front of people and learn from what happens at a pace that would once have required a much larger team and a considerably larger pile of money. That doesn’t remove the need for good data, proper security, sensible governance or reliable systems. It does change how long we should be prepared to discuss them before doing something. The answer isn’t to throw everything into production and hope the error messages are written politely. It’s to make the work smaller, make the safeguards proportionate and shorten the distance between thinking and learning. Build enough foundation to support the next useful piece, then build the piece. If it works, strengthen what needs strengthening and continue. If it doesn’t, you’ve discovered that before spending two years constructing an immaculate platform beneath it. This requires more discipline than either extreme likes to admit. Moving quickly doesn’t mean skipping difficult questions, while building carefully doesn’t mean every question must be answered before anybody is allowed to begin. Some decisions are genuinely hard to reverse and deserve serious scrutiny. Plenty of others can be tested safely, measured honestly and changed when the evidence tells us to change them. That distinction matters because delay has consequences too. Organisations are very good at recording the risks associated with action and considerably worse at recording the risks associated with another twelve months of workshops. Customers carry on struggling with the same service. Staff keep compensating for systems that don’t work. Meanwhile, smaller organisations learn, improve and move further ahead. I don’t think every company needs to behave like a start-up. Most established organisations have responsibilities, scale and technical baggage that 42 Things To Do simply doesn’t, and pretending otherwise would be ridiculous. But they can borrow one useful habit: foundations and delivery don’t have to happen in separate eras. Repair the bit of foundation you need. Build something modest on it. Watch what happens, learn quickly and repeat. Because if you wait until every foundation is perfect before allowing construction to begin, you may eventually look up from the hole and discover that everybody else is living in floating cities.