Everyone Fails with Software They Don’t Build

There are three types of software systems that any company runs. First, high-value software systems that drive customer value. Second, the systems necessary to deliver the product or service, but not sufficient as stand-alone products on their own. Third, systems that support the business but are not related to the competitive advantage of the company. The fourth type of software system is one that doesn’t exist. Every company has software they chose not to build. This is "Unbuilt Software". To understand how much value organizations are missing out on, we must first better understand each type of software system and how software investment decisions are made. Tier 1 - High-Value Systems These systems or services compose the key building blocks for the company. They are the services that set the standard for what other software in the company will comply with. Meaning their requirements for security, performance, or quality set the standards other software at the organization is expected to meet. Since they are the highest value, they dictate what language and frameworks will be used and what architectural and hosting patterns are used by engineers in the company. These systems establish the culture and establish what skills are high status inside of the engineering groups. Tier 2 - Necessary Systems The second type of software systems are systems that are necessary but not sufficient for the company to exist. These are systems that will use the frameworks, languages, testing processes, release methodology, and security frameworks that the high-value systems use. These systems are important for the company but do not drive the same outsized value of Tier 1 systems, hence they do not warrant the same level of investment to create new policies, procedures, or technologies. Tier 3 - Supporting Systems Companies have other systems that are necessary for the company to exist. If the company was to be formed again it might not even be integral to the company, but at this point, it would cost more to migrate to some other provider than to just stay. This is the classic: "We have been running X for years. It works fine. Why do we need to spend money to switch?" These systems are usually one-off ancillary systems handled by a particular department that has a roll-up of functionality underneath them; this is often the domain of an IT operations group. How to fail - Tier 1 You can fail at the first type of system by not truly understanding the constraints in which you are operating. These systems might have very high levels of requirement for performance. For example, If the engineers do not understand the mechanisms and are not schooled in the particular technologies or optimization required to meet those objectives, this can become an existential threat to the company. How to fail - Tier 2 You can cause the second type of system to fail by overly constraining its ability to be improved. If the security and build processes needed in the first type of system constrain the second type of system such that they do not and are not upgraded and improved, they will fall out of pace with the industry. This creates an opportunity for competitors to enter the market with improved efficiencies around the second type of system, which lowers their overall cost basis. Unfortunately, this can then become an existential threat to the company. How to fail - Tier 3 A way to fail with the third type of system is to not understand the . These systems are necessary, but any additional investment is throwing good money after bad. If they are so critical that they are necessary for the business to operate then they must be considered one of the other types of systems. It seems the primary way to fail with these types of systems is to let them absorb budget and time from the business beyond their business value. sunk cost fallacy It’s much better to take three days or a week of downtime at your convenience and at a known time than to risk having the system fail completely when you are unprepared and possibly at a critical time for your business. Any effort or investment of time and money should be focused on migrating or eliminating the systems altogether. It is much better to have an account with a company whose business it is to provide that service as that company's first priority versus to have it as an afterthought or red-headed stepchild within yours. How to fail - Tier 4 The software you don’t build What this analysis leaves out is the types of systems that do not exist. These are the systems that are speculative. When building software, oftentimes, the full value of the system does not become apparent till the system is beyond a prototype. Invention and innovation are created through experimentation. If the constraints of an organization's build and deployment systems limit the range of software that an individual may build, then the organization will limit the value of the software they may build because they are not able to anticipate the value created by the experiments. Any minimum fixed cost of building software will cause the organization to only build projects that have a reasonable certainty of exceeding the cost of building them. Organizations struggle to prioritize building software whose value to a system is hard to quantify. Examples are tools that more quickly surface information from multiple sources for employees, tools that eliminate communication between groups, or tools that reduce delay for individuals. If the value of software systems is distributed as a power law, then to increase the value you should take more samples from the distribution. This implies that it is most important to increase the number of potential opportunities to have a runaway success. If the only way to experiment is to pay the tax of complying with Tier 1 processes, you’re sentencing your organization to a decreased amount of innovation. A way out One way to increase the number of experiments is to enable the largest number of individuals in your organization to conceive of and implement these experiments. Each organization has some individuals who are able to do so without assistance. A system that enables them to do so with less friction and less difficulty will increase the frequency that they experiment. Lowering the difficulty will also increase the number of individuals in your organization that are able to experiment. This means creating a way for individuals to rapidly prototype new ideas outside of the usual constraints of Tier 1 systems, but in a way that they can evolve into Tier 1 systems. This capability is a strategic advantage to an organization. Having an experimentation system will create long-term value for the organization. Has your software team found a way to succeed at Tier 4? Visit us in our and share your successes. Discord community