Your tech stack is not the product

If you are the technical co-founder or early engineering lead at a startup, and you want to talk about your microservices, hand-rolled CI/CD, in-house monitoring stack, or any other unique part of your stack, I will say: Cool. Let’s riff. Take me deep, I’m ready.

But there’s something I’m likely to tell you in return, something I’ll probably insist you’re overlooking and need to internalize as soon as possible: Your technology stack is not the product.

A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success.

The typical startup

At most software startups, customers typically don’t care if your product runs on Heroku, Kubernetes, or a really brittle singly-homed machine in Joe’s closet. No purchasing decisions hinge on your commitment to write servers in Rust or use Nix for hermetic everything. And although they might exist, I have sadly never had a customer write a testimonial for the elegant collection of internal services involved in responding to that single HTTP request.

No; customers are not paying for, nor give a shit about, these things. Sorry. It’s still cool stuff. It’s just not what you’re selling.¹

Customers want software that delivers problem-solving impact. And at the early stage, which is all the way until you’ve reached product-market fit, they’re almost certainly not getting enough, fast enough. You should be spending as much time as you can at this level of the stack, The Product: thinking, building, learning.

So what then, is that it? Is Kube always silly and Joe’s closet machine always good? Am I saying just YOLO it? Of course not.

There are still better and worse decisions. Being able to make good decisions, ones that maximize product impact, starts with intentionality: realizing how and when you as a leader are actually making them.

Recognize implicit decisions

Many of the most consequential technology decisions happen implicitly, without even realizing a decision is being made. This is especially true when the team is small and everything is a green field. For example:

• You’ve used Go before, so you start writing the stack in it. Suddenly you’re a “Go shop”.
• You were curious to play with Kubernetes², and got Hello World working, so since nothing else is around it becomes the de facto serving environment.
• You are coming from a much later-stage and/or higher-scale company, so approach problems for a scale the company does not yet have.

These decisions glide through so easily because they feel good, fun, and natural. There’s probably nobody else around to notice! And they can often be the right decisions.

But there are many instances where an innocent, ill-considered early decision turned out much worse over the longer term. It becomes a time-sucking, success-hindering mess requiring costly correction later. I’ve certainly been responsible for my share of them.

How do we get out of making these sort of “just because” decisions, and increase our chances of success?

Set overarching goals

A good technology decision—one that is more than a “just because”—is decision that can be connected to an overarching long-term goal. As a technology team, why do we exist?

Set technology goals, early, which answer that question and which will be used guide technology decisions. Here’s a starting set:

Our Technology Goals

1. Ship the product. Frequently and reliably.
2. Support growth. Be able to bring in more people, gradually, that can do (1).

These might seem unrealistically simple, but it’s pretty easy for me to connect all variety of technical decisions to these.

• If the system is unreliable, we won’t ship as much product.
• If we’re constantly building/maintaining infrastructure, we won’t ship as much product.
• If we pick exotic technology, it’ll be harder to hire (and we won’t ship as much product).

They work well at a later stage, too:

• If we don’t hire a dedicated SRE, product builders will spend more time maintaining infra, and we won’t ship as much.
• If we don’t replace this system, more and more customers will experience a broken product, and the costs to fix will grow.

Best of all, by keeping “the stack” out of the picture, these goals make it clear where your brainpower is best focused: on keeping the product moving and improving. The stack is but a means to that end.

Now you can start evaluating some of those concrete decisions the same way:

• Why is Joe’s closet computer a bad choice? Because it’s a single point of failure and we won’t be able to ship fast if it breaks, which it will.
• Why am I building in Python and not Arc? Because I know the language and when we start hiring, there are a lot of others who do, too.
• Why are we building a monolith? Because the product isn’t at the scale where anything benefits from more services, and building more tooling would cut into the time we have for product features.

Goal alignment moves the “why” behind your decisions from “because I’m awesome and have great instincts” to “it’s what we need, now”. (You are still awesome.)

Still, there will be situations where multiple options would seem to meet the goal. How do you make a choice when there is not clear winner?

Establish shared values

Goals alone tell us what we want to achieve, but not how. Pair your technology goals with a set of values that accelerate the process of picking “the how”.

I usually start with a set something like this:

1. No sacred bits: Launch, learn, iterate. It’s expected we’ll throw things out and outgrow past decisions. And some of our product ideas won’t succeed no matter how well-built the software was. We value getting it out the door over getting it perfect, and we will quickly and unemotionally change our approach when new information supports it.
2. Today’s bets over tomorrow’s theoreticals. We do our best to anticipate future needs, but we place the most emphasis on building what we know we need today.
3. Favor “boring technology” and in-house expertise. We move fastest when we know our tools well, not just their strengths but also their limitations. The ideal tools are the ones we’re already expert in, or at least can learn to proficiency quickly, even if they have some drawbacks.
4. Buy non-core competencies whenever prudent. If we need something we don’t have, and it’s not something this company needs to become a leader in, buy it whenever practical (i.e. affordable and easily integrated).

You don’t have to use my values as long as you set some³. There are plenty of examples out there. An old friend turned me on to “even-over” values, which put two virtues in tension (to emphasize the primacy of the first). Someone even built an aggregator of values by company so you can select your next job accordingly. Go be you. Have fun with it.

The important thing values should do is create cultural license for breaking habits and instincts that might send us in the wrong direction. Make it okay to say “we’re not Google”, or, “we’ll solve that later”.

You still set, and edit, strategy

Panicking about the “simplicity” of the stack this would lead to? Worried that when you reach scale, the PaaS bill will be through the roof? Upset that you’ll have nothing crazy to blog about for years?

Relax. You will still own the technology strategy. You will be making decisions continuously, and have both the right and the obligation to make changes when needed.

But your stack is unlikely to ever be the “main character” your customers rave about it. At best, only its qualities are what stand out. That’s a good thing. Feel good about keeping it that way.