Reflexive AI usage is now a baseline expectation at Shopify

With these words, Shopify CEO Tobi Lütke attempted to reset the behavior of his employees. I say “attempted” because history suggests that (bad news for him) this isn’t how change happens. (Good news) there are predictable, actionable patterns for how change, particularly the adoption of technical innovations, how that change happens.

In our excitement about the new new (& believe me I’m full of excitement—coding at 3AM for the first time in decades) we forget that technologies, even revolutionary ones, don't spread instantly based on technical superiority. They grow in the medium of individual & community connections.

It’s not our first time. We enter the Wayback Machine.

Hybrid Corn

Around the beginning of the 20th century, agricultural researchers started applying the sparkling new knowledge of genetics first published by Mendel in 1866 (note we’re already 40 years along). Hybridization is cool, unintuitive, & too much to go into in detail here, but the basic idea is to in-breed 4 lines of plants for several generations, then cross-breed pairs, then cross-breed those cross breeds. Voila! 15% better yields.

15%. Same farming process. Same land. Same equipment. 15%. So every farmer started using hybrid corn, right? Right?

The first hybrid seed company was founded in 1926 (60 years). Adoption clustered in Iowa at first, then spread. By 1945, 90% of the Corn Belt was planted in hybrid seed (80 years, 20 years from commercial availability). European adoption followed in the 1950s, followed by the rest of the world in the 1960s. [ed: he says, from a naively American perspective].

The Better Mousetrap vs. The Logistic Curve

Rural sociologists Bryce Ryan and Neal Gross published “The Diffusion of Hybrid Seed Corn in Two Iowa Communities” in 1943, examining the mystery of “It’s better, why don’t they?” They interviewed 259 farmers about their adoption decisions and found:

1. Adoption Categories: Different categories of adopters follow different incentives (innovators, early adopters, majority adopters, and laggards)

2. S-Shaped Diffusion Curve: Adoption followed an S-shaped curve over time, with “slow” initial uptake, followed by rapid acceleration, then leveling off

3. Information Sources: Initial awareness sources (commercial seed dealers and salesmen) and influence sources (neighboring farmers) leading to actual adoption

4. Two-Step Flow of Communication: Information flows from external sources to opinion leaders and then to followers

5. Adoption as a Process: Adoption is not a single decision but a process with multiple stages (awareness, interest, trial, evaluation, adoption)

Economics

Money is not the only driver of adoption, but money matters. Zvi Griliches published “Hybrid Corn: An Exploration in the Economics of Technological Change” in 1957. He found:

• Adoption rates varied by region based on economic profitability

• Regions with higher expected returns adopted hybrid corn more quickly

• Adoption followed a logistic growth curve

He created a model that could predict the timing and rate of adoption based on economic variables.

The Logistic Curve

The S-shaped logistic curve is another deep dive we don’t have time for here. While there are closed form expressions of the logistic curve, I think of it in terms of a tug of war between two feedback loops. The growth side is a reinforcing loop where the bigger you grow, the easier it is to grow bigger:

Left to its own devices, growth goes (from our perspective) vertical forever. We know that doesn’t happen, though. An inhibiting loop comes along & overpowers the reinforcing loop at some point. The inhibiting loop introduces friction—the larger you grow, the harder it is to grow larger:

There’s so much more to say about this, some of which I’ve said in talking about 3X: Explore/Expand/Extract. The relevant point here is that growth follows laws & it’s way more complicated than “build a better thing & then everyone will instantly use it”.

Risk Mitigation

If you’re a peddler of innovation, as I have been for lo these decades, the logistic curve seems like friction. “But my stuff is better! Why isn’t everybody using it?” Well (and this is hard for us peddlers to swallow) maybe your stuff is better and maybe it’s not. The logistic curve protects the tribe from unintended negative consequences of innovation.

Lots of people will try lots of innovations. Yours is just one. Maybe there’s a hidden gotcha in your idea. The “slow” adoption gives the tribe the chance to explore the whole space. Sometimes this results in delays in adoption versus instantly adopting the best innovation, but the information to evaluate “best” doesn’t exist at the moment that decision would have to be made.

VHS is the price you pay for avoiding disaster.

Why AI Is Adopted Slowly

Maybe it is, maybe it isn’t. You can’t tell yet. That’s the first lesson of the logistic curve—early failure & early success look identical early.

The second lesson is that adoption follows social lines, not technical analysis. Other people like you will use an innovation when they see you using it. Or vice versa.

The third lesson is that “like you” is not homogenous. There are folks incentivized by novelty [ed: raises hand], folks incentivized by finding early advantage, folks incentivized by risk reduction, & folks incentivized to maintain the status quo.

The fourth lesson (“crossing the chasm”) is that cross-pollination between those seeking early advantage & those seeking risk mitigation is rare. Reaching that early majority requires different tactics, different messages, different market structures.

The final lesson is that all this takes time. Even if time is compressed, it’s still time. Pages will need to be pulled from calendars before lots of folks program with agents.

Predicted AI Adoption Timeline

So what would I say to the Tobi Lütkes of the world?

• It’s still early: Despite the explosion of interest in generative AI over the past year, we're likely still in the early adopter phase for most AI applications. The steep part of the curve is ahead of us, not behind us.

• Social: The most effective driver of AI adoption isn't better models or improved accuracy—it's success stories from peers and respected figures in professional networks. Rather than push AI, encourage communities that will push AI.

• Time: Organizations need time to adapt workflows, retrain staff, address valid concerns, and develop the complementary skills needed to extract value from AI.

• Malicious compliance: The implied threat in the opening quote means that the downside of appearing not to use AI is a more powerful motivator than the upside of actually using it. Beware of getting what you asked for in ways that interfere with what you actually want.

Surfing the Logistic Wave

The logistic curve isn't a limitation to overcome, it's a rhythm to understand and work with.

To my frustrated “everybody in 18 months” friends: vibe coding isn't failing, it's growing. Naturally. The S-curve is the shape of success. But it won’t be 18 months. It’s both already here & it’ll take a decade.

Like the hybrid corn that transformed agriculture field by field, farm by farm, the truly transformative AI applications will spread not through marketing campaigns or technical superiority alone, but through the social fabric that connects us all, one trusted relationship at a time.

Here is the Claude chat I used as research for this piece: https://claude.ai/share/2d0e502d-c1a7-4e06-bb4f-d3e91fded2e0

First published November 2016

I’m hearing many stories about performance review cycles and the incentives they create, but I’m also getting a very reasonable question: what should we do now? Here’s an immediate suggestion.

