The Future is Small
Posted on: Mar 06, 2018 by Allan Kelly
I was interested to read the Digital Business Continuum white paper recently published by the Atos Scientific Community. In my view, a key topic in this whitepaper is about learning to think small and optimizing for small. Short feedback cycles, constant small adaptations, a multitude of local autonomous decisions, small safe to fail experiments, and more. Each one small act allows for learning and knowledge generation.In all sorts of ways digital business exhibits diseconomies of scale rather than economies of scale1 . In part that is because learning is more effective when done in the small. And part of that is because modern technology allows exploitation of small.
Ever since Jack Kilby created the first semi-conductor transistor in 1958 the integrated circuit industry has been on a quest for small: shrinking transistor size.
As transistor size has fallen the number of transistors in use has increased. The iPhone 7 contains over three billion transistors alone. Small begets many.
Faster CPU clock times make for more instructions per second. The small but many challenge is increasingly seen in software development and the digital businesses built with that software.
Anyone who has written software as part of a team will have experienced small tight teams which out-perform larger teams. A team of five is likely to be more productive per person than a team of 15 which in turn will be more productive per person than a team of 50.
Likewise, a change to a 5,000 line system is far easier and faster than a change to a 50,000 line programme, and any change in a 500,000 line system is a serious challenge.
Shorter feedback cycles create more change, enhance reactivity and generate more improvement opportunities. A 1% performance improvement might not sound much but when 1% improvement is achieved every week the compound effects are game changing. The size of the improvement is less important than the frequency.
Shorter product lifecycles present challenges and might initially appear expensive and disruptive. Yet at the same time, enhancing existing products to serve customers better reduces risk, creates more resell and upgrade opportunities while simultaneously locking out competitors who lack the same capabilities and customer base.
There may be an inflection point, typically where a new product moves from development to production. At this point diseconomies cease to apply and economies of scale apply.
Thinking small can be difficult enough for those who have built a career on exploiting economies of scale but the challenge is greater: not just to think small but to optimize for small. Processes, practices and organizations need to be rethought for lots of smaller rather than occasional large.
When teams work on small initiatives the start-up costs of assembling a temporary project team are unsustainable. Better to have standing teams and flow the work to the team.
Funding models too need to optimize for small. Rather than handing out large sums of money in return for a well-researched (and time consuming) business case funding models need embrace small and many too. Like a Silicon Valley VC many small investments and successive funding rounds may be a better model.
The Continuous Delivery/DevOps community has already demonstrated how lots of small reduces risk because each initiative (release) is a standalone entity. Eliminating Too-Big-To-Fail projects is the first step towards Safe-To-Fail.
Big still has a place but one also needs to be able to spot when big is right and when small is best. Once big visions and overarching goals are set those doing the work need the autonomy to make a myriad of small decisions.
Again small begets many: in devolving work to members of self-organizing teams every team member becomes a mini-manager. Each mini-manager requires information and management skills to partake in the many small decisions which replace occasional big decisions.
In the knowledge economy diseconomies of scale may well be a better guide than industrial economies of scale. The trick is to know which applies and when.
1. For a longer discussion of diseconomies of scale see Continuous Development eBook https://leanpub.com/cdigital/