This is the final part of a 6-part series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3, part 4, part 5.

We want to be careful how we create process. The fastest way to a mediocre team is to define your process around mediocrity. A slow but sure way to a mediocre team is to define your processes to gradually push them towards putting their own self interest front and centre – like the conclusions the guy drew from the promotion process we talked about earlier.

• Incentivizing complexity is terrible. When you incentivize complexity, you get a lot of it. Most of it unnecessary.
• Impact is contextual and subjective. Time in app is a good example – is it good if people are spending more time on your app if it’s also making them more miserable? Are there longer consequences from that?
• People leave when they don’t grow. Not all people, but still – if people don’t see a way to learn, or increase their impact, or whatever growth means to them, they will leave in search of it. Remember career development was the top thing developers were looking for in new jobs.
• And people leave when they feel unappreciated. When the work they are doing doesn’t seemed valued in whatever definition of value they have – financial, or recognition (or both).
• If you don’t feel like you can be successful somewhere, why would you stay? Which is why we need to understand what people think of as success, so that we can give them a path – or encourage them to find that path elsewhere.

There’s a Japanese concept called ikigai – the intersection of what you love, what you care about, what the world needs, what you can get paid for. The question this inspires, for me at least, is how do you bring out in people what they love, and how they are most excited to contribute to what’s around them.

One thing that we talk about in my current team, is the idea that a senior engineer makes the whole team better. Which whilst it has the problem of subjectivity that many things do, it’s clear when it’s happening, and clear when it’s not. The person who does a lot of great work hiring or onboarding, or the person who spends a lot of time on architecture or code review – their impact goes beyond lines of code of features shipped. But the person who doesn’t work with others, or who leaves things unfinished for teammates – it’s clear they are not contributing in that way.

As we approach the end, what can we take from all this?

The dysfunctions of your organization become the dysfunctions of your product. Dysfunctional teams of mean, insecure people, build shitty products.

I have this idea I think of as the hierarchy of kindness. Essentially, we’re kind to ourselves. And on top of that we are kind to our teammates. Kindness to the user sits above both of those. If you can’t show empathy to the people you work with every day, how can you show empathy to someone you will never meet?

Or: Resilient individuals -> strong teams -> towards a purpose (the user).

But strong teams are necessary but not sufficient. All organisations have their quirks. It’s fun and entertaining to talk about extremes, but things don’t need to be extreme to cause problems.

• When you don’t make decisions: product features don’t get clearly prioritized, leading to stagnation or bloat.
• When teams can’t work together: your UX becomes disjointed. This is Conway’s law – Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
• When you incentivize complexity: you get a lot of unnecessary complexity.
• When you are too into shipping fast: what you ship is mostly unfinished.
• When you are too into long, complex architecture projects: what you ship is few and far between.
• When you have to do a rewrite: you have failed. How do you not fail again?
• When you get disconnected from how people really operate: you create a very rigid product.

Here’s the thing about organizational dysfunction. Sometimes it’s created by political machinations. But often it’s created through good intentions and deliberate process.

Arbitrary characteristics of early team members become enshrined in the hiring process and don’t evolve as needs change. The things that make small teams successful are still lore and aren’t revisited as teams grow. An elaborate promotion process gets defined in the name of fairness as a preventative measure against fiefdoms. We experience poor managers and then we become poor managers ourselves – or just devalue the whole concept. We pattern match, but we don’t really know what the patterns are.

I love what this snippet of David Bowie captures. The idea that in art, a piece is not finished until it is experienced. This is so true for products. This is where we live – in the grey space in between.

Thanks for coming on this journey with me. It’s left me with more questions than answers in many ways, but also with a strong conviction that this is the work – understanding those motivations, and creating that alignment. I leave you with three thoughts.

A sense of accomplishment is personal. Ask someone what gives them that for a potentially fascinating conversation.

Zoom out for clarity. The disconnects appear when we step back – from the individual to the team, from the team to the users the product is meant to serve, from the feature to what the person is trying to do.

Say thank you. If you liked something that someone did or built or wrote, tell them. Impact matters to people, but people don’t know they have had an impact on us unless we let them know.

Thanks to my colleague @folletto who helped me turn a collection of disjointed thoughts into a coherent structure and introduced me to Campbell’s law, and @mattmiklic who made my slides beautiful after I destroyed everything.

Related

How Do Teams Define Success?

This is part 3 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2. Taking a step back from individual…

April 17, 2018

In “management”

How Do Users Define Success?

This is part 4 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3. Let’s take another step…

April 24, 2018

In “management”

How Should We Define Success?

This is part 5 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3, part 4. What we’ve…

May 1, 2018

In “management”