Thanks to today’s sponsor Unblocked.

When I was a young programmer we were berated for not writing more documentation, but that documentation always turned out to be useless by the time we needed it. That experience was my impetus for writing about communicative code (Smalltalk Best Practice Patterns & Implementation Patterns).

Unblocked meets the same need in the same moment--I have to change this code but what is going on? Unblocked answers this question with less effort on the part of the original programmer & the answers are always up-to-date.

Performance review is a lousy planning tool [ed: see also predicted key results in OKRs], because it:

• Requires that you predict the unpredictable

• Attribute all impact to an individual

• Slice impact to fit into six months. Then five. Then four...

What if you and your team used performance review retrospectively? Engineer the way you should engineer together:

• Balance long- and short-term

• Balance features and quality

• Help each other

• Experiment cheaply

• Dig in hard when you find value.

Then, at the end of the cycle you all sit down together and divide up the pie. Y’all know how to engineer.

This only works if everyone on the team does it. One “free rider” will ruin it for everyone. The manager needs to accept the responsibility for keeping the team roped together & telling everyone’s individual story at review time.

Every once in a while this is going to backfire. You won’t have enough impact or as much impact as you’d like. As a way to bet, though, it’s likelier that you will have more stories to tell at the end of the cycle this way than if you divide up a non-existent pie before you start.

My point is that he looked at terrain completely differently from how I looked at terrain. I’d see a hill & think, “Well, I’ve got to go around that.” He’d look at a hill & think of all the different places he could put it, all the shapes he could leave it in.

Warning: In what follows my main point is about digging into what I call background work more frequently because it’s become so much cheaper & easier. That seems to get lost in the example I chose—AI potentially replacing programmers—& the means I chose for analysis—namely Claude. Neither AI vis a vis programmer employment nor LLM hallucination invalidate my main point—be more curious, it’s cheaper now.

Analysis

When I had the impulse to use Thinkie Reverse Causality on the relationship between employee count & revenue, the subsequent analysis took most of a day. I was digging data out of SEC filings, figuring out how to render the data, iterating on the analysis.

All this is hard enough work that I hesitate to undertake it more than once a month. I think, “I wonder…”, grimace 😬, & move along. Those “I wonder” moments are what I need to change. Analysis just got cheaper.

I posted the following on LinkedIn the other day.

60K impressions, 480 likes, 80 comments & here’s the thing—nobody did the assignment. Nobody drafted a before & after income statement & balance sheet. This is the moment I’m trying to call out. Because it’s easy now to start to do the assignment.

Claude’s Answer

I asked Claude the same question. A minute later I got this. Of course the analysis is shallow & flawed. Not the point! What I have here is good enough to decide whether I want to dig deeper.

That same moment, that “gotta go around this hill” moment, has changed. We can now decide to routinely dig into analysis that would have been too expensive to even start previously.

Financial Impact Analysis: Tech Company Before & After AI-Enabled Staff Reduction

Base Assumptions

• 50% reduction in software engineering headcount

• Maintained productivity through AI augmentation

• Using average tech company compensation metrics from 2023

• Analysis based on public financial data from major software companies

Income Statement Impact

(All figures in millions USD)

Before AI Implementation

After AI Implementation

Balance Sheet Impact

(Key changes only)

Assets

• Increase in Cash (+$150M annually from improved operating income)

• New Intangible Assets: AI software licenses & implementation costs

• Potential reduction in office space & equipment

• One-time increase in restructuring reserves for severance

Liabilities

• New technology lease obligations or licensing payables

• One-time increase in severance liabilities

• Reduced ongoing compensation liabilities

Real-World Examples

Microsoft (2023)

• Laid off 10,000 employees (~5% of workforce)

• Reported $1.2B in severance costs

• Maintained revenue growth while reducing headcount

• Invested heavily in AI infrastructure

Meta (2022-2023)

• Cut 21,000 jobs

• Saved $1B+ in annual costs

• Maintained user growth and ad revenue

• Increased AI investment by $4B

IBM (2020-2023)

• Ongoing restructuring with AI focus

• ~$1.5B average annual savings from automation

• Reinvested savings into AI/cloud capabilities

• Maintained service delivery with reduced headcount

Emotional Burps

20 years of the internet have trained us to respond purely emotionally. Look at the comments on my original post.

Business is about maximizing profits..however that can be achieved..

Generating tonnes of code via GenAI, claim tax relief as R&D, huge balance sheet assets, inflated valuation, sell to clueless investors, profit 💰💰💰

But the code is unmanageable and riddled with 0-day vulnerabilities.

The best trick that engineering has pulled off to date is to convince marketing that what amounts to a glorified guessing game - one that consumes energy like it's mining cryptocurrency - is, in fact, a manifestation of intelligence.

Again! Nobody did the assignment! We have gotten into the habit of responding in emotional burps instead of doing the work. I’m noting, not blaming. The incentives encourage burping—burping is less effort with more upside if you spark outrage.

Caveats

If you’re going to do this kind of analysis, be responsible.

• Make progressive investments. Spend the first 5 minutes finding out if the next hour is going to be worth it. Spend the hour finding out if a day will be worth it.

• Double check everything. Make sure numbers add up. I fed Claude’s analysis to Perplexity & got good pointers for where to follow up.

• Publish your results. Write up what you find. Whether people are interested or not, writing will accelerate your learning.

But for goodness sake, dig in! It’s cheaper now, more fun, & potentially accelerates our collective learning. We no longer have to steer around “I wonder”s. We can plow right through them.

P.S.

When I said a while back “the economic value of 90% of my skills just went to $0 but the value of the other 10% just increased by 1000X”, people reasonably asked, “What’s the 10%” & I reasonably responded, “How would I know?” The above is an example of that 10%—asking good “I wonder” questions & then following up.

Insurance activates otherwise-idle resources for socially productive purposes. People need houses. Banks have money. The risk that a house will burn down & leave the bank with a loss, though, rationally prevents banks from lending.

Home-owner’s insurance comes along & transforms risk into opportunity. Now the bank’s risk of loss disappears. The bank writes the loan. People get a house. Contractors get work. The bank locks in a profit. Society benefits. (There are benefits to the policy holder too, but that’s not today’s topic.)

Try a more personal case—an entrepreneur who happens to be a cancer survivor. They have an idea that could create social value. The bank has money to lend. The bank, though, responsibly takes into account the increased risk that the entrepreneur will die during the term of the loan & leave the bank with a loss.

Again, insurance transforms risk into opportunity. By taking out a life insurance policy with the bank as the beneficiary, the bank can now lend, the entrepreneur can start their business, society benefits.

