Excerpts from the annual letter
May 24, 2022
Company
Below is an edited version of our internal annual letter.
Our business is the business of business systems – specifically, we offer a catalog of tools that developers can use to build integration systems for themselves and their customers.
I started Stedi, though, not just to solve the problem of business integrations – nor just to build a big business or a successful business – but to build a world-class business.
A world-class business is a business that doesn't just win a market – it defines a category, dominates a field. Its name becomes synonymous with its industry. Its hallmark characteristic is not some single milestone or achievement, but enduring success over a very long period of time.
Types of businesses
When the topic of world-class businesses comes up, someone inevitably mentions Amazon. Amazon bills itself as a customer-obsessed company. It seems sensible that customer obsession is a path to building a world-class business; customers are the lifeblood of a business – without customers, a business will cease to exist.
The problem with customer obsession is that optimizing for delivering value to customers can cause a company to make structural choices that are detrimental to the company's long term operational efficiency. A company that is inefficient becomes painful to work for; when a company becomes painful to work for, the best people leave – and when the best people leave, a company becomes disadvantaged in its pursuit of delivering value to customers. Paradoxically, customer obsession as a company's paramount operating principle can lead to a declining experience for the customer over time.
The alternative to a customer-obsessed company is a company that is operations-obsessed. The operations-obsessed company optimizes for efficient operations – it works to continuously eliminate toil.
What exactly is toil? Toil has many definitions – a popular one is from Google's SRE book:
“The kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
If "fear is the mind killer," toil is the soul-killer. Eliminating toil allows people to focus on the inherent complexity of the difficult, interesting problems at hand, rather than the incidental complexity caused by choices made along the way. Of course, most companies are neither customer- nor operations-obsessed, and, without an explicit optimization function, drift around aimlessly with middling results.
To be sure, a customer-obsessed company can also prioritize operational excellence, just as an operations-obsessed company can also – must also – prioritize delivering exceptional customer value. The difference between the two comes at the margins: when push comes to shove, what takes priority? In other words: will the company incur toil in order to further its success with customers? Or will it leave upside – that is, revenue or profit – on the table in order to further its long-term operational advantage?
Amazon is the former: a customer-obsessed company that also prioritizes operational excellence. Said in a slightly different way, Amazon is an operationally-excellent company subject to the constraint of customer demands. It is operations-obsessed up until the point that operational concerns conflict with customer demands, at which point Amazon – as a customer-obsessed company – runs the risk of prioritizing the latter. This is one reason why on-call at Amazon can get notoriously bad: when push comes to shove, operational concerns can lose out.[1]
Costco and ALDI, on the other hand, are examples of the latter: operations-obsessed companies that also excel at delivering customer value. They are customer-focused companies subject to the constraint of minimal operational overhead. When customer demands conflict with minimizing operational overhead, these companies sacrifice customer experience. This is why, as a Costco customer looking for paper towel, you have to walk through a harshly-lit warehouse with a giant shopping cart and pick a 48-pack off of a pallet – certainly not the most customer-friendly experience in the world, but in exchange for it, you get to purchase exceptional quality items at 14% over cost.
Stedi is definitively in this latter category: we are an operations-obsessed company. When push comes to shove, we are willing to leave revenue or profit on the table in order to reach ever-lower levels of operational toil.
I made this choice early on for two reasons. First, because I believe that over a long enough time horizon, an operations-obsessed company will lead to better outcomes for our customers. And second, because, well, I think it's just an enormously rewarding way to work. Eliminating toil brings me tremendous, tremendous satisfaction. If you feel the same way, you've come to the right place.
Thermodynamics and toil
Most of us have heard the first law of thermodynamics, though likely aren't familiar with it by name – it's also called the law of conservation of energy, and it states that energy can neither be created nor destroyed.
But the lesser-known second law is, in my opinion, a lot more interesting and applicable to our daily lives. The second law of thermodynamics states that entropy - the measure of disorder in a closed system – is always increasing.
What exactly does this mean? Eric Beinhocker sums it up nicely in The Origin of Wealth:
“The universe as a whole is drifting from a state of order to a state of disorder[…]over time, all order, structure, and pattern in the universe breaks down, decays, and dissipates. Cars rust, buildings crumble, mountains erode, apples rot, and cream poured into coffee dissipates until it is evenly mixed.”
The law of entropy applies to any thermodynamic system – that is, "any defined set of space, matter, energy, or information that we care to draw a box around and study." But while the total entropy – the disorder – of the universe at large is always increasing, the entropy of a given system can ebb and flow. "[A] system can use the energy and matter flowing through it to temporarily fight entropy and create order, structure, and patterns for a time[...]in [a system], there is a never-ending battle between energy-powered order creation and entropy-driven order destruction."
Stedi itself is a thermodynamic system. It imports energy in the form of capital (either from investors or from customers), which it uses to pay humans – that is, all of us – to create order and structure in the form of software that our customers can use, along with the various business systems required to support that customer-facing software.
You and I are thermodynamic systems, too – we use some of that capital to buy food, and we use the energy stored in that food to repair that damage that entropy has done since our last meal and to power the energy-hungry brain that works to build Stedi. From a thermodynamic standpoint, the food we eat becomes the intellectual assets – code, pixels, docs, emails, and more – that makes Stedi, Stedi. I think that's pretty remarkable (it's also another great reason why Stedi pays for lunch).
Anyways, some portion of our energy (your and my time, and Stedi's capital) is spent on building new order and structure, and some portion of it is dedicated to fighting the decay brought on by entropy.
Our word for this latter energy expenditure – energy expended just to stay in the same place – is toil. Our goal as a company is to spend as little energy on toil as possible, allowing us to allocate the maximum amount of energy possible to building new order and structure – that is, new value for our customers.
The practice of mitigating toil has a quality of what economists call increasing returns or agglomeration effects – the more toil we mitigate, the more attractive it is to work at Stedi, and the more attractive it is to work at Stedi, the more great people we can hire to build new order and structure and mitigate more toil, which starts the process over again.
Another way of thinking about this is that if we continue to mitigate toil wherever we find it, we'll find ourselves with ever-larger amounts of time to work on building new order and structure for our customers. That's the basic reason why an operations-obsessed business model wins out over a long enough time horizon: it's designed to minimize the surface area upon which entropy can do its work.
Ways to mitigate toil deserves its own memo, but there are two basic tactics that I wanted to touch on briefly: automation and elimination.
If you think about entropy as automatic decay, then one tactic is automatic [mitigation of] toil. One example of this is Dependabot. Dependabot doesn’t eliminate toil – rather, it employs a machine to fight automatic decay with automatic repair. Automatic repair is better than manual repair, but it’s not as good as eliminating it altogether; automation inevitably fails in one way or another, and if we’re going to disappear to a different dimension, there isn’t going to be anyone there to give our automatic decay-mitigation systems a kick when they get stuck.
Toil can be eliminated (from our thermodynamic system, at least) by drawing the system boundary a bit differently. When we use an external service instead of an external library, we’re moving the code outside of our system – thereby outsourcing the entropy-fighting toil to some third party. Not our entropy, not our problem.
As a general rule of thumb, when trying to reduce our surface area in the fight against entropy, we want to use the highest-order (that is, the lowest amount of entropy) system that satisfies our use case. A well-supported open source library is preferable to a library of our own (because the code entropy is someone else’s problem), and a managed service is preferable to open source (because fighting the code entropy and the operational entropy are someone else’s problem).
When we choose to whom and to what we outsource our fight against entropy, there are a number of questions to ask ourselves. Is the entity in question – be it a library or a service or a company – winning, losing, or standing still in the fight against entropy? Pick a GitHub library at random, and the overwhelming odds are that there hasn’t been a commit made in recent history – the library is rotting. Amongst more popular libraries, the picture is better, with brisk roadmaps and regular housekeeping.
When it comes to managed services, though, it’s quite rare to find a company that's winning – the vast majority of Software-as-a-Service companies are either treading water or falling behind. NetSuite is one example; it’s in some state approaching disrepair – no reasonable onlooker would say that NetSuite is definitively winning the war against entropy (though it certainly seems to be winning the war for market share). It has so much surface area that it has to dedicate an overwhelming percentage of its resources just to fight decay, leaving little to build new order and structure. Once a company reaches this state, it’s extraordinarily unlikely that it will ever recover.
There are certainly counterexamples, like AWS, GCP, and Stripe. They are good operational stewards of their production services and they routinely create new and valuable order and structure. But even then, we have to dig deeper: do they truly insulate us from the fight against disorder and decay, or do they leak it through in batches? Each time a provider like GCP deprecates a service or makes a breaking API change, they push entropy back onto us.
Same goes for price increases. A SaaS provider brings the code within the boundaries of their own infrastructure – that is, the thermodynamic system for running and operating the code – and we have to give them energy (in the form of money, which is a store of energy) as compensation. When the price goes up, they’re changing the energy bargain we’ve made.
The four horsemen of SaaS entropy, then, are: feature velocity, operational excellence, minimal breaking changes, and price maintenance. This is the reason we prefer working with AWS over most other providers – AWS has an implicit commitment to its customers that it will do everything in its power to avoid deprecating services, breaking APIs, and making price increases. For the same reason, we hold these principles near and dear for our products, too – our customers are entrusting us to fight their business-system-related entropy, and we want to be excellent stewards of that trust.
Every time we move up the ladder to a higher-order system, we have to make some tradeoffs. When we use a library, we lose some flexibility. Maintaining the library’s order is no longer our problem, but we have to live with their decisions unless we want to maintain our own fork. When we use a managed service, we lose even more flexibility – we lose the ability to change the system’s order altogether. Our system becomes harder to test, since it isn’t self-contained, which makes development slower and riskier.
There are big tradeoffs in terms of flexibility, development speed, testing, and more, and they all add up. But on the other hand, there’s the colossus that is entropy working every single minute of every single day to erode everything we dare to build. When I take stock of it, I’d prefer just about anything to fighting the second law of thermodynamics and the inevitable heat death of the universe.
Entropy and our customers
Our overall driving metrics measure usage. I say usage and not revenue because usage begets revenue – in the world of EDI, usage is a proxy for customer value delivered, and it’s exceptionally rare for a software company to deliver customer value and find itself unable to capture some of that value for itself.
Pricing
To facilitate usage, our pricing needs to be as cheap and reliable as running water, where you wouldn’t think twice (in a developed nation, from a cost standpoint) about running the faucet continuously when brushing your teeth or washing the dishes, or worry that the water might not come out when you need it the most. If our pricing were high compared to other developer-focused, API-driven products in adjacent spaces, it would discourage usage – it makes developers think about how to minimize the use of our products, rather than maximize the use of our products. This is precisely the opposite of the behavior we want to incentivize.
There is a second reason to avoid high prices: high prices signal attractive margins to competition. Once we have like-for-like competition – which is inevitable – we’ll be forced to lower our prices; if we’re going to lower our prices in a couple of years, then the only reason to have higher prices now is to capture additional revenue for a short period of time. This sort of "temporary" revenue is short term thinking; the long-term cost of temporary revenue is that you’ve incentivized competitors to enter your space (conversely, very low prices discourage competitors from entering the space, because the revenue potential is small).
Products
To drive usage, we're also expanding our product offering.
To think about our building blocks again in terms of thermodynamics, each building block is a piece of order or structure that we’ve committed to create, maintain, and improve on behalf of our customers; our customers can outsource their fight against entropy by using our building blocks.
We currently have three Generally Available products – three building blocks – that developers can use to build business systems: EDI Core (which translates EDI into developer-friendly JSON, and vice versa), Mappings (which allows transformation of JSON format to another), and Converter (which converts XML and CSV into JSON).
There are a limited number of use cases that customers can address using only these three products – there is a large amount of entropy that customers need to maintain in order to build end-to-end use cases.
To address this, we're launching a wide-reaching range of new products (many in June) – broadly, these products allow developers to build complete, end-to-end integrations all within the Stedi platform. Those products are:
Functions: a serverless compute service to run code on Stedi's infrastructure (now in Developer Preview).
SFTP: fully managed serverless SFTP infrastructure for exchanging files at any volume (now in Developer Preview).
Stash: simple, massively scalable Key-Value store delivered as a cloud API (now in Developer Preview).
Buckets: cheap, durable object storage to accommodate any file, in any format (coming soon to Developer Preview).
Guides: EDI specifications defined in standardized JSON Schema, and accessible via API (coming soon to Developer Preview).
There's a common theme for these developer-focused building blocks: they're as simple and generic as possible (in order to be easy to adopt and flexible for the extreme heterogeneity of EDI use cases), and they're scalable – both economically and technically – so that our customers never outgrow them, no matter how large they get (or how small they start). In many cases, developers may never exceed our monthly free tiers, and incur no costs at all.
Developers can use these building blocks as standalone items for just about any business application they might need to build – or assemble them together to build powerful, flexible EDI applications and integrations. With each building block we add, the number of use cases we can support rises exponentially.
In talking about this, I’m reminded of a passage from the book Complexity by Waldrop:
“So if I have a process that can discover building blocks,” says Holland, “the combinatorics [of genetic systems] start working for me instead of against me. I can describe a great many complicated things with relatively few building blocks. The cut and try of evolution isn’t just to build a good animal, but to find good building blocks that can be put together to make many good animals.
Focus
We are here to build a world-class business – a serious, first-rate business that the entire world of commerce can depend on, and that each of us can depend on for a first-rate, exceptional professional career with an exceptional financial return. My job is to be a steward of that path.
In a letter like this, it’s easy to get lost. What is most important? What is our focus?
To that end, I’d like to share a few passages.
For six months I’ve been piecing together the puzzle of why Kenyans are such good runners. In the end there was no elixir, no running gene, no training secret that you could neatly package up and present with flashing lights and fireworks. Nothing that Nike could replicate and market as the latest running fad. No, it was too complex, yet too simple, for that. It was everything, and nothing. I list the secrets in my head: the tough, active childhood, the barefoot running, the altitude, the diet, the role models, the simple approach to training, the running camps, the focus and dedication, the desire to succeed, to change their lives, the expectation that they can win, the mental toughness, the lack of alternatives, the abundance of trails to train on, the time spent resting, the running to school, the all-pervasive running culture, the reverence for running.
When I spoke to Yannis Pitsiladis, I pushed him to put one factor above all the others. “Oh, that’s tough,” he said, thinking hard for a moment. Then he said pointedly:
“The hunger to succeed.”
Guidelines for the Leader and the Commander:
“It follows from that, that you must, through this process of discernment and storing away, create in yourself a balanced man-whereby you can handle concurrently all the different parts of the job. You don't concentrate on one and forget the other, such as maintenance; you don't concentrate on marksmanship and forget something else. The best organizations in the American Army are the organizations that are good or better in everything. They may not make many headlines, they may not be "superior" in any one thing, but they are our best organizations.”
“Successful investing requires thoughtful attention to many separate aspects, all at the same time. Omit any one and the result is likely to be less than satisfactory.”
“The art of investment has one characteristic that is not generally appreciated. A creditable, if unspectacular, result can be achieved by the lay investor with a minimum of effort and capability; but to improve this easily attainable standard requires much application and more than a trace of wisdom.”
It’s remarkable to me that when you look across so many different disciplines – sport, military, investing, and dozens more – the common theme from the people at the pinnacle of their game is that there’s no one single secret, no shortcut to being the best. It requires doing it all.
– Zack Kanter
Founder & CEO
[1] I say can lose out because it doesn't have to happen this way – every senior leader I've talked to at Amazon has pushed back on this and said that Amazon recognizes that failure to address operational toil leads to an inability to deliver value to customers. But ask any front-line Amazon employee what Amazon's #1 focus is, and they'll tell you customer obsession – when faced with delivering a feature or addressing an on-call issue, that's what comes to mind.
Below is an edited version of our internal annual letter.
Our business is the business of business systems – specifically, we offer a catalog of tools that developers can use to build integration systems for themselves and their customers.
I started Stedi, though, not just to solve the problem of business integrations – nor just to build a big business or a successful business – but to build a world-class business.
A world-class business is a business that doesn't just win a market – it defines a category, dominates a field. Its name becomes synonymous with its industry. Its hallmark characteristic is not some single milestone or achievement, but enduring success over a very long period of time.
Types of businesses
When the topic of world-class businesses comes up, someone inevitably mentions Amazon. Amazon bills itself as a customer-obsessed company. It seems sensible that customer obsession is a path to building a world-class business; customers are the lifeblood of a business – without customers, a business will cease to exist.
The problem with customer obsession is that optimizing for delivering value to customers can cause a company to make structural choices that are detrimental to the company's long term operational efficiency. A company that is inefficient becomes painful to work for; when a company becomes painful to work for, the best people leave – and when the best people leave, a company becomes disadvantaged in its pursuit of delivering value to customers. Paradoxically, customer obsession as a company's paramount operating principle can lead to a declining experience for the customer over time.
The alternative to a customer-obsessed company is a company that is operations-obsessed. The operations-obsessed company optimizes for efficient operations – it works to continuously eliminate toil.
What exactly is toil? Toil has many definitions – a popular one is from Google's SRE book:
“The kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
If "fear is the mind killer," toil is the soul-killer. Eliminating toil allows people to focus on the inherent complexity of the difficult, interesting problems at hand, rather than the incidental complexity caused by choices made along the way. Of course, most companies are neither customer- nor operations-obsessed, and, without an explicit optimization function, drift around aimlessly with middling results.
To be sure, a customer-obsessed company can also prioritize operational excellence, just as an operations-obsessed company can also – must also – prioritize delivering exceptional customer value. The difference between the two comes at the margins: when push comes to shove, what takes priority? In other words: will the company incur toil in order to further its success with customers? Or will it leave upside – that is, revenue or profit – on the table in order to further its long-term operational advantage?
Amazon is the former: a customer-obsessed company that also prioritizes operational excellence. Said in a slightly different way, Amazon is an operationally-excellent company subject to the constraint of customer demands. It is operations-obsessed up until the point that operational concerns conflict with customer demands, at which point Amazon – as a customer-obsessed company – runs the risk of prioritizing the latter. This is one reason why on-call at Amazon can get notoriously bad: when push comes to shove, operational concerns can lose out.[1]
Costco and ALDI, on the other hand, are examples of the latter: operations-obsessed companies that also excel at delivering customer value. They are customer-focused companies subject to the constraint of minimal operational overhead. When customer demands conflict with minimizing operational overhead, these companies sacrifice customer experience. This is why, as a Costco customer looking for paper towel, you have to walk through a harshly-lit warehouse with a giant shopping cart and pick a 48-pack off of a pallet – certainly not the most customer-friendly experience in the world, but in exchange for it, you get to purchase exceptional quality items at 14% over cost.
Stedi is definitively in this latter category: we are an operations-obsessed company. When push comes to shove, we are willing to leave revenue or profit on the table in order to reach ever-lower levels of operational toil.
I made this choice early on for two reasons. First, because I believe that over a long enough time horizon, an operations-obsessed company will lead to better outcomes for our customers. And second, because, well, I think it's just an enormously rewarding way to work. Eliminating toil brings me tremendous, tremendous satisfaction. If you feel the same way, you've come to the right place.
Thermodynamics and toil
Most of us have heard the first law of thermodynamics, though likely aren't familiar with it by name – it's also called the law of conservation of energy, and it states that energy can neither be created nor destroyed.
But the lesser-known second law is, in my opinion, a lot more interesting and applicable to our daily lives. The second law of thermodynamics states that entropy - the measure of disorder in a closed system – is always increasing.
What exactly does this mean? Eric Beinhocker sums it up nicely in The Origin of Wealth:
“The universe as a whole is drifting from a state of order to a state of disorder[…]over time, all order, structure, and pattern in the universe breaks down, decays, and dissipates. Cars rust, buildings crumble, mountains erode, apples rot, and cream poured into coffee dissipates until it is evenly mixed.”
The law of entropy applies to any thermodynamic system – that is, "any defined set of space, matter, energy, or information that we care to draw a box around and study." But while the total entropy – the disorder – of the universe at large is always increasing, the entropy of a given system can ebb and flow. "[A] system can use the energy and matter flowing through it to temporarily fight entropy and create order, structure, and patterns for a time[...]in [a system], there is a never-ending battle between energy-powered order creation and entropy-driven order destruction."
Stedi itself is a thermodynamic system. It imports energy in the form of capital (either from investors or from customers), which it uses to pay humans – that is, all of us – to create order and structure in the form of software that our customers can use, along with the various business systems required to support that customer-facing software.
You and I are thermodynamic systems, too – we use some of that capital to buy food, and we use the energy stored in that food to repair that damage that entropy has done since our last meal and to power the energy-hungry brain that works to build Stedi. From a thermodynamic standpoint, the food we eat becomes the intellectual assets – code, pixels, docs, emails, and more – that makes Stedi, Stedi. I think that's pretty remarkable (it's also another great reason why Stedi pays for lunch).
Anyways, some portion of our energy (your and my time, and Stedi's capital) is spent on building new order and structure, and some portion of it is dedicated to fighting the decay brought on by entropy.
Our word for this latter energy expenditure – energy expended just to stay in the same place – is toil. Our goal as a company is to spend as little energy on toil as possible, allowing us to allocate the maximum amount of energy possible to building new order and structure – that is, new value for our customers.
The practice of mitigating toil has a quality of what economists call increasing returns or agglomeration effects – the more toil we mitigate, the more attractive it is to work at Stedi, and the more attractive it is to work at Stedi, the more great people we can hire to build new order and structure and mitigate more toil, which starts the process over again.
Another way of thinking about this is that if we continue to mitigate toil wherever we find it, we'll find ourselves with ever-larger amounts of time to work on building new order and structure for our customers. That's the basic reason why an operations-obsessed business model wins out over a long enough time horizon: it's designed to minimize the surface area upon which entropy can do its work.
Ways to mitigate toil deserves its own memo, but there are two basic tactics that I wanted to touch on briefly: automation and elimination.
If you think about entropy as automatic decay, then one tactic is automatic [mitigation of] toil. One example of this is Dependabot. Dependabot doesn’t eliminate toil – rather, it employs a machine to fight automatic decay with automatic repair. Automatic repair is better than manual repair, but it’s not as good as eliminating it altogether; automation inevitably fails in one way or another, and if we’re going to disappear to a different dimension, there isn’t going to be anyone there to give our automatic decay-mitigation systems a kick when they get stuck.
Toil can be eliminated (from our thermodynamic system, at least) by drawing the system boundary a bit differently. When we use an external service instead of an external library, we’re moving the code outside of our system – thereby outsourcing the entropy-fighting toil to some third party. Not our entropy, not our problem.
As a general rule of thumb, when trying to reduce our surface area in the fight against entropy, we want to use the highest-order (that is, the lowest amount of entropy) system that satisfies our use case. A well-supported open source library is preferable to a library of our own (because the code entropy is someone else’s problem), and a managed service is preferable to open source (because fighting the code entropy and the operational entropy are someone else’s problem).
When we choose to whom and to what we outsource our fight against entropy, there are a number of questions to ask ourselves. Is the entity in question – be it a library or a service or a company – winning, losing, or standing still in the fight against entropy? Pick a GitHub library at random, and the overwhelming odds are that there hasn’t been a commit made in recent history – the library is rotting. Amongst more popular libraries, the picture is better, with brisk roadmaps and regular housekeeping.
When it comes to managed services, though, it’s quite rare to find a company that's winning – the vast majority of Software-as-a-Service companies are either treading water or falling behind. NetSuite is one example; it’s in some state approaching disrepair – no reasonable onlooker would say that NetSuite is definitively winning the war against entropy (though it certainly seems to be winning the war for market share). It has so much surface area that it has to dedicate an overwhelming percentage of its resources just to fight decay, leaving little to build new order and structure. Once a company reaches this state, it’s extraordinarily unlikely that it will ever recover.
There are certainly counterexamples, like AWS, GCP, and Stripe. They are good operational stewards of their production services and they routinely create new and valuable order and structure. But even then, we have to dig deeper: do they truly insulate us from the fight against disorder and decay, or do they leak it through in batches? Each time a provider like GCP deprecates a service or makes a breaking API change, they push entropy back onto us.
Same goes for price increases. A SaaS provider brings the code within the boundaries of their own infrastructure – that is, the thermodynamic system for running and operating the code – and we have to give them energy (in the form of money, which is a store of energy) as compensation. When the price goes up, they’re changing the energy bargain we’ve made.
The four horsemen of SaaS entropy, then, are: feature velocity, operational excellence, minimal breaking changes, and price maintenance. This is the reason we prefer working with AWS over most other providers – AWS has an implicit commitment to its customers that it will do everything in its power to avoid deprecating services, breaking APIs, and making price increases. For the same reason, we hold these principles near and dear for our products, too – our customers are entrusting us to fight their business-system-related entropy, and we want to be excellent stewards of that trust.
Every time we move up the ladder to a higher-order system, we have to make some tradeoffs. When we use a library, we lose some flexibility. Maintaining the library’s order is no longer our problem, but we have to live with their decisions unless we want to maintain our own fork. When we use a managed service, we lose even more flexibility – we lose the ability to change the system’s order altogether. Our system becomes harder to test, since it isn’t self-contained, which makes development slower and riskier.
There are big tradeoffs in terms of flexibility, development speed, testing, and more, and they all add up. But on the other hand, there’s the colossus that is entropy working every single minute of every single day to erode everything we dare to build. When I take stock of it, I’d prefer just about anything to fighting the second law of thermodynamics and the inevitable heat death of the universe.
Entropy and our customers
Our overall driving metrics measure usage. I say usage and not revenue because usage begets revenue – in the world of EDI, usage is a proxy for customer value delivered, and it’s exceptionally rare for a software company to deliver customer value and find itself unable to capture some of that value for itself.
Pricing
To facilitate usage, our pricing needs to be as cheap and reliable as running water, where you wouldn’t think twice (in a developed nation, from a cost standpoint) about running the faucet continuously when brushing your teeth or washing the dishes, or worry that the water might not come out when you need it the most. If our pricing were high compared to other developer-focused, API-driven products in adjacent spaces, it would discourage usage – it makes developers think about how to minimize the use of our products, rather than maximize the use of our products. This is precisely the opposite of the behavior we want to incentivize.
There is a second reason to avoid high prices: high prices signal attractive margins to competition. Once we have like-for-like competition – which is inevitable – we’ll be forced to lower our prices; if we’re going to lower our prices in a couple of years, then the only reason to have higher prices now is to capture additional revenue for a short period of time. This sort of "temporary" revenue is short term thinking; the long-term cost of temporary revenue is that you’ve incentivized competitors to enter your space (conversely, very low prices discourage competitors from entering the space, because the revenue potential is small).
Products
To drive usage, we're also expanding our product offering.
To think about our building blocks again in terms of thermodynamics, each building block is a piece of order or structure that we’ve committed to create, maintain, and improve on behalf of our customers; our customers can outsource their fight against entropy by using our building blocks.
We currently have three Generally Available products – three building blocks – that developers can use to build business systems: EDI Core (which translates EDI into developer-friendly JSON, and vice versa), Mappings (which allows transformation of JSON format to another), and Converter (which converts XML and CSV into JSON).
There are a limited number of use cases that customers can address using only these three products – there is a large amount of entropy that customers need to maintain in order to build end-to-end use cases.
To address this, we're launching a wide-reaching range of new products (many in June) – broadly, these products allow developers to build complete, end-to-end integrations all within the Stedi platform. Those products are:
Functions: a serverless compute service to run code on Stedi's infrastructure (now in Developer Preview).
SFTP: fully managed serverless SFTP infrastructure for exchanging files at any volume (now in Developer Preview).
Stash: simple, massively scalable Key-Value store delivered as a cloud API (now in Developer Preview).
Buckets: cheap, durable object storage to accommodate any file, in any format (coming soon to Developer Preview).
Guides: EDI specifications defined in standardized JSON Schema, and accessible via API (coming soon to Developer Preview).
There's a common theme for these developer-focused building blocks: they're as simple and generic as possible (in order to be easy to adopt and flexible for the extreme heterogeneity of EDI use cases), and they're scalable – both economically and technically – so that our customers never outgrow them, no matter how large they get (or how small they start). In many cases, developers may never exceed our monthly free tiers, and incur no costs at all.
Developers can use these building blocks as standalone items for just about any business application they might need to build – or assemble them together to build powerful, flexible EDI applications and integrations. With each building block we add, the number of use cases we can support rises exponentially.
In talking about this, I’m reminded of a passage from the book Complexity by Waldrop:
“So if I have a process that can discover building blocks,” says Holland, “the combinatorics [of genetic systems] start working for me instead of against me. I can describe a great many complicated things with relatively few building blocks. The cut and try of evolution isn’t just to build a good animal, but to find good building blocks that can be put together to make many good animals.
Focus
We are here to build a world-class business – a serious, first-rate business that the entire world of commerce can depend on, and that each of us can depend on for a first-rate, exceptional professional career with an exceptional financial return. My job is to be a steward of that path.
In a letter like this, it’s easy to get lost. What is most important? What is our focus?
To that end, I’d like to share a few passages.
For six months I’ve been piecing together the puzzle of why Kenyans are such good runners. In the end there was no elixir, no running gene, no training secret that you could neatly package up and present with flashing lights and fireworks. Nothing that Nike could replicate and market as the latest running fad. No, it was too complex, yet too simple, for that. It was everything, and nothing. I list the secrets in my head: the tough, active childhood, the barefoot running, the altitude, the diet, the role models, the simple approach to training, the running camps, the focus and dedication, the desire to succeed, to change their lives, the expectation that they can win, the mental toughness, the lack of alternatives, the abundance of trails to train on, the time spent resting, the running to school, the all-pervasive running culture, the reverence for running.
When I spoke to Yannis Pitsiladis, I pushed him to put one factor above all the others. “Oh, that’s tough,” he said, thinking hard for a moment. Then he said pointedly:
“The hunger to succeed.”
Guidelines for the Leader and the Commander:
“It follows from that, that you must, through this process of discernment and storing away, create in yourself a balanced man-whereby you can handle concurrently all the different parts of the job. You don't concentrate on one and forget the other, such as maintenance; you don't concentrate on marksmanship and forget something else. The best organizations in the American Army are the organizations that are good or better in everything. They may not make many headlines, they may not be "superior" in any one thing, but they are our best organizations.”
“Successful investing requires thoughtful attention to many separate aspects, all at the same time. Omit any one and the result is likely to be less than satisfactory.”
“The art of investment has one characteristic that is not generally appreciated. A creditable, if unspectacular, result can be achieved by the lay investor with a minimum of effort and capability; but to improve this easily attainable standard requires much application and more than a trace of wisdom.”
It’s remarkable to me that when you look across so many different disciplines – sport, military, investing, and dozens more – the common theme from the people at the pinnacle of their game is that there’s no one single secret, no shortcut to being the best. It requires doing it all.
– Zack Kanter
Founder & CEO
[1] I say can lose out because it doesn't have to happen this way – every senior leader I've talked to at Amazon has pushed back on this and said that Amazon recognizes that failure to address operational toil leads to an inability to deliver value to customers. But ask any front-line Amazon employee what Amazon's #1 focus is, and they'll tell you customer obsession – when faced with delivering a feature or addressing an on-call issue, that's what comes to mind.
Below is an edited version of our internal annual letter.
Our business is the business of business systems – specifically, we offer a catalog of tools that developers can use to build integration systems for themselves and their customers.
I started Stedi, though, not just to solve the problem of business integrations – nor just to build a big business or a successful business – but to build a world-class business.
A world-class business is a business that doesn't just win a market – it defines a category, dominates a field. Its name becomes synonymous with its industry. Its hallmark characteristic is not some single milestone or achievement, but enduring success over a very long period of time.
Types of businesses
When the topic of world-class businesses comes up, someone inevitably mentions Amazon. Amazon bills itself as a customer-obsessed company. It seems sensible that customer obsession is a path to building a world-class business; customers are the lifeblood of a business – without customers, a business will cease to exist.
The problem with customer obsession is that optimizing for delivering value to customers can cause a company to make structural choices that are detrimental to the company's long term operational efficiency. A company that is inefficient becomes painful to work for; when a company becomes painful to work for, the best people leave – and when the best people leave, a company becomes disadvantaged in its pursuit of delivering value to customers. Paradoxically, customer obsession as a company's paramount operating principle can lead to a declining experience for the customer over time.
The alternative to a customer-obsessed company is a company that is operations-obsessed. The operations-obsessed company optimizes for efficient operations – it works to continuously eliminate toil.
What exactly is toil? Toil has many definitions – a popular one is from Google's SRE book:
“The kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
If "fear is the mind killer," toil is the soul-killer. Eliminating toil allows people to focus on the inherent complexity of the difficult, interesting problems at hand, rather than the incidental complexity caused by choices made along the way. Of course, most companies are neither customer- nor operations-obsessed, and, without an explicit optimization function, drift around aimlessly with middling results.
To be sure, a customer-obsessed company can also prioritize operational excellence, just as an operations-obsessed company can also – must also – prioritize delivering exceptional customer value. The difference between the two comes at the margins: when push comes to shove, what takes priority? In other words: will the company incur toil in order to further its success with customers? Or will it leave upside – that is, revenue or profit – on the table in order to further its long-term operational advantage?
Amazon is the former: a customer-obsessed company that also prioritizes operational excellence. Said in a slightly different way, Amazon is an operationally-excellent company subject to the constraint of customer demands. It is operations-obsessed up until the point that operational concerns conflict with customer demands, at which point Amazon – as a customer-obsessed company – runs the risk of prioritizing the latter. This is one reason why on-call at Amazon can get notoriously bad: when push comes to shove, operational concerns can lose out.[1]
Costco and ALDI, on the other hand, are examples of the latter: operations-obsessed companies that also excel at delivering customer value. They are customer-focused companies subject to the constraint of minimal operational overhead. When customer demands conflict with minimizing operational overhead, these companies sacrifice customer experience. This is why, as a Costco customer looking for paper towel, you have to walk through a harshly-lit warehouse with a giant shopping cart and pick a 48-pack off of a pallet – certainly not the most customer-friendly experience in the world, but in exchange for it, you get to purchase exceptional quality items at 14% over cost.
Stedi is definitively in this latter category: we are an operations-obsessed company. When push comes to shove, we are willing to leave revenue or profit on the table in order to reach ever-lower levels of operational toil.
I made this choice early on for two reasons. First, because I believe that over a long enough time horizon, an operations-obsessed company will lead to better outcomes for our customers. And second, because, well, I think it's just an enormously rewarding way to work. Eliminating toil brings me tremendous, tremendous satisfaction. If you feel the same way, you've come to the right place.
Thermodynamics and toil
Most of us have heard the first law of thermodynamics, though likely aren't familiar with it by name – it's also called the law of conservation of energy, and it states that energy can neither be created nor destroyed.
But the lesser-known second law is, in my opinion, a lot more interesting and applicable to our daily lives. The second law of thermodynamics states that entropy - the measure of disorder in a closed system – is always increasing.
What exactly does this mean? Eric Beinhocker sums it up nicely in The Origin of Wealth:
“The universe as a whole is drifting from a state of order to a state of disorder[…]over time, all order, structure, and pattern in the universe breaks down, decays, and dissipates. Cars rust, buildings crumble, mountains erode, apples rot, and cream poured into coffee dissipates until it is evenly mixed.”
The law of entropy applies to any thermodynamic system – that is, "any defined set of space, matter, energy, or information that we care to draw a box around and study." But while the total entropy – the disorder – of the universe at large is always increasing, the entropy of a given system can ebb and flow. "[A] system can use the energy and matter flowing through it to temporarily fight entropy and create order, structure, and patterns for a time[...]in [a system], there is a never-ending battle between energy-powered order creation and entropy-driven order destruction."
Stedi itself is a thermodynamic system. It imports energy in the form of capital (either from investors or from customers), which it uses to pay humans – that is, all of us – to create order and structure in the form of software that our customers can use, along with the various business systems required to support that customer-facing software.
You and I are thermodynamic systems, too – we use some of that capital to buy food, and we use the energy stored in that food to repair that damage that entropy has done since our last meal and to power the energy-hungry brain that works to build Stedi. From a thermodynamic standpoint, the food we eat becomes the intellectual assets – code, pixels, docs, emails, and more – that makes Stedi, Stedi. I think that's pretty remarkable (it's also another great reason why Stedi pays for lunch).
Anyways, some portion of our energy (your and my time, and Stedi's capital) is spent on building new order and structure, and some portion of it is dedicated to fighting the decay brought on by entropy.
Our word for this latter energy expenditure – energy expended just to stay in the same place – is toil. Our goal as a company is to spend as little energy on toil as possible, allowing us to allocate the maximum amount of energy possible to building new order and structure – that is, new value for our customers.
The practice of mitigating toil has a quality of what economists call increasing returns or agglomeration effects – the more toil we mitigate, the more attractive it is to work at Stedi, and the more attractive it is to work at Stedi, the more great people we can hire to build new order and structure and mitigate more toil, which starts the process over again.
Another way of thinking about this is that if we continue to mitigate toil wherever we find it, we'll find ourselves with ever-larger amounts of time to work on building new order and structure for our customers. That's the basic reason why an operations-obsessed business model wins out over a long enough time horizon: it's designed to minimize the surface area upon which entropy can do its work.
Ways to mitigate toil deserves its own memo, but there are two basic tactics that I wanted to touch on briefly: automation and elimination.
If you think about entropy as automatic decay, then one tactic is automatic [mitigation of] toil. One example of this is Dependabot. Dependabot doesn’t eliminate toil – rather, it employs a machine to fight automatic decay with automatic repair. Automatic repair is better than manual repair, but it’s not as good as eliminating it altogether; automation inevitably fails in one way or another, and if we’re going to disappear to a different dimension, there isn’t going to be anyone there to give our automatic decay-mitigation systems a kick when they get stuck.
Toil can be eliminated (from our thermodynamic system, at least) by drawing the system boundary a bit differently. When we use an external service instead of an external library, we’re moving the code outside of our system – thereby outsourcing the entropy-fighting toil to some third party. Not our entropy, not our problem.
As a general rule of thumb, when trying to reduce our surface area in the fight against entropy, we want to use the highest-order (that is, the lowest amount of entropy) system that satisfies our use case. A well-supported open source library is preferable to a library of our own (because the code entropy is someone else’s problem), and a managed service is preferable to open source (because fighting the code entropy and the operational entropy are someone else’s problem).
When we choose to whom and to what we outsource our fight against entropy, there are a number of questions to ask ourselves. Is the entity in question – be it a library or a service or a company – winning, losing, or standing still in the fight against entropy? Pick a GitHub library at random, and the overwhelming odds are that there hasn’t been a commit made in recent history – the library is rotting. Amongst more popular libraries, the picture is better, with brisk roadmaps and regular housekeeping.
When it comes to managed services, though, it’s quite rare to find a company that's winning – the vast majority of Software-as-a-Service companies are either treading water or falling behind. NetSuite is one example; it’s in some state approaching disrepair – no reasonable onlooker would say that NetSuite is definitively winning the war against entropy (though it certainly seems to be winning the war for market share). It has so much surface area that it has to dedicate an overwhelming percentage of its resources just to fight decay, leaving little to build new order and structure. Once a company reaches this state, it’s extraordinarily unlikely that it will ever recover.
There are certainly counterexamples, like AWS, GCP, and Stripe. They are good operational stewards of their production services and they routinely create new and valuable order and structure. But even then, we have to dig deeper: do they truly insulate us from the fight against disorder and decay, or do they leak it through in batches? Each time a provider like GCP deprecates a service or makes a breaking API change, they push entropy back onto us.
Same goes for price increases. A SaaS provider brings the code within the boundaries of their own infrastructure – that is, the thermodynamic system for running and operating the code – and we have to give them energy (in the form of money, which is a store of energy) as compensation. When the price goes up, they’re changing the energy bargain we’ve made.
The four horsemen of SaaS entropy, then, are: feature velocity, operational excellence, minimal breaking changes, and price maintenance. This is the reason we prefer working with AWS over most other providers – AWS has an implicit commitment to its customers that it will do everything in its power to avoid deprecating services, breaking APIs, and making price increases. For the same reason, we hold these principles near and dear for our products, too – our customers are entrusting us to fight their business-system-related entropy, and we want to be excellent stewards of that trust.
Every time we move up the ladder to a higher-order system, we have to make some tradeoffs. When we use a library, we lose some flexibility. Maintaining the library’s order is no longer our problem, but we have to live with their decisions unless we want to maintain our own fork. When we use a managed service, we lose even more flexibility – we lose the ability to change the system’s order altogether. Our system becomes harder to test, since it isn’t self-contained, which makes development slower and riskier.
There are big tradeoffs in terms of flexibility, development speed, testing, and more, and they all add up. But on the other hand, there’s the colossus that is entropy working every single minute of every single day to erode everything we dare to build. When I take stock of it, I’d prefer just about anything to fighting the second law of thermodynamics and the inevitable heat death of the universe.
Entropy and our customers
Our overall driving metrics measure usage. I say usage and not revenue because usage begets revenue – in the world of EDI, usage is a proxy for customer value delivered, and it’s exceptionally rare for a software company to deliver customer value and find itself unable to capture some of that value for itself.
Pricing
To facilitate usage, our pricing needs to be as cheap and reliable as running water, where you wouldn’t think twice (in a developed nation, from a cost standpoint) about running the faucet continuously when brushing your teeth or washing the dishes, or worry that the water might not come out when you need it the most. If our pricing were high compared to other developer-focused, API-driven products in adjacent spaces, it would discourage usage – it makes developers think about how to minimize the use of our products, rather than maximize the use of our products. This is precisely the opposite of the behavior we want to incentivize.
There is a second reason to avoid high prices: high prices signal attractive margins to competition. Once we have like-for-like competition – which is inevitable – we’ll be forced to lower our prices; if we’re going to lower our prices in a couple of years, then the only reason to have higher prices now is to capture additional revenue for a short period of time. This sort of "temporary" revenue is short term thinking; the long-term cost of temporary revenue is that you’ve incentivized competitors to enter your space (conversely, very low prices discourage competitors from entering the space, because the revenue potential is small).
Products
To drive usage, we're also expanding our product offering.
To think about our building blocks again in terms of thermodynamics, each building block is a piece of order or structure that we’ve committed to create, maintain, and improve on behalf of our customers; our customers can outsource their fight against entropy by using our building blocks.
We currently have three Generally Available products – three building blocks – that developers can use to build business systems: EDI Core (which translates EDI into developer-friendly JSON, and vice versa), Mappings (which allows transformation of JSON format to another), and Converter (which converts XML and CSV into JSON).
There are a limited number of use cases that customers can address using only these three products – there is a large amount of entropy that customers need to maintain in order to build end-to-end use cases.
To address this, we're launching a wide-reaching range of new products (many in June) – broadly, these products allow developers to build complete, end-to-end integrations all within the Stedi platform. Those products are:
Functions: a serverless compute service to run code on Stedi's infrastructure (now in Developer Preview).
SFTP: fully managed serverless SFTP infrastructure for exchanging files at any volume (now in Developer Preview).
Stash: simple, massively scalable Key-Value store delivered as a cloud API (now in Developer Preview).
Buckets: cheap, durable object storage to accommodate any file, in any format (coming soon to Developer Preview).
Guides: EDI specifications defined in standardized JSON Schema, and accessible via API (coming soon to Developer Preview).
There's a common theme for these developer-focused building blocks: they're as simple and generic as possible (in order to be easy to adopt and flexible for the extreme heterogeneity of EDI use cases), and they're scalable – both economically and technically – so that our customers never outgrow them, no matter how large they get (or how small they start). In many cases, developers may never exceed our monthly free tiers, and incur no costs at all.
Developers can use these building blocks as standalone items for just about any business application they might need to build – or assemble them together to build powerful, flexible EDI applications and integrations. With each building block we add, the number of use cases we can support rises exponentially.
In talking about this, I’m reminded of a passage from the book Complexity by Waldrop:
“So if I have a process that can discover building blocks,” says Holland, “the combinatorics [of genetic systems] start working for me instead of against me. I can describe a great many complicated things with relatively few building blocks. The cut and try of evolution isn’t just to build a good animal, but to find good building blocks that can be put together to make many good animals.
Focus
We are here to build a world-class business – a serious, first-rate business that the entire world of commerce can depend on, and that each of us can depend on for a first-rate, exceptional professional career with an exceptional financial return. My job is to be a steward of that path.
In a letter like this, it’s easy to get lost. What is most important? What is our focus?
To that end, I’d like to share a few passages.
For six months I’ve been piecing together the puzzle of why Kenyans are such good runners. In the end there was no elixir, no running gene, no training secret that you could neatly package up and present with flashing lights and fireworks. Nothing that Nike could replicate and market as the latest running fad. No, it was too complex, yet too simple, for that. It was everything, and nothing. I list the secrets in my head: the tough, active childhood, the barefoot running, the altitude, the diet, the role models, the simple approach to training, the running camps, the focus and dedication, the desire to succeed, to change their lives, the expectation that they can win, the mental toughness, the lack of alternatives, the abundance of trails to train on, the time spent resting, the running to school, the all-pervasive running culture, the reverence for running.
When I spoke to Yannis Pitsiladis, I pushed him to put one factor above all the others. “Oh, that’s tough,” he said, thinking hard for a moment. Then he said pointedly:
“The hunger to succeed.”
Guidelines for the Leader and the Commander:
“It follows from that, that you must, through this process of discernment and storing away, create in yourself a balanced man-whereby you can handle concurrently all the different parts of the job. You don't concentrate on one and forget the other, such as maintenance; you don't concentrate on marksmanship and forget something else. The best organizations in the American Army are the organizations that are good or better in everything. They may not make many headlines, they may not be "superior" in any one thing, but they are our best organizations.”
“Successful investing requires thoughtful attention to many separate aspects, all at the same time. Omit any one and the result is likely to be less than satisfactory.”
“The art of investment has one characteristic that is not generally appreciated. A creditable, if unspectacular, result can be achieved by the lay investor with a minimum of effort and capability; but to improve this easily attainable standard requires much application and more than a trace of wisdom.”
It’s remarkable to me that when you look across so many different disciplines – sport, military, investing, and dozens more – the common theme from the people at the pinnacle of their game is that there’s no one single secret, no shortcut to being the best. It requires doing it all.
– Zack Kanter
Founder & CEO
[1] I say can lose out because it doesn't have to happen this way – every senior leader I've talked to at Amazon has pushed back on this and said that Amazon recognizes that failure to address operational toil leads to an inability to deliver value to customers. But ask any front-line Amazon employee what Amazon's #1 focus is, and they'll tell you customer obsession – when faced with delivering a feature or addressing an on-call issue, that's what comes to mind.
Share
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.