Developer's Guide to Tech Strategy

Author's Note: This is a free chapter of the Strategy section of The Coding Career Handbook. If you liked this, come check out the rest of the topics!

This is a very high level overview of tech strategy; that is, the business of software rather than the art and science of creating software itself.

It goes without saying that your coding does not have independent value; it must be applied usefully on some economic problem to have sustainable real world impact.

Table of Contents

Tech Strategy and Your Career

Perhaps more pertinent to your career: your coding ability and, to some degree, financial outcomes, will be associated with the success of your company (we infer better coding ability in someone who was an early engineer at Uber than we do a random unknown startup, despite having no knowledge of their actual contributions).

Even if you don't care about that, and never intend to be a founder, your understanding of the business you're in allows you to offer suggestions and prioritize work in alignment with economic opportunity. It may not feel like much, but as the person closest to the code, you have a tremendous amount of autonomy to the final experience delivered:

• You make delivery estimations, and give advance warning of serious technical blockers
• You make technical tradeoffs between the "quick and dirty" way and the "right" way
• You pick abstractions for scale and pluggability vs rejecting premature abstraction
• You evaluate commercial solutions compared to the cost of a custom solution - the infamous "build vs buy" decision
• You can defensively code for every probable system failure, or understand where failures are more acceptable than their cure
• You sweat the fine A11y/UI/UX/Uptime/Response time details
• You can find the "low hanging fruit" ideas to implement, offered by your data models and pre-existing frameworks (and plugins), and can suggest them to your product owners.

As you advance in autonomy, you will even get to pick the projects you work on and to pitch new initiatives that you eventually own (this is a GREAT career move).

If you read the story of how Google Maps' Satellite view was almost named "Bird Mode", you will understand how your broad ranging powers even come right down to product names.

A well run company will not put you in this position, but when the chips are down, Developers are designers and product managers of last resort.

As you increase in seniority, you will also have to grow in your business judgment. In fact, taking a glance over every Engineering Career Ladder will tell you how important your business impact is to your career advancement.