Reality

That’s the theory. In reality, the entrepreneur is unlikely to find coverage. Insurance companies, following a rational series of decisions I outline below, have for decades continually reduced the risks they cover, and so fail to fulfill their social purpose.

For example, according to the terms of my divorce agreement, I’m obligated to carry $1 million in life insurance coverage with my ex-wife as the beneficiary. Here’s what it looks like when I’m shopping for a policy.

I naturally want to pay as little as possible for this coverage, so I pick the vendor at the top. Turns out I’m not alone —the vast majority of shoppers [what is the percentage?] choose the cheapest policy. Why not? The service is a commodity.

Imagine you’re an insurance company. You want to make more sales. You have to lower prices to get that coveted top spot.

(Read this is as: we push price down because that strongly effects ranking going up which strongly affects sales going up.)

You can’t, though, in good faith or in fear of regulators, just lower your prices below profitability.

(Read this as: also, as price goes down, our chance of survival goes down. Whoopsie!)

What other levers are there? Another way to lower prices without affecting profit or survival is to take on less risk.

Those low prices are an illusion to me as a customer. The policy offered by the cheapest vendor requires that I prove that I’m not taking any risks. Not big risks like bungee jumping or hang gliding. I won’t be able to actually get a policy if I mountain bike. Or work on a container ship. Or god forbid that I actually survived cancer. The smallest additional risk increases prices & results in the vendor selling drastically fewer policies. The vendor excludes all possible risks.

Industry

If just one vendor faced these incentives, the industry as a whole would still create social value. However, every insurance company is trapped in the same game. In the struggle to claim that productive top spot, all insurance companies tend towards only writing policies for people who won’t conceivably submit a claim.

Both companies face the same incentives. But sales are (to a first approximation) a zero-sum game.

So we make the counter move & shave off even more risk to get back that coveted top spot.

But that cuts into our competitor’s sales, so they risk shave too.

It’s at this point in a system diagram that I like to simplify. In short, the less risk we take, the less risk they take, all mediated through this “cheapest take all” sales process.

Every insurance company is part of this system. Collectively, the industry is shaving off the risk that could be turned into opportunity. The social benefit for which insurance was created is vanishing.

The companies aren’t doing anything morally wrong. If I was a short-term investor I would insist that they behave exactly as they are. What emerges from all of these rational decisions, though, is an industry failing society.

Remedy

One solution is to offer coverage for actual people, not for a theoretically perfectly safe customer. For example, SquareLife, Check24, and DeHoop have combined to offer individually priced life insurance in Germany. Every applicant is separately underwritten & priced. The result is a fair price for the risk & a sustainable business for the vendors. The combination of vendors is powerful:

• DeHoop has spent the century underwriting non-standard risk, precisely to expand the social benefit of insurance.

• Check24 is Europe’s largest comparison shopping site.

• SquareLife efficiently administers special-purpose insurance policies.

Instead of being told, “Sorry, no insurance for you. You have a mildly risky job.”, these vendors can take into account significant health risks like addiction, obesity, or previous conditions & still write policies.

It is hard work to scale custom underwriting. However, it is possible. Without covering actual risk, the insurance industry risks social irrelevance. The insurance industry needs to abandon commoditization, embrace insuring actual people, & activate idle assets for society.

It’s always good news when I find a reinforcing loop that just happens to be running backwards from my goal. Reversing a reinforcing loop is a powerful lever for creating large changes to behavior with small changes to inputs. However, the system will have to change for society to recover the promised benefits of insurance.

“Yeah, I totally agree. I mean, look, the other piece of this is, some engineers aren't customer-facing ready. And I mean, no offense, but the neckbeard types, and there's a few people with ASD in our world, and that's okay.

That's great. I mean, it takes all kinds. And it's probably extremely uncomfortable for some of those people to do that.”

From CTO Insights Podcast: Mastering the CTO Role with Drew Falkman, Sep 13, 2024

This material may be protected by copyright.

I had to stop listening. Walk faster. Stop for breakfast. Walk some more.

Of all the arrogant, contemptuous, infantilizing, narrow-minded, self-centered things to say. In 2024.

Here’s what I heard:

Compassion

Okay, anger is a reminder to defend one’s boundaries. I’ve heard that reminder. I’m about to defend my boundaries, but with compassion & constructive conversation. Contempt is also a reminder, a reminder of self-doubt.

I don’t know the folks involved in the podcast personally, so I can only speculate & extrapolate from my own experience. In my experience, product people who try to “protect” customers from programmers (or is it protect programmers from customers, I can never quite tell?) seem insecure about the value they bring to the whole team. If every request doesn’t filter through them, well, then what are they adding? If they don’t make the priority decisions, well, then maybe they are superfluous to the process.

Hey, product folks, I see you. You’re going to be okay. You have substantial contributions to make to software development. Just not like this.

Programmers Are People

I’m not going to go on & on here. I wanted to be sure to plant my flag on the subject. Here’s the thing—direct contact between programmers & customers of all kinds is a powerful tool:

• Programmers understanding the nuances of users needs can make small adjustments that have large outcomes.

• Programmers gain emotional energy from seeing the consequences of their work. This energy turns into better results.

• Programmers understanding the cost of features can identify subtle opportunities for features in conversation with customers.

I’m not saying it’s a free-for-all, just throw the programmers & customers together (well, actually I am saying that—see also XP—but only after thorough preparation). Help programmers learn customer communication skills, what kinds of things to say & what kinds of things not to say (I’m still learning these lessons).

The comment above about autists is both ignorant & condescending. My sense is that while autists are often drawn to programming, the density has diminished over the years as more normies become programmers. And the autists can also learn communication skills, so that’s a dumb excuse.

My metaphor for product leadership is less chess player moving helpless pieces & more party host. “You really should talk to so-and-so! I think you’d really get along.” Keep a sense of the mood of the party, where & how to intervene.

Responsibility

I’ll finish with a cautionary word to anyone who has a platform. Don’t say stupid shit, discriminatory shit, contemptuous shit. Your platform comes with responsibility. You won’t feel the consequences of your mistakes, so you need to make yourself feel those consequences. Otherwise you’re running open loop & that never ends well.

Peace.

• When should they be run?

• How long?

• What topics?

• How big a team?

• What questions?

People

Hang on. We’re missing the point here. What fundamental human need is met by a morning standup? Not what does the team need or the organization need or the users need. The geeks, when they meet in the morning, what’s going on?

It’s tempting to view the activities of a software development team as a kind of board full of knobs/levers/gauges. Too many bugs? Turn up the tests. Not enough responsiveness? Plan more often.

