Photo by Cayetano Gil on Unsplash
Between the 1600s and the late 1800s, thousands of people set off from the edge of the new American civilisation and headed West.
Driven by vision, stubborn determination or maybe just a pinch of peer pressure, they travelled across uncharted territory, forging new paths, discovering new places and dying in new and interesting ways.
Pioneers
These pioneers were excited by the journey, the experience of discovery and exploration, and the thrill of not knowing where they would end up.
Pioneers are often called crazy (or eccentric if they’re crazy AND rich), meandering towards an imagined future with no regard for conventional wisdom. But without pioneers we’d all still be living in caves, if we were living at all.
Pioneers love the new, the unbeaten track, figuring out what works and what doesn’t.
Of course many pioneers weren’t successful, going beyond their means or travelling too far away from food and other resources. Sometimes they took a wrong turn and ended up chewed to bits by a newly discovered animal, in a swamp or falling off a waterfall.
Settlers
Over time, some people followed behind the pioneers and then stopped, understanding the importance of setting up stopping points and base camps along the new route to make future pioneering endeavours easier and safer.
These settlers knew how to build trust and rally teams to fund and build houses, shops, saloons and sheriff’s offices/jails. They knew how to find order in the Wild West chaos and harness it into functioning settlements.
Settlers widened and tidied the roads beaten by the pioneers, they built around them, strengthening the connection back to established civilisation, making it easier for less laissez-faire travellers to follow in the pioneers’ footsteps.
The result was a series of trading posts forming a lucrative commercial backbone across the country.
Town Planners
Over time, the settlements evolved, they were refined and grew in size and importance.
Some settlements grew so large they couldn’t be thought about in terms of individual houses or shops, and instead needed to be reasoned about at a higher level, in terms of zones (residential, commercial, industrial – all recognisable if you’ve played a SimCity game) and how those zones fit together, what their needs are (water, power, food, etc).
As settlements grew, the need to connect people with their places of work becomes an issue. Town planners designed and built road networks, railways, water systems and electricity grids. Vast, shared infrastructure for anyone to use and support a myriad of new emerging technologies like telephones and TVs.
These utilities needed to be robust, so town planners focused on maximising quality while reducing variability (e.g. standardisation of domestic supply voltage or water mains pipe diameter, railway gauge or road signage) leading to reliable, commodity services.
It is only through these commodity, interoperable and scalable utilities that we enabled the vast megacities seen around the world.
How does any of this relate to software?
Well, software companies are like the wild west.
Pioneers are generally the less-institutionalised developers; those people with perhaps less organisational baggage or entrenched muscle memory. Younger and junior developers are great pioneers because their expectations are not yet set and everything is relatively new anyway – although some people can thrive in this mindset their entire careers.
Pioneers are great at doing ‘spikes’ – time-boxed, experimental and innovative work yielding brand new concepts and creative solutions. Spikes use ‘stubs’ (placeholders) for other systems and are expected to be thrown away once lessons are learned so code quality and best practices are thrown to the wind allowing for raw progress to be made – trial and error is the typical methodology.
Pioneers thrive in teams of like-minded people, their vibe is typically fun and casual, with collaborative practices like mob programming being popular.
Settlers are those people who find it rewarding to take a proof-of-concept or minimally-viable products (MVP) and cultivate it into a product. Settlers enjoy, and are good at, building out concepts into production-ready features that meet the functional needs of their customers.
Settler-minded folks apply structure, modularise code making it more maintainable, they standardise interfaces and document how things work.
Settlers see their work as a craft. They thrive in environments where quality is a stated goal and measured accordingly. Their vibe is attention to detail and they feel deeply responsible for what they build.
Town planners are those people who obsess over the non-functional requirements – quality, performance, scalability, reliability, etc. They strive to reduce risk and reduce variation, increase standardisation, eliminate single points of failure and build solid foundational technologies, on top of which new technologies can be born.
If you’re running any mission-critical infrastructure or systems internally then the teams operating those need to think like the electricity board – accepting nothing less than 100% uptime and continually refining strict, extremely-high-quality practices and processes to ensure maximum service delivery at all times (or as close as possible).
Any critical software components (e.g. encryption libraries, remoting contracts, profile descriptors, monitoring and alerting integrations, cache and persistence repositories, etc) should also be maintained by people with this mindset.
Town planners thrive in an environment where they can protect the ‘steady state‘ of a system. That is, prevent fiddling and non-essential change – if it ain’t broke, don’t fix it! They crave information about their system and obsessively monitor it.
As an Architect it would be easy for me to say this is all the job of the Architect but I’ve had the fortune to work with enough people in this industry to know Town Planner thinking doesn’t just come from hard-earned experience. I’ve seen people fresh out of university, and even earlier, who naturally seek to build robust, reliable technology and aren’t distracted by the new shiny things.
When to Build, Buy or Partner?
One of the most challenging questions faced by IT decision makers is whether to build, buy-in or form a strategic partnership when a new business capability is needed. There are several tools and techniques out there to help make the decision.
Cloud Architecture guru, Gregor Hophe (of Enterprise Integration Patterns fame) proposes the following heuristic (with caveats):
If the functionality will differentiate our business, we should build it.
Gregor Hohpe, Build vs. Buy
But if it doesn’t, we should buy it.
What has this got to do with Pioneers and electricity companies?
The answer is everything.
Problem-Personality Fit
Electricity companies can’t differentiate their core offering (power) – it’s a commodity and standardised. Commodities can’t differentiate your business, so you should (almost) always buy them in. (Don’t try and build your own power plant unless you’re a power company!)
What can differentiate your business is innovative and creative ideas: the domain of the pioneer, but only if they are productionised: the domain of the settler.
All of this article has really been a retelling of Simon Wardley‘s game-changing work on mapping. He identifies that different types of work require different types of people:
While we should be outsourcing as much of the stuff on the right as we can, that’s not always possible in the short or medium term, so while we have commodity systems in our organisations, such as servers and data centres and mainframes (enterprise businesses are particularly burdened with such things) it’s absolutely essential to the success of your business that you don’t have pioneers looking after them!
The Commoditisation Scale
Everything eventually becomes a commodity. Once upon a time online banking was the preserve of the most radical and forward-thinking banks. Now you’d be laughed out of the market if you didn’t offer online banking.
The UK’s Government Communication Headquarters (GCHQ) calls this the Commoditization (sic) Scale:
Simon Wardley defines this as a map (of course) called the Evolution Curve:
As an architect, I feel obliged to chuck another visual into the mix, the Commoditisation Hierarchy, showing the dependencies between technologies at different stages of their evolution:
The reason I felt the need to do this was not ego but to make a very important point: especially in today’s world, you need to understand the supply chain.
Supply chain attacks are some of the most terrifying ways businesses can have their security breached. But that’s been blogged to death.
My point is that knowing the supply chain gives you the ability to measure the value of a business (or sector). Consider the explosion of neobanks and fintechs – challenger banks, financial aggregators and novel payment systems. They all seem like the next billion-dollar unicorns, but beware…
Many of these businesses are merely thin, shiny veneers over incumbent, decades-old technologies. The only differentiating feature is their website’s stylesheets (created by pioneers!).
But not all of them.
It’s the ones with the weird and wonderful features that deserve your time. Blockchain is now headed into Commodity territory, NFTs are migrating from custom-built into products – worth a punt, especially if they’re building novel and unique features around them. But you’ll need to diverisfy because nobody truly knows how a market will respond to each innovation.
Get it right though, and those folks riding the innovation Oregon Trail could easily be building the foundations of the next Redmond.
