Sturgeon's Biases

This is a recording of a talk given at Lean Agile Exchange, Thursday, 28 April 2022.

As a technical leader do you have problems with different disciplines and communities of practice within your organisation? Do you find misconceptions about what different groups can do getting in the way of achieving your objectives?

In this talk I'll explore these problems through the lens of Sturgeon’s Revelation usually stated as “ninety percent of everything is crud!

In a career it's surprisingly easy for a good developer to have only worked with bad product people. Or a good product manager to have only worked with bad UX people. Or a good UX Designer to have only worked with bad developers. And so on.

Each of those people builds generalisations based on their experiences. Creating coping mechanisms for those generalisations that start being counter-productive when they finally get to work with good people.

You'll see how easy it is for people inside and outside of a discipline to have radically different experiences of its competencies. We'll work through some options to help break down those misconceptions — so we can create happier, more empathic, teams!

(An earlier version of this talk was given at LeadDev Live 2021. A stand alone PDF of slides is also available.)

Slides & Transcript

I'd like you to meet Theodore Sturgeon.

For those who don't already know Theodore was a science fiction author. He wrote over a hundred short stories, eleven novels and a some Star Trek scripts.

(Including the classic original Star Trek episode "Amok Time" if we have any Trekkers in the audience!)

But he is arguably as well known for some things he wrote in Venture magazine in 1958 — about the many, many criticisms Science Fiction got from people who hated the genre.



People started calling this revelation “Sturgeon's Law”

(sometimes folk use other words instead of “crud” :-)


In the last few years I've found Sturgeon's Law to be a useful lens to help me understand some of the problems I encounter when different communities of practice start butting heads. When developers rant about how terrible managers are. When a manager says agile is awful. When agile folk hate on designers. And so on.

I work helping companies fix problems where development, product management, and user research overlap. So I see folk butting heads. A lot!

A great deal of the conflict seems to be caused by a couple of different biases around how different communities of practice perceive each other.

I've been calling them Sturgeon's Biases because they are caused by people forgetting that Sturgeon's Law applies to groups too.

(as an aside — if you discover a better label for this, do let me know! It feels like the sort of problem some smart sociologist wrote about seventy years ago!)

Anyway…

Imagine a community with 100 people in.

They can be developers, product managers, lawyers — it doesn't matter.

Now in any community of practice some people are going to be awesome practitioners and some folk are going to be… ineffective — along with everything inbetween. For the sake of simplicity let's use Sturgeon's Law…

So our green 10% are awesome folk — which makes the other 90% “crud”.

Which makes intuitive sense. If I look around me in an organisation or a community there are going to be some folk who are better and some folk who are worse. Through leadership, or management, or training, or exposure to good practices, or ability. This seems to be the model many people have on how communities are broken down. A random distribution.

The problem is this picture is a lie.

Because the distribution of people in a community of practice isn't random. Good people in a field tend to seek out other good people. They tend to hire other good people. They tend to talk more to other good people.

They cluster.

They also tend to either raise up the folk near them through influence and education, or push them away if they can't / don't want to.

Which means that the best practitioners in a community of practice get a really, really biased view of the general level of ability. They only see the people around them — who all tend to be awesome or awesome adjacent.

Whereas the majority of people see this:

The best people in a community experience it as 90% awesome, when the reality is 10% awesome.

This is the first of Sturgeon's Biases: The best people in a community experience 90% awesome, when the reality is 10% awesome

.

For example: For the first ten years or so of my career I hated testers.

Which is dumb, I know.

But the reason I hated testers is that all the testers I worked with were terrible at testing. They were old school, no automated testing, running through a checklist, very little independent action on problems.

My favorite example of this was when there was a curse word in some copy (and this was the era of shipping on floppy so it really mattered). This curse word got seen but not called out because it wasn't on the checklist!

But this isn't the only bias.

All the voices in a community of practice are not equally prominent. Who speaks at the conferences? Who writes the articles? Who works on the most exciting and influential projects?

We hear the voices of the some people much more frequently. They have much, much more visibility than everybody else.

We don't tend to get conference keynotes about work that went terribly wrong and everybody walked away learning no lessons!



Which leads to the second bias.

The presentation of a community is 90% awesome, when the reality is 10% awesome.

And that dissonance can cause problems. If the world tells you something is awesome, and your only experiences of it are terrible, then you tend to dismiss the awesome as a lie.

 If somebody tells you Scrum is awesome, and your only experience of it is as a process-heavy, estimate-driven, velocity-chasing feature factory — then it's hard to take them seriously.

These biases are, of course, a massive over simplification

People don't neatly fall into two categories of "awesome" and "crud". The 10% and 90% proportions? Probably wrong — they've just been made up.

Ability is certainly not fixed! People can improve through training and experience. People can get worse when the world changes around them, and they don't change.

