The Truth of 10X

Much has been debated about the “10X software developer” — she who can (purportedly) do the work of 10 average engineers.

The biggest problem I have with this debate is that development velocity is usually not in the top reasons why software-driven organizations/software-development projects fail. Instead of velocity, try using a more strategic measurement — such as “effectively delivering software that customers want”. Then it’s quite easy to see that some organizations do this much more than 10 times better than the average organization. I’ll call these 10X organizations for this article.

This article is for anyone who has ever wondered why their organization delivers software much less effectively than the best do — and how they might be able to get a competitive advantage through particular organizational, process, or talent improvements in their organization.

Let’s start by talking about why we have 10X organizations / why we have a big spread in effectiveness between the top 10% and the average.

In short, it is because we are finally discovering how awesome software is — that it is so quickly malleable — but we don’t yet collectively understand how to control our worst, laziest impulses in order to build effectively.

It’s worth remembering the days of all-waterfall software development, where we built software like we have to construct buildings. In those days, we planned and planned and planned, and then built and built and built, and then we had something that worked as we designed.

But that’s honestly a mediocre way to build anything. Anyone who’s designed and built a house — or even a kitchen remodel — can list off a number of things they wished they’d done differently, regardless of how much time they spent designing it and doing 3-D walkthroughs, etc.

The great thing about software — versus building construction — is that you can make changes to software much, much more cheaply and quickly. And so we started the slow process of all learning how to develop software iteratively, learning as we went, which is what we now collectively call “Agile”.

We have also been learning some the things that Agile makes a lot harder — more likely to over-engineer things badly, more likely to create technical debt as original assumptions are changed, too much temptation not to do any planning at all.

What we haven’t learned collectively yet is the negative impact that Agile has had on the highest strategic levels of the organization.

In other words, we now basically understand that Agile is easy to do wrong at a tactical/technical level, and if we keep changing requirements constantly, we’ll end up with a mess of code in substantial technical debt. And some of us have even learned that Agile works best if we actually do a decent amount of planning up front — at least trying to keep the roadmap set a couple of weeks in front of development, instead of trying to write stories as developers are coding them.

But what the vast majority of senior executives that I speak with haven’t learned yet is that Agile has made it incredibly easy for those executives to be very lazy with respect to making hard choices and setting focus.

The result seems to be that the organization can be extremely inclusive in its goals — we’ll be everything to everyone!” seems like a virtue, but it isn’t. Agile is used an excuse to drive toward very short-term goals, and the only senior executive priority is to throw gobs of people at the most urgent problems. Because software! Because Agile!

The reality is that successful organizations (and executives) are always making hard choices and setting focus — and, in particular, setting focus that isn’t 2–3 weeks out, but rather years out. Agile is wonderful, but it won’t get you what you want if you don’t yourself have a clear vision of what you want and a staff aligned and focused to reach that vision.

The rest of this article describes the key constraints that any organization needs to abide by in order to deliver software effectively — even in the age of Agile.

To deliver software that customers want, you need to start by understanding who your customer is and what problem your software solves for the customer. The most effective organizations make each product+dev team have singular focus here: one customer, one problem for that customer at a time.

Note that the definition of a customer can encompass large numbers of people, and can have many personas within that customer group, but there is a need to have homogeneity across the customer group. As soon as a team’s focus is split between different customers who have different problems (or need them to be solved differently), you are sentencing your teams to build mediocre products with hopelessly conflicting guideposts.

The 10X organization not only has individual teams focus on one customer, one problem (at a time), but also stays very close to the customer. This is one of the reasons why many have started talking about “customer development” instead of “product development”; the former necessitates close customer contact, while the latter is usually an executive who, based on a relatively small amount of customer interaction, thinks she knows the customer.

A good guide on how to do customer development correctly is Cindy Alvarez’s Lean Customer Development.

One of the reasons why there are so many great software-development tools today, whereas the tools for, say, building construction are so bad, is that the software developers making the software-development tools are the customers, and the problems they are solving are painful and real.

