I’m Kwesi, a 24-year-old born and raised in London. Having done a Maths degree at Cambridge, I decided to go into software. I’ve been working at Metaswitch for just over 2 years now, and am currently a Test Lead. A typical work week involves a mix of exploratory testing, coaching, managing the delivery of projects, and trying to improve our processes (I’m a firm believer that things can be different!).
In terms of what interests me, I’m very interested in rationality, biases, and understanding the psychology of people - I regularly read blogs (such as “Overcoming Bias”) and books (such as “The Black Swan” by Nassim Nicholas Taleb) about this stuff. I’m also love playing sport; a typical week will involve a mixture of football, ultimate frisbee, touch rugby, basketball, boxercise, and more. I’m also partial to a pint or two with friends.
[Note - my opinions are my own and don't necessarily represent the views of anyone else!]
It’s a question we’re asked all the time, at networking
events, at parties, on dates (good or bad), the list goes on. Often, we’ll
answer by giving our job title: “I’m a tester”; “I’m a senior developer”; “I’m
a product owner”, and so on.
Now, I’m not saying job titles are a bad thing. They’re
labels that give useful information about activities that we may or may not do
at work. If your job title is “junior developer”, you probably spend some time
writing code, and you probably don’t attend quarterly board meetings where you
attempt to justify the company’s overall strategy for the next 12 months. If
your job title is “tester”, you probably spend some time looking for bugs, and
you probably don’t spend time trying to define the overall architecture for the
new product your team is building. If your job title is “<something>
manager”, you probably spend most of your time doing “management things”.
Labels do give a sense of what you do.
However, labels take away, reduce, and diminish the complete
picture of what you do and who you are.
One of the talks I heard at the conference (titled “More Than
That”) was given by someone who called himself a tester (amongst other things).
He told an anecdote about how he applied for a job that was basically being a
business consultant for a real estate company. At the interview, the hiring
manager asked him the following: “So, I’ve taken a look at your CV, and there’s
something I’m concerned about. I see that you’re… just a tester. What makes you
think you’ll be able to do this job?”
Just a tester. Do you ever think of yourself as “just a
I’ve certainly had that feeling before. Occasionally, I’ll
meet people in social situations that work in tech. When they ask me what I do,
and I tell them I’m a tester, I’ll often get looks of surprise or confusion.
They’ll often say things like:
“But isn’t being a developer more interesting?”
“So, do you actually enjoy spending your time
writing test cases?”
“If you want to progress your career, you need
to get out of testing”
I’ve gotten pretty good now at explaining to people why
testing is a complex, valuable thing and why being a testing specialist is a
useful, challenging profession. However, it does make self-doubt creep in
However, I’ve definitely seen examples where viewing myself
as a tester has stopped me from doing things that would have been valuable and
Believing that I can’t write good code because I’m just a
tester, and therefore:
Being reluctant to do code reviews of our test
Being reluctant to refactor our test automation
Being reluctant to suggest new tools or try to
write tools to help testing
Believing that I can’t contribute usefully to
architecture or design meetings because I’m just a tester, and therefore:
Being reluctant to get involved in design
Being reluctant to speak up or provide input in
Believing that I can’t really change processes
because I’m just a tester, and therefore:
Accepting processes as they are, even if they’re
not working for me
Only suggesting minor tweaks to processes,
rather than wholesale changes
Believing that I can’t really change the project
parameters because I’m just a tester, and therefore:
Accepting time or resource constraints, even if
I think they’re unreasonable
Accepting the output of other teams, even if I
think it’s not to the required quality bar for the given project
In all cases, it was this label of being “just a tester”
that was stopping me. So, how to solve this problem?
The answer came from a talk called “Finding Power in
Authenticity”. What do I mean by authenticity? To quote the speaker:
Authenticity is acknowledging
who you are: Finding power by embracing your strengths and working on improving
In her inspiring talk, she told the story of how she moved
country and found herself in an unfamiliar role as a quality analyst. It was a
solo role, where she was expected to work as a modern QA as part of a
high-performing team. After going through a period of struggling initially, she
asked herself: “what differentiates me that others value?” By listening to her
authentic voice, she found plenty of ways to provide value:
Using her curious nature as a “question asker”
to drive quality conversations to help align the team
Using her natural attention to detail and
product focus to provide value when pairing with developers on infrastructure
Using her passion for monitoring and logging to allow
the team to monitor previously hidden issues in the quality of the product
Inspired by these talks, I’ve started to listen to my
authentic self to shape what I do. If somebody were to ask me “what do I do”, I’d
respond by saying I’m a quality inspirer – the thing I love doing most is
leading and coaching teams to a more mature quality culture. This has started
to manifest in the work I do:
I love coaching people: I’ve started mentoring
new testers and coaching developers on writing end-to-end automated testing
I love optimising processes: I’ve started to
make large tweaks in the ways we do testing (e.g. embracing a Session-based
test management approach and doing more time-boxed exploratory test sessions)
I am a dreamer who thinks things can be different:
I’ve done some work to restructure our test automation framework to make it easier
to write and maintain tests
Ultimately, by doing this, I’m even happier at work! If you
want to make your work fun, I’d encourage you to embrace your authenticity. How?
Embrace your talents and interests
Open yourself to the possibility of change
Learn by experimenting, and find out what works
I’ll leave you with three questions:
What do you do?
Does what you do harness your talents and
How could you change what you do to harness your
This was particularly true for me when I read Tim Ferriss’s
The 4-Hour Workweek. I pulled a bunch of good ideas from his book, but one in
particular that stands above the rest is this:
A lack of time is
a lack of priorities.
I think this idea has improved my life over the last few
years more than any other tidbit of productivity or life hacking advice.
Most often, a lack of time—time pressures, rushing,
scrambling to finish things, busyness—is simply a lack of priorities. We can
choose to spend our time differently, on the things that are more important,
and ditch the things that aren’t, thereby freeing up our time and energy.
We choose to be busy or rushed, and we can choose otherwise.
A lack of time is
a lack of priorities.
I concur that this idea has improved my life over the last
18 months more than almost any other piece of advice.
When I first started working after uni, I found myself
overwhelmed by the demands of doing a full-time job, handling domestic chores,
doing self-care, socialising, maintaining relationships, pursuing my hobbies,
and a million other demands on my time.
I found myself committing to way too much, realising far too
late that there was no way that I was going to be able to do everything I’d
committed too, and upset a lot of people along the way.
Something had to change.
A lack of time is
a lack of priorities.
The first thing that helped was realising that there was
almost nothing I had to do.
There is nothing in the world that we truly must do. We can
choose to do or not do just about anything. Take wearing clothes in public. It
sure feels like you have to do it—and if you’re like me you want to do it
too—but you don’t actually have to.
I found this idea very hard to internalize at first.
Let’s say you feel that you have to complete an important
assignment. If I say, “You don’t have to do it, you can choose to do it or
not,” you’ll probably think, “Okay, that’s true… but it still feels like I have
to do it!”
This can be so deeply engrained in your psyche that it will
take a long time to fix. I’m not entirely sure what helped me move away from
“must” thinking to “choice” thinking; it’s been such a gradual change over
Being aware of the distinction is probably the place to
start. If you can constantly remind yourself that you choose to do the things
that you do, you’ll slowly shift away from “must” thinking.
You can always make more time for things if you choose to.
A lack of time is
a lack of priorities.
The second thing that helped was actually thinking about
what my priorities were.
Without a clear sense of priorities you’ll have difficulties
deciding where to best spend your time and energy.
If you don’t know your priorities it’s probably worth your
time to sit down and think about it. You’d be amazed what you can come up with
in just five minutes of conscious effort.
How many of you know actually have a clear sense of your
Lots of things sound “plausibly important”, and without
having a sense of priorities, I found it really hard not to say that everything was important.
At the beginning of this year, I spent an afternoon thinking
about exactly what my priorities were, and explicitly writing them down. Most
productive afternoon I’ve spent this year. Since doing that, I’m basically
never stressed about having too much to do. I can pick what’s most important
(based on my priorities), and do just that.
A lack of time is
a lack of priorities.
The final thing that helped me was learning to use the
thought “I have too much to do” as a trigger to reduce the amount I’m going to
Say you’re a college student, and you have a paper due. The quality of the paper will depend upon the amount of effort you put in. We’ll say that you know the project pretty well: you can get an A with only moderate effort, and with significant effort you could produce something much better than the usual A-grade paper.
environment implicitly attempts to convince students that their preferences
point ever rightward along this line. Parents and teachers say things like
“you should put in your best effort,” and they heap shame upon people
who don’t strive to push ever rightward along the quality line.
react to this coercion in one of two ways. The first group (the
“slackers”) rejects the implication that quality=preferences. These
are the people who don’t care about the class, who complain constantly about
the useless pointless work they have to do, who half-ass the assignment and
turn in something that either barely passes or fails entirely. Slackers tend to
resent the authority forcing them to write the paper.
The second group
(the “tryers”) are the ones who accept the premise that
quality=preferences, and strive ever rightwards on the quality line. Tryers
include people of all ability levels: some struggle as hard as they can just to
get a C, others flaunt their ability to produce masterpieces. Some try to curry
favour with the teacher, others are perfectionists who simply can’t allow
themselves to turn in anything less than their best effort. Some of them are
scrupulous people, who feel guilty even after getting an A, because they know
they could have done better, and think they should have. Some are humble, some
are show-offs, but all of them are pushing rightward.
Society has spent
a lot of time conditioning us to think of the tryers as better
than the slackers. Being a tryer is a virtue. Slackers are missing the point of
education; why are they even there? The tryers are going to go places, the
slackers will never amount to anything.
But in fact, both
groups are doing it wrong.
At university, I saw
the worst effects of this “tryer” culture.
expectations placed on the students: “You should be able to read the entirety
of Paradise Lost and write a 2,000
word essay on it within a week”; “Here’s an explanation of Gödel’s
incompleteness theorems in 60 minutes – we expect you to have completely
understood it by the next lecture in 2 days time”; “We expect you to maybe take
a week off during the holidays, and then spend 40 hours a week revising the
material the rest of the time (an actual
quote from a lecturer!)”.
competitiveness that permeated every student interaction: “I heard she didn’t
get an internship this summer – how embarrassing”; “I heard he got a 2:2 – poor
him”; “God, you never see them out, they’re just studying all the time, what a
and normalisation of sacrificing your mental health towards the pursuit of
perfection at all costs: People literally spending 18 hours a day in the
library in the two months leading up to exams; people casually talking about
“week 5 blues”, as if getting downtrodden by an environment in a month is just
normal; the expectation that if you’re not working yourself to exhaustion
you’re not trying hard enough.
effects this wrought on people’s happiness! People dropping out because the
expectation of “getting a first, being in a uni sports team, having a really good relationship with a really attractive partner, getting an
internship at a prestigious company, being president of 17 societies and having
all these amazing friendships” was (shockingly!) not something that they could
live up to. People having breakdowns because the pressure of failing and of
being a failure was too much to bear. The endemic and epidemicrates of mentalhealthissues.
There is a different
When I was at university,
for the first time ever, I realised that I couldn’t do well academically
without putting in an extraordinary effort. To get that first, I needed to
forsake my social life and relaxation time to work as hard as I physically
could, nothing else would have sufficed.
remembered what I was fighting for: (quote again from this blog post)
What is your goal in
taking this class? Perhaps you’re doing it thanks to a combination of social
pressure (your parents said to), social inertia (everybody else goes to
college), and a vague belief that this is the path towards a good job and a
comfortable life. Or perhaps you’re there because you want good grades so you
can acquire lots of money and power which you will use to fight dragons. Or perhaps you’re
there out of a genuine thirst for knowledge. But no matter why you’re there,
your reason for being there will pick out a single target point on the quality
line. Your goal, then, is to hit that quality target — no higher, no lower.
Your preferences are not “move rightward on the quality line.” Your preferences are to hit the quality target with minimum effort.
If you’re trying to
pass the class, then pass it with minimum effort. Anything else is wasted
If you’re trying to
ace the class, then ace it with minimum effort. Anything else is wasted motion.
If you’re trying to
learn the material to the fullest, then mine the assignment for all its
knowledge, and don’t fret about your grade. Anything else is wasted motion.
If you’re trying to
do achieve some combination of good grades (for signalling purposes), respect
(for social reasons), and knowledge (for various effects), then pinpoint the
minimum quality target that gets a good grade, impresses the teacher, and
allows you to learn the material, and hit that as efficiently as you can.
Anything more is wasted motion.
Your quality target
may be significantly left of F — if, say, you’ve already passed the class, and
this assignment doesn’t matter. Your quality target may be significantly to the
right of A — if, say, you’re there to learn the material, and grade inflation
means that it’s much easier to produce an A-grade paper than it is to complete
the assignment in the maximally informative way. But no matter what, your goals
will induce a quality target.
slackers and the tryers are pursuing lost purposes. The
slackers scoff at the tryers, who treat an artificial quality line like it’s
their actual preferences and waste effort over-achieving. The tryers scoff at
the slackers, who are taking classes but refusing to learn. And both sides are
right! Because both sides are wasting motion.
The slackers fail to
deploy their full strength because they realize that the quality line is not
their preference curve. The tryers deploy their full strength at the wrong
target, in attempts to go as far right as possible, wasting energy on a fight
that is not theirs. So take the third path: remember what you’re
fighting for. Always deploy your full strength, in order to hit your
quality target as fast as possible.
with everything you’ve got.
And that’s exactly
what I did at uni. I realised that my main aims were picking enjoyable courses
and getting a 2:1, so aimed for that, in the full knowledge that a first was
never on the cards. It made my uni experience much more enjoyable.
objection might be the following: “We want to be the best at what we do.
Therefore, we need to push as far right as we can on the quality curve”.
Here’s 9 examples of
us not doing that:
As a developer:
We choose not to
make a design the best we could possibly muster, because we decide it’s not
worth the time or effort to do it.
We choose not to
refactor every bit of sub-optimal code that we see, because we decide our
efforts are better spent elsewhere.
We choose not to
write our tools to the same quality bar as our products, because we decide it’s
not worth the investment.
As a tester:
We accept that
certain bugs aren’t worth fixing because they’re not required to get us to the
desired quality bar.
We decide not to
test most areas that we could test, or don’t test as deeply as we could,
because we decide that the information we’d uncover isn’t worth the effort.
As a customer
We don’t immediately
drop everything and fix an issue a customer has raised, and may not fix the
issue at all, because we decide that they could live with the issue.
As a manager:
We choose not to do
the majority of the things that would be beneficial to the project because
there’s not enough time. Instead, we pick the highest value things, and do them
as well as they need to be done.
As a product owner
or product manager:
We choose not to
implement the majority of requests that people make of the product, because
most of them aren’t worth the investment.
As a senior manager
We choose not to do
99% of things because they’re not the things that provide maximum value.
What all these cases
have in common are the same goal: hitting one’s quality target as fast as
possible, with minimum effort.
The modern testing
mission statement is “Accelerate the
achievement of shippable quality”. I think that thinking about testing in this
way has some advantages over the context-driven school of thought.
context-driven school of thought is a better guide when it comes to “how to
test”, in terms of “evaluating a product by learning about it through
exploration, experimentation, observation and inference”, and is useful in
thinking about all aspects of quality in the right contexts (capability,
reliability, usability, performance, scalability etc).
However, what I
really like about the modern testing way of thinking about things is its
emphasis on hitting the desired quality bar with
Take the word
“shippable” for example. The implication here is that there are bugs that we
don’t need to fix to have a shippable product. The other day, somebody
mentioned that “bugs are bad, and should always be fixed”. NO! It’s not always
Take principles 2
and 3 for example:
We accelerate the
team, and use models like Lean Thinking and the Theory of Constraints to help
identify, prioritize and mitigate bottlenecks from the system.
We are a force for
continuous improvement, helping the team adapt and optimize in order to
succeed, rather than providing a safety net to catch failures.
A modern tester
could consider these principles, look at their organisation’s development
practices, and realise that they can provide most value by driving the
organisation towards a CI/CD system. Crucially, this is valuable because it
makes it much easier for developers to get information about the quality of
their code, and allows us to ship at any time.
Or take principles 4
We care deeply about
the quality culture of our team, and we coach, lead, and nurture the team
towards a more mature quality culture
We expand testing abilities
and knowhow across the team; understanding that this may reduce (or eliminate)
the need for a dedicated testing specialist
The minimal effort
way to achieve the desired quality bar from day one is to make sure that the
entire team is unified in their understanding of what “quality” means for a
given project, and equipping them with the skills for them to assess the
“quality” of the product themselves.
What all these cases
have in common are the same goal: enabling the team to hit their quality target
as fast as possible, with minimum effort.
So, to summarise:
Strive to remember what you’re fighting for.
Aim to hit the
quality target with minimal effort.
As a tester, your
goal is to enable the team to hit their quality target as fast as possible.
(This is a follow-on from the previous blog post – there, I
explain why you should pursue development goals strategically. This blog post
will focus specifically on the “how”).
Recently, I spoke to my friend about how they do personal
development at their company:
“In my company, this is how we do personal development – at
the beginning of each month, my manager and I set high-level personal
development goals. Each week, I set smaller personal development goals, which
build towards the high-level goals. At the end of each week, I score myself
from one to three on each small goal and discuss this with my manager. At the
end of each month, we do a proper review, where we analyse the progress I made
towards the high-level goals. Then we repeat the process again.
If you’re not doing
this, how do you know whether you’re developing or not?”
I agree with my friend – this is the bar we should be aiming
for when it comes to personal development.
You wouldn’t write product code without doing
some thinking about design
You wouldn’t carry out testing for a project without
doing some thinking about strategy
So why would you try and do “personal
development” without doing some thinking about your approach?
This is the approach that I personally take:
At the beginning of each month, decide what your high-level goals are.
My high-level goals for Jan 2019 were the following:
Learn how to give effective feedback
Identify and implement changes to our Dev/ST
Learn how to effectively review functional
specs/designs from an ST perspective
Note – these goals are quite vague. That’s okay, because the
weekly goals will be much more specific.
Before the beginning of each week, decide what your weekly goals are. These
goal should be linked to the high-level goals.
Here are some examples of weekly goals that I used:
[Learn how to give effective feedback] For
people X and Y, identify one specific area where they would improve their
capability. Give feedback to them about this. Get an explicit example of them
using the feedback and getting measurably improved performance as a result.
Justify with examples to manager in status on Friday
[Identify and implement changes to our Dev/ST
process] Have a meeting with the Segment Routing team and discuss some of the
Dev/ST process changes you’d like to make and come to an agreement about what
process changes you’ll use on this project.
[Learn how to effectively review functional
specs/designs from an ST perspective] For the EVPN Multicast project, consider
the estimates and testability implications of the project plan. Either give
suggested changes to these estimates/testability plans, or else come up with
independent justifications for why they are sensible. Justify to manager in
status on Friday
As part of my status with my manager every week, explicitly set some time to
talk about how the weekly development goals went.
As an example, with the feedback goal, my feedback wasn’t
quite having the desired effect. We discussed this, and identified two issues:
I wasn’t explaining the goal/mission/context
I wasn’t being specific enough in the feedback
(for example, saying something is “good” without explaining what specifically
was “good” about the thing)
At the end of each month, I have a longer check-in meeting with my manager (30
minutes), where we discuss how the high-level development goals have gone, and
what the next set of things to work on is.
As an example, with the Jan 2019 goals, we agreed that I’d
made good progress on learning how to effectively review functional
specs/designs from an ST perspective. Giving effective feedback went less well
and digging into it suggested that the wider mentoring skills were the limiting
factor. This helped me to shape my Feb 2019 goals.
Some things to think about when setting goals (also see
previous blog post):
For the person
trying to develop themselves
Personally developing yourself is your job. Nobody else is going to do it for
you. Only you know what you actually want to achieve.
You can ask for help – and you can ask people who aren’t your manager, or even
in your management line. A couple of examples:
I wanted to learn about how to build a team.
Yanqing Cheng has done a lot of good thinking in this area, so I asked to chat
to her for half an hour about it, which was really useful.
I wanted to learn how to teach contractors to do
session-based testing effectively. Pete Whiting had done this for various
projects he’s worked on, so I asked to chat to him for half an hour about it,
which was also really useful.
For personal development to work, and for people to be able to help you, you
must be honest with yourself:
Developing yourself is hard – are you willing to
put the time and energy into doing it?
Developing yourself will be uncomfortable – are
you willing to try new things, be vulnerable and sometimes fail?
Developing yourself requires commitment – are
you willing to put in time every week for the next month? The next year? The
For the person coaching/mentoring
others in personal development
Encourage people to think about what they
actually want to achieve, and why
Challenge people to stretch themselves and push
themselves outside their comfort zone (if they’re willing)
Explicitly give them the time to work on
personal development (if Google Engineers can spend up to 20% of their time on
personal development, we can find the time too)
Ask probing questions to understand their
motivations and suggest other ways of doing things
Tell people what they should aim to develop – if
it doesn’t come from them, it won’t work
Force people to push themselves outside their
comfort zone if they’re not willing – it requires them to be bought into it
Sacrifice personal development time for the sake
of achieving short-term project goals – otherwise you’ll be fire-fighting
Impose your way of doing things onto them –
they’re different to you, so different things will work for them
Make evaluations or judgements without doing the
active listening first
Ask ten of your colleagues who know something
amount about Rust how they learnt to use it, and try the three best suggestions
that you hear
All the above have a non-zero chance of achieving the goal
“I want to get better at coding using Rust”. But:
How do you know that the approach you’re taking
is any good?
How do you know that there isn’t a vastly better
approach you could be taking?
When it comes to personal development, most of the time we
choose to “pursue our goals” through routes that are far less effective than the
routes that we could find if we tried.
More specifically, most people do at least the following:
Tell ourselves and others stories of how we’re
aiming for various “goals”
Search out modes of activity that fit in with
the narrative of goal-seeking
Feel happy or sad when we do/don’t achieve our
However, there are heuristics that would be useful to
goal-achievement that we do not
automatically carry out by default. By default, we do not do the following:
Ask ourselves what we’re trying to achieve:
Is there a specific project I want to work on that requires Rust?
Am I learning just for interest’s sake?
Ask ourselves how we could tell if we achieved it and how we can track progress?
Does “success” look like creating a new tool using Rust?
Does “success” look like being able to solve the first 100 HackerRank problems using Rust?
Find ourselves strongly, intrinsically curious about information that would help us achieve our goal:
Have I spent 10 minutes sitting down and thinking about what information I need to get better at coding in Rust?
Gather that information:
Have I asked anybody else how I could get better at coding in Rust?
Have I spent 5 minutes googling to try and find out how to get better at coding in Rust?
Have I thought about which strategies have/haven’t worked in the past when trying to achieve similar goals, like learning a new programming language?
Systematically test many different conjectures for how to achieve the goals, including methods that aren’t habitual for us, while tracking which ones do and don’t work?
Have I tried more than one approach towards learning Rust?
Have I tried any non-habitual approaches towards learning Rust?
Do I have any idea what strategies actually work for me when learning a new thing?
Focus most of the energy that isn’t going into systematic exploration on the methods that work best:
How much time do I actually spend using methods I know to be effective for learning Rust?
Make sure that our “goal” is really our goal, that we actually want it, and we’re not constrained by fears or by uncertainty as to whether it is worth the effort
Am I actually just saying that I want to learn Rust to keep my manager happy?
Do I have people I can talk to for support in case it proves much harder than expected to learn Rust?
Use environmental cues and social contexts to bolster our motivation
Have I got time budgeted and agreed with my manager to spend time learning Rust?
Have I scheduled one evening a week to go through that Rust tutorial?
Most of the time, when we’re trying to achieve our goals, we
just do things. Maybe we act from habit or from impulse; maybe we act based on
a prompt from our manager; maybe we act because our friend suggested that this
would be a cool thing to try. However, we do not systematically choose the
narrow sets of actions that would effectively optimize for our claimed goals,
or for any other goals.
But we can do much better! The heuristics above go a long
way to optimizing for our claimed goals, but they require work to make
Do you want to get better at achieving your goals? And are
you willing to put the work in to train yourself to get better?
In the next article, I’m going to share a framework for
pursuing development goals strategically, based on the above heuristics.
Recently, I’ve come to believe the Earth is flat, not round.
I know this opinion will be controversial to many of you,
but hear me out. Firstly, intuition tells us that the earth is obviously flat –
just look at it! There is empirical evidence to back up our intuition – one
such famous experiment is the Bishop Experiment (and there are many others):
California Monterey Bay is
a relatively long bay that sits next to the Pacific Ocean. The distance between
the extremes of the Monterey Bay, Lovers Point in Pacific Grove and Lighthouse
State Beach in Santa Cruz, is just over 23 statute miles.
On a very clear and chilly day it is possible to see
Lighthouse Beach from Lovers Point and vice versa. With a good telescope,
laying down on the stomach at the edge of the shore on the Lovers Point beach
20 inches above the sea level it is possible to see people at the waters edge
on the adjacent beach 23 miles away near the lighthouse. The entire beach is
visible down to the water splashing upon the shore. Upon looking into the
telescope I can see children running in and out of the water, splashing and
playing. I can see people sun bathing at the shore and teenagers merrily
throwing Frisbees to one another. I can see runners jogging along the water’s
edge with their dogs. From my vantage point the entire beach is visible.
Correcting for the height of the observer of about 20
inches, when looking at the opposite beach over 23 miles away there should be a
bulge of water obscuring objects up to 300 feet above the far beach. There
isn’t. Even accounting for refraction, the amount hidden should be around 260
feet – seeing down to the shoreline should be impossible.
Not only is there strong empirical evidence to back up the
claim, there are robust arguments against attempts to falsify this belief.
Surely we’ve sent people to space, and they’ve
seen that the Earth is round? Nope. As a concrete
example, contrary to popular opinion, “There is no Flat Earth Conspiracy. NASA
is not hiding the shape of the earth from anyone. The purpose of NASA is not to
‘hide the shape of the earth’ or ‘trick people into thinking it’s round’ or anything
of the sort. There is a Space Travel Conspiracy. The purpose of NASA is to fake
the concept of space travel to further America’s militaristic dominance of
space. That was the purpose of NASA’s creation from the very start: To put
ICBMs and other weapons into space (or at least appear to).”
How is circumnavigation possible? Here are
some maps of what the world could look like; in particular, “The
earth is surrounded on all sides by an ice wall that holds the oceans back.
This ice wall is what explorers have named Antarctica. Beyond the ice wall is a
topic of great interest to the Flat Earth Society. To our knowledge, no one has
been very far past the ice wall and returned to tell of their journey. What we
do know is that it encircles the earth and serves to hold in our oceans and
helps protect us from whatever lies beyond.”
How does sunrise/sunset work? Here’s
an explanation. Why are other planets round, but not the Earth? “The
Earth is not a planet by definition, as it sits at the centre of our solar
system above which the planets and the Sun revolve.” Why doesn’t gravity pull
the Earth into a spherical shape? This is explained by the theory of Universal
I’m assuming the vast majority of readers haven’t been
convinced by the above If I asked you to attempt to try and refute the above, I
assume that you’d put all your cognitive effort into doing things like:
Calling out questionable assumptions (like the
implicit assumption that the our senses are always an accurate guide to understanding
Being sceptical of certain claims (Are NASA
really spending billions of dollars a year purely for propaganda purposes? Has
nobody ever tried to go beyond the ice wall?)
Noticing that you’re confused by certain things
(What about the phenomena that don’t seem to fit with the theory of Universal
I’m further assuming that you wouldn’t find it difficult to
do this, because you already are pretty much convinced that the Earth is round,
so it’s not hard to attempt to try and falsify the claim that the Earth is
But I now want you to consider the fact that even people
that you hold in high esteem often hold beliefs that you think are wrong. Isaac
Newton is generally regarded as being a pretty smart cookie, yet people often
forget that he spent a significant amount of time dabbling in alchemy.
There are some very, very smart people (see here and here)
who genuinely believe in transhumanism. Elon Musk is Elon Musk and he’s got
some views that are pretty
More generally, you’ve seen friends and family, or other
people you know who you consider generally to be very intelligent believe
things that are wrong. As an example, I’ve seen friends do degrees or go into
careers, where it was obvious at the time that they were going to hate it. And
the scary thing is that they’d come up with plausible-sounding (but incorrect)
explanations about why they were making the right decision (they’ve revised
that opinion since!). You yourself know that you’ve made bad decisions in your
life or held beliefs that were just completely wrong – the scary thing is that
you were certainly convinced at the time that the decisions or beliefs were
The bottom line is this: a significant proportion of the
claims that both you and people you hold in high esteem are making have major
flaws, which they themselves cannot see.
Suppose now that you’re testing something. I’d like to highlight
two possible attitudes that you might have whilst testing it:
I believe that this thing should fundamentally
work. We should do some testing to check that this is the case, and I’m sure
we’ll find some bugs. However, I think that in general, the thing is going to
There is basically no chance that this thing
will fundamentally work. I am going to make every effort possible to find
evidence that this thing doesn’t work. Only after I’ve made the best effort
possible to disprove that this works, if the evidence permits me to believe
that this thing works, I may start to believe it.
When it comes to testing products, it’s not too hard to take
attitude 2. We’ve all seen enough examples of faulty software to know that
often products don’t behave in the way that we want them to behave.
What’s much more common is to take attitude 1 when it comes
Authoritative documents (such as requirements
documents, or functional specifications)
Designs (at the level of whiteboard sessions,
High-level Designs, System-level Designs etc)
Claims made by authoritative people (such as
senior engineers, product managers etc)
However, by taking attitude 1, we are doing our colleagues a
disservice! Just like everyone else, they are fallible. As testers, we spend
our time (amongst other things) being professional sceptics, and we are not
helping to create a better product if we don’t apply our critical thinking in
these contexts as well.
To be clear, I’m suggesting doing the following: Take
something like a functional specification or a requirement given by an
authoritative figure; review it with the same level of scepticism that you
might apply to a claim like “the Earth is flat”; feed it back to the relevant
people. I think there are at least two valuable contexts where it’s worth doing
In meetings such as “whiteboard sessions”,
“design meetings”, “requirements specification” etc – the tester’s role here is
to play “Devil’s Advocate” in the sense described above
When reviewing authoritative documents (such as
designs, requirements, functional specifications etc) – again the tester’s role
here is to play “Devil’s Advocate”
I’ve been trying to come up with a catchy name for this type
of testing – I’m going with “Playing Devil’s Advocate”, but if people have
better suggestions, let me know.
So, how might a tester go about practicing doing this? As a
potential option, I’d suggest doing something like the following:
Look at the functional specification for a
product that you’re going to test
Explicitly make a note of all the claims and
assumptions made in the specification
For each of the claims and assumptions:
Check whether there are any given reasons or
justifications for the claims/assumptions made
“Apply critical thinking” to evaluate whether
these reasons or justifications are valid (as a good rule of thumb, if you
sense that you’re confused by any of the reasons, or you don’t feel that you
could confidently explain this reason to your manager, they’re probably not
Try and generate contexts in which these
reasons/justifications would not be valid (that will help you to explain why
they’re valid in the specific context it’s being applied to)
Report your findings to the appropriate people.
Ideally, it should be the people who own the document, but if you’re feeling
nervous about this, report your findings to your manager to raise as
I’m also suggesting that it should be general practice for
testers to do charters to review authoritative documents, and to attend design
meetings etc, and play the role that I’ve specified above.
Here’s an extract from a blog
post I recently read:
Consider the boiling
of water. That’s straightforward, water boils at 100 °C, right?…
Put yourself in the
shoes of someone at the start of the 1800’s, with only a crude, unmarked
mercury thermometer, trying to figure the physics of temperature.
Go to your stove,
put some water in a pot, start heating some water, and pay attention as it
The first thing
you’ll probably notice is a lot of small bubbles gathering on the surface of
the pot. Is that boiling? The water’s not that hot yet; you can still even
stick your finger in. Then the bubbles will appear faster and start rising, but
they somehow seem ‘unboiling’. Then you’ll start to see little bubble storms in
patches, and you start to hear a hissing noise. Is that Boiling? Sort of? It
doesn’t really look like boiling. The bubble storms grow
larger and start releasing bigger bubbles. Eventually the bubbles get big and
the surface of the water grows turbulent as the bubbles begin to make it to the
surface. Finally we seem to have reached real boiling. I guess this is the
boiling point? That seems kind of weird, what were the things that happened
earlier if not boiling.
To make matters
worse, if you’d used a glass pot instead of a metal one, the water would boil
at a higher temperature. If you cleaned the glass vessel with sulfuric acid, to
remove any residue, you’d find that you can heat water substantially more
before it boils and when it does boil it boils in little explosions of boiling
and the temperature fluctuates unstably.
Worse still, if you
trap a drop of water between two other liquids and heat it, you can raise the
temperature to at least 300 °C with nothing happening. That kind of makes a
mockery of the statement ‘water boils at 100 °C’.
It turns out that
‘boiling’ is a lot more complicated than you thought.
amount of detail is not limited to “human” or “complicated” domains, it is a
near universal property of everything from space travel to sewing, to your
internal experience of your own mind.
Suppose that (say, at school) you were asked to test the
claim that water boils at 100 °C. I’d like to highlight two possible approaches
you could take.
Approach 1: You get some water, a pot and a thermometer. You
heat the water in the pot until the thermometer reads 100 °C. You (probably!)
observe bubbles on the surface of the water and steam coming out of the pot.
You conclude that water does boil at 100 °C, and there’s not much more to test.
Approach 2: You actually observe the water as you heat it.
You notice some things that don’t really make sense to you (how is it that the
water bubbles and yet is still cold, for example?). You consider some other
factors, such as whether the vessel you heat the water in makes a difference.
You consider the interaction between water and other residue substances it may
come into contact in before you heat it. And so on. You conclude that there’s
so much that you could learn if you continued to test this claim further!
Now take a moment to consider the following: it’s really, really easy to take
approach 1, and to (erroneously) conclude that you understand how boiling
This is a very common failure mode, which happens in the
You think that you know the expected behaviour,
and all the factors that are relevant (in approach 1, the assumption is that
the only relevant factor is the temperature of the water)
You run a test that confirms the expected
behaviour, ignoring all the details that aren’t considered in your model (like
the type of vessel you heat the water in)
I certainly didn’t know most of the facts presented above
about water boiling, and before reading that article, I thought I had a pretty
good understanding of how boiling worked – how wrong I was!
Also, it’s worth highlighting that some of these surprising
details are extremely important in certain circumstances: “The possibility of
superheating liquids means it’s important to use a packed
bed when boiling liquids in industrial processes lest your
process be highly inefficient and unpredictable.”
Now, suppose that you’ve been
asked to test a feature of a piece of software. Given infinite time, how much
testing COULD you do?
It’s worth taking some time (say,
5 minutes) to think about just how much you could test here. It’s worth
thinking about this in two ways:
you made the assumption that this piece of software was random, how would you
you threw out the assumption that this piece of software was always random, and
desperately tried to find ways in which this software wasn’t random, how would
you go about doing that?
If you’ve gone through that
exercise, you should notice that in the latter case, your list is vastly
All the above has been building up
to a key point that I want to make: given that reality has a surprising amount
of detail, the set of things that you could test is always vast! I want to make
this point because I occasionally hear people say things like “there wasn’t
much to test” or “We’ve got complete coverage of this feature”. Let me be clear
– these statements are simply incorrect. I think what they mean to say is
“there’s nothing else worth
testing”. This is a very different statement.
Now, an obvious objection to what
I’ve been talking about above is “well, clearly we’re not going to have time to
test everything we could test”. This is obviously true. However, I think the
exercise of thinking about everything you could test if you had infinite time
is a useful exercise, because you’re more likely to notice that certain areas
that you wouldn’t otherwise have considered are indeed worth testing, or worth
testing in more detail.
So, I’d like to leave you with a
couple of things. The first one is a heuristic for generating test
a charter focused on generating as many ideas as possible for things you could
test, if you had infinite time
a charter focused on evaluating the costs and risks of doing/not doing each
area of testing
to the relevant stakeholders which testing you are and are not going to do
based on the constraints you have, explaining clearly the risks of not doing
the feedback that you’ve got from stakeholders and repeat steps 1-3 as
The second thing is some good
questions to ask in test debriefs or when testing is reported more generally:
testing would you do if you had another day?
Do not accept “None” as an answer – there is
definitely testing they could do if they had more time
are we doing that additional bit of testing? Is it worth an additional day?
aren’t we doing that additional bit of testing? What’s the risk if we don’t do
Suppose that you won $10,000,000 tomorrow. How
happy would you be in a year’s time?
Suppose that you became paralysed from the neck
down tomorrow. How happy would you be in a year’s time?
We have a strong tendency to overestimate the impact that
extreme events will have on our lives. For example, with the two questions
above, a surprising result:
“In a very famous study published by researchers at
Northwestern University in 1978 it was discovered that the happiness levels of
paraplegics and lottery winners were essentially the same within a
year after the event occurred. You read that correctly. One person won a
life-changing sum of money and another person lost the use of their limbs and
within one year the two people were equally happy.” (See here)
Once you know about this effect, you’ll see it crop up again
and again and again. A few examples (Examples 3-6 are based on this):
“College students overestimated how happy or
unhappy they would be after being assigned to a desirable or undesirable
“People overestimated how unhappy they would be
two months after the dissolution of a romantic relationship.”
“Untenured college professors overestimated how
unhappy they would be five years after being denied tenure.”
“Women overestimated how unhappy they would be
upon receiving unwanted results from a pregnancy test.”
So, what’s going on?
Section I was basically describing “The Impact Bias”.
Harvard Professor Dan Gilbert has done a fair bit of research on this, and he
suggests the following
as one of the contributors to this bias:
tend to overestimate how much they will think about the event in the future,
and at the same time, they underestimate the degree to which other events will
influence their thoughts and feelings. So people get too focused on a particular
event and its emotional impact.”
If I were
to sum the above up in my own words, one way of describing it is “Stop
tunnelling! Don’t get obsessed with one event, but focus on the bigger picture,
and work out what actually matters!”
change of pace now. Imagine that you were developing some software for a
customer (I’m assuming imagining this won’t be too much of a stretch!) Here are
some examples of things that could go horribly, horribly wrong:
With quite a tight deadline, you write code to
implement 10 different features. Because of time constraints, the quality of
the 10 features is not that great. However, when you deliver the product to the
customer, it transpires that they only care about 2 of the features, and wanted
them to be really good quality.
This product is completely new, and has never
been delivered to customers. As normal, the testing focuses on functionality,
robustness, scalability, interoperability, performance, security, and you’ve
gathered enough information that you’re reasonably confident in making the
judgement that the product is of good quality for all these quality criteria.
However, it turns out that the product is really hard to install, and the
documentation is completely unhelpful when it comes to using the product. As a
result, the customer stops using the product, because they can never get
started using it.
Your customers hate regressions, and you decide
that you need many automated, regressible checks to help guard against this. A
very large proportion of your testing effort involves writing scripts up front to
carry out these checks, and after spending 2 weeks writing scripts, debugging
them, and getting them working, you eventually find some fairly serious issues.
You then realise that, if you’d used method X instead, you’d have found all
these issues in a day, rather than 2 weeks.
theme that all these failures have is the fact that the team has succumbed to
focalism! They’ve narrowed in on these sub-goals, but missed the bigger
picture. Note the parallel to Impact Bias – we’ve succumbed to tunnelling in
exactly the same way! Fortunately, both these biases have the same solution,
which I’ll describe to you now.
In the book
Coaching Habit”, the author describes seven questions that allow you
to have a greater impact. I personally think that all these questions are worth
adding to a tester’s arsenal, but I’m going to focus on question four:
“What do you want?”
A key aim
of asking this question is to make sure that you truly understand what the
other person is trying to achieve, at the highest-level of abstraction
possible. Useful questions to ask in addition to this question are the
following: “why do you want that”; “what will that help you achieve”; “What
problem are you trying to solve”. Once you know what they actually want, you
can do stuff that you know will be actively useful. A few examples:
Consider the following dialogue.
Person X: We’re going to make these 10 features,
and I’ll need you to test them all.
Tester: What do these features do?
Person X: Feature 1 does this, Feature 2 does
this, … and feature 10 does this.
Tester: What is the customer going to do with
Person X: (thinks for a bit) Well, they
definitely said that they wanted features 3 and 7 to do Y, but I think the
other features will be useful to them as well.
Tester: Do we need to make all these 10 features
now? If we do, we’ll have much less time to test them, and the quality will be
Person X: Hmmm well I suppose we could just make
features 3 and 7 for now, and if the customer asks for more features, we can
make them later.
Consider the following dialogue:
Tester 1: I’m blocked.
Tester 2: In what way are you blocked?
Tester 1: My test script is blocked on bug
896135 (which makes the system crash)!
Tester 2: What does the test script do?
Tester 1: Well, it configures a network, and
then has 20 more steps. I’m hitting this bug on step 2.
Tester 2: Is it important which order you do the
Tester 1: (thinks for a bit) No, not really. The
steps basically delete and re-configure stuff, checking that things are okay
after each re-configuration step. So the steps are mainly independent.
Tester 2: So, what could you do to stop step 2
Tester 1: Hmmm, I could temporarily remove step
2, and try the other steps.
Consider the following dialogue:
Person Z: I’ve just had an issue raised by a
customer saying that process P takes too long. Once we’ve fixed the bug we’ve
raised, we should do some testing to make sure that process P takes less than a
Tester: What does process P do?
Person Z: Well, process P is used when a link
fails to switchover traffic to a working link. And it’s important that this
switchover happens quickly!
Tester: What happens if the switchover doesn’t
Person Z: Well, then voice traffic is dropped
for too long, and the person on the other end can’t understand what’s being
Tester: How long does traffic need to be dropped
for before you can notice it?
Person Z: Hmmm, let me check. (Checks)
Tester: So would you prefer us to do some
testing to make sure that process P takes less than 50ms?
Person Z: Yes please.
takeaway both in work and in life – when people say “I want X”, don’t just
blindly trust them! Do some digging, and make sure that you understand what
they actually want!
Here’s an extended quote from the book “Steal Like An
Artist” by Austin Kleon:
Every artist gets asked the question,
“Where do you get
The honest artist answers,
“I steal them.”
How does an artist look at the world?
First, you figure out what’s worth stealing, then you move
on to the next thing.
That’s about all there is to it.
When you look at the world this way, you stop worrying about
what’s “good” and what’s “bad” – there’s only stuff worth stealing, and stuff
that’s not worth stealing. Everything is up for grabs…
What a good artist understands is that nothing comes from
nowhere. All creative work builds on what came before. Nothing is completely
If we’re free from the burden of trying to be completely
original, we can stop trying to make something out of nothing, and we can
embrace influence instead of running away from it.
To summarise, every new idea is just a mash-up or a remix of
one or more previous ideas.
In order to test things, you first need to come up with test
ideas – this requires creativity! So how do we go about it?
When I first started testing, I was a helpless little lamb,
so I didn’t generate test ideas. Rather, I imitated the procedures described in
a test plan to the best of my ability. After some time, I realised that in
order to develop my skills as a tester, I’d need to be able to generate test
ideas by myself.
Unfortunately, I made a huge mistake – my model of a skilful
tester generating test ideas was the tester going away, doing some “magic”
(thinking based on experience and knowledge of the product), and ending up with
a test plan chock-full of good ideas.
I have no doubt now that this model is severely deficient.
The problem with just relying on your personal skill to generate test ideas is
that, unfortunately, you can’t know all the relevant things, and more
importantly, you have a strongly biased perception of what matters about the
thing you’re testing.
I have seen for myself the limitations of this model! I
remember the first time that I attempted to write a test plan; I went away,
read the spec, read some RFCs, and then produced a document that I proudly
called a test plan. Fortunately we had processes in place that meant that the
document I produced got review from wiser people than me, and they helped me to
do a far better job. Crucially, the thing that made the test plan better was
the collaboration involved between different people in order to generate good
So, what do we replace this model with?
My current model of how to effectively generate test ideas
is to be a thief. And I’m not talking about stealing like the occasional
shoplifter, but rather I’m talking about stealing rapaciously as if your very
life depended on it! I’m talking about stealing as shamelessly as a pirate! I’m
talking about employing every sneaky trick you can think of in order to steal
the ideas you need!
For example, if you’re attempting to generate test ideas for
testing product P, you could start by interrogating every possible stakeholder
until you’ve extracted every useful idea from them that you can.
Suppose developer D wrote the spec – you should 100%
organise a meeting with them until you know everything that they care about
(regarding product P) and all the test ideas they can think of. And if coder C
wrote the code, you should do the same to them. Has tester T tested product P
before? If so, plunder their brain until you’ve stolen all their best ideas. Do
you know what the customer cares about, and how they’re going to test product
P? If not, make it a mission to ensure that you know that information, stealing
You can put this model into practice today! The next time
you write a test plan, start by making sure that you probe deeply into all the
ideas that all the relevant stakeholders might have. Then let your brain do its
magic by remixing and synthesising all the ideas, and marvel at the test plan
that you will create.
“Need” is quite a hard word to define, so I’m not going to
attempt to define it. Instead, here are some examples of needs (copied from here):
CONNECTION continued safety
to know and be known
to see and be seen
to understand and
celebration of life
Here are some more examples of needs (copied from here):
nutritious food and water
safe work environment
supply of clothing
safe physical environment
primary relations with others
birth control and child-bearing
basic and cross-cultural education.
I’m hoping that this is sufficient to explain what I mean by
What happens when people don’t have their needs fulfilled?
I’m going to assert that when this happens, it prevents the person “from
endeavouring to attain their vision of what is good, regardless of what exactly
that may be” – in other words, they can’t bring forward the best versions of
themselves if they have many needs that aren’t being fulfilled. I’m not going
to rigorously justify this assertion; all I’ll say is that this view is
consistent with current
academic thought on needs.
I think it would be nice if everybody worked in an
environment where everybody was able to have their needs met pretty much all of
the time. I speculate that the vast, vast majority of workplaces do not achieve
this – why? One possible answer is the following: “unfortunately, there are
lots of mean people in the world, who aren’t willing to accommodate the needs
of other people. Most workplaces have some mean people. If you had a workplace
where the vast majority of people were nice, it would be easy to achieve this.
When people’s needs aren’t being met, they’d ask for what they need. The people,
being nice, would go out of their way to accommodate all reasonable needs
others ask for.”
I think that answer has some fatal flaws…
I’m just going to copy and paste three paragraphs from this
There was a debate, in the late 1800s, about whether
“imagination” was simply a turn of phrase or a real phenomenon. That
is, can people actually create images in their minds which they see vividly, or
do they simply say “I saw it in my mind” as a metaphor for
considering what it looked like?
Upon hearing this, my response was “How the stars was this actually a real
debate? Of course we have mental imagery. Anyone who doesn’t think we have
mental imagery is either such a fanatical Behaviorist that she doubts the
evidence of her own senses, or simply insane.” Unfortunately, the
professor was able to parade a long list of famous people who denied mental
imagery, including some leading scientists of the era. And this was all before
Behaviorism even existed.
The debate was resolved by Francis Galton, a fascinating man who among other
achievements invented eugenics, the “wisdom of crowds”, and standard
deviation. Galton gave people some very detailed surveys, and found that some
people did have mental imagery and others didn’t. The ones who did had simply
assumed everyone did, and the ones who didn’t had simply assumed everyone
didn’t, to the point of coming up with absurd justifications for why they were
lying or misunderstanding the question. There was a wide spectrum of imaging
ability, from about five percent of people with perfect eidetic imagery to
three percent of people completely unable to form mental images.
It’s extraordinary how different people’s minds are – they
can be so different that it’s almost incomprehensible. A consequence of this is
that people’s needs might be so different from yours that it wouldn’t even
occur to you that somebody could have that need.
A personal example – I’ve only recently come to accept that
some people very much need to live and work in clean, tidy and neat
environments. I think it’s fair to say that I am not a tidy person. Here’s an
artist’s depiction of what my desk currently looks like (my room at home is
I mean, I understood on some abstract level that people
sort-of preferred tidy environments, but I always imagined that it was a mild
preference – I found it very confusing that they spent so much time organising
things and tidying things, it struck me as a complete waste of time. It wasn’t
until university that I properly got how necessary and uncompromising neatness
was to some people (there were many arguments that led to tears…).
But it extends wider than this – here’s a question for you:
What percentage of US high school students cheat on tests? What percentage have
shoplifted? The answer is nobhg gjb guveqf unir purngrq naq nobhg bar guveq
unir fubcyvsgrq (rot13ed so
you have to actually take a guess first). I don’t know a single person from
either school or my group of friends who has done either of those things, so
the answer was shocking to me. The key idea is that it’s fallacious to
believe that your own social circle is at least a little representative of
society at large.
What’s the consequence of this? Our workplace has lots of
people. Some of them will have needs that are so disjoint from how you view the
world that it would literally never have crossed your mind that a particular
thing could even be an issue! For example, we’re getting a new office fairly
soon; an obvious design question is whether the office should be open plan or
not. These (somewhat click-baity) articles (1
bring up some concerns about open plan offices that would literally never have
occurred to me. Here’s a tweet as an example:
Oh my god, yes. A couple jobs ago, I was basically a zoo
animal. Incessant staring and comments on my clothes, makeup, jewelry,
conversations, personal habits, food, facial expressions, everything. One guy
would even stare between the monitors all day and comment while I worked.
To summarize, the “typical-mind fallacy” basically means
that loads of people are going to have needs that really strongly affect them,
which would never occur to you. I fear that I’m not conveying exactly how
pervasive the typical-mind fallacy is, so if you’re interested, I’d strongly
encourage you to read at least one of these blog posts, all of which are
Suppose you accept that the typical-mind fallacy is true,
and therefore, we will often be unable to pre-empt people’s needs. One could
argue that this isn’t a problem: “So, we may not be able to guess what people’s
needs might be, but surely if somebody has a need that isn’t being met, and
it’s important to them, they’ll speak up about it?” It would be nice if this
were true. However, I strongly believe that this isn’t true.
A personal example – apparently I come across as confident
generally, and apparently people definitely wouldn’t describe me as “shy”. One
might therefore assume that I’d speak up if I had a need that was important to
me that wasn’t being met. However, this assumption is in fact untrue – in the
vast majority of scenarios, I’m terrible at communicating my needs. If I
perceive that a need I have is in conflict with something that somebody else
wants or needs, I’m overwhelmingly likely to just go with what the other person
A detailed investigation of why that’s bad, why I find it so
difficult, and what one can do about it will have to be reserved for a later
blog post, but here’s a short explanation of why: the secondary reason is due to
the following – I don’t really have strong feelings, wants or desires the vast
majority of the time. So generally, when I think that my needs are in conflict
with somebody else’s needs/wants, I assume that my needs are less important
than theirs (using some utilitarian pseudo-justification), and go with what
they say. However, the primary reason why I’m so bad at it is very simple.
I find the idea fucking terrifying.
I have no idea how to convey the sense of dread that I can
feel at the prospect of communicating my needs if I think it will make the
other person upset or angry – I think it’s not dissimilar to the fear that many
people feel when it comes to public speaking. The key point is that people may
not genuinely communicate their needs, even if they’re very much in pain as a
consequence of their need not being fulfilled.
(Note – I speculate that gender might be a significant
factor in how likely people are to communicate their needs. This is based on
the following excerpt from the book “Nonviolent Communication”:
In a world where we’re often judged harshly for identifying
and revealing our needs, doing so can be very frightening. Women, in
particular, are susceptible to criticism. For centuries, the image of the
loving woman has been associated with sacrifice and the denial of one’s own
needs to take care of others. Because women are socialized to view the
caretaking of others as their highest duty, they often learn to ignore their
My mother was once at a workshop where other women were
discussing how frightening it was to be expressing their needs. Suddenly she
got up and left the room, and didn’t return for a long time. She finally
reappeared, looking very pale. In the presence of the group, I asked, “Mother,
are you all right?”
“Yes,” she answered, “but I just had a sudden realization
that’s very hard for me to take in.”
“I’ve just become aware that for thirty-six years, I was
angry with your father for not meeting my needs, and now I realize that I never
once clearly told him what I needed.”
My mother’s revelation was accurate. Not one time, that I
can remember, did she clearly express her needs to my father. She’d hint around
and go through all kinds of convolutions, but never would she ask directly for
what she needed.
So, I’ve spent a long time rambling about needs, and I
promise there’s a purpose to it!
Currently, many companies are making a concerted effort to be
more inclusive. Until recently, I didn’t have a good definition of what
“inclusive” actually meant – but now I think I do.
I’m going to offer the following definition: an “inclusive
environment” is an environment in which:
People feel comfortable expressing their needs
and believe that their needs will be heard and understood.
People will adapt the environment in order to
help people meet their needs.
I like this definition because it allows me to draw some
interesting conclusions. Firstly, I am confident in asserting that making the
environment more inclusive will be beneficial for everyone, because people can
bring forward the best versions of themselves when their needs are being
fulfilled. Best versions of people = better company.
Secondly, and more importantly, I think it makes it clearer
that creating an inclusive environment is HARD. Like, really HARD. I think that
everyone being nice isn’t even nearly sufficient to create an inclusive
environment. The typical-mind fallacy means that many people will have needs
that other people can’t even really conceive, let alone notice. Moreover, many people
find it really, really scary bringing up needs, so won’t do it unless they feel
safe doing it.
This sounds like a problem.
This final section isn’t “Here’s a bunch of answers and some
exquisitely crafted justification to demonstrate that they’ll work” but is more
“I have a couple of things that could be tried, and I’m very keen on other
ideas/feedback”. So here goes:
Firstly, status meetings are a thing (a one-to-one chat with
your manager where you talk about things, often related to project status). I
think one could make a few tweaks to status meetings so that they’re a more
effective environment for communicating needs:
Every status meeting should have explicit time
set out for each person in the meeting to communicate their needs, and this
should be encouraged as standard practice in these meetings.
Secondly, what we would like in an ideal world is for
everyone to have the following capabilities:
The ability to effectively and directly
communicate needs and requests
The ability to respond empathetically and
compassionately to needs and requests
Both these things are super hard. The book “Nonviolent
communication” (NVC) (by Marshall Rosenberg) is basically an attempt to
describe a framework that allows people to do those two things through
effective communication. I’ve read it, and spent quite a lot of time thinking
about it. I’m not entirely sold on everything that he says, but I think it’s
worth investigating further. Something that exists is a NVC workshop, carried
out by an experienced NVC practitioner. It may be worth running a trial session
within a company.
Here are some suggestions – I’d love to hear your thoughts
on the suggestions, and I’d also love to hear if you have other suggestions of