My four insights on adapting software delivery to scale up
I had a conversation about product development recently, and it really got me thinking. I was asked something along the lines of “If you were the head of development and got a significantly increased budget with the objective to scale up, what would you do?”
Author: Markus Eliasson, consultant at factor10.
The person asking me this is well acquainted with business and product development but has limited insight into architecture and code. It is obviously a very hypothetical and open-ended question, with many ifs and buts. But I quickly jotted down some of my initial thoughts – my gut feeling – on a piece of paper.
When revisiting these notes after about a week, I noticed a pattern: I would avoid foreseeing the future and improve what I have.
I have distilled my thoughts into four insights about what I would do or avoid doing. They are not ordered, not binary and there is certainly some overlap between them.
Follow the money
If some part of your system needs to shift technology to prepare for growth, such as going from on-prem to cloud, it might be tempting to start with a safe-to-fail, peripheral part of the system. I think it is important to do the exact opposite.
Start with a part of the system that will generate revenue as quickly as possible. Why? A technology shift is a liability until it’s self-sustaining, and spending effort on a peripheral part is neither technically representative nor interesting enough for your stakeholders to care about.
Do not make a rewrite
When you have an existing stack it is very easy to fall into the misconception that it’s all bad and if you only could write from scratch with all the knowledge you have now, everything would be perfect. This is a fallacy! You will most likely make new bad assumptions and it will cost you a lot of money. And more importantly: it will take a lot of time.
The reasons for failure are frequently:
- What you are trying to achieve is a moving target.
- The thing you are replacing is making money, and so it will always be prioritized.
- A rewrite is often a pendulum movement, giving you a whole new set of problems you did not foresee.
Resist headcount increase
When cash is coming in, there’s often an urge (by management) to hire more people. For many, more people equals more activity which equals a higher value. This however is not true. Adding too many people will slow you down, and while you might produce more activity and features, those things are not necessarily valuable.
Find your current bottleneck
The best thing you can do is to solve the current problem that hinders change and value, and not to try to tell the future*. I am not necessarily referring to a technical bottleneck but rather a bottleneck in your business that can be solved with technology. According to Theory Of Constraints, any work that does not resolve your current bottleneck is a potential waste of effort.
* In the remake of the TV-show Shogun they use the Japanese saying 明日は明日の風が吹く. Which was translated to “Tomorrow’s winds will blow tomorrow”, which has become my new favourite saying.