By John Saddington (Do not publish)
I realized something fascinating the other day: I realized that, as a startup entrepreneur and founder, I’m a builder of systems.
In other words, my entire job as a founder is to build and connect interdependent systems that (hopefully) work exceedingly well together.
And, if I can construct those systems in a way that’s both simple and approachable enough to be understood and to excite others, then, it’ll be enough to convince independent, creative, and motivated people to join in my efforts to engineer even more systems (and even more relationships between those systems) that will eventually coalesce into the form of a world-class organization.
I mean, what is a business if not a collection of systems, organized in a way to maximize throughput, optimize performance, and produce out-sized results (i.e. profits)?
And this is where startups have an unbelievable advantage over older and much larger companies: A startup has the opportunity to decide, for itself, not only what the fundamental and principal systems will be and how they will operate, but also the way in which the organization decides on what new systems to build and how they will integrate and be added to the existing, larger metasystem.
And the “meta system” is simply the collection of beliefs and the resulting behaviors that are have been generalized and normalized across the entire organism. One might call this organizational culture; hopefully, it’s one built on trust.
Gall’s Law is especially applicable and important for new companies — they need to take the time the necessary time to intentionally and explicitly think upon the systems that they use so that they will have a fighting chance to construct their world-changing ideas into real services and products that people truly want.
You see, John Gall’s work has become the rule of thumb for systems design and has been used as a very strong argument for underspecification (which is where all startups begin):
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a simple working system.
This is where startups have to be hyper-vigilant and emotionally aware and mature enough to know that they can do irreparable and permanent harm to their chances of success if they, either intentionally or accidentally, divorce themselves from the foundational system(s) that made their unique insight actually usable.
I know because I’ve done this to myself in the past: I’ve built over-complicated and over-engineered systems and introduced them to my teams only to discover that they’ve done much more harm than good!
In addition, some businesses codify these principle and original systems into mission or vision statements or prop them up as part of their corporate value statements while others will not. Even the act of codifying an understood and used system is an intentional decision by the founding team and leadership!
And the temptation to over-engineer something (anything!) is already quite large; add a bit of business momentum, a few new hires, a smidge (or a lot) of venture capital, and a product that seems to be working, and you’ll suddenly wake up one morning and realize that you and your team is completely bloated and overweight with dozens of barely-used SaaS web services and a ton of (made-up) processes that, with an honest look, appear to exist for their own sake.
Good job startup founder — you just played yourself.
And we had such a good thing going! You started simply and things were working just fine and seemingly overnight you’ve backed yourself into a complex web of systems that “cannot be patched up to make it work” — you’re going to have to nuke a few things to get back to the baseline and the foundational “gem” that was working.
This is why most larger companies can’t compete against the much smaller and more agile startups — the cost of reverse engineering or deconstructing and dismantling a dysfunctional, complex system is oftentimes too large and too destructive to be worth the effort!
Consequently, the dysfunctional system is “good enough” for most people and the larger organization and very few folks are motivated to “raise the white flag” and advocate for what is truly required: Starting over with a working, simple system.
Obviously, startups that have intentionally built a culture of introspection and ruthlessly review their outdated and outmoded systems will fare much, much better than their peers and, of course, their larger enterprise competitors.
Startups begin their lives with simple systems and naturally expand and grow new systems that are generally bolted-on in a fashion that most would consider random and hodge-podge. The collection of simple systems form complex systems and some of these work for a long time while others break down very quickly.
The organization that recognizes the delta of successful and unsuccessful integrations between the new systems and the old are going to succeed (and survive) much longer than those that willfully ignore the dysfunction or naively assume that it’ll all work itself out along the way.
And the organizations that not only recognize quickly and intentionally work together actively towards fixing the issue but also are willing to, if the situation requires extreme action, dismantle entire systems in order to build new, simpler ones to support the weight of a new and altogether different organization (startups can fundamentally change as often as every 6 months!).
Needless to say, it is exceedingly difficult to strategically and tactically keep systems simple while adding to them wisely and intentionally as the organization scales.
This isn’t to say that I’m an expert; rather, I’m emotionally aware enough to know (and have empirical evidence) that organizations tend toward chaos and entropy without a steady and consistent review of not just what is being done but how it’s being done.
And, if I’m to be even more honest, I know that I tend to introduce entropy to systems if I’m not careful! In fact, I know that even if I try my hardest it’ll be an uphill battle every single step of the way.
It is in the team’s best interest to do some, if not all, of the following:
- Schedule in time to review your systems by team and/or organizational department (e.g. ops, engineering, marketing, sales, etc.).
- Identify, as best as you can, the principle (original) simple system that eventually became a complex one and clarifies clearly the (expected) outputs and the persons that should be involved.
- Outline and identify the interdependencies of the system that’s being reviewed; that is to say, the other systems that have direct interplay with the one in the review.
- Ruthlessly judge the system and adjust, prune, or outright destroy it and then build a new, simpler version (or maybe go back to the Genesis version).
- Consensus might be required or not, but, regardless of how your team makes decisions, make sure that everyone is on board with the new (and improved!) system and that everyone firmly commits for accountability.
- Time-box the experiment and set a time for review of the newly-changed system. Calendar in a retrospective.
- Rinse and repeat.
This is a big deal for my company and me, especially since we’re in the middle of growing our team. It’s also relevant because I’ve realized that it’s high time for us to review the systems that we’ve built and, with a fine-tooth comb, take the time required to optimize and (re)build the foundation of our company.
How else will we ever get to the moon? ? ? ?
John is the software engineer at YEN, a social platform that combines the power of social networks and multiple cryptocurrency exchanges.