Ability is often constrained by external factors. If your company doesn't support professional development and training, doesn't ever give you new experiences, etc. then you're not going to get better. And that's not your fault.

Popular communities attracts newbies and exploiters! Machine learning is super popular now, which means there's a massive influx of new people — and not all of those have the skills to do that work well. There are also a bunch of people coming in who want to make money and are about extracting value from the community with certification and training — and not necessarily add value back in.

Communities of practice are also fuzzy and fractal! There isn't a neat border around 100 people. There's a messy domain, which overlaps with other messy domains, and has a bunch of sub-disciplines and domains. There are no clear straight lines around things.

And yet… I see problems all the time. Somebody dismissing Agile as never working is seen as an idiot by people who see it working all the time. The new user researcher is ignored by the product manager, because every other researcher they have worked with has given them useless, unactionable reports. A company expects product managers to be a machine to turn client requests into user stories, because that's all they've experienced from other people with that job title. Design Thinking is seen as snake oil, because people have personally experienced nothing but post-it note theatre.

These are all problems I've encountered — and Sturgeon's Biases has helped me understand them. It is really easy for somebody in the awesome bubble, to have never seen the bad. It's really easy for somebody outside the awesome bubble to have never seen the good.

So how do we address this?

Actually listen to what people tell you. And believe them.

Remember me hating testers? In the late 90s I got to work with an awesome tester who turned that around.

He didn't turn that around by saying "You're an idiot. Testing is good.". He turned it around by listening to my experiences. Telling me "Yeah, that sounded kind of sucky." before he started with the "That's not what good testing is. Let me show you this good stuff."

He listened first.

He also asked for stories. "Can you tell me about the last time you shipped something with QA?", "What happened?", "Can you tell how testing affected that result?", "Can you tell me about your last experience doing this or that or whatever?".

Those stories helped him understand where I was coming from, and what my experiences were, so he could take me to a better place.

In the discussions about good and bad practice it's really easy to get trapped in the details about what folk are doing, rather than the “why” of doing it.

For example recently I was working with a guy who hated Scrum. For very, very good reasons. He had worked in some terrible environments that were using and abusing Scrum.

But the place he was working now wasn't using Scrum — and was having a few problems. It was a rapidly changing environment. People were working really hard individually on things — and they weren't quite in sync on the work that they were doing.

They thought everybody was aligned at the started of the day, but people really heard slightly different messages. So there was a bit of waste, a bit of rework that didn't need to happen, or the wrong work happening.

By talking about the outcomes "We wanted to get synced up.", "We wanted to make sure everyone knew where we were at the start of the day.", etc. they ended up adding a short meeting to the start of every working day where everyone talked about what they were trying to get out of the day and where they were trying to go. He basically re-invented the Scrum stand-up — a meeting from a process that he hated. Because he talked about the outcomes that he wanted from that first, and worked forward from there.


If somebody has had a terrible experience doing work that's been labelled a certain way, it's really hard to use that label without bringing those experiences back. So use a different word for the same thing. Or use a more specific word, or a more general one.

I hit this one a bunch with “user research”. A lot of folk have only experienced user research as a slow and expensive process. When somebody says “user research” they hear “slow, expensive, and not very useful”.

With those people I find using other phrases more useful “Qualitative insight gathering”, “discovery sprint”, “short diary study”, etc. Ones that are more unfamiliar to them so we can have the conversation about intent and outcomes without any preconceptions.



And finally — question your own lived experiences. Which bubbles are you living in?

Are most of your experiences of being a developer in the awesome bubble? Are most of your experiences of product management in the “crud” bubble? How can you find out?

I'm really, really glad I don't think testers suck any more. I wish I'd been smart enough to learn it earlier than ten years into my career.

Question your assumptions. Question what your immediate reactions to another community of practice are like. If you can keep Sturgeon's Biases in your head, it can help you more easily see your own bubbles, as well as helping folk get out of theirs.

Talking of Theodore.

In his Venture magazine article he talked about two corollaries to his revelation.

So don't feel to bad about the 90% of crud in your domain. Admit it, and realise that everybody else has the same problem.



So don't forget that the awesome bits of your domain are still pretty darn awesome.

I hope keeping Sturgeon's Biases in mind will help you find the awesome more often.



Thank you for your attention.

Further Reading

• Find out more about Theodore Sturgeon on the Theodore Sturgeon Wikipedia page and at the Theodore Sturgeon Literary Trust
• The Wikipedia page for the Star Trek episode "Amok Time".
• More on the history and variations of Sturgeon's Law can be found on the Sturgeon's Law Wikipedia page.

Keep in touch

If you liked this you'll probably like our newsletter (No fluff — just useful, applicable information delivered to your inbox every other week. Check out the archive if you don't believe us.)