While practices do have observable effects, there is a deeper, more human & humane, interpretation of the activities of software development. We aren’t engineers in a giant, insubstantial locomotive. We’re people. Dealing with people.

Person → Teammate

Capitalism requires code switching. From the close of business one day to the start of business the next, we are parents, spouses, musicians, writers, runners, movie critics, comedians. Then when that whistle blows in the morning, we are instantly transformed into workers & teammates. Our individual goals & aspirations & skills are seconded to the team, to a degree & for a while.

I’m not going to guess which one of these sets of roles is Bruce Banner & which is The Hulk for you, but the transition between is painful. It may be the sort of pain we just get used to & so pretend it doesn’t exist, but it’s still there.

That’s what the standup meeting is there for—to give everyone a moment to say, “Oh, yeah, okay, these people & their needs are going to be important to me for the next 9 hours.” Take a breath. Get to work.

Different contexts will require different approaches to this transition. If the team is co-located & used to showing up at around the same time & pairs switch frequently & folks gather around the espresso maker most mornings, then maybe folks don’t need a ritual to manage the transition from person to worker. If the team is fully remote & in different timezones & just getting used to each other then likely yes, the need for ritual supporting the transition is greater (also harder because of the time shifts, which is why Mechanical Orchard teams tend to be organized by longitude).

At Gusto a group of us used to gather by the coffee machines & give everyone walking to their morning coffee a giant “woo woo” & an arm wave. If you’re looking for efficiency, that’s a damned efficient way to get folks out of “me” mode & into “us” mode. Doesn’t look great from a bits/person/second metric but hey metrics don’t tell the whole story.

Treating standup meetings as a technical solution to a technical problem—we need to communicate this many bits of information to this many people as efficiently as possible—misses the real point. We’re people. With needs. The better those needs are met, the better we can meet the needs of others.

As with all short takes, I elided nuance to keep the word count down. Below’s a more thorough treatment of how I see documentation & when to write it.

Straw Arguments

“Irresponsible”. It is the responsibility of all programmers to communicate effectively with their colleagues (and their future self). Even if the business doesn’t ask you to communicate, or actively discourages you from taking the time to communicate, programmers have a duty of care to communicate. I’m not saying “don’t communicate”. I’m saying think about the tradeoffs when you consider what & how to communicate.

“No documentation”. I didn’t say “no documentation”. People reasonably commented:

I don’t have a problem with that level of documentation.

“Self-documenting code”. Not what I’m advocating. Near as I can tell, “self-documenting code” was invented as yet another excuse for programmers not to have to talk to other people. Yes, communicating through code is one of the media we should get good at using, but that’s different than whistling past “self-documenting”.

Cycle

I’ll admit to being triggered by the calls for more documentation. It’s part of the neo-waterfall movement rising recently.

• Just write the specification first, then development will go more smoothly.

• Design up front, then development will go more smoothly.

• Have product people pick the features & hand them to programmers, then development will go more smoothly.

• Don’t waste programmers’ time with tests. Have a QA department test, then development will go more smoothly.

(One wonders if “development goes more smoothly” is just the wrong goal, but that’s a topic for another day.)

I’ve been through this documentation story before. I can predict how it ends. By the time you read the documentation it’s out of sync with the code so you end up reading the code anyway. But then you feel bad, so you write more documentation & force yourself to update documentation whenever the code changes. But that takes time away from development & the pressure is on, so you stop writing/updating. So the next time you read the docs they don’t help. Damned if you do, damned if you don’t.

The more documentation the greater the burden, the greater the burden the less useful the documentation.

As I said up front, I’m not anti-documentation, I’m just anti-authority-misaligned-with-responsibility calls for more documentation.

Tradeoff

Just as every line of code you write should be justified in some way, every document you write should be justified. Here are the factors that create the sweet spot for a document:

• Large audience. Erich & I happily wrote Javadoc for JUnit because we had hundreds of thousands of users. If we were writing for 3 colleagues, then we could just explain stuff in person.

• Stability. If the information conveyed doesn’t change much, then documentation costs less to write/update. After the first couple of years, the JUnit API stabilized, so documenting was also stable.

• Low cost of delay. If you could be writing another user experiment potentially unlocking 50% growth & instead you stop to write docs, then that’s an exorbitantly expensive document.

Alternatives

I started by saying that communication is a programming imperative. What else is a programmer to do to communicate besides writing documents?

• Simplify. As someone who has spent thousands of hours writing literate programs, I appreciate the moment when I have to choose between explaining something unnecessarily complicated & removing the unnecessary complication. To paraphrase the quote about pilots, the superior programmer exercises superior design skills to avoid having to exercise superior communication skills.

• Socialize. Pairing. Whiteboarding. Story-telling over lunch. We humans have used social methods for millennia to communicate our most sacred concepts.

• Test. Passing tests are guaranteed to be in sync with the code. If you focus on tests as a communication medium as well as a double-check on system health, you can make them speak.

• Code. Likewise, focusing on code as a communication medium yields, surprise, surprise, better communication. (I’ve written 2 books on the subject.)

In the end, write the docs you want to write. If no one reads them, or if readers find they are out of date, then consider not writing them next time. But don’t let anyone shame you into wasting time. The question is not, “Do you have documentation?” but rather, “Do you communicate clearly?”

I find it ironic that calls to increase documentation come just at the moment that LLMs are getting good at explaining code. At Mechanical Orchard we’ve developed some amazing internal tools to answer our questions about legacy mainframe code. These tools are only going to improve. The one part of software development that LLMs are clearly better at than humans is one task reactionaries have latched onto.

I’ve had a couple of followups about the coming price increase. Subscribe now & pay the current price forever (well, as long as the newsletter lasts) (and as long as you want to keep reading). On Monday the price goes to $25/month or $250/year, in line with other professionally-oriented newsletters.

That’s not what I want to talk about, though. I want to reflect here on a huge misunderstanding I’ve been carrying for 62 years about human motivation, how my mistaken belief has held me back from business prosperity, & what I’m going to do about what I’ve learned.

Naive Model

Here’s how I thought this newsletter would work. I would create some valuable stuff & charge people for it. More value, more money. (You can also change the slope of the line through better marketing & sales, but that’s way outside my bailiwick.)

“The margin” is one of the great concepts of economics—there are some people who will transact for sure, others who will never transact, & a gray area in the middle. Move the margin & some folks will transact who wouldn’t have before.

