A Tale of Two Businesses

If you haven't read "A Tale of Two Teams" by Jeremy Daly then you should read it now because it's a fantastic read. Based on the story you might be tempted to take away that serverless is better at building a product than Kubernetes. Jeremy does not say that and I know he does not believe that from talking with him. But I've seen this sentiment in the serverless community. This made me want to provide a rebuttal not to the story but its interpretations.

ServerlessOps being a company that promotes and utilizes serverless as a means towards DevOps transformation and AWS migration, we understand that serverless is not right for every organization. We're fine with that. We know the chief competitor to us isn't Kubernetes, it's apathy, stagnation, and the status quo. We don't believe in "Serverless... Now tell us your problems." We believe in asking what your problems are and determining if serverless is a fit for you. Our differentiator isn't the technology we employ but our strategic thinking and problem solving abilities. As you read the rest of this, ask yourself if your organization can benefit from our approach.

A Tale of Two Teams

"A Tale of Two Teams" is the story of two teams building a technical product and launching a company. One is VC backed and goes with Kubernetes for their technical infrastructure while the other is bootstrapped and chooses to go serverless. The story follows their business and technical development.

But If you read "A Tale of Two Teams" as a technical story and strategy plan for success then you're missing the point. This is first a tale of two different business growth strategies, VC backed versus bootstrapped funding. Their funding strategies are way more influential to the story than their technical decisions. Second, it's an allegory on the decisions new businesses make and the execution required in order to survive and grow. I'm going to discuss the decisions made by the different teams and also compare them with my own startup observations and experiences. Where serverless fits in I'll get to.

VC Backed V. Bootstrapped

Being VC backed versus bootstrapped is a regular argument in the startup and entrepreneurship world. There are pros and cons to each as a business funding model. Not to mention, money, or lack of it, doesn't guarantee success. You still need to execute.

In "A Tale of Two Teams", the two companies differ in their funding models. Your funding model, or more specifically your availability of cash, can have effects on your technical decision making. For example, significant cash availability can erase the cost argument for serverless. Let's briefly run through the different funding models and choosing one.

VC Backed Company

The point of taking VC is to grow fast. If your market is time sensitive then this makes sense. However this comes at the expense of giving up part of your company, being answerable and accountable to outsiders, and the headaches all this causes. The VC backed company is expected to move fast and meet the benchmarks they established with their investors.

This company must find their way on an established time table.

Bootstrapped Company

Bootstrapping is great for retaining control of your company and moving at a slower pace. You can't move as fast as a VC backed company but you can move slower if you consider that the best course of action. There's reasons to move slower too. One is to test out different ideas and see what sticks without the pressure of a board and investors. This is great if you have the time.

The bootstrapped company is afforded the ability to find their own way at their own pace.

Which Funding Model Is Right For Your Business?

The correct business funding model is the one that aligns with your values and goals. I can't answer this question for you.

Taking VC is a high risk / high reward option. If your desired company exit is big (e.g. large IPO or acquisition), your window is small, and your you have the patience to answer to someone else for a business you started that's increasingly less owned by you, then VC may be the way to go. You should also be prepared for the high chance your business fails or that the situation goes bad in general.

Bootstrapping is great if you have the money (to lose), your monetary aims are more modest, you have time to experiment with ideas, and you want to retain control. You may find this suits what you're looking for better. Particularly if your primary goal is to build a business that provides you with your definition of "the good life", and not garnering press mentions. The lack of pressure and accountability VC investment creates can also have a downside for the less disciplined. It can lead many to never making the leap from experiment / side-hustle to business.

By the way, there's also a hybrid approach to all of this. Investors can choose to invest in potential or they can choose to invest in existing success. You can bootstrap yourself to a proven product and seek VC later on to scale it. This is a very common model and not one to be overlooked.

Business Execution

Once you've figured out how to fund your company you need to execute. While we often laud large fundraising rounds, raising money isn't success. If you thought raising money was hard, the execution phase is significantly harder.

What's apparent between the two different companies in the story is their execution. One executes in a manner fairly average for a lot of startups. The second executes above average. 

VC Backed Company

The piece was I think too hard on the the VC backed company. It exhibited a lot of common startup smells. (As an employee you should look for these.) They mismanaged their cash by dropping it on fancy offices, an expensive logo, t-shirts, stickers, etc. They're following a generic and uninspiring marketing playbook. Finally, the product they're developing isn't really clear in the beginning. No amount of money fixes this poor execution.

What I take away from that is a company that lacks clear product vision, has mediocre marketing, and is wasting money... So, your average startup. This is why most of them die.

Bootstrapped Company

On the flip side, the piece is too easy on the bootstrapped company. It's I think overly optimistic on organic growth and execution by its two engineer co-founders. Too many engineers, even if they deny it, believe in, "If we build it they will come." As someone with marketing experience and an accomplished marketing advisor for ServerlessOps, organic growth is very hard to achieve without someone experienced in its execution.

I've also found too many engineers are walled off from how their employer makes money which leads to them to not understanding successful product development or the effort that goes on outside of engineering to make a product successful. I think this is a by-product of our field's over-emphasis on technical understanding over business understanding in vertical movement. No one gets praised for solving an engineering issue with a credit card. But spend a month or two on a challenging DIY solution and watch it roll in. Rarely does anyone ask what else could have been accomplished in all that time. This misalignment of incentives causes engineers to prioritize technical decision making or business decision making.

Execution Is Hard

