Beyond 10×

In the January 1968 issue of computer science trade magazine Communications of the ACM, a paper appeared under the unassuming title “Exploratory experimental studies comparing online and offline programming performance.” “Programming is a multibillion dollar industry,” the paper begins, but given just how much money is spent on on their salaries, nobody had yet bothered to study how programmers work. So the authors broke new ground, creating a set of experiments to measure programmer productivity. Across different skill levels, years of experience, and task types, they found “large individual differences between high and low performers.” The differences were as large as “an order of magnitude”—that is, the most effective programmers were 10 times more productive than the least effective ones.¹

The myth of the 10× programmer was born.

The Communications of the ACM paper was widely cited and spread, most notably in Fredrick Brooks’ The Mythical Man-Month. From there, it was re-interpreted and re-hashed. An infamous example from 2019 is a Twitter thread describing a 10× programmer as someone who:

1. Hates meetings
2. Works irregular hours
3. Uses a dark theme for their IDE
4. Rarely looks at help documentation
5. Etc.

The thread was swiftly parodied mercilessly. What made the parodies hit home, though, is self-awareness: we all want to be the 10× programmer. Or the 10× designer. Or the 10× product manager. I definitely want to be a 10× design leader ! Maybe then I’d get my annual reviews done without an extra weekend of work. It’d make the case for a promotion or a raise much easier; maybe I’d get invited to speak at more conferences, or be given a bigger budget, or more headcount.

I don’t think that a 1,000% increase in productivity is outrageous. It’s just a matter of looking at the problem a little differently, applying some sound (but clever) technology, and looking for the markers of a good feedback loop. In fact, with the right approach, 10× is just the start.

10× what?

First of all, let’s get something straight: no software product is built by a single person. It doesn’t matter if they’re a 10, 100, or 1,000x-er. Modern software is complex. It comprises rich features, complicated user flows, and elaborate technical systems, all coming together seamlessly. Teams, sometimes teams of teams, come together to build software by combining expertise from design, research, UI, software architecture, QA, and more. So, if we are going to consider any huge leaps in the efficiency of producing software, we have to think about the efficiency of the team.

Second, a key to unlocking productivity is to shift focus away from output and towards outcomes. One of my favorite anecdotes about this shift comes from Andy Hertzfeld: In 1982, a team at Apple was working on Lisa, the often-forgotten predecessor to the Macintosh. “Some of the managers decided,” Andy explains, “to track the progress of each individual engineer in terms of the amount of code that they wrote.” Every Friday, the programmers would submit a form recording how much code they wrote that week. The designer of the user interface, Bill Atkinson, was a prolific contributor to the codebase; one week, he completely re-wrote his UI code to be faster and more efficient, resulting in a 6x performance improvement. His rewrite also happened to be 2,000 lines shorter than the original. When filling out his productivity report for the week, he stopped at the part about lines of code. “He thought about it for a second,” Hertzfeld writes, “and then wrote in the number: -2000. I’m not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.”²

The key insight is this: what matters is your team’s outcomes, not the raw amount of work they do. Bill Atkinson’s contributions were reflected in the performance of his code and the innovativeness of his interface, not in the number of lines of code he wrote. Similarly, your team’s value is in the great things they enable your users, customers, and business stakeholders to achieve.

Moving over the line

Let’s take a look at some common tasks for a software development team, in terms of effort—how much time and energy the task takes—and outcome—the value that the task produces for users and stakeholders.

Of course, the placement of tasks in this spectrum is highly subjective and varies from team to team. But all tasks fall somewhere on this spectrum. And there’s a 45-degree angle line down the middle dividing tasks into net positive—where the value of the outcome is greater than the effort — and net negative — where the effort is greater than the outcome.

Sometimes, “10×” conversations focus too much on picking and choosing work, only doing things that have a high value-to-effort ratio. But to go beyond 10×, your team has to figure out how to move tasks from one side of the dividing line to the other. It’s important to recognize that there are times where seemingly net negative work is called for. Business requirements, legal compliance, and risk-limiting all sometimes call for work that doesn’t have a clearly positive outcome. High-performing teams know how to make any work a net positive.

And the neat thing about this paradigm shift is that net-negative work can turn net-positive two different ways: by increasing the value of the outcome, or by decreasing the effort required. The increase or decrease doesn’t have to be by much; by finding tasks on the borders, and nudging them across to be net positive, a team can transform their productivity.

