In Spacemaker, we have a set of core beliefs. They are our guiding statements for time to value; speed, quality, reliability, and agility. We use them for alignment and guidance when discussions get heated about some choice we need to make in a stressful situation. I have for some time intended to create a couple of blog posts elaborating on a few of them, and finally, I have started! Who knows, maybe all of them will get some elaboration over time?
But, before we dig deeper, how did we end up with these core beliefs? In Spacemaker, we have many people with previous experience from different companies, with various tech, culture, and leadership structures, both as employees and consultants. One recurring theme for companies is that they tend to build up massive organizational overhead and debt. Debt can be both organizational, tech, and product-based, and more often than not, these are tied together. Why is that? And what has changed in the last decade or two that makes us believe it is possible to build a more robust company that reduces the debt you take on over the years to come? We asked ourselves these questions when we developed our core beliefs.
The first one I felt like writing more about is Minimize ownership, make it somebody else’s problem.
Inventing and caring about a thing has a huge hidden cost — you have to build/configure it, maintain it, it spreads focus, broadens competence needs, takes time in maintenance, increases the potential for technical debt, etc. All in all, it dramatically increases time to value (in a non-transparent way). It also increases time spent on non-critical tasks. Since our most expensive resource is hours spent by our employees, most hours should be spent building the unique stuff only we have — our business logic and user interaction.
So, suppose an existing, well-designed, maintained software lib or managed service can do 70% of the job or fits only 70% unless you redefine your problem. In that case, you should work hard to reduce your problem to fit into this slot before you even consider doing it yourself. AWS Lambdas are an excellent example of something that has significant constraints on runtime, environment, and resources but should almost always be favored for its ease of use and reliability. Another example would be product support. If that is not your main product, why would you ever try to build a support platform yourself when you have SaaS like Intercom? You shouldn’t; these SaaS tools’ main mission is to solve support the best way possible, pouring millions into that goal. Let somebody else build it, and focus instead on building what is strategic to your product.
And if you ever consider building it, be aware that what we build WILL have lower Quality of Service than what you can get “off the shelf” — others have spent thousands of hours iterating over the existing service. The more our business grows and the more users we have that rely on our services every day, our QoS requirements will grow. Be humble and thankful to the sacrifices of all those engineers solving problems that we have as parts of our total product delivery. :)
So, start every day looking for stuff we could throw away and replace with something somebody else owns for us — and accept owning more stuff only when you are desperate :)
Own as little as possible, and build the things you own so that others don’t need to know or care how it works. This reduces time to value dramatically, as you can move forward independently of both the services you consume and of your consumers.
Why is this easier to accomplish now than before?
There are many reasons why this core belief is easier to adhere to today than ten years ago. With services like Github, npm, Docker, and others, the open-source community has exploded. People have a place to share, collaborate, and easily build upon each other’s work and ideas. Previously, this kind of sharing and collaboration was happening primarily in the Linux community. Now, sharing has also become a commodity for software companies and developers in every industry. There’s been a seismic shift in the number of software libraries and frameworks available for everyone to use as part of their product development.
However, the most significant shift is the explosion of companies building products and services, solving problems for other companies delivered as digital services running in the cloud — also called Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service, or SaaS, PaaS, and IaaS, respectively. This ecosystem has gone from just having a couple of choices to becoming a candy store with products, services, and libraries solving almost every problem out there.
Photo by Luis Aguila on Unsplash
When new companies emerge, they can build upon these products to solve the main problem they have set out to solve instead of building everything from the ground up. Learning to take advantage and pick from that big pool of candy is essential to reduce both organizational, technical, and product debt over time.
Adapting your problem to a solution will often be worth it
An argument in favor of DIY is that you get to build a solution tailored to your needs. Either because the offering you are considering does not match the problem you are solving or simply because the API is cumbersome to work with. Here is where our core belief gets pretty brutal: “If an existing, well-designed, maintained software lib or managed service can do 70% of the job or fits only 70% unless you redefine your problem. In that case, you should work hard to reduce your problem to fit into this slot before you even consider doing it yourself.”.
The benefits of using software libraries and SaaS are so great that we are willing to let the available offerings define how we build our product. We often choose not to tailor a solution to our needs but instead say that we are happy to build something within the constraints and boundaries set by the SaaS product we are buying or library we are using. Because in the end, the maintained SaaS or library is likely more invested in solving that problem than we would be. Therefore: fewer bugs, faster fixes, and better scalability.
We use SaaS and libraries to solve many of the sub-problems we have. That gives us more time to focus on the complexities of the main problem we’re trying to solve: building our product. Which drastically decreases the time to value for our users.
Exploiting the SaaS ecosystem
If you don’t know your way around the candy store, it is easy to resort to DIY. I still hear about companies that pour resources into building systems for monitoring their products. Why? Because they didn’t find that one product that solved all their needs.
Checkly is an excellent example of a monitoring SaaS tool we use in Spacemaker. It lets us monitor our services E2E and build tests that ensure we get notified if we break our product’s core value. If we were to make something like Checkly, it would take years and many resources, and it would not take us closer to solving what our product is supposed to solve. Checkly solves a sub-problem for us, but it lacks in-depth logging tools. However, many other companies out there are experts on building in-depth logging tools that we can utilize.
An excellent thing about the candy store of SaaS tools is that they fit together. They are incentivized to integrate with other SaaS because it elevates the value proposition of their own product, making these products a part of a total monitoring ecosystem of SaaS. These integrations allow the customers to tailor the overall monitoring platform based on multiple tools that solve different problems inside that domain.
On-premise should not be an option
When discussing this with established businesses, I hear arguments like “using SaaS tools is not as secure”, “let’s build something on our own”, or “having it on-premise is better”.
It’s not! The only way it could be more secure is to guarantee with 100% certainty that your tool/service/system is never accessible through the internet. And in 2021, you most likely want that.
If it is accessible, the chances are that you’re running an outdated and insecure lib, runtime, or OS. Solving that issue by adding a VPN on top of it is not solving the actual problem. At best, it is a band-aid, securing something with something else. At the same time, you are increasing the overhead and complexity, and therefore time-to-value for everyone in the company.
On the other hand, a SaaS with millions of users would very likely have dedicated teams to keep their service secure. Not only are they a target for hackers, but their reputation and business are also on the line. No one would want to use a service where security is not taken seriously, and a service provider definitely doesn’t want to be held responsible for security breaches. This is a massive incentive for making sure it happens as few times as possible.
It is naïve to believe that you can do better than what’s already out there, and even though you can, why would that take you faster towards solving your main business problem?
Don’t fall for the standardization trap
Another hidden cost of running these services on your own, or building some lib from scratch, is that you have limited resources for maintaining the service because it’s not your primary business. That triggers standardization; fit into the same box. Standardization in a world that innovates at the pace that our world does is organizational debt that you sometimes need. However, it would be best if you avoided it as long as you can. One size fits no one!
Why does it trigger standardization? As a simplified example, say you have 50 teams running on your on-premise service. When would it be best for your server team to support a new version of something? You would upgrade when the last team is ready for it. Because maintaining two versions for a long time is too heavy for your team, or creating the abstraction to handle it is too costly.
In the meantime, the other teams that are ready for the upgrades have to wait for new capabilities that potentially could reduce time to value for the teams. You will never be faster than the slowest team! And since teams need to optimize for different things, you can’t say that the slowest team is prioritizing wrong because they might have more critical issues than getting ready for the new capabilities that the upgrade gives.
Making teams dependent on each other in this way will, over time, make companies, teams, and people slow. And what are the benefits left with trying to solve a problem that someone else has more resources and focus on solving than you have? It only makes sense if your business’s primary goal is to solve the same problem in a better way and be a competitor.
This is why we in Spacemaker focus on creating teams that own their domain from top to bottom. It helps them be autonomous both organizationally, product and tech-wise, and they are therefore optimized for time to value. Having a candy store of products, libraries and services enable that vertical thinking.
Final words
Building upon each other’s learnings has been one of the main drivers for human evolution, and now you can do the same with products and services accessible from everywhere! Of course, you should seize the opportunity to minimize ownership and make it somebody else’s problem! If you want to create products customers love, at the quality and speed they demand, is there really any alternative?
Want to read our tech core beliefs? https://github.com/spacemakerai/spacemaker-tech-core-beliefs