I've been through a few startups and the story of the VC backed company's execution doesn't surprise me one bit. If you dream of going to a startup because it's an opportunity to engineer and build a business "the right way", good luck with that. Startups are messy chaotic places that require a high risk tolerance. You need to be okay with the constant hum of circus music in your head as you look around and wonder what's going on.

If you haven't been at an early stage startup before, then you should find someone who has and ask them to tell you stories. Particularly if you're a later stage employee, find one of the early employees. The stories from even successful companies might end up shocking and amazing you. There's a very good chance you'll be left asking, "How did this company even survive?" Well, they survive because of that garbage codebase you're working on that got them their next series of funding. That garbage is why you have a job.

Wanting greater exposure to business mechanics was one reason I spent time in marketing. I knew in order to start my own company I would need exposure to another side of the business that was closer to the revenue stream. Based on that experience, bootstrapped company is presented as achieving fairly easy organic growth. (I know the author does not believe it's easy.) But I find too many engineers do not know or understand this hard lesson about building products and companies. For many, I think the success of the bootstrapped company in the story furthers the fallacy that if you build something good, people will show up. Your biggest challenge to overcome as a new business is obscurity. Your next obstacle is retention. Finally, there's apathy for your solution or even apathy towards solving the problem you address. All these combined are far harder to solve than technical challenge you're facing

Organic growth is very hard. I say this as someone works very hard to organically grow ServerlessOps. There's a lot of work in the funnel to attract, retain, nurture, and convert people. If you're reading this and see a popup to subscribe to this company's newsletter, that's us attempting to retain and nurture you further along.

Finally, as a result of my observations and experience, I'm wary of an all engineer founder team and their ability to understand the necessary mechanics to build a successful company. I look favorably on a combination of technical and non-technical co-founders. Both bring perspectives that are necessary for successful execution.(I don't like the term non-technical but it has a known meaning in the startup world.) Their inevitable conflicts should also help balance out the other's myopia.

Is Serverless Best For Your Business?

I said we'd get back to where serverless fits in. Is serverless better than Kubernetes for your new business?

I couldn't answer what funding model was best for your business earlier. Nor do I know the answer to several other relevant questions like what your own technical background is, your hiring market, and so on. The answer to most technical questions is contextual. What are you trying to solve, what are your constraints, and what does success look like? You know these things better than me or anyone else.

However, if you've decided bootstrapping, at least early on, is the funding model for your business then serverless may be right for you. Your technical costs are lower and that's good when you're spending your money and not your investors' money. I would seriously consider it if you prefer to retain greater control over your company, want to grow at your self directed pace, or VC isn't readily available to you. Alternatively, you can get pretty far on AWS EC2 t2 instances.

If you decide to go VC backed that doesn't mean you shouldn't go serverless. But, you don't (depending on your raise) have the same pressing need for cash as a bootstrapped company. All cost arguments for serverless are solving a problem you don't have. Additionally, the adage "use boring technology" is very relevant. Use what you know, with known patterns, and with known problems in order to meet your growth targets. If you can execute faster with VMs and containers than by going serverless, and some people can, then go with that.

Serverless is also not going to make you automatically better than your competition. Serverless doesn't guarantee better execution. There's too many other moving parts in your business that add up. The choice of technical stack is one of many decisions you'll make and probably one of the lesser important ones.

In the story, one company also had an unclear product vision while the second one experimented and responded to market feedback. No technology can makeup for lack of clear product direction or execution. If you're adept at receiving and interpreting market feedback then the quick iteration will help you validate ideas and deliver the right things to your customers. A faster feature factory delivering the wrong things will lose to a slower feature factory building the right things.

Success requires a strong product management organization. If you're serverless and investing all your energy into product engineering and paying little attention to product management then you're not going to effectively capitalize on the feature velocity advantage.

Why We Like Serverless

The reason we like serverless technology is for all the same reasons highlighted in "A Tale of Two Teams". It allows teams to be nimble and improve feature and service delivery velocity. It allows a team to better focus on meeting the needs of their users, whether they be internal or external. Less time spent on infrastructure means more time analyzing and validating you're solving the problems at hand.

But to be able to make the most out of it requires work and proper execution. It requires planning and analysis to ensure a team is moving in the right direction and deliver the a solution that solves the intended problem. It can also requires some adjustment for engineers. Serverless has a learning curve that needs to be gotten over. It's not tremendous but it does exist. These are reasons why we're here as a company.

Final Thoughts

There's two consistent ideas I believe when it comes to engineering, product development, and business growth.

1. The answer to most all technical decisions is "it depends".
2. Your tech stack won't make or break you

First, if you can't capitalize off of the advantages a technical decision creates, or it solves problems you don't have, then at best the decision was inconsequential and at worst it was wrong. Second, at the end of the day there are so many other contributing factors to success that your choice of tech stack probably doesn't matter too much in whether your business lives or dies.

I like "A Tale Of Two Teams" but it's import to read it as an allegory and not as a strategy document. The VC backed Kubernetes using company story is pretty realistic in describing your average startup. But the bootstrapped serverless using company story is a bit idealized. With minor tweaks I'd expect the VC backed Kubernetes using company to live and the bootstrapped serverless using company to die.

I'm aware that "A Tale of Two Teams" is just a story. The Phoenix Project is also just a story but I've spent the last few years listening to people claim their company played out just like the book. Good stories have a habit of taking on a life of their own, particularly when they represent our best hopes and achievements.

Finally, if you'd like a discussion of whether serverless is right for you then check out our DevOps transformation and AWS migration advisory services. Our differentiator isn't serverless technology, it's understanding your problems and the context of your organization, and providing a nuanced and balanced look at your technical options for achieving growth and success.