The Maersk Triple-E Class container ship is 1,800 feet long and carries more than 18,000 containers over 11,000 miles between Europe and Asia, and... The whole crew can fit in the passenger van.
Greg Kogan, a former naval architect and now a startups marketing consultant, found that the same principle that allows a 13-man crew to successfully move the world's largest container truck to a port across the globe is also applicable to startups. Especially 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 manage, and easy to understand. This makes it easier to repair them, which means they have less downtime. In this case, by "idle time" we mean the time it takes to correct the break and continue moving thousands of miles from the shore.
Take, for example, the ship control system. The steering wheel pushes the metal rods left or right. These rods are moved by hydraulic pressure. The pressure is controlled by the hydraulic pump. The pump is controlled by an electronic signal from the wheelhouse. This signal is controlled by an autopilot. The ship's crew will not need the help of a missile engineer or naval architect to find the cause of the crash and solve any problem:
- if the autopilot fails, drive the ship from the hull manually;
- If the electronic signals don't work, head to the wheelhouse to manually control the pump by talking to the bridge through a simple audio phone.
- If the hydraulic fails, use a mechanical emergency steering wheel;
- If it doesn't work, hook the chain on both sides of the steering wheel and pull it in the right direction!
Startups, like ships, should not stop because of 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 already exists on modern ships, it affects only the time required to perform tasks and the attention required to monitor all systems. The engines and auxiliary systems are easier than ever, thanks to modern diesel and electric engines that have replaced overloaded steam units.
Why Simplicity Reduces Downtime
1. Skills save time
If the person in charge of the system leaves, falls overboard, goes under the bus (see the bus factor) or goes into a new project, another person can replace it without special training or training. In this case, more people can be involved in troubleshooting and problem resolution.
For example, a dashboard created by Tableau is likely to require a higher level of expertise than a dashboard created with a set of custom scripts and APIs. No one should distract data analyst experts or product developers from their direct work to correct the histogram.
2. Troubleshooting takes less time
In a system where the behavior of each component and its relationship to others is easy to understand, troubleshoot, and troubleshoot the faulty component (root cause of failure) intuitively.
For example, if your company's website has many downloads and the same form is responsible for downloading them, it would be easier to fix the problem, since you would have to look in one place (in the code of this form). But if there is a custom form for each document, it is much more difficult to do so.
3. More alternative solutions
When each part of the system has a clear function, it is easier to replace it with an alternative.
For example, imagine a Salesforce that uses automation and third-party tools to evaluate, filter, classify, and assign new potential customers. If it stops arranging us or everything breaks down, it will not be possible to offer a substitute. 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 notification of each new sales leader along with the appropriate details. This allows them to decide whether to follow this trend or not. If the Salesforce notification process fails, it is easy to think of hundreds of other ways to pass this information to the sales department: reports, export a list of goods, manually collect data, or use Zapier to send an alert in almost any way. In this case, the idle time will not exceed a few minutes.
History of one startup
One of my clients used the outdated Enterprise Marketing Automation (Marketo) platform with 629 automated processes that have been built up over the years. When something was broken or needed to be set up, there was only one person among the 150+ employees who could do it. It took a few days or even weeks to fix each problem. During the technical work period, marketing campaigns were inserted with a stake. And with each patch, the whole system became more complex.
When this man left the company, there was no one who could manage the system. A new problem could emerge every week. But it took more than a week to find and fix it.
To keep things from getting bogged down, I rushed to move the company from Marketo to HubSpot, a simpler platform that makes it easier to work and troubleshoot.
Migration took only one week. However, another complex system, Salesforce, appeared on this path. It had 10 automated processes with more than 100 related operations and all depended on different automated Marketo processes. It took us two weeks (twice the time it took to migrate) to understand and integrate these processes with the new marketing platform.
In general, these two complex systems (Marketo and Salesforce) resulted in six weeks of downtime for Marketing and three weeks of downtime for Sales. And that doesn't include the weeks of downtime they've been experiencing over the last few years, and the many weeks of downtime they'd be experiencing in the future if we hadn't built up a new automated system.
The new system had 97% fewer processes (20 vs. 629), but still provided the same capabilities. And the error, discovered a few days later, was fixed in four minutes.
This experience made me wonder what principles startups can use to avoid errors related to complexity of systems.
How to Work with Simple Systems
Keeping such 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 additional time and resources to carry out major repairs at each break.
I suggest three principles to follow 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 on a corporate marketing platform like 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 long to explain or understand an idea, it will be difficult to implement it, and when something inevitably breaks down to fix it will take even more time. For example, a sales process that requires an hour-long explanation would be a nightmare to support and support, no matter how thoughtful it may seem.
- Try to make modifications, not to produce add-ins. When new requirements arise, there is a tendency to add layers to the existing system through crutches or integrations. Instead, consider changing the kernel of the system to meet the new requirements. A kernel change can result in (planned and one-time) downtime, as in my example Marketo-HubSpot migration, but can result in (unplanned) downtime in the long run.