There is so much attention given to startups these days, and hard work leading to great success stories and big payoffs are compelling. But we don’t talk as much about what it takes to get there. It’s an almost never ending process of technical decisions, changes, and costs — all to be scrutinised, analysed, and made against a backdrop of not-always-managed chaos.
Of course, all of this applies to longer-established enterprises too. Hopefully in a mature organisation, there is less chaos and an ability to lean on change management processes to support business change. Yet this is not always the case. Sometimes the cost of change can be even more prohibitive.
Experience can demonstrate guidelines for technical decision making, the crucial things start-up technical leaders should focus on, and when it makes sense to opt for expensive solutions that have cheaper alternatives, and when it doesn’t. In fact, the costs of change can be discovered, discussed, and directed more easily than is often apparent in the heat of the moment.
How can tech leaders take people with them on their digital transformation journey?
What is the cost of change?
Grady Booch, one of the godfathers of modern software engineering, said that architecture represents the set of significant design decisions that shape the structure and behavior of a system, where significance is measured by cost of change. Cost of change is one of the most important ideas to grapple with as a technology leader.
The drivers of that change evolve with the growth of the business. In the early days, when trying to figure out product-market fit, the scope of change is massive. There are many well-known examples: a podcasting system called Odeo became Twitter; a gaming engine called Tiny Speck became Slack; an online RPG called Ludicorp became Flickr; an operating system for cameras became the Android OS. It should be clear that a willingness to make dramatic change is what enables a business to find the right product-market fit.
Setting in stone the way that systems function in a way that reduces the ability to change can be very expensive later on, when a shift is required. However, for the business willing to throw out code and start over, the cost of change is actually low!
So until the product-market fit is certain, a business could end up making a 90 or 180 degree pivot. For example, when the structure of a business model is locked into various microservices, it will greatly increase the cost of the kind of change likely to be needed in early stages. It’s wise to optimise for the ability to make big, sweeping fundamental shifts in business operation from the get-go. It’s wise to maintain this mind-set as the business grows so as to never fall into the same trap wearing different clothes.
Five emerging trends to drive tech innovation for the next decade — Gartner
Put off costs until you are certain they will confer value
Bear with me on this one: don’t make any decision you don’t have to, and try and put off any decision you do have to make for as long as possible. As a technology leader there are complex, interesting, and challenging decisions to make every day. Put off these decisions as long as you can. Deferring big decisions is not a way of avoiding difficult tasks — it is a core strategy to minimise costs of change.
Startup technology leaders should favour ambiguity. You can’t honestly know what business you’re in yet, whether or how you’ll have to scale, or answers to many other existential questions. So an ambiguous position requires that you:
- Avoid any decision that you could also make later.
- Use as much existing material as possible.
Most of the time, we don’t even know that we’re making a monumental design decision at the time we make it, because the alternate path hasn’t shown up yet. At the same time, correct solutions have a habit of revealing themselves if you can find a way to wait long enough. Technology gains traction, or dies.
Here’s an example: if you chose a container orchestration engine in 2016, there’s a roughly 20% chance that you would have chosen Kubernetes. That means by the beginning of 2018, almost 80% of companies were switching. Those are not great odds, so deferring can be good. However, deferring to the point of creating a crisis is not. This does require an agile mind, and a thoughtful approach, frequently revisiting the same questions.
Balancing agile and traditional processes in compliance-driven markets
Don’t fall in love with an exotic tech stack
There is no tech stack that will give you a leg-up because it’s new and different from what everybody else is using. The only thing that will give you a leg-up is something that everybody already knows how to use.
But what about “this is the best tool for the job”? That way of thinking can be a myopic view of both the words ‘best’ and ‘job.’ The job is keeping the organisation in business. The best tool will occupy the ‘least worst’ position for as many problems as possible. Pragmatism wins the day. Build things that are simple, build things that are boring, and build things that are battle-tested.
Isolate things that are specifically tied to one area of your business and make sure all of that is together. When you must make decisions about encapsulating or abstracting it, it’s all contained. Then you can define boundaries.
Make sure you define those boundaries within a simple code base. Think about this in terms of cheap vs expensive: it’s cheap to stick to those boundaries. Understand your boundaries, be clean with them and adjust them as you’re evolving. And don’t ever stop!
The cost of reshaping a function name, or its position in a code base, is extremely low relative to the cost of moving things between services. Look at things like ports and adapters or hexagonal architecture: there are very well-established patterns for defining well-isolated, well-bounded code within a single code base. Then, when you scale to the point where you realise you need to pull a piece out, you know exactly where that piece is.
Fight technical complexity as you scale. Always keep driving toward product-market fit and focus on the decisions that will enable you to pivot as quickly, as often, and as cost-effectively as necessary. If you maintain focus on your highest leverage decisions as a technical leader, you will be in the privileged position of having the time and money to later untangle your speedy but strategic early decisions. With strategy, relentless focus, and a little bit of luck, you’ll get there.