Once I focused on creating a sustainable business model for this newsletter, my investment became clear—create more value. More value, more customers. More customers, more revenue. More revenue, more focus on stuff that matters to living a good life.

The more value → more revenue → more sustainability strategy kind of worked. Over the past six months I poured myself into the newsletter, optimized everything I could find to optimize, experimented with different formats & topics. On the scale of my financial milestones the results still weren’t significant, which led to the strategy not being sustainable, but it kind of worked.

Intervention

As part of my optimization, one of my advisers asked me, “Why $7/month? That’s pricing for personal newsletters. Anything that gets expensed is going for $20+/month.” I didn’t have anything to lose, really. I was running out of energy for just trying to pump up the value. May as well try raising prices. (I didn’t consciously choose the $7/month price. It was Substack’s default. I was just trying to shame myself into finishing Tidy First?.)

Two weeks ago I announced the price increase. The results astounded me. Here, I’ll just show you the graph.

Nothing I’ve done to “create more value” has had anywhere near as big an effect on my business than this. 40% increase in 2 weeks. People, apparently, don’t make decisions the way I thought they made decisions.

I was imagining someone “on the margin”, thinking, “Yeah, there’s some value, but not enough.” Then they see more value. Then they think, “Yeah, okay, I’ll sign up.” Nope. Not according to the data.

Re-Interpretation

More value didn’t result in more sign-ups. It was more like, “If I don’t sign up now for this price, it’s going to cost more more later.”

One of the Thinkies (Thinkies are habits of creative thought that I’ve gathered—I publish one to paying subscribers every Tuesday) is called Trust the Market. If the market is acting in a way that doesn’t make sense, back up & ask yourself what would have to be true for the market to be right & you to be wrong. (Markets can be wrong, to be sure, this is just a way to generate an idea that will then be evaluated.)

Folks signing up recently already knew about the value. They are converting from unpaid subscribers. The value didn’t change. Now, though, something is worth $7/month that wasn’t worth it before. What?

This kind of thinking is really, really hard for me. People & their motivations are mostly opaque to me. Not just opaque, actively camouflaged. Cloaked.

I’ll give it a whirl, but this is really raw thinking. One possibility is that they knew that they could sign up at the current price. Now they are faced with the possibility that they couldn’t justify signing up at the new price. They avoid the loss by signing up today.

“I could sign up today & get value but never mind. Oh, I might not be able to sign up tomorrow? I’d better sign up today!”

I think I’ve rediscovered the Going Out Of Business Sale.

Ethics

There are (at least) 2 sets of needs to care for in this situation:

• My need for a sustainable business

• Subscribers’ needs for, well, learning & skills & community & encouragement & …

What I don’t want to do is any of my grandfather’s sleazy car sales stuff. I don’t want to use fear to get my needs met at the expense of subscribers. I don’t want anyone to sign up who is making an objectively bad decision by signing up.

At the same time I’d like everyone to sign up who would genuinely benefit. I suspect that is far more people than have signed up so far.

Next?

First, I’m going through with the price increase Monday as planned. No reason not to. Upside with no downside. Part of me is worried that new signups will drop to zero, but okay. Get your employer to pay for it, folks! They are reaping the rewards!

Second, in a couple of weeks I’ll send a discount coupon with an expiration date so folks who didn’t get $7/month can still pay less than $25/month. (For this to be effective I shouldn’t tell y’all this, but whatever.)

Third, I’m going to think about what I’ve learned about human motivation & decision making. I want to understand how it affects my own decisions. I want to understand how to use the information for mutual benefit. I want to understand the perverse incentives it creates & how to avoid them.

If you read today’s blog post on measuring productivity as a tradeoff, I invite you to interact with a model trained on some of my previous writings but more particularly that post. Here it is.

Have at it! Ask t…

Read more

Good news: there are effective ways to address the needs of all involved—engineers, managers, executives, & customers

The desire to measure engineering productivity expresses a genuine human need. The problem is that trying to meet that need through metrics or even surveys inevitably poisons the data on which productivity measurement relies. Let’s dive into the structure of this dilemma before talking about the actual needs & how they can actually be addressed.

Tradeoffs

Paying subscribers to Tidy First? receive weekly Thinkies, habits of creative thought I’ve collected. Lately I’ve been particularly interested in thinking in terms of tradeoffs. Tradeoffs have a surprisingly subtle structure, leading me to write a booklet diving into the details (also available to paying subscribers).

Subscribe now

Measuring engineering productivity is an excellent example of a tradeoff. It has all the anatomical elements of a tradeoff:

• A goal to be improved upon—reducing wasted effort.

• A continuum of possibilities for addressing the goal—measurement from none to surveys to increasingly detailed metrics.

• A response curve—how much waste you expect to eliminate for each of interventions.

• A counter response curve—waste created because you went too far

Graphically, it can be rendered like this:

Seems sensible—diminishing marginal returns & increasing overhead for greater measurement precision. Sensible but wildly wrong.

Better Picture

The response curves:

• Are the wrong shape.

• Are out of proportion.

• The counter-response curve in particular misses gigantic effects.

The potential gains from productivity improvement aren’t infinite. You have an organization now. You have customers now. You’re doing something. It works. Some.

If you kept improving for years, yes you might make dramatic improvements, but that will come through all kinds of interventions, not just measuring productivity. Measuring & responding may net a win but then the bottleneck will move elsewhere.

Overhead & analysis remain. Who knows their magnitude compared to the potential efficiency gains. I’ll just make them similar. Draw your own curves for your own tradeoff.

As soon as metrics have consequences, gaming begins. Goodhart’s Law kicks in1. The cost rises as people spend effort gaming the system instead of doing useful work. Also, the distortion of the measurement reduces any value to be derived.

Note that it’s hard to catch gaming, exactly because it’s intended to be invisible to operation of the metrics. How much effort do you want to expand catching cheaters instead of setting up a system where cheating doesn’t make sense?

Precise measurement rises further. As departments’ incentives diverge, the incentive to collaborate diminishes. Why would I make you look good if that’s going to make me look worse by comparison? Work that would have been done together for mutual benefit ceases.

Again, these costs are completely off the books, unaccounted for. Engineering just seems slow. I know! Moar mezzures!

Alternative

The most surprising lesson for me about the whole “measuring engineering productivity” conversation has been trying to get a straight answer to the question of, “Why?” As an engineer I get why I would want to measure my own efforts—I want to improve & I can improve faster if I know what I’m currently doing. I have no incentive to game the system. I can balance how much I want to invest in doing my work versus analyzing how I do my work.