One of the biggest innovations in high-performing software development teams has been the use of design systems. That’s because design systems do exactly what I’ve been outlining: they increase the value or decrease the effort of many of the common tasks that teams have to do. Some of those shifts—like reusing components — are well-known. But other shifts — like automations — are just being explored.

Increasing value through re-use

Some work can be pushed over the dividing line by increasing its value. Design systems do this primarily by allowing you to re-use the same component multiple times; every time you use a design system component, you’re driving up the value with very little extra effort.

There’s a number of ways that your design system can be geared towards re-use without a ton of effort:

• Document how to use a component, don’t just provide a mockup. A lot of design system documentation is focused on how a component looks or works. A button, say, has 10 pixels of padding, and has such and such a hover state. And while that documentation might make it easy for a developer to implement the button the first time around, it doesn’t make it any more reusable. If your design system doesn’t have it, work on documentation that helps designers and developers use your components: include the package dependencies, required configuration variables, and potential errors. Make the component easy to find in Figma or Sketch or XD, and provide some clear guidance on how it interacts with other components or plugins.
• Don’t over-specialize. Don’t over-generalize. Extremely general components — I’m looking at you, <box> — require a ton of configuration and finessing to become useful in a real-world feature. Extremely specialized components — <SecondaryAutoCompleteModalCloseButton> — will never be re-used and become a drag on maintainers. Find a sweet spot in between. I like to use the rule of three to tell me when a component is ready for the design system.
• Use systems thinking. Once your work goes from one-off specs and buildouts to reusable systems of components, you’re treading in a complex and unpredictable current. Systems thinking is a broad umbrella of tools and techniques for dealing with uncertainty. Grappling with concepts like interconnectedness, synthesis, emergence, feedback loops, and causality can help you anticipate the counterintuitive outcomes of long-lived design systems.

If you’ve spent much time with design systems, you are probably familiar with just how effective re-use can be at increasing the value of your work. But like we saw earlier, that’s not the only way to get to 10× and beyond. How do design systems decrease the effort involved with software development?

Decreasing effort through automation

Automation is a scary word. In many conversations, automation is associated with people losing their jobs to machines that can do the same work for far less money. However, in design and development, automation allows us to remove repetitive, low-effort, low-value work from our day-to-day, enabling us to work together on the high-value or high-effort end of the scale.

Automation is still a new frontier for design systems, and there’s lots to explore:

• Design tokens are ways of automating the tedious work of converting common values between different units of measurement, operating system contexts, or presentational modes. The work that was started by the folks behind Salesforce’s Theo is being continued by tools like Style Dictionary, Knapsack, Diez, and more. Recently, the W3C Design Tokens Community Group finished its first editor’s draft, signaling the start to a new phase in the standardization of design token technology. Soon, any design tool will be able to create and share tokens in a standard, interoperable way, reducing the effort required to maintain tokens between tools and teams.
• Design APIs reduce the effort required to move decisions and specifications between designers, developers, and user-facing applications. I recently went through the exercise of building a design API as a proof of concept; while the technology is still very nascent, it’s extremely promising to see how a fully automated design system can push design and code out to users with minimal effort. Tools like Specify are sprouting up to make design APIs even more accessible to teams.
• Testing and continuous integration tools like Storybook are beginning to explore what automated tests look like for design systems. By running tests for accessibility issues, design consistency, functionality, and visual regression, Storybook substantially reduces the effort required to maintain big design systems; tests run in the background as components are being built and shipped, freeing designers and developers up to focus on functionality.

If there’s one thing automation does well, it’s eliminating repetition. Some of the most frequent day-to-day tasks of collaboration between designers and developers — copying and pasting, double-checking values, inspecting and testing — all but disappear from the work with just a touch of automation. Decreasing the effort of our work, even a little, can shift our net-negative work across the line into net-positive.

Putting it all together

Forget 10×. With a focus on outcomes and an eye towards the border between net-positive and net-negative work, any team can push their productivity beyond their previous limits. And with the innovations in design systems, there is a vast array of high-leverage tools and techniques that are ready to be applied to designer-developer collaboration.

That’s why design systems are becoming instrumental to building software products: not because they look nice (some don’t) or are more elegant (most aren’t) or organized (definitely not). It’s because they make so much of our work slightly more valuable, or take slightly less effort, or some combination of both.

If you can perform one task better than most people, you might be a 10× designer or developer or product manager (or whatever you are). But if your team can find small ways to make many of their tasks net-positive, 10× is just the start.