Survival of the fittest in a transparent business world often translates to speed; and the ability to move faster than the competition. Whether your organization sprints in intervals, or keeps a steady pace, the one who, over time, proves to be the most agile and fastest moving wins.
At Northern.tech we aim at keeping a steady pace, like a drum beat. Besides the fact that this mode leads to more predictability and increased peace of mind and harmony for involved parties, this seems a natural choice.
Although organizations are an artificial construction, they can be thought of as a living organism. Like living organisms, organizations go through the lifecycle from inception to eventual end. Learning from biology, organisms evolve and experience gradual change. The same principle, I think, should apply to organizations. Instead of revolutionary changes, big hairy projects, and one-off initiatives, steady continuous pace of operations will prevail, the same way your body steadily and gradually change.
At Northern.tech we seek evolution and continuous operations, not revolution and sporadic operations. One analogy we often use is that we are in the business of building 747s (designed for repeatable take-offs and landings), and not one-off rockets (yes, Mr Musk is about to destroy this beautiful analogy). Changing small and frequently constitute the core of this principle.
Small frequent, not infrequent and large changes
Small changes translate to speed, meaning you will get from one state to another quickly. Frequent changes mean faster feedback loop to improve on the change to the benefit of the receiver. Infrequent and larger changes lead to the opposite; slower speed and longer time to improve.
Who has ever heard of successful large IT-projects where everything comes together at one magical point in time? Not many, and the idea of frequent and small changes is not rocket-science, but the ability to work in this modus seems to be.
At Northern.tech, we work to avoid infrequent and large changes. For product development, the analogy we use, is that if we are going to build a large luxury car, let’s first scope and finish a skateboard. It is usable, but far from the car we envision. It is ok to even be ashamed of its state. It will soon improve. After the skateboard, we take aim at a soapbox car, and so it goes until we end up with a luxury car that is based on numerous user feedback loops.
Our approach often goes under the name of Minimum Viable Product or Minimum Loveable Product. However, we don’t stop at product development. In everything we do, from product development, to finance, sales and support, we seek to apply the same principle. Everyone, everywhere in the organization shall operate like a living organism and be in continuous change.
Continuous finance
As an example of continuity, let’s have a look at how we do finance.
Instead of once a year spending brutal amounts of time to create an annual expense budget, we evaluate new initiatives (costs and potential ROI) continuously. Whenever we decide to accrue a new cost, it’s added to a 24 month rolling financial forecast. Every employee has access to the financial forecast (12 and 20 months), and buckets of data like details about all online services we use and their monthly cost and trend, accumulated cash balance, monthly breakdown of expense cost types, total employee expenses, collections, etc.
By sharing all the financial numbers, people will be more mindful about their own spending as they can easily compare, and make their own cost/benefit analysis. I also think live financial transparency leads to greater sense of belonging and empowerment. It helps employee see a bigger picture which ease making tough (financial) decisions.
Traditional financial methodology can lead to straitjacket situations. In many organizations the goal is to spend the budget to avoid reduction the next budget year. “Spend the budget, or lose it”. This zero sum game attitude, where budget owners are either winners or losers clearly is not in the best interest of the company. Moving towards continuous finance and evaluation might help out in this case.
Continuous software release
Another example of continuous operation I have to mentioned since we are in the software business, relates to software releasing.
Everyone shares the same goal: Minimize the time it takes from an idea, product feature or new process improvement pops up in the head of the product/process owner to when the customer can benefit from it. How fast can we release a new improved version based on market feedback enough times for all parties to be satisfied?
At Northern.tech we work to improve continuous integration systems, increase and automate tests and release checklists. With our upcoming hosted product, we are going from an on-premise software vendor to a 24-7 service provider. Our goal is to continuously update the backend system. We want to get to a stage where we can make a new release from a developer’s desktop (aka always have a continuously release-ready master branch)
Hopefully the continuous finance and continuous software release examples help understand what we mean by continuous operations. Most people can probably sympathize with the main message in this post, but the bigger problem lies in how to line up the ducks in such row that you can operate in a continuous manner. Next follows some key ingredients I believe need to be in place for continuous operations to have a chance.
How to make continuous work - 5 enablers
How can an organization achieve a continuous way of working where changes are small and frequent, where changes are embraced? Below follows top 5 germane enablers the way I see it.
1. Decentralized (local) decision making
Frequent changes, means several changes. Consequently, this means the decision-making for the majority of changes needs to be local and decentralized. If changes have to be approved and filtered through layers of people, or always initiate at some sort of manager level, the desired frequency cannot be achieved.
Continuing on the living organism analogy, similar to cells changing throughout your body, agile organizations see change everywhere in the organization, not only “higher up”.
In an hierarchical structure the size of change grows upwards. The higher up the more infrequent and larger the changes. This is the opposite of small and infrequent changes championed in this post. For this to be practically possible, most changes needs to be decentralized.
2. Small batches
Regardless of the nature of the change, make it is small. If it is big, then break it up in smaller parts. If it is big and it can’t be broken up, go back to the planning board and refine and research the change. This applies organizations all sizes. Even large incumbents who want to improve must start small.
The best, like olympic champions, work continuously to improve. They break their plan up in small consumable pieces. One should apply this to the business desire for change.
3. Utmost transparency
Whether a change is good or bad, doesn’t matter that much. What matters is that there is a change, and others see it. A bad change means fast failure detection and recovery. If the change is good, a good state to work out from has been established. Transparency ensures more eyes on the change and more can help decide (or detect) a change being positive or not.
Avoid operating in the darkness. The longer one waits for stakeholder feedback the more risky the change will be and the deeper the hole to crawl up might get.
4. High level of trust
Making change is scary. Status quo is safe. No change equals no risk of doing wrong. People who operate in safe and trusted environments prove more willing to take risk, because they know there won’t be unfair repercussions. They trust change is good and safe. For this to be true management should explicitly express this attitude in words and actions.
In addition peers need to live this out and encourage change everywhere, regardless of outcome. Employees who trust the system and their peers that change is good, more likely initiate change.
5. Live metrics system
The main reason for change should be to improve. Therefore it is important to have access to relevant metrics to measure the before/after effect. The only way to know whether a change was good or not lies in comparison. The smaller and well-defined the change, the easier it will be to measure. At Northern.tech one doesn’t need to set a % goal improvement, or other metrics to justify a change. As long as it will improve something, just do it!