That’s not who McKinsey is talking to. The case that keeps getting quietly mentioned is a board meeting. Sales & Engineering have both asked for more budget. Sales says, “We get $1m of sales per person, each of whom costs $500K. Give us $20m & we’ll deliver $40m in additional revenue.” Engineering says, “Um, yeah, well, uh, we need more headcount mumble mumble technical debt mumble scaling mumble keeping the lights on.” Uncomfortable!

Another way this scenario is introduced is, “The CFO wants to know if they are getting their money’s worth from Engineering.” If I was the VP Engineering in that room, I’d want to be able to answer that question. The CFO has a genuine need. The VP Eng has a genuine need. “Measuring” “productivity” may seem to meet those needs, but at enormous cost.

What’s the alternative? Listening & thinking. The best executives I’ve worked with used data, yes, but they always had direct connection to the work. They had a diverse group of individual contributors they talked to on a regular basis. Trusted relationships let them identify misaligned & perverse incentives. It may seem like scaling requires interacting with abstractions like charts & graphs, but relying solely on abstractions puts you at the mercy of whoever creates those abstractions. They have their own agenda & it might not match yours.

At Facebook we [Kent here] instituted the sorts of surveys McKinsey recommends. That was good for about a year. The surveys provided valuable feedback about the current state of developer sentiment.

Then folks decided that they wanted to make the survey results more legible so they could track trends over time. They computed an overall score from the survey. A 4.5 became a 4. What happened? Very reasonable thing to do. That was good for another year

Then those scores started cropping up in performance reviews, just as a "and they are doing such a good job that their score is 4.5". That was good for another year. 

Then those scores became goals. “Move from 4.2 to 4.5 during this performance review period.” And the scores started getting rolled up. A manager’s score was the average of their reports’ scores. A director's score was the average of their reporting managers’ scores. 

Now things started getting unhinged. Directors put pressure on managers for better scores. Managers started negotiating with individual contributors for better survey scores. “Give me a 5 & I’ll make sure you get an ‘exceeds expectations’.” Directors started cutting managers & teams with poor scores, whether those cuts made organizational sense or not.

Things went from, “we’d like to know how things are going,” to, “we know even less about how things are going. But they are definitely going worse because people are now gaming the system.” How did this occur? Well, because we started to measure & incentivize (with money & status) changes in the measures! And measuring leads to behavior change – behavior change including coming up with creative ways to improve those measurement scores even at the expense of results that everyone agrees matter.

In this two-part article, we seek to arm engineering leaders with perspectives to the question: Can you measure developer productivity? It’s the sum of our viewpoints, professional experiences, and what we’ve seen work, firsthand:

• Kent Beck brings 40 years of software engineering experience, and has tried, failed, and tried again to measure developer productivity for almost all this time.

• Gergely Orosz brings 15 years of software engineering experience, including 5 years’ managing engineering teams.

Two weeks ago, McKinsey published the article “Yes, you can measure software developer productivity.” In it, the company claimed it has an approach for measuring software developer productivity that nearly 20 companies already use, and that the consultancy is ready to extend the roll out of the custom approach.

As tempting as it is, we won’t go into a detailed critique of the McKinsey article and the measurement methodology. The thinking that’s evident in the article is absurdly naive and ignores the dynamics of high-performing software engineering teams. But it was written for a reason: CEOs and CFOs are increasingly frustrated by CTOs throwing up their hands and saying software engineering is too nuanced to measure, when sales teams have individual measurements and quotas to hit, as do recruitment teams in the number of positions to fill. The executive reasoning goes: if other groups can measure individual performance, it’s absurd that engineering cannot.

The reality is engineering leaders cannot avoid the question of how to measure developer productivity, today. If they try to, they risk the CEO or CFO turning instead to McKinsey, who will bring their custom framework, deploy it – even as the CTO protests – and start reporting on custom McKinsey metrics like “Developer Velocity Benchmark Index,” “Contribution Analysis,” and “Talent Capability.” 

We believe that introducing such a framework is wrong-headed and certain to backfire. The McKinsey framework will most likely do far more harm than good to organizations – and to the engineering culture at companies. Such damage could take years to undo. So let’s get around to answering this question without evasion, and give demanding CEOs and CFOs what they want.

We cover:

• A mental model of the software engineering cycle

• Where does the need for measuring productivity come from?

• How do sales and recruitment measure productivity so accurately?

• Measurement tradeoffs in software engineering

Who is this article for? We wrote this article for software developers and engineering leaders, and anybody who cares about nurturing high-performing software development teams. By “high performing” we mean teams where developers satisfy their customers, feel good about coming to work, and don’t feel like they’re constantly measured on senseless metrics which work against building software that solves customers’ problems. Our goal is to help hands-on leaders to make suggestions for measuring without causing harm, and to help software developers become more productive.

When reading articles like McKinsey’s, keep in mind they’re written for a very different, and specific, audience: untechnical CEOs and CFOs with little to zero experience with software development. Engineering is just another department. They need to treat engineering the same way they treat Sales or Recruitment – and will do so, regardless of the damage misconceived frameworks do to development culture.

A mental model of the software engineering value

How does software engineering create value? Take the typical example of building a feature, then launching it to customers, and iterating on it. What does this cycle look like? Say we’re talking about a pretty autonomous and empowered software engineering team working at a startup, who are in tune with customers:

We start by deciding what to do next, and then we do it. This is the effort like planning, coding and so on. Through this effort, we produce tangible things like the feature itself, the code, design documents, etc. These are the output. Customers will behave differently as a result of this output, which is our outcome. For example, thanks to the feature they might get stuck less during the onboarding flow. As a result of this behavior change, we will see value flowing back to us like feedback, revenue, referrals. This is the impact.

So let’s update our mental model with these terms:

The effort-output-outcome-impact model describes software engineering, and works just as well for smaller tasks as it does to model thinking about feature development, or shipping complex projects.

We reference this model throughout this article.

Where does the need for measuring productivity come from?

Before we answer how to measure, let’s start with the more important question:

Who wants to measure productivity, and why?

This is such an important question to start with. The answer will differ dramatically, depending on who’s asking, and what the goal of the question is. Here’s a few common examples:

#1: a CTO who wants to identify which engineers to fire. “How can I measure the productivity of engineers in the organization, to identify the least productive 10%, and let them go?”

Unfortunately, this case is timely in the wake of recent layoffs across the tech industry. Here are some ways to answer it:

• Identify the lowest performers based on the latest performance review scores. This approach uses historical data that is likely somewhat outdated.

• Decide based on tenure, and lay off based on the “last in, first out” method. This uses no performance-related data and simply assumes that the exit of recent joiners will affect productivity less.

