TBM 263: "I Aspire to Regret How We Used to Work"

Note: I will return to my series on dependencies (see Part 1 and Part 2) in 2024. 

I'd like to close out 2023 with something brewing in my mind for a while. It involves one of the critical limiting beliefs that gets in the way of improvement and one of the core enabling beliefs that sets "good" teams apart. It is also something I'm considering as I set some goals and aspirations for 2024 and catch myself falling into common traps.

The Carpenter

A hobbyist (Allison) decides to take up carpentry. Allison picks her first project—a simple two-section coffee table. The going is slow as Allison gets familiar with new tools and techniques. Ellen, her good friend, shows up. Ellen is a professional carpenter with two decades of experience. "Ellen, do you mind giving me some pointers?" asks Allison. "Sure!" responds Ellen.

Allison watches Ellen move a large multiple faster, gracefully, and effectively, with almost zero resets. Without effortless efficiency, Ellen finishes things that took Allison five to ten minutes in one to three minutes. Under Ellen's simple instruction, Allison also starts making solid contributions. Interestingly, Ellen also takes longer on some things that Allison breezed over. The results look so much better. Ellen could sell the end product if she wanted, and people would pay hundreds of dollars. 

Does anything I've described surprise you? Probably not. The performance discrepancy between someone with two decades of carpentry experience and a rank beginner makes absolute, rational sense. 

The Team

Compare this to the following scenario:

In six months, a product team doubles their "batting average" (the impact of the bets they place on near-term and longer-term outcomes), increases the throughput of bets they make by 2x, reduces the probability of team members leaving in the next six months by 50%, and decreases the amount of reactive work addressing issues in production impacting customers by 80%. And they do this without changing their team composition—there's no Ellen, they were all Ellens, or somewhere in between, but it didn't change.

What's going on in your mind?

When I present this scenario to teams in workshops, I get a lot of theories.

They must have been doing a terrible job before this. When things are awful, you can improve by doing some basic stuff. It's easy to go from 1 to 4. See if they can go from 4 to 10! If getting better was that easy, someone must have been seriously dropping the ball before this—a major lapse in leadership and management.

I bet someone started to pay attention, and the team stopped slacking. They were phoning it in before. In business, a watched pot DOES boil. They are afraid they will lose their job.

The high performer on the team must have checked out. Then they suddenly started to care, and it upleveled everyone.

I've seen this, but it always involves a new leader or manager. A team doesn't magically fix itself like this. If the team composition stayed the same, I bet you mean the people on the individual team stayed consistent. There had to be changes elsewhere to facilitate this.

The carpentry example makes sense. The team improvement example elicits a lot of inquiry, questions (and some disbelief). Responses range from "This is impossible" to "I can see this happening if there was a tiny intervention of some sort that triggered an inflection point."

The Dissonance

Which brings us to the dissonance.

Humans are biased to believe that improvement is only possible with the application of new expertise or attitudes (encouraged by people with new expertise or attitudes or some kind of change of heart or realization). The Ellen example makes sense. The team example leaves us stuck. If the improvement "just happened," we immediately assume something was broken or amiss or the scenario is missing an important detail (in fairness, my scenario was purposefully short on more information).

In response to a post on this topic on LinkedIn, Rebecca Murphey (Stripe, Swarmia, Indeed, Bazaarvoice) had a fascinating reply:

I like to actually use this as a thought exercise: "It's two years from now, and we're saying we can't believe we used to put up with <what?>." I aspire to regret how we used to work, no judgment.

To me, this strikes at the fundamental question. I doubt there is anything Ellen (the carpenter) will do now that she regrets in two years. Allison, yes. Ellen, no. Yet, based on my personal experience, I can relate to Rebecca's sentiment. Even when things are going well, I assume we'll look back and laugh. I chatted with someone I used to work with recently, and we were reminiscing about how we worked half a decade ago. 

"Can you believe what we put up with?" "Can you believe how the industry has shifted its perspective on X since then?" "Hah, we were going in circles for like six months! That was crazy!"

At the time, I would have said we were doing great. Looking back, compared to today, not so much.

About once a week, I hear about the "reality" of how some lauded practice went down:

I was at Google for ten years while the company extolled the virtues of OKRs. Yet the truth was they were only applied effectively in small corners of the company with easily measured outcomes. For everybody else, they were messy accountability theater.

