Sturgeon's Biases

This is an overview of a talk given at LeadDev Live, 14 September 2021.

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!

(You can view the video of this talk at the LeadDev site. A stand alone PDF of slides is also available.)

Slides & Transcript

I'd like you to meet Theodore Sturgeon.

To the right a picture of Theodore Sturgeon, an older thin bearded man wearing a pendant in the shape of a Q with an arrow through it. To the left some lurid 50s SF magazine covers and a still from the Star Trek episode Amok Time with Spock fighting Kirk.

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.

A quotation: Sturgeon's Revelation, which was wrung out of me after twenty years of wearying defense of science fiction against attacks of people who used the worst examples of the field for ammunition, and whose conclusion was that ninety percent of SF is crud. The Revelation: Ninety percent of everything is crud. — Venture Magazine, March 1958



People started calling this revelation “Sturgeon's Law”

Sturgeon’s Law: 90% of everything is crud

(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.

Sturgeon's Biases

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.

One hundred circles, representing one hundred people, randomly spread.

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…

One hundred circles randomly spread. Ninety of them are white and ten are green. The green circles are spread evenly among the white.

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

One hundred circles randomly spread. Ninety of them are white and ten are green. The green circles are spread evenly among the white. Ten circles are highlighted in yellow — one green and nine white.

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.

Ten green circles are clustered in the middle of the image. They are surrounded by ninety white circles distributed at random.

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.

Ten green circles are clustered in the middle of the image, with four lighter green circles next to them. They are surrounded by ninety white circles distributed at random. There is a gap surrounding the green circles — a moat — as if they have pushed the white ones back.

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.

Ten green and four light green circles are clustered in the middle of the image, surrounded by a small gap, and then 86 white circles. The green circles are surrounded with a yellow highlight. Because of the gap — the yellow highlight touches almost no white circles.

Whereas the majority of people see this:

Ten green and four light green circles are clustered in the middle of the image, surrounded by a small gap, and then 86 white circles. The white circles are surrounded with a yellow highlight. Because of the gap — the yellow highlight touches almost no green circles.

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

Sturgeon’s Biases: The best people in a community experience 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?

Ten large green circles and four slightly smaller light green circles are clustered in the middle of the image, surrounded by a small gap, and then 86 very small white circles. Because of their size the green circles domainate the image.

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.

Sturgeon’s Biases: The best people in a community experience 90% awesome, when the reality is 10% awesome. The presentation of a community is 90% awesome, when the reality is 10% awesome.

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

Sturgeon’s Biases are a simplification. People don’t neatly fall into two categories. 10/90% is probably wrong. Ability is not fixed. Ability is often constrained by external factors. Popular communities attract newbies & exploiters. Communities of practice are fuzzy & fractal.

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.

Ten large green circles and four slightly smaller light green circles are clustered in the middle of the image, surrounded by a small gap, and then 86 very small white circles. Because of their size the green circles domainate the image.

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?

Never dismiss a lived experience

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.

Ask for stories

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.

Talk about outcomes first

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.

Use different words


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.



Question your own lived experiences

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.

To the right a picture of Theodore Sturgeon, an older thin bearded man wearing a pendant in the shape of a Q with an arrow through it. To the left some lurid 50s SF magazine covers and a still from the Star Trek episode Amok Time with Spock fighting Kirk.

Talking of Theodore.

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

Corollary 1: The existence of immense quantities of trash in science fiction is admitted and it is regrettable; but it is no more unnatural than the existence of trash anywhere — Venture Magazine, March 1958

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.



Corollary 2: The best science fiction is as good as the best fiction in any field — Venture Magazine, March 1958

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

Sturgeon’s Biases are a simplification. People don’t neatly fall into two categories. 10/90% is probably wrong. Ability is not fixed. Ability is often constrained by external factors. Popular communities attract newbies & exploiters. Communities of practice are fuzzy & fractal.

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



Thank you for your attention.

Further Reading

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.)