Finally - the technologies that you work with are also strongly influenced by their economic incentives. "Free and Open Source" does not mean "Free of any commercial considerations" nor does it mean "Open Direction decided by Direct Democracy". The platforms you run on (whether it is the browsers or the public clouds, databases, payment/fulfilment platforms, or even language distributions) all have massive (I'm talking 10 figures and up in some cases) investments.

Software is Eating the World

I am assigning this to you as required reading. In 2011, Marc Andreesen wrote "Why Software is Eating the World" which set out the foundational thesis of his venture capital firm. It foretold the rise of massive software businesses in the decade since, and made the case for why every industry is now in the business of software. Marc has since updated this with takes on healthcare, biotech and crypto.

This is now widely understood in the software industry and you should at least be aware of it even if you disagree with it. (Though it does make the software engineer the center of the new world.)

Horizontal vs Vertical

The basic split in tech strategy you should be aware of is Horizontal vs Vertical businesses.

If you work on infrastructure you might be familiar with "Horizontal vs Vertical scaling". This is different. Here we are talking with respect to your customers:

• If your business is designed from the ground up to serve a single industry or customer profile, you are a Vertical business. Vertical businesses typically grow by offering more and more capabilities to serve the customers they have, despite these features existing as standalone offerings elsewhere. The goal is to be a "One Stop Shop". User experience can be mindblowing when it is vertically integrated - but frustrating when limitations arise.
• If your business can be used by customers across any industry, you are a Horizontal business. Horizontal businesses typically grow by reaching more and more kinds of customers, building any integrations required or adding knobs and configs to accommodate their usecase. The goal is to "Do One Thing Well" and be the best in the world at it.

You'll also run into two other typical analogies offered to describe this divide:

• Apple (Vertical) vs Android (Horizontal): Apple is fully vertically integrated for the high end smartphone market, from Payments, Messaging, Photos, and Operating System all the way down to Processor. Android is a free open source operating system and it is used by all sorts of phone manufacturers, and extreme customization of the launcher and widget experience is the norm.
• Bundling (Vertical) vs Unbundling (Horizontal): a reference to this famous Jim Barksdale/Marc Andreesen quote:

There are 2 ways to make money in software - bundling and unbundling.

None but the most disciplined businesses are 100% horizontal or vertical. There is usually a healthy debate within the company as to which direction to pursue, as both are valid ways to grow. But pursuing both signals lack of vision, inability to accept tradeoffs and will lead to problems in resourcing, product development and sales and marketing.

You'll also hear this idea applied to other aspects of business - Horizontal vs Vertical Integration, Horizontal vs Vertical Acquisition, and Horizontal vs Vertical Strategy. They are all variants of business expansion along one of these lines.

Business Models

The next dimension you should be aware of is business models. Quite simply, this answers the question of "who pays?", "what directly makes revenue go up?", and, not often enough, "what must you spend money on?"

The most common ones you should be aware of are Agencies, Advertising, Subscriptions, and Marketplaces. Most other companies that employ software engineers have aspects of some of these embedded within them. I cannot possibly do justice to them in the space I have here, but I will at least introduce them here and try to give you what you need to learn more.

Agencies

The Agency model is the most common one for small teams. I don't have numbers for this, but my guess is it is responsible for most tech jobs as well.

• With an agency model, you have one or more clients and you are paid for your time.
• If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client.
• If you are a consultant or freelancer, you are a one-person agency.
• There are a thousand small ways to tweak dev setups and payment terms, but broadly, as the amount of dev-hours grows, the amount of money flowing into the agency grows.

Ideally, you should be trying to get the most done per hour, but cynically, bad incentive systems can lead to just booking more hours. The common thread is that your income isn't fully pinned to the success of your client's business, which is sometimes a feature and often a bug of the Principal-Agent Problem. Despite its flaws, agencies are still so popular simply because of the sheer amount of work that needs to be done, and the specialized talent needed to do certain high-skill types of work.

Advertising

The Advertising model is next most common. Here you make money from getting more traffic to your site, or usage of your product, and selling advertiser spots.

• Sometimes the advertising is display ads (paying for Cost Per Milles - aka ears and eyeballs - just to be there and build brand awareness).
• However, most advertisers these days prefer performance based marketing - paying for directly measurable user actions e.g. Cost per Click.

Most social networks and news/opinion sites run this way, though there is an absolutely massive assortment of marketing technology to help ad buyers find the best ad inventory for them. Because end users pay nothing and advertisers pay for access, the derisive view is that "Users are the Product". However this may not always be a negative - the Wirecutter and the Points Guy are both well regarded high quality content sites that make their money from affiliate marketing, which is just a reformulation of performance based marketing.

Subscription

The next most common type of business model is Subscriptions:

• If you sell usage of your software, this is known as Software as a Service (SaaS), which is an investment category all of its own. The common characteristic of the IaaS/PaaS/SaaS models is they transform Fixed Cost to Variable Cost which provides immediate value for customers.
• Content subscriptions are the other major category, for example for audio (e.g. Spotify), video (e.g. Netflix), news (e.g. the New York Times), blogging (e.g. Stratechery), data (e.g. Crunchbase) or membership to a professional group/community. All of which require software to support them.

Since users directly pay for the software/content/membership, and can walk away at any time, the incentive alignment is clear - use subscription revenue to make a better offering, which helps drives more subscriptions, which helps finance a better offering, and so on. Since digital content can be replicated infinitely, the gross margin and therefore cashflow of these kinds of business is high. To grow, the business has to grow its marketing funnel, increase conversion rates, keep a lid on cost of content (e.g. revenue sharing with content creators), and decrease churn.

Most subscription businesses are a buffet - pay your subscription, and you can consume all-you-can-eat. This has an inherent flaw - some people just eat a whole lot more than most. This is expensive to support and essentially the lighter users subsidize their "abuse" of the platform (by bringing down average usage). Therefore all subscription business eventually start charging per-seat, and then find their way toward some form of metered billing (using some form of value metrics).

Marketplaces

Marketplaces are the hardest software businesses to build, and therefore there are fewer of them than other kinds of business. However, once established, they exhibit gobsmacking dual sided network effects, which makes them very valuable.

Marketplaces match buyer and seller, just like their offline counterparts. The marketplace gives both sides an assurance of liquidity (buyers can find what they want, sellers can sell what they have or the marketplace will die) and quality (buyers are good customers, sellers must meet standards, or they get kicked off the platform). In exchange, it takes a fee, from either the buyer or seller. Because the fee typically is a percentage of the money that changes hands, this is called a take rate and marketplaces want to grow the Gross Merchandise Volume it is based on. Take rates range wildly based on platform power - Gumroad charges 3.5% while Apple and Google's app stores take 30%.

This model sounds simple, but there are a lot of ways to make additional revenue. For example, suppliers often pay certification or listing fees, or they could instead be paid to join. It turns out that the marketplace's own site is prime ad space, while customers will pay for better service, so it is true that you can build both an entire advertising business AND an entire subscription business INSIDE a marketplace business, both of which Amazon has done.

In a way, this is the business model to end all business models, because you essentially now run your own economy.

Two final, major advantages you need to know:

• Marketplaces don't own inventory, since suppliers are the ones to bring their inventory to market. This makes them asset light, which means they can scale enormously with little investment. Airbnb offers more room nights than any hotel chain in the world without owning real estate, Uber and Lyft transport more passengers than any taxi company without owning a car.
• Large enough marketplaces drive both seller and buyer to optimize for each other - buyers want high ratings (esp when buying repeat services), sellers want great reviews. The slightest nuances of the platform - everything from picture dimensions to product offered - will be exploited to exactly meet the marketplace's needs. This not only means that buyers and sellers are optimizing for each other for free, it also makes starting a competitor marketplace extemely difficult since the investment has been made and the reputation gained.

These benefits don't come free - marketplaces are hard to build for a few reasons:

• Fakes and Disputes: Marketplaces offer an implicit or explicit guarantee of quality, which means they need a way to handle what happens when things go wrong.
  • If goods are sold, you must handle the issue of fakes, lemons, and returns. This doesn't seem fun at all, but Zappos made great return policy a competitive advantage.
  • If services are sold, you must handle the billion things that can go wrong when strangers work with strangers, and you're not around to verify what actually happened. Airbnb had to roll out a Million Dollar Liability Insurance Program to reassure hosts.
• Cutting out the Middleman: Every strong enough supplier eventually chafes at paying the take rate. At stake is not only more revenue, but also a more direct, long term relationship with the customer, free of any unfavorable changes the marketplace may make in future. For service marketplaces, buyers and sellers who like each other enough can simply take their relationship "offline". This means that buyer and seller churn is a huge problem for marketplaces, and it must provide a compelling reason for both sides to stay on even after they have found each other.
• The Chicken-and-Egg Issue (alternatively, the "cold start" problem): If there aren't enough buyers, it is not compelling for suppliers to join the platform. If there aren't enough suppliers, buyers won't even come by. A marketplace can toggle back and forth between being demand or supply constrained a few times in its life.

One way to get past many of these issues is to be your own supplier - so that you only grow the demand side of the market. You could view all ecommerce businesses as "one-sided marketplaces", although the trendy term for this is Direct to Consumer or "D2C".

Platforms and Aggregators

I've used the word "Platform" a couple times without definition. The word is horrendously overloaded, so that you can never really be sure what is meant without more context. When it comes to the business of software, though, you can do a lot worse than listen to Chamath Palihapitiya quoting Bill Gates:

I was in charge of Facebook Platform. We trumpeted it out like it was some hot shit big deal. And I remember when we raised money from Bill Gates, 3 or 4 months after — like our funding history was $5M, $83M, $500M, and then $15B. When that \$15B happened a few months after Facebook Platform(...) Gates said something along the lines of, “That’s a crock of shit. This isn’t a platform. A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.

He's right. And because Platforms are such tremendous economic centers of gravity, we need to differentiate them from your average, run-of-the-mill marketplaces (which, I hope I have established, are powerful economic engines already).

The 3 most important platforms of all time are Windows, iOS and Android. Per Ben Thompson, it's no coincidence that both are operating systems:

• Windows was the OS for the Desktop Age: Developers made apps to run on Windows, manufacturers made hardware to run Windows, which Windows again more attractive for both sides. Quoting Ben:

The end result was one of the most perfect business models ever: commoditized hardware vendors competed to make Windows computers faster and cheaper, while software developers simultaneously made those same Windows computers more capable and harder to leave.

• iOS and Android are the OS for the Mobile Age: Developers make apps for iOS and Android, users are trained to find everything via the Google and Apple Play Stores, which makes iOS and Android more attractive for both sides.

Note: Ben originally called Google Search a platform, but changed his mind as he developed his theory further.

Platforms exist on a higher level than business model - for Windows it was licensing, where for Google it is ads. Yet the 2 sided nature of a Platform makes it seem like a Marketplace, and Bill Gates' definition seems comparable to GMV.

But Platforms don't play the transaction volume game - their M.O. is to look at the most critical usecases and to build them out as subsequent products. Windows built out Office (Word, Excel, Outlook, etc), and then Windows Server. Google built GSuite (Docs, Sheets, Gmail, etc), and acquired YouTube.

A contrasting economic model to Platforms are known as Aggregators.

Aggregators

Aggregators are the main characters of Aggregation Theory, defined by Ben Thompson.

Note: If this seems strangely focused on the theories of one person, it's because Ben has shaped the entire zeitgeist of tech with this theory, to the point of being quoted at Apple keynotes - so I feel no choice but to have to introduce it to you.

Aggregators must have three characteristics:

• Direct relationship with users (payments, accounts, regular usage)
• Zero Marginal Costs for serving users
• Demand-driven Multi-sided Networks with Decreasing Acquisition Costs (aka a very specific type of the 2 sided network effect we have discussed)

Aggregators take advantage of a fundamental shift in power enabled by the Internet and the digital economy. Because the marginal cost of digital goods is zero, the ability to generate profits has shifted from companies that control the distribution of scarce resources (Suppliers) to those that control demand for abundant ones (Aggregators).

If you aggregate users, you call the shots. This means great user experience is paramount, and explains the tremendous amount of investment in web and mobile clients over the past 10 years. (One answer to why React developers are strangely in demand.)

Levels of Aggregators:

1. Supply Acquisition - they have a great user relationship, but buy their supply, e.g. Netflix and Spotify. Content cost is a concern.
2. Supply Transaction Costs - they don't buy their supply, but pay some marginal costs to bring suppliers onboard, e.g. Uber and Airbnb.
3. Zero Supply Costs - they don't buy their supply, and incur no supplier acquisition cost, e.g. Amazon.
4. Super-Aggregators - they have at least three sides - users, suppliers, advertisers, and zero marginal costs on all of them. E.g. Facebook (with Instagram), Snapchat and Google.

Platforms vs Aggregators

It can help to situate these two models by contrasting them. I'll point you to Ben's writeup on his site:

Platforms (e.g. Windows) are critical for their suppliers (e.g. Windows apps) to function, Aggregators (e.g. Google) aren't critical for their suppliers (e.g. websites) to function.

Platforms facilitate a relationship between users and 3rd-party developers, while Aggregators intermediate the relationship between users and 3rd-party developers.

Platforms help people do things (aka Bicycles for the mind), Aggregators do things for people.

To find more information, you can read Ben Thompson's body of work - be aware, his definitions changed between 2015 to 2019. Also, the commonly accepted usage of the word "Platforms" also encompasses Aggregators.

One final point is relevant for us - Both Platforms and Aggregators make it so much easier for suppliers to reach customers that it enables new types of businesses to be created atop them. Apple, Microsoft, YouTube, Amazon, Teachable and others have all minted millionaires and developers can make a great living working on them or for them.

Other Strategic Perspectives

As you might see, the analysis of what drives the rise and fall of tech companies can get very nuanced indeed. Though tech giants get all the limelight, good ideas are fractal, and you can apply them in smaller contexts within your professional network, language ecosystem, and internal company politics.

I haven't any room left but want to point you to a few more interesting dynamics you can investigate on your own:

• The funding of Open Source is always a point of contention - Open Core models are increasingly viable and benefit the developer ecosystem greatly while also being great employers. However, if your core is open, anyone can compete with you on hosting your core, so this has caused the Great Relicensing.
• Land Grab vs Organic Growth: some business opportunities must grow extremely quickly due to a Winner-Takes-Most network effect, and so should raise VC, others will always be one of many and profit and unit economics should be a core focus for bootstrapped growth. Joel Spolsky has a good introduction to this idea.
• Categorical Imperatives: I have a suspicion that software has intrinsic desires, expressed by inevitable and unimaginative customer and product manager feature requests. If you anthropomorphize the codebase you are working on and treat it as a living, breathing thing, you can think about what IT "wants". You can therefore predict what features you are going to have to build. Examples:
  • Every collaboration app wants email
  • Every data analysis app wants to be Excel
  • Every marketplace wants to be two-sided
  • Every social app wants chat
  • Every User Generated Content app wants stories
  • Every B2B app wants a dashboard
  • Everyone eventually wants a CMS

Comments

[Thomas Lombart]

Thanks for this post! I think it's essential to understand what's the business model of your company and where the money comes from. We, developers, can have huge impacts on companies, and the choices we make day-to-day should take the business goals into account.

As feedback, I found your post really insightful but also a little bit hard to read because of the vocabulary specific to the business and finance :)