• Decide on a few easy-to-measure metrics like the number of pull requests, number of tickets closed, and so on. Basically, to decide by effort and output.

• Ask managers to identify the number of engineers to be let go. This approach can harness team dynamics and unquantifiable information like a manager knowing which engineers are about to hand in their resignation, which quantitative metrics miss.

With layoffs, team dynamics are impacted, and any approach which fails to take this into account, is likely to result in a less than ideal outcome. At the same time, layoffs often come with constraints, like senior leadership not wanting to get line managers involved. As a result, decisions are often made based on metrics known to be incorrect.

#2: To compare two investment opportunities. “How can I measure the productivity of teams, and allocate additional headcount to the team that will make the most efficient use of additional headcount?”

To answer this question, you want to compare the return on investment. This is not a question about productivity, it’s about the impact of allocating more headcount to one team or another

#3: To manage performance. “How can I measure engineers’ productivity to identify and reward the top 10%, and to identify the bottom quarter in order to debug and improve their performance?”

There are plenty of ways to go about measuring performance, and doing so with metrics is possible, though error prone. A hands-on manager can immediately name their bottom and top performers, and then examine and debug outputs, and look closer at how engineers do their work (their effort.) Performance calibrations are a standard way to do this.

#4: a software engineer who wants to grow at their craft. The question could be: “How can I measure my own productivity, and which metrics can I improve to become a better engineer?” This is a question more engineers should ask of themselves! Here are two helpful approaches:

• Aim to only have one red test at a time when using test driven development (TDD). This approach measures both effort and output. Get to the point where you can confidently, deliberately and consistently have one red test, when you expect one red test.

• Set a goal to merge a pull request every day, and track this goal over a week. This measure includes both effort and output. This goal forces you to do smaller commits, which are easier to review and get signed off quicker. It also pushes you to write code that’s correct and follows team standards.

As long as you keep tracking these “scores” and work on improving them, you’ll almost certainly improve your efficiency as a software engineer.

But what would happen if you showed these metrics to your manager and your performance was then judged by them? It would be a disaster: you’d be measured not on outcomes or impact, but by output. When you experiment with approaches – for example, learning a new language to help a team in need – then your output could drop, even though you are helping the team achieve a better outcome!

Why can sales and recruitment measure productivity so accurately?

As the software engineering industry, we should collectively admit we’ve done a much worse job of measuring productivity down to the individual level, than other functions have. Take sales as an example. Here is Kent’s account of the level of accountability Sales operates at, from a meeting of sales and engineering leadership at one of his past companies:

“I clearly remember this meeting where it was engineering and sales leadership reporting on progress. Each person from the sales team spoke and gave an update which went something like this:

‘My team’s target for the quarter was $600K, and we delivered $520K. I take accountability for the miss. Here are the reasons it happened, and here is my plan of what I’m changing to hit next quarter’s goal of $650K. Additionally, here is a two-quarter-long initiative I am putting in place, which I expect will bring an incremental $100K for each quarter, once complete. Any questions?’

If anyone had questions, the sales leader would drill down all the way to the individual level – which sales reps were above quota and which were below it, and by how much – and do so in a way that everyone in the room understood.

And then, it was engineering’s turn. My goodness, the contrast was stark. The typical engineering update went something like this:

‘So, this quarter we shipped Feature A, and we are slightly behind on some tech debt migration, and next quarter we’ll ship Feature B and catch up on the migration. Any questions?’

If anyone had questions about some delay, the answer was never about individuals – as with sales – and usually included factors like unforeseen difficulties, tech debt, APIs; all things which non-engineers in the room didn’t really understand.”

The level of accountability which sales and customer support work with is on a completely different scale from what a CEO observes from engineering. But when the CEO examines overall departmental costs, engineering probably costs more than sales!

It’s not just sales that demonstrates higher levels of accountability. Recruiting teams have targets for “heads to fill.” A recruitment team can without hesitation answer the question of what percentage of their targets have been met, how many more recruiters they need to meet aggressive hiring targets, and to identify the top and the bottom recruiters, purely based on metrics.

Let’s put ourselves in the shoes of a CEO. Sales has ways to clearly measure productivity, as does recruitment. So why not engineering?

Let’s return to our effort-output-outcome-impact mental model of how software engineering works. We can apply this model to sales and recruitment. The sales team measures itself by deals closed, so where does this metric go in the model? It falls into “outcome” or “impact:”

What about the recruitment team’s main metric: the number of heads filled? It’s also categorized as “impact:”

We can repeat this exercise for other functions with high accountability in how they work. For example, customer support can be measured by the number of tickets closed (an outcome), the time it takes to close a ticket (also an outcome,) and by customer satisfaction scores (impact.)

Neither Kent nor I have seen accountable teams within tech companies which are not measured by outcome and impact. In order to make software engineering more accountable, we need to look at how to do this.

Measurement tradeoffs in software engineering

One popular framework to measure software engineering team efficiency is the DORA framework. Let’s map out the focus of this framework measurement:

The 4 DORA metrics: each measures outcome or impact

All DORA metrics measure outcomes or impact.

Let’s look at another way to measure developer productivity: the SPACE framework. It seeks to capture satisfaction, performance, activity, communication, and efficiency (SPACE.) It’s not only outcomes and impact, as with DORA. The SPACE framework does not outline definite metrics – but gives example ones. Several of the metrics come with a warning, like measuring lines of code. Metrics that come with a warning from the SPACE framework authors – such as the ‘lines of code’ metric – tend to measure effort or outcome.

One critique of McKinsey’s system we have is that nearly every single one of its custom metrics which differ from DORA and SPACE metrics, measure effort or output:

4 out of the 5 new metrics suggested by McKinsey’s measure effort or output

What’s wrong with this approach? First, the only folks who care about these metrics are the people collecting them. Customers don’t care. Executives don’t care. Investors don’t care. Second, and most crucially, collecting & evaluating these metrics interferes with the team delivering on the measures downstream folks actually do care about, like profitability.

Why is McKinsey adding ways to measure effort? One reason is that it’s the easiest thing to measure! But the McKinsey approach ignores an important truth: the act of measurement changes how developers work, as they try to “game” the system.

The earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences. Let’s take the extreme of measuring only profits. The good news is that everyone is aligned, across the company! The bad news: attributing who contributed how much to the profit is nearly impossible! You can ‘fix’ the attribution question by measuring outputs, or effort. But the cost is that you change people’s behavior, as it incentivizes them to game the system to ‘score’ better on those metrics:

Measurement tradeoffs: capturing impact and outcomes boosts alignment, but makes it harder to attribute individuals’ contribution. But measuring earlier in the cycle creates unintended consequences, as people stop caring about group or company goals

Let’s take the case of a company that’s reasonably profitable and in the upper quartile for the industry. The company’s leadership dislikes being unable to attribute individuals’ performance in contributing to profitability.

Would you be tempted to screw up your company’s business by introducing micro-measuring? Hell no!

We urge engineering leaders to look to outcome and impact measurements, to identify what to measure. It’s true that it is tempting to measure effort. But there’s a reason why sales and recruitment teams are not judged by their performance in being in the office at 9am sharp, or by the number of emails sent – which are both effort or output.

So which outcomes and impacts can be measured for engineering teams? DORA and SPACE give some pointers, and we offer two more:

• Please the customer at least once per team, per week. This output might not sound so impressive, but in practice is very hard to achieve. The most productive teams – and nimble companies – can pull this off, though. If you consider why a startup moves so fast and executes so well, it’s because they have to do so out of necessity, even if they do not measure this.

• Delivering business impact committed to by the team. There is a good reason why “impact” is so prevalent at the likes of Meta, Uber, and other fast-moving tech companies. By rewarding impact, the business incentivizes software engineers to understand the business, and to prioritize helping it reach its goals. Is shipping a $2M/year cost-saving exercise via a configuration change, less valuable than shipping a $500K/year cost-saving exercise that takes 5 engineering months? No! You don’t want to focus solely on impact, but not focusing on the end goal of delivering business value is a poor choice.

Takeaways

There is, undoubtedly, mounting pressure from the business in wanting to quantify the productivity of software development teams. Companies like McKinsey are responding to this clear demand by providing frameworks that promise to do exactly this.

Measuring effort and output is attractive. These come with tradeoffs that will negatively impact the engineering culture. As engineering leaders: be sure to consider this tradeoff, and how it could change the incentives of developers.

In Part 2 of this article – coming out on Thursday –, we will go into the dangers of only measuring outcomes and impact; and offer our answer to the question on whether & how to measure developer productivity.

(Kent here: I am writing this with and his valuable stack. Please consider subscribing. Thursday’s piece will give you my personal takes on what to do & what not to do when it comes to measurement.)

Here is an engineering-oriented perspective on creating value, where to measure, & what each measurement point means. tl;dr measure too early in the chain & you risk worse results at the end of the chain where you actually care about results (profits, in this case).

Subscribe now

Once upon a time there was a guild of bakers. Bakers belonged to a kitchen and the kitchens belonged to the guild. They were fortunate enough to live in a town simply mad for pies. As soon as they baked a pie it was bought and eaten.

The bakers all dreamed of flour and lard and fillings of apple and cranberry and chocolate and caramel. When they awoke, it was to the realities of another day of mixing and kneading and rolling and baking.

Tarts

The townsfolk all wanted different pies. As a result, each baker baked their own tarts, just enough for one customer to eat.

To keep track, each baker stamped their initials on each pie they baked. After a while, the kitchens would collect all the stamps, then get together to compare the jobs the bakers had been doing.

Tarts → Pies

The town grew, based largely on the prosperity created by the thriving pie trade. As demand for pies grew, tarts were no longer necessary. Several people wanted apple pie in a day, so it made sense to bake whole pies at a time. This let the person who wanted to learn to make crusts just make crusts and the person who wanted to learn to make fillings to just make fillings.

The tradition of stamping pies with the initials of the bakers continued. Since several people made each pie, it was necessary to slice the pies and stamp the slices. This was merely a nod to tradition, though, since everyone knew that any one pie was the product of several people together.

The Pie Problem

Soon two kinds of kitchens emerged. In the first kind, the focus remained on making bigger and better pies. Slicing and stamping was seen as something that happened for historical reasons but it had no influence on the making of the pies. How could it?

In the second kind of kitchen, however, stamping and slicing became the primary activities. It seemed as if the pie itself was nothing more than an excuse to play the Slicing and Stamping Game. These kitchens naturally turned out smaller pies and worse pies, since they weren’t actually focused on the pie but on the game.

It would be easy to dismiss the second kind of kitchen. We all know that pie is the point, not who gets credit. That’s only true, however, as long as there is enough credit to go around. When fear of lack of credit becomes stronger than excitement about accomplishment, it’s a natural human reaction to dream of slices and stamping and neglect the pie.

I leave this story unfinished, as it is in truth. Will the bakers:

• Continue the trend toward focus on slicing and stamping? Re-focus on pies and let the slicing and stamping fall where it will?

• Find a new way to acknowledge the diverse contributions of bakers to pies?

We will find out. But we will also create the answer by our own behavior.

Buried in this tweet by Gergely Orosz is an interesting quote: “Team matching was very frustrating for hiring managers.”

Briefly, team matching is the process where hiring an employee is separated from the decision of which team the new employee will join. Back when I was a wee engineer, I was always interviewed & approved by the team I was to join. When I got to Facebook in 2011 I was surprised to find that 1) I would be hired without having a team assigned and 2) I had significant control over which team I would join.

One theory behind team matching is that engineers work significantly better if they are excited about what the problem they are addressing. Since most can’t know pre-employment which problem they will find most motivating, late binding to teams increases overall motivation & thus effectiveness.

Impact on Managers

As the quote above highlights, team matching creates challenges for managers. What if you are managing a team & no one picks you? What if all the new candidates try out working with you & your team & decide to apply their talents elsewhere? Well, what happens is that your team’s performance dwindles & you’re out of a job.

You can react a couple of ways to this. You can go back to early/forced team choice. You’ll see shorter & shorter lists of “approved” teams, even if the trappings of team matching remain. Eventually you’re left with Hobson’s Choice.

What I saw at early(-ish) Facebook, though, was that if executives hold the line on team matching, it creates powerful incentives for managers to improve. To survive in the competition for talent:

• Managers need to articulate a vision for why their team’s scope is important.

• Managers need to find & communicate ways for new team members to meaningfully contribute.

• Managers need to encourage the growth & development of existing team members (team members do most of the work selling the team to prospects).

• Managers need to avoid the most egregious bad behavior—the bathroom telegraph broadcasts managerial abuse.

I can imagine the frustration of a manager unable to do one or more things on this list. As an executive or investor, I want the manager to learn & grow. It’s not my job to free their job of frustration. Nor is it my job to shield unskilled managers from the consequences of their shortcomings.

I like that team matching frustrates some managers. Those are the managers I want to frustrate, even as I offer them coaching & training to improve their skills.