Hi there, Matt here.
It’s been a few months since my last update, but I promise I have a good reason: I’m writing a book! There, now that I’ve said it, I can’t take it back. It’s a book about copying, using my long-form essay Copying as foundation. I’ve written about 15,000 words so far, which seems like a lot, but in the grand scheme of things is just a start. I’m hoping to share a few chapters along the way, so stay tuned.
Here’s a quick song recommendation before today’s essay: Penrose Tiling is a skittering and melodic take on drum & bass by the virtuosic Max Cooper. The title refers to the beautiful geometric curiosity featured in the linked video; if you’re interested in infinite planar tiling, you should read more about the phenomenon.
Now, on to the essay. As always, you can read it on my website if you prefer.
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 juzst 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.1
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:
The thread was swiftly and mercilessly parodied. 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.
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.”2
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.
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.
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:
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?
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:
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.
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.
Sackman, H., et al. “Exploratory Experimental Studies Comparing Online and Offline Programming Performance.” Communications of the ACM, vol. 11, no. 1, Jan. 1968, pp. 3–11. DOI.org (Crossref), doi:10.1145/362851.362858. ↩
Folklore.Org: -2000 Lines Of Code. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt. Accessed 10 May 2021. ↩