[swyx]

thanks! well.. i hope people will google stuff they dont know. cant keep stopping to explain each word 😂 but when i publish i'll go over one more time to see if i can reduce jargon while still communicating the same thing.

[Julian Garamendy]

Awesome article/section!

Just wondering where do you think video games fall in the Business Models categorisation?

I'm thinking mobile games with in-app purchases (not necessarily subscriptions) that keep "customers" for years.
Candy Crush has been around for 7 years now. Is it a pay-as-you-go "subscription"?

[swyx]

mm thats a good one. you could call it a subscription but it doesnt really reflect the dynamics of the games biz - free for most and then a few whales make up the majority of the revenues. can consider it either a casino (esp if you can sell items from lootboxes), or a D2C ecommerce brand with purely virtual goods.

[Nico S___]

These are very important concepts to grasps for any developer (at any seniority level) that wishes to have a high level of autonomy in their trade.
If you fail to understand what your business needs, then someone will always have to be there to make sure you deliver it (project managers, product owners, etc)

[Amit Biswas]

Few simple things should also be considered when you are building something -

1. Is it worthwhile?
2. Is there similar thing exists? If so, how is my contribution is unique?
3. Is it beneficial for others?

If all of your answers are satisfying, proceed without fear. Your honest approach will single handedly do the rest. Even if it is a machine like Google!

[Entony]

The author really understands the topic. But I would like to ask the question what metrics are used to assess marketplace liquidity? According to the idea, they should be universal for any product. By the way, I can find a detailed description here. Or should you use a unique approach to each type of product?

[Naveen]

Woah, I wonder how much time it takes to be a specialist in this field. Thanks for all this information. Also, I would love to tell you that I am a blogger and doing some wordpress guide. It would be a lot if you give my website a look and tell me if it's good or not. Link: 9to5wordpress.com/what-is-ad-netwo...

[Jploft]

‍‍Your industry knowledge is always full of golden nuggets, Thank you for sharing this useful post. The Technical strategy serves as one of the guiding principles for the Engineering team to operate. The Technical strategy focuses on how to build the project. Technical strategy is an abstract idea for many developers who are providing software development services. Many organizations have an Engineering team but few have a well-defined technological strategy.