What Do You Do?

This blog post has been inspired by the recent Test Leadership Congress. I would highly recommend the conference!


What do you do?

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 tester”?

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

However, I’ve definitely seen examples where viewing myself as a tester has stopped me from doing things that would have been valuable and useful:

  • 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 automation code
    • Being reluctant to refactor our test automation code
    • 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 meetings
    • Being reluctant to speak up or provide input in design meetings
  • 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 your weaknesses.

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 scripts
  • 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 for you

I’ll leave you with three questions:

  • What do you do?
  • Does what you do harness your talents and interests?
  • How could you change what you do to harness your inner strengths?

Lack Of Time = Lack Of Priorities

The following is inspired by the recent UKSTAR testing conference. I’d highly recommend it to anyone.


Three questions:

  • Do you feel that you are always busy, and can’t do everything you have to do?
  • Do you think that a lack of busyness equates to laziness?
  • Do you often find yourself thinking “If only I had more time” or “I have too much to do”?

If the answer to any of the above questions is yes, then the following advice might be useful:

A lack of time is a lack of priorities.

In more detail (quoting from this blog post):


Sometimes the simplest ideas really stick out.

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.

In more detail (quoting from this blog post):


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

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.

In more detail (quoting from this blog post):


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 priorities?

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

In more detail (quoting from this blog post):


Over the last few years I’ve slowly improved my ability to notice that feeling of “If only I had more time!” or “I have too much to do!”

Whenever I catch myself reasoning along these lines I think, “Wait! I don’t have to be busy. What’s important here? What’s not? What else could I be doing with my time?” etc.

In other words: Pause. Reassess. Decide. Relax.

This has come in handy more times than I can count.


I endorse practicing this technique – whenever you find yourself thinking “I have too much to do”, practice using that as a trigger to reassess what you actually have to do.


To summarise (quoting from this blog post):


You have all the time in the world to do what’s important.

Don’t have the time? Then drop something else to make the time.

Or, accept that it’s not important enough and move on.

Or, accept that you’ll voluntarily be busy for the next little while; that it’s a choice, not a burden.


Against Perfectionism

Against Perfectionism

The following is a blog post inspired by the recent UKSTAR testing conference. I’d highly recommend it to anyone.


From this blog post:


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.

The education 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.

People generally 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.

The outrageous 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!)”.

The oppressive 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 loser”.

The glorification 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.

The devastating 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 epidemic rates of mental health issues.

There is a different way.


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.

Fortunately, I 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 motion.

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.

Both the 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.

Half-ass everything, 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.


One possible 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 support engineer:

  • 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 or executive:

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

Yes, the 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 minimal effort.

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 worth it!

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 and 7:

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

Half-ass everything with everything you’ve got.

Reject perfectionism.

How To Pursue Development Goals Strategically (Part Two)

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

Step one: 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 process
  • 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.

Step two: 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

Step Three: 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 clearly enough
  • I wasn’t being specific enough in the feedback (for example, saying something is “good” without explaining what specifically was “good” about the thing)

Step Four: 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

Thing One: Personally developing yourself is your job. Nobody else is going to do it for you. Only you know what you actually want to achieve.

Thing Two: 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.

Thing Three: 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 next decade?

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
  • Listen


  • 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 forever
  • 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

How To Pursue Development Goals Strategically (Part One)


“I want to get better at coding using Rust”.

Suppose this was one of your personal development goals. How would you go about achieving this?

Here are some approaches that you could take:

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 “goals”

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:

  1. 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?
  2. 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?
  3. 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?
  4. 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?
  5. 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?
  6. 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?
  7. 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?
  8. 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 habitual.

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.

Playing Devil’s Advocate


Recently, I’ve come to believe the Earth is flat, not round. Seriously.

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



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 the world)
  • 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 Acceleration?)

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

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 out there.

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

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:

  1. 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 be okay.
  2. 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 to:

  • 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 this:

  • 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:

  1. Look at the functional specification for a product that you’re going to test
  2. Explicitly make a note of all the claims and assumptions made in the specification
  3. For each of the claims and assumptions:
    1. Check whether there are any given reasons or justifications for the claims/assumptions made
    1. “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 valid)
    1. 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)
  4. 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 appropriate.

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.

Reality Has A Surprising Amount of Detail


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

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.

This surprising 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 works.

This is a very common failure mode, which happens in the following way:

  1. 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)
  2. 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?

As a concrete example, consider the following random number generator:

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:

  1. If you made the assumption that this piece of software was random, how would you confirm that?
  2. If 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 longer!

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 strategies/plans:

  1. Do a charter focused on generating as many ideas as possible for things you could test, if you had infinite time
  2. Do a charter focused on evaluating the costs and risks of doing/not doing each area of testing
  3. Communicate 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 further testing
  4. Incorporate the feedback that you’ve got from stakeholders and repeat steps 1-3 as appropriate

The second thing is some good questions to ask in test debriefs or when testing is reported more generally:

  1. What testing would you do if you had another day?
    1. Do not accept “None” as an answer – there is definitely testing they could do if they had more time
  2. Why are we doing that additional bit of testing? Is it worth an additional day?
  3. Why aren’t we doing that additional bit of testing? What’s the risk if we don’t do it?

What do you want?


Two quick questions:

  1. Suppose that you won $10,000,000 tomorrow. How happy would you be in a year’s time?
  2. 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):

  1. This blog post.
  2. This blog post.
  3. “College students overestimated how happy or unhappy they would be after being assigned to a desirable or undesirable dormitory.
  4. “People overestimated how unhappy they would be two months after the dissolution of a romantic relationship.”
  5. “Untenured college professors overestimated how unhappy they would be five years after being denied tenure.”
  6. “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:

“Focalism: People 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!”


A slight 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:

  1. 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.
  2. 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.
  3. 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.

The common 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 “The 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:

Example 1: 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 these features?
  • 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 less good.
  • 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.

Example 2: 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 steps in?
  • 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 blocking you?
  • Tester 1: Hmmm, I could temporarily remove step 2, and try the other steps.

Example 3: 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 second.
  • 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 happen quickly?
  • Person Z: Well, then voice traffic is dropped for too long, and the person on the other end can’t understand what’s being said!
  • Tester: How long does traffic need to be dropped for before you can notice it?
  • Person Z: Hmmm, let me check. (Checks) Apparently 50ms.
  • Tester: So would you prefer us to do some testing to make sure that process P takes less than 50ms?
  • Person Z: Yes please.

A key 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!

Steal Like An Artist


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 your ideas?”

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 original…

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 test ideas.

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 as appropriate.

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.



Everybody has needs.

“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
to know and be known
to see and be seen
to understand and
be understood

sexual expression





celebration of life
to matter

Here are some more examples of needs (copied from here):

  1. Adequate nutritious food and water
  2. Adequate protective housing
  3. A safe work environment
  4. A supply of clothing
  5. A safe physical environment
  6. Appropriate health care
  7. Security in childhood
  8. Meaningful primary relations with others
  9. Physical security
  10. Economic security
  11. Safe birth control and child-bearing
  12. Appropriate basic and cross-cultural education.

I’m hoping that this is sufficient to explain what I mean by “needs”.

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 blog:


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 similarly messy):

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 and 2) 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 excellent. (1, 2, 3 and 4)


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 wants/needs.

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 own needs…

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

“What’s that?”

“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 your own.