Simple systems have less downtime


The 400-meter Triple-E class Maersk container ship transports 18,000 containers over 11,000 nautical miles between Europe and Asia, and its entire crew can easily fit in a Moscow minibus

As a former naval architect, and now startup marketing consultant, I can confidently tell you: if a team of thirteen people is able to drive the largest container ship on the planet across half the world without breakdowns, then there are no impossible tasks at all for a small startup.

Simple systems have less downtime.

The systems on ships are as simple as possible. Painfully clear interfaces. Everything is duplicated many times. If the system is easy to understand and easy to operate, it will be easy to repair, which reduces downtime. This is a very important quality for a ship, where downtime can mean an accident a thousand kilometers from the nearest help.

For example, a control system. Metal rods move the steering wheel left or right. The rods themselves operate under hydraulic pressure. The pressure is controlled by a hydraulic pump. The pump is electronically controlled from the wheelhouse. The signal is controlled by the autopilot. You don’t need to be a nuclear physicist or naval architect to understand the cause and find a solution to any problem:

Like ships, startups can’t afford downtime. Long downtime in sales, marketing, backend, customer support, hiring, product support will cause irreparable damage at the start when we have exponential growth every day across all metrics.

(Although many systems are automated on modern ships, this only reduces the time fulfillment actions, but not the amount of time to control these systems. Marine propulsion and auxiliary systems are simpler than ever, thanks to modern diesel and electric motors that have replaced tube steam systems.)

1. Fast learning

If the employee in charge of the system quits, falls overboard, gets hit by a bus, or leaves for another project, the colleague will take over his responsibilities without much education or training. This means more people can get involved in problem solving and troubleshooting. That is, we become

more professionals

For example, a Tableau dashboard is simpler than a dashboard with many custom scripts and APIs. Accordingly, a larger number of employees are able to solve the problem in it. Nobody will rip off highly trained analysts, data scientists, or programmers to fix a simple bar chart.

2. Fast troubleshooting

If the behavior of each component and their relationships among themselves are completely clear, then the root causes of any malfunction become intuitively clear, stupidly by the method of exclusion.

For example, if a company has many PDFs to download on its site, and they are all covered by a common form (rather than separate ones), then if the download fails, there will only be one form and one automation workflow to troubleshoot.

3. More alternative solutions

If in the system each part has a clear function, then it is easier to find alternative solutions.

For example, the Salesforce process uses a jumble of automation and third-party tools to score, filter, classify, and assign new leads (potential new customers). If the process fails, then there is no obvious replacement. Everything will stop until the process is fixed or replaced with a similarly complex solution.

Now imagine a process where the sales team simply receives a notification of each new lead, along with the relevant details, to decide whether or not to continue with that lead. If Salesforce notifications stop working, it’s easy to think of a hundred other ways to get that information back to the sales force: reports, Slack notifications, list exports, manual monitoring, or Zapier to send alerts across virtually any channel. Downtime will last a maximum of several minutes.

One client of mine has 629 processes in the legacy marketing automation platform Marketo over the years. When something broke or needed work, then among the one and a half hundred employees, everyone was looking for one and only competent guy. Each issue took days or weeks to fix, and marketing campaigns were idle. And with each patch, the system only got more complicated.

When that guy quit, there was no one to manage the system. New problems arose every week. We did not have time to eliminate them.

To avoid work stoppages, I hastened to move the company from Marketo to the simpler HubSpot platform.

The transition took only a week. However, along the way, I came across another complex system – Salesforce. There were a dozen automated processes with over a hundred combined operations, all of which depended on various finely timed automations in Marketo. It took two weeks to understand and integrate these processes into the new marketing platform – twice as long as the migration.

Overall, these two complex systems (Marketo and Salesforce) caused six weeks of downtime for the marketing department and three weeks for the sales department. To fully appreciate the damage, add many weeks of downtime over the past few years and many weeks into the future.

I implemented a new system with 20 processes instead of 629, which provided all the same capabilities. When a bug was found a few days later, it was fixed in four minutes.

This experience got me thinking about how startups work to avoid the pitfalls of complex systems.

System upgrades and migrations are expensive, even if the long-term benefits are worth it. Many startups, like ships, do not have the time and resources to overhaul.

Here are three principles that I follow when evaluating or implementing new systems:

  • Features are no excuse for complexity… What good is a fancy flight control system if it knocks out all planes? Or in an enterprise marketing platform like Marketo, if after a failure no one can carry out a marketing campaign? Choose simple tools over maximum functionality. I often recommend HubSpot as a marketing platform for startups instead of Marketo, Eloqua, or Pardot.
  • Complex ideas lead to complex realizations… If it takes a long time to explain or understand an idea, then the implementation will be difficult. And when something inevitably breaks, it takes too long to fix it. For example, if it took an hour to present a new sales process, then supporting it would be a nightmare, no matter how smart the process may seem.
  • Better to fix than add… When new requirements arise, it is tempting to add layers on top of the existing system – additional steps or integrations. Instead, see if you can change the kernel of the system to accommodate the new requirements. At first, changes can cause (planned) downtime, as in my example migration from Marketo to HubSpot, but in the long term, the (unplanned) downtime will be less.

“… The simpler a thing, the more difficult it is to ruin it, and the easier it is to fix it when it is ruined.” – Thomas Payne, “Common sense”, 1776

Of course, while traveling in a startup, everything will break down, just like on a ship crossing the globe. But if the onboard systems are simple and straightforward, then the startup will not be abandoned helplessly drifting in the middle of the ocean.

Similar Posts

Leave a Reply