People put X on a pedestal and are often surprised to find out the reality if they join or if anyone talks honestly. 

So even where we'd expect "the best," you can see things are a work in progress and not what they seem. Things work and then stop working:

Realistically, in the last twenty years in Silicon Valley across four well-known companies, things have clicked for about six to eight years. Things ebb and flow. Good things go to shit. Other times I thought things were shit, and then looking back, I realized they were slowly changing for the better. It's hard to tell when you're in the moment and easy to attribute it to outside factors when it's mostly luck and time.

It is important to acknowledge that something is different about this game we're playing.

The Difference

So what's going on?

Product development is cross-disciplinary—a blend of skills and perspectives. It is collaborative.

There's a lot of luck and timing involved. I'm unsure who said it originally, but product-market fit can gloss over many problems. A rapid deterioration of product-market fit can cause a "high-performing" company to falter.

Product development is not carpentry. New technologies, skills, and practices emerge (layered on top of existing technologies, skills, and practices). Consumer expectations change. Very importantly, employee expectations change! After you've tried X, it can be hard to do Y, and there's a very good chance that X is not evenly distributed. If you were to take a sample of revenue-generating carpenters globally and compare practices, you'd find far less variation. In product, you can take ten companies operating in often very different ways, achieving similar results. You can also find companies swimming in money operating 15-20 years behind "state of the art."

A company's context is constantly changing. "What got us here will not get us there" is a constant in any environment with opportunity and uncertainty.

Unlike the linear skill acquisition seen in carpentry, progress in product development can be non-linear and less predictable. Teams may experience breakthroughs or setbacks not just because of internal changes but also due to external factors that are out of their control.

Implications

I am starting to believe that one of the biggest blockers to improvement is this dissonance and not fully appreciating the difference.

The Limiting Beliefs:

1. If improvement is easy, something is wrong.

2. Change must be hard. The only time "big changes" are possible is when there are big changes. It has to be hard.

The Enabling Beliefs:

1. Things do not exist in isolation. We work in teams. Teams work with teams. Companies partner and compete with companies.

2. Sometimes, the best results come from intuitive, effortless actions rather than forced efforts. Doing things "harder" (trying and pushing back, for example) doesn't always yield the results we are looking for.

3. Progress is non-linear and influenced by a variety of factors, both internal and external.

4. Product development is in a constant state of flux and change. This doesn't invalidate past techniques. Rather, we're layering and adapting. What "works" now will inform what works in the future (but will not be the whole picture). Even within a single company, diverse contexts require different approaches.

5. It's important to embrace continuous learning and adaptation. There's no end-state (evidenced by how the "best" are consistently learning).

This work is hard enough as it is, so:

Are improvements easy? Great! Celebrate. 

If change is hard, make it easier!

This may sound like eastern philosophy, and I'm ok with that. Is this a mindset? Perhaps. Or maybe it is something you learn after doing this for a while—a meta-skill.

So What Was It?

I'll end with a return to our example team. What "caused" it?

As you might expect, it was a mess of things.

1. The company stopped selling a product, causing much of the reactive work.

2. They got around to instrumenting key parts of a workflow, which helped inform product decisions.

3. They had an offsite where they could finally spend quality time together and committed to small experiments with outsized results. They also resolved one of the ongoing conflicts on the team that had plagued decision-making. Funnily enough, the budget for the offsite was an accident. Someone had entered an extra zero in a budget request almost a year before.

4. They invited an unbiased facilitator to the offsite.

5. One of the team members got the go-ahead to use a certain technology they were eager to learn. This kept them at the company for the foreseeable future.

6. One of the team members took a training that shifted their view on something important. They were the "holdout," and the shift unblocked the team.

7. Luck: some decisions from a couple of years ago started to bear fruit. Key customers re-discovered the functionality.

8. Time. The team hadn't been working together for a long time. It took time to settle into a flow.

9. Macro factors: the economy took a shift that favored retention over acquisition. Their product focused on retention, which brought more visibility and words of support. That made a difference.

Questions:

How can you put your teams in a position where they can “surf” the changes?

How can you intervene lightly to encourage exploration and adaptation?

How can you foster an environment where improvement is seen as a constant?

Happy New Years

And with that, thank you so much for reading my newsletter in 2023. 

I'm very grateful for the people who take the time to read and reach out with questions and words of encouragement.