Greg Kogan, as a former naval architect and now a marketing consultant for startups, discovered that the same principle, which allows a crew of 13 to successfully move the world’s largest container ship to the port across the globe, is also applicable to startups. Especially for those who want to achieve aggressive growth and set ambitious goals.
Simple systems have less downtime
Ships consist of simple systems that are easy to operate and easy to understand. This facilitates their repair, which means they have less downtime. In this case, by “downtime” we mean the time it takes to fix the breakdown and continue driving thousands of miles from the coast.
Take, for example, a ship control system. The steering wheel is pushed left or right by metal rods. These rods are moved by hydraulic pressure. The pressure is controlled by a hydraulic pump. The pump is controlled by an electronic signal from the wheelhouse. This signal is controlled by the autopilot. In order to find the cause of the breakdown and the solution to any problem, the ship’s team will not need the help of a rocket scientist or naval architect:
- if the autopilot fails, manually control the ship from the wheelhouse;
- if electronic signals do not work, go to the wheelhouse to manually control the pump, talking to the bridge through a simple sound phone;
- if hydraulics fail, use a mechanical emergency steering wheel;
- if this does not work, hook the chain on both sides of the steering wheel and pull in the right direction!
Startups, like ships, should not stop due to system downtime. Long downtime in sales, marketing, network, customer support, hiring, products and other systems can cause irreparable damage to the project and its growth rate.
Although automation is already available on modern ships, it only affects the time it takes to complete tasks and the attention it takes to control all systems. Engines and auxiliary systems are easier than ever thanks to modern diesel and electric propulsion systems that have replaced overloaded steam plants.
Why simplicity reduces downtime
1. Qualification saves time
If the person responsible for the system leaves, falls overboard, falls under the bus (see Bus factor) or goes into a new project, another person can replace it without special training or training. In this case, more people can do troubleshooting and problem solving.
For example, a dashboard created by a company TableauIt is likely that it will require more highly qualified specialists to service than a panel created using a set of user scripts and APIs. No one should distract data analysts or product developers from their immediate work to correct the histogram.
2. Troubleshooting takes less time
In a system where the behavior of each component and its relationship with others is easy to understand, troubleshooting and finding the faulty component (the root cause of the breakdown) is intuitive.
For example, if the company’s website has a lot of downloadable documents and the same form is responsible for downloading them, it will be easier to fix the problems, as the problem needs to be found in one place (in the code of this form). But if each document has its own custom form, it is much more difficult to do.
3. More alternatives
When each part of the system performs a clear function, it is easier to replace it with some alternative.
For example, imagine a system Salesforce, which uses automation and third-party tools to evaluate, filter, classify and assign new potential customers. If it ceases to suit us or everything breaks down, a replacement cannot be offered right away. Work will be frozen until the problem is resolved or a similar, equally complex solution is found.
Now imagine a system in which the sales department simply receives a notification of each new sales leader along with the relevant details. This allows them to decide whether to follow this trend or not. If the Salesforce notification process fails, it’s easy to think of a hundred other ways to pass this information on to your sales team: reports, exporting a list of products, manually collecting data, or using Zapier to send alerts in almost any way. In this case, the downtime will not exceed a few minutes.
The story of one startup
One of my clients used an outdated corporate marketing automation platform (Marketo) with 629 automated processes that have been built for several years. When something broke or needed to be set up, among 150+ employees there was only one person who could do it. It took several days or even weeks to fix each problem. For the period of technical work, marketing campaigns got a stake. And with every patch, the whole system became more and more complex.
When this person left the company, there was no one who could manage the system. Every week a new problem could appear. But to find and fix it, it took more than a week.
So that the situation does not come to a standstill, I hastened to transfer the company from Marketo to Hubspot, a simpler platform that is easier to work and troubleshoot.
Migration took only one week. However, another complex system arose on this path – Salesforce. It had 10 automated processes with more than 100 related operations and all of them depended on various Marketo automated processes. It took us two weeks (twice as much as it took to migrate) to understand and integrate these processes with the new marketing platform.
Altogether, these two complex systems (Marketo and Salesforce) resulted in six weeks of downtime for the marketing department and three weeks of downtime for the sales department. And this is not counting those weeks of downtime that they experienced over the past few years, and many more weeks of downtime that they would experience in the future if we had not put together a new automated system.
The new system had 97% fewer processes (20 versus 629), but at the same time provided all the same capabilities. And the error detected after a few days was fixed in four minutes.
This experience made me think about what principles startups can use to avoid errors related to the complexity of systems.
Principles of working with simple systems
Keeping rip-and-replace projects afloat is a painful and destructive process, even if the long-term benefits are worth it. Many startups, like ships, do not have the luxury of extra time and resources to carry out major repairs for each breakdown.
I propose three principles that must be followed when evaluating or implementing new systems:
- Uniqueness does not justify complexity. What good is a complex flight management system if it is based on an entire fleet of aircraft or in a corporate marketing platform such as Marketo, if no one can conduct a marketing campaign? Choose tools that are easy to use and those that offer most of the features you need.
- Complex ideas lead to complex implementations. If it takes too much time to explain or understand an idea, its implementation will be difficult and when something inevitably breaks down, it will take even more time to correct the situation. For example, a sales process that requires an hour of clarification will be a nightmare for support and maintenance, no matter how thoughtful it seems.
- Try to perform the modification, and not produce a superstructure. When new requirements emerge, there is a tendency to add layers on top of an existing system using crutch solutions or integrations. Instead, see if you can change the core of the system to meet new requirements. Changing the kernel can lead to a (planned and single) increase in downtime, as in my Marketo-HubSpot migration example, but to a decrease in (unplanned) downtime in the long run.
“… The simpler the thing, the harder it is to spoil it and the easier it is to fix it when it is corrupted.” Thomas Payne, Common Sense, 1776
There is no doubt that during the launch of a startup something will definitely break – like on a ship that goes around the globe. However, if the embedded systems are simple, then these problems will not leave a startup helplessly drifting in the middle of the ocean.