But the average company is building software to solve a problem that no one in the company has — and they are relying upon a terribly low-bandwidth telephone game from sales to product owner to product to engineering at best. At worst, it’s primarily relying upon 5–10 hours of conversations that the de facto product owner (who may be the CEO) has with various high-ranking people in the customer industry — probably not the target users of the software.

Common objections I hear to this one customer/one problem view are as follows:

• We are building a platform, so we have to solve multiple problems for multiple customers at once
• We are building a marketplace, so we have to solve multiple problems for multiple customers at once
• We are building a utility product that solves the same basic problem for many different customers at once

These are all false objections, and I have yet to see a company try to solve multiple problems for multiple customers with a single team at once in any way that was efficient and successful. Your competitors are truly incompetent if you can reach significant success with such a split focus.

The best solution to the first case — “we are building a platform” — is to start by solving all problems through one customer. For example, I have built SaaS for building departments before, which was a platform play: building clerks use it to handle permit workflow; building officials use it for reporting and management; building contractors use it to request permits/inspections, pay for permits/inspections, check permit/inspections status; homeowners use it to view permit histories on their homes/homes they’re interested in purchasing.

There was a very strong push to consider each of these customers and their problems semi-equally, but the far better choice to get proper adoption was to ask, “who is the most important customer in order for us to be successful, and how can we view each of the other stakeholders through that customer?”

The answer was to view the building official as the first and only customer (initially), because the building official made the go/no-go decision on whether the platform actually got up and running. Note that this is also the same basic choice that Salesforce.com made — the first customer was sales managers, not salespeople, and that still basically remains the key customer for Salesforce. Just ask any salesperson how easy/fast Salesforce is to use!

The second case — “we are building a marketplace” — may actually require that the organization tackle two different customers with two different problems — but the teams should be separate, and both should be viewed as working on different products. Each product, then, has one customer and one problem.

Many non-technical executives will think that the teams here need to be combined “because they’re all working on the same code”, but that makes about as much as sense as saying that two teams need to be merged because they’re both located in the same office and both use pens and paper. We understand quite well today how to set up automated testing, code review, APIs, branching/merging, continuous integration, etc so that it’s just not that hard for different teams to interact with similar code.

Although in practice, it should be quite easy for a marketplace to have two completely separate code bases — look at etsy, ebay, cdbaby, etc— they have distinct sections for buyers and sellers that only need to have their designers working from the same style guides and intelligent routing at the web server/proxy level.

Finally, in the third case — “we are building a utility that has a lot of different users” — unless you start with one, you’ll build something that doesn’t work particularly well for any of your users. If they are all different enough to want to talk about separately, and their problems are all a little different, then trying to build for some kind of amalgamated average means you’re building a mediocre product that doesn’t actually solve anyone’s problem in the way that they want.

And it means your competitors will eat you by picking off a customer/problem at a time. For example, consider how Instagram has taken over social photo-sharing from the more generic social sharing Facebook, or how generic freelancer marketplaces like TaskRabbit and Guru (or even Craigslist) have lost substantial volume to more specific marketplaces like Rent-a-Coder, Rover, HomeAdvisor, and even AirBnb.

So before you get to any kind of product or software development process, let alone personnel, you need to ask whether you have the kind of singular focus and clarity on customer and problem that enable you to set a product+dev team up for success.

After you have one customer and one problem, you need one product owner whose sole responsibility is to make sure that the solution you are developing solves the problem for the customer.

This job consists of three main activities: (a) having a coherent, consistent view of the application, how it works, and how it should grow over time; (b) proactively taking feedback from customers, potential customers, developers on the project, and others to continue to revise the roadmap for the application; and (c) continually communicating with designers, developers, product/project managers, and everyone working on the application to help them understand where it is going and to validate that all of the work being put into the product is taking it where it needs to go.

Being a product owner is almost always a full-time job. If the product owner is doing other things beyond the above items, unless you have a threadbare or part-time development staff, you have a product without an effective owner. If you have multiple people who are all doing the above items and they can override each other (or one person who occasionally checks in — like the CEO —and overrides the ostensible product owner directly with the development teams), then you will have an incoherent/inconsistent roadmap and you will have excessively long and inefficient development cycles at best.

Remember that you are trying to leverage the great feedback cycle that you can get from customers and Agile software development that allows you to make constant changes to make the best possible solution to the problem. It is a full-time job for the product owner to be: making sure that lots of feedback is being taken in, synthesized, turned into roadmap, being communicated to the design/development teams, and being verified/accepted once development has built. There is no good way to spread the responsibility of creating and communicating this roadmap to all of the people who need to execute on it.

There is a corollary to the single product owner here: It’s extremely important that the product owner be allowed to be wrong. With great responsibility needs to come great power, otherwise it’s not possible to make good on the requirements of responsibility.

If you have one customer and one problem, and you have one product owner who is allowed to be wrong and gets to spend all of her time thinking through what the right next steps are to solve that problem for that customer, you’re likely already very far ahead of the average organization developing software today.

Even if your software development processes and talent are below average, you will likely be more successful than your competitors at solving that problem for that customer, because of the enormous benefits of focus and clarity in leadership.

But, all things being equal, even with one customer/one problem/one product owner, one organization can still execute more than 10X more effectively than another with the right talent.

There is one thing that matters more than anything else when you are purely looking at 10X engineering: leveraging existing services so that you do not have to build them yourself. That’s right — somewhat unintuitively, the thing that distinguishes the best, fastest, most efficient engineering organizations is how little code they actually write.

They don’t write code faster than the average, and they don’t necessarily even write better code than the average. They write less code, because they’re leveraging what exists.

Perhaps the best piece that’s been written on this concept to date is a blog post from venture capitalists a16z, which asks, “How long before we have a billion-dollar acquisition offer for a one-engineer startup?”

Yet almost everywhere I go, even when I bring technologies that dramatically reduce development time, the amount of code that has to be written, and the operational needs to keep production running smoothly, I encounter extreme resistance.

For example, Algolia is a great service — it’s essentially like ElasticSearch, but it’s faster, and it has all the features that normally require that engineers write a proxy to sit in front of ES (e.g., rate-limiting calls from SPAs, limiting which data gets returned for security, etc). But the most common response I get when I build a POC in Algolia for an organization is that they re-implement that functionality in ElasticSearch.

Why? Because they know ElasticSearch. Because they can come up with some ways that Algolia is worse than ElasticSearch (e.g., dynamic sort orders), even if those aren’t critical to roadmap. Because no one is organizing the engineering function around these 10X concepts and how the organization will gain substantial business benefits from having an outsource-to-service first view of engineering.

The default rule of 10X engineering: if there’s a service out there that does the job “good enough” for the initial cut, even if it’s likely to not be sufficient for the long term, you should still use it.

Getting to market and proving out product-market fit for the solution to the problem for the customer is the key risk. The main reason most software projects fail is because they don’t reach product-market fit before the business’s ability/willingness to fund development runs out.

You can always roll your own search service/image service/authentication service/pdf-processing service once you’ve figured out why the one that lots of other organizations use won’t work for your customers. In the meantime, get to market — you might just find that your assumptions about what they need are wrong!

There’s a lot of hype today about the benefits of serverless application architectures, and it’s really just a matter of time (and better tooling and better understanding of the correct architectural patterns) before they are default.

But far more relevant to the 10X organization is what has been called by some “Serviceful” development. I presented at the first Serverlessconf on my experiences and recommendations with using lots of services (slides, video). Martin Fowler’s website entry on serverless, by Mike Roberts, touches briefly on this as “Backend-as-a-Service” which I think is only part of the picture.

So, to summarize, organizations that deliver successful software 10X faster/better than the average organization do so because they follow the following principles:

For each product + development team:

• One customer
• One problem
• One product owner
• Do as little engineering as possible

Anything else is suboptimal.