Take your business to the next level with our features

In Part 1 of this series, I talked about the importance of having a platform strategy and why platforms are ultimately a business strategy. Once you have defined a strategy, the next step is to execute this strategy. Unfortunately, executing a large strategy is rarely ever simple, and plans will have to change and adapt.

In Part 2, I will talk about how you can define first principles to help your team make decisions in uncertain situations.

The Role of Principles

If you have ever executed a strategy, you know that the actual execution never quite matches how the project was planned out. Inevitably, you run into unknown unknowns: issues that you cannot foresee but have to deal with. You may run into unexpected scaling issues due to a new load pattern. You may lose a key member of your team. You may have to go through a product pivot. Because of these unknown unknowns, it is impossible to perfectly plan the exact details of how a strategy will be executed upfront.

James Cowling put this very well in his blog post, “Stepping Stones not Milestones.” Strategies are a cone. They define not a single acceptable solution but a set of acceptable solution space. The art of engineering is navigating the cone of strategy to arrive at the acceptable problem space without straying out of the cone.

Platform strategies are not any different. They define the shape of a solution; not exactly how to get there or what the exact solution is. For example, your platform strategy may be to make minimal investments and rebuild everything after finding product-market fit. The strategy does not state exactly how you should design your systems, as there are many ways to build to fit the strategy.

The pitfalls of building tactically as written in the first section exemplify what happens when one builds without staying in the cone of strategy.

So, how do you navigate the cone of strategy? This is where principles come in. Instead of defining what decisions to make upfront, you should instead define how to make decisions. Principles empower your team to make decisions when they inevitably face unknown unknowns.

How to Define Principles

How do you define principles? Unfortunately, there is no one size fits all. Just as platform strategies are necessary business strategies, principles, too, should be defined with a business-oriented mindset. Fortunately, your principles for building your platform can be derived from your business needs.

One principle you will want to define is how much investment to make in a system. As a result of the significant mindshare platforms have gotten, many commoditized solutions exist for various parts of the stack. Need an authentication solution? Check out auth0, Okta, or other alternatives. Need a protocol for services to communicate? gRPC is widely used, making it a natural choice.

The challenge here is that no commoditized solutions will fit your company perfectly. Engineering is an art more than a science; everyone has a slightly different perspective and preference for how to do things.

Many engineers, including myself, have fallen into the trap of building custom solutions or a special add-on on top of a commoditized solution to bend precisely to the company’s needs. For example, you may decide to use auth0 only for authentication and build your permissions system. When determining how much time to invest into a system, you should ask yourself, is this system a differentiator for your business? If the answer is no, relying on commoditized solutions offloads parts of your stack that are not business differentiators and lets you invest your time on the parts that are. Authentication and authorization, for example, are often table stakes but are unlikely to be a differentiator for most businesses.

Business needs are not static and are influenced by a variety of internal and external factors. They evolve and your strategies and principles should shift accordingly. The needs of a pre-product-market fit and a post-product-market fit company can be very different. Business needs also respond to market conditions. When capital was effectively free, as it was during the past few years, the horizon for which efforts must return value was looser. With capital once again being more restricted, the horizon shortens. Therefore, it’s imperative to have principles in place to brutally prioritize your business and platform strategy even more.

After the business needs, the next factor that is often worth to optimize optimizing for is your team composition and core competency. Assuming your hiring strategy is business aligned (it should be, as are all strategies in your company), your team’s very composition may be a business differentiator. Your principles should reflect that. For example, you may be a startup in the infrastructure business and have access to a strong team of infrastructure engineers. One of your principles may be to invest heavily in the core foundation of your infrastructure and hack around everything else, as you likely can move faster and better than your competitor in your core competency.

Lastly, you likely do not want more than a handful of principles (say 3–5). Any more will be too challenging to operationalize. Keep in mind that these are first principles; they are fundamental and can be used to derive anything else.

Conclusion

Platforms must be a business strategy. The execution of a strategy cannot be fully planned for upfront; there will always be unknown unknowns. Principles should be defined upfront to empower the team to make decisions regarding unknown unknowns. Therefore, platforms must be built from first principles.

Once you have defined a platform strategy and first principles, you will want to operationalize your strategy and principles so that your team can operate and make decisions using these principles. Operationalizing principles is a significant topic I may revisit in detail in the future. In the meantime, my co-founder Andrew Fong spoke on this topic on The Engineering Leadership Podcast a while back, which may be worth a listen.