First Drafts on adrianhoward.com

The Push to Solo Work

adrianh@quietstars.com (Adrian Howard) — Mon, 08 Jun 2026 00:00:00 +0000

An anti-pattern I’ve been noticing more recently is an individual trying to use frameworks and canvases intended for collaborative work solo (in UX, dev, product, research, whatever…) — and failing.

The person who says “I just need to fill out the Canvas” rather than getting their views challenged by others.
The person who sets OKRs “for” rather than “with” their team/department/organisation.
The person who builds an opportunity solution tree by themselves, and misses a stack of risks and opportunities.
The person who does the user story mapping exercise solo, and misses all the non-obvious stress-cases.
The person who does a kind of “collaboration washing” by misrepresenting a solo-produced artefact as the result of a team or group’s thinking.
… and so on …

This is something I’ve noticed before — but I’m noticing it more frequently. People I work with are dealing with the fallout from this behaviour this more often. Especially with folk confusing asking an LLM to produce an artefact with collaboration.

Would they be working solo anyway? Is the work environment encouraging them to work by themselves more? Does the structure and apparent clarity of the framework make it easier for them to fall in an antipattern? Are their fewer opportunities for collaboration?

Can we design stuff to make these problems less likely?

Something to think about more.

TL;DR: Some people seem to miss that collaborative tools lose their value when used by one person.

ttfn.

Group Customer Interviewing Practice

adrianh@quietstars.com (Adrian Howard) — Mon, 29 Dec 2025 00:00:00 +0000

(Just been talking with somebody about getting a team better at customer interviewing — which reminded me of a thread on the hellsite I wrote after John Cutler asked for something similar. So reproducing and lightly expanding here for easier reference, and because I’m allowed to have shitty incomplete first drafts of stuff here :-)

Ingredients:

Zoom, or your group chat app of choice.
Miro, Mural, post-it notes + camera — whatever you can use to share stickies/notes as a group. Use Google Sheets/Docs at a pinch
Google docs, or your shared text editor of choice
Calendly for bookings — or something else that lets you easily book in remote meetings onto a calendar

Preparation:

Get together on the shared text editor. Come up with an overarching research question. Hopefully pinned to your actual company strategy/active discovery work.

(I should write a lot here about ways you can figure out decent research questions. But I’m currently on my Christmas break and I don’t want to, because it would turn this into a much, much longer article. The short version: If you end up with something like “Do they want to use feature X?” you’re doing it wrong. The long version: go read Indi Young’s or Steve Portigal’s books.)

Then, as a group, write every dumb question you can think of around that pokes at that research question.

Then, as a group, group related questions together. Maybe switch over to Miro/Mural — but sticking with google docs can work as well.

Start asking “What higher level questions would evoke a story around that group of questions?”.

Repeat.

Carry on repeating.

This often works it way up to questions like “Tell me about the last time you did X?” or “Tell me about your typical day doing Y?”

(Don’t throw the more specific questions away — having a hierarchy of questions from general to concrete can be super useful if you want to probe around specific areas. But the more general story-based questions are going to end up being your workhorses.)

Practice:

Our preparation gives us research question, topics of interest, and a hierarchy of possible questions around those topics.

Time to talk to a customer… NOT!

Time in fact to rehearse. Rotate around the group. One interviewer. One interviewee. Everybody else observers.

Practice introductions, getting consent signed off (consent, in this as in everything, is important), making the video recording work, etc.

Lead off with the high level questions. Listen for the topics coming up — maybe assign different observers to different topics. Experiment. Let the interviewer follow up with open questions, reflecting what the interviewer said, etc.

(“Can you tell me more about X?” — where X is something they said earlier — is a super question to help dive deeper, or redirect the conversation that’s gone off track.)

You mostly won’t need the low-level questions — but if a topic area doesn’t get mentioned you can probe with more specific questions.

After each mock interview reflect. What did we see/hear? What better questions could we have asked? Knock off the rough edges.

Repeat.

For zoom get all the observers to switch off their cameras, then you can set the display to hide non-viewers which can help the interviewer/interviewee focus.

Perform:

When you stop finding ways to improve your observation practice / questions — time to find some actual live participants. But do proper consent forms and do a verbal ask on recording as well to double check. Go talk to your ResearchOps or User Research folk for this if you have them.

Block out a day into blocks of interviewing time + decompression/discussion time. 30/15m or 60/30m feel about right. Remember time for lunch. Setup calendly to book out the slots. Fill ’em. If you get a no-show use it as another practice round.

(and if I wasn’t feeling lazy I’d fill out some bits on decent note taking advice and analysis/synthesis type stuff here — so go read some Books to Get Your Customer Interviewing Practice Up and Running instead.)

The other sneaky thing you’ll notice when you do this as a group activity is that… it’s often better than the results you get when you do it solo.

You have multiple brains in the room poking at refining the research question. More people finding good questions to evoke stories from customers. More ears to hear and interpret what the customer has to say.

TL;DR: Building the muscles for doing customer interviewing can be a fun group exercise.

ttfn.

A Minimal Viable Change Readiness Assessment

adrianh@quietstars.com (Adrian Howard) — Mon, 15 Dec 2025 00:00:00 +0000

Getting an organisation to change how they work is hard — and a bunch of folk I know have been forced to become some variety of “change agent” when they would much rather be doing the actual work.

The user researcher who wants to kickstart Research Operations — so he can spend more time doing actual user research work. The developer who wants to convince the company to experiment with WIP limits, so she can spend more time coding and less time context-switching between a dozen different things.

Sometimes it can be hard to figure out whether that change work is going to be worth the effort.

I have a very informal three item assessment that’s been useful to me in the past when facing that challenge — trying to understand an organisation’s expectations & needs, and whether spending the energy to do change work is likely to succeed.

Because I’m not very complicated, it’s not very complicated:

Are they seeing it as long-term change or a quick-fix? Because everybody is already working one way and it’s hard to turn that boat. It will need continual repetition & checking. Existing working habits are hard to break, even when folk want to break them. There will be missteps. People will accidentally fall back into old ways. There will be resistance. Time, money, and people will needed for it. Are they expecting that work?
Do they see it as a change, or as an addition? Are they willing to talk about the things they’re gonna stop doing as much as the things they’re gonna start doing? (Hard to become more outcome focused if every exec update is focused on a date-based feature roadmap. Hard to become more incremental in our delivery work if we’re 100% invested in an internal design agency model that only delivers page perfect mock-ups. etc.)
Are they looking to solve a problem, or do they want a solution? Do they want to deliver useful software more often, or do they want to “be Agile”? Do they see issues with strategy deployment because teams are off doing random stuff and they don’t know how to steer, or do they want to “do OKRs”? And so on. Problem-first folk end up much better people to work, and if you cannot get the solution-first folk to talk about their problems then things are likely to go poorly. (Chris Matt’s piece on Communities of Need & Community of Solutions helped clarify this for me several years back.)

I don’t have a formal assessment for the above — I gut-grade people based on the conversations about the work, and poke at areas explicitly if I don’t get a read on them.

When I feel I have enough context I evaluate like this:

Enthusiastic “yes”: Folk looking for Long-Term Change to address a Problem tend to be fun and productive people to work with.
Hard “no”: Folk who want a Quick-Fix Additive Solution are almost guaranteed to be terrible people to work with on change (maybe just give a talk / workshop type activity, which can maybe turn some hearts and minds for later work.)
Worth exploring:
- If folk have problem focus, and the problem is large — then investing some time on moving expectations on quick-fix vs long-term, and change vs addition, can be worth it. They’ve identified an actual pain point, and if you can find ways to show incremental progress they’re more likely to be willing to spend more time & attention on it.
- If folk have a solution focus, but they’re expecting it to be a long-term change — then investing some time on pulling out their underlying problem can be worth it. They’re set up for the long haul, and figuring out the real problem can be part of that work.
Leaning “no”: Every other combination tends to involve a lot of work. Some good will usually come of that work — but it will often be a frustrating PITA. Consider saving your energy for something more likely to be long-term successful.

I think the biggest value for me was getting a handle on that final “frustrating PITA” category — because I found having the expectation of “This is not going to be the perfect gig, but some good will come out of it” helps make it a better experience when I did say “yes”.

When I was talking about this framing on the socials the always insightful Melissa Appel commented:

you need whole company buy-in, which means you need the CEO and executive team fully on board with making changes in their teams too.

Which is absolutely spot on. One of the things I find useful about this model is that you can apply it quick ’n’ dirty at the individual level.

If you got to browse my notebooks you’d see a bunch of little diagrams like the above attached to different people at different levels inside an organisation. Comparing those diagrams can be wonderfully informative.

For example a pattern that’s popped up multiple times is folk closer to the team level tending towards the “problem” & “long-term” end of the scales. As you move up the org — and things get simplified and narrowed down — it gets a bit more “solution” and “short-term” oriented.

Having those differences visible can make poking at them so much easier.

TL;DR: Look for people expecting a Long-Term Change to address a Problem, and avoid people demanding a Quick-Fix Additive Solution.

ttfn.

Don't Track Tasks. Track Interruptions.

adrianh@quietstars.com (Adrian Howard) — Tue, 02 Dec 2025 00:00:00 +0000

I’ve had a couple of conversations recently about the joys of time sheets — and why tracking an individuals work is usually a terrible idea (as well being a PITA.)

This is not a post about that pain, but the conversations reminded me of a trick I’ve found useful when forced to track time.

The trick is simple: Block out the time for the primary task — then log and subtract the time spent on the things interrupting that task.

The nice things this approach gives me:

I end up with a list of interruptions — along with what they interrupted. Looking back at that each week, sometimes with co-workers, was a super useful starting point for conversations about focus, the cost of context switching, etc. It became the fuel for many a productive conversation in retrospectives.
It made me, and the interrupter, much more conscious of things that took me away from my main task. Which sometimes helped both of us realise that it wasn’t the smartest thing to be doing at this particular moment.
I had to spend less time faffing with time tracking — since most of my time was spent on the primary task.

(I’ve yet to see a tool support this kind of time tracking model explicitly — if you find one do let me know.)

I’ve found tracking interruptions useful even when nobody is being forcing to track time.

Even (maybe especially!) at the senior leadership level.

For example — I worked with a VP of Product who was having a problems with her strategy work. Once we started tracking interruptions we could see how she was getting dragged into a whole bunch of lower-level tactical discussions by the rest of the product org (who had maybe got a little bit too used to her solving their problems ;-)

Once everybody could see the underlying problem it was much easier to see solutions like delegating more, training up some folk, encouraging more peer work amongst the product folk, etc.

When somebody cannot find focused time — or when something isn’t progressing as we expect — surfacing and tracking interruptions often reveals interesting things.

It’s useful at the team level too.

For example — back in the good old days where we had a physical kanban board — we managed to train a co-founder to stop interrupting the team with random tasks by walking them to the board and discussing whether it was more important than the current story being worked on.

Visualising the impact of interruptions as explicitly as possible helps everybody to have a sensible conversation about impact, priorities & value.

TL;DR: If you’re forced to track your time, try tracking interruptions instead.

ttfn.

Give Your Metrics an Expiry Date

adrianh@quietstars.com (Adrian Howard) — Mon, 13 Oct 2025 15:05:01 +0100

(I wrote this back in May and failed to hit publish for some reason — which I discovered when I wanted to point somebody else to it. So publishing now!)

Today the expiry date for a dashboard metric came up. It’s a proxy trailing metric for Something We Care About. The details are unimportant.

Tracking it for the last eighteen months has helped us spot some opportunities to improve.

In the last six months exploring some of those opportunities has helped us improve month-on-month for the last six months.

Which is delightful!

But having an expiry date means we get to take a step back and reassess whether it’s still useful. While it’s still a half way decent proxy:

we now have more of an idea what specific actions move Something We Care About — and can track those directly
while the metric lets us know we are improving, it doesn’t give a lot of signal on the rate of improvement
we’ve not used the metric to make any decisions with over the last three months

The metric has turned from something valuable — something that helped us make decisions and drive action — to a little number that’s always saying “it’s good”.

It’s now failing the three questions I use to assess dashboard metrics:

Is it visible at the right time?
Is it actionable?
Is it used?

So… time for that particular metric to be thanked for its service and retired!

Would we have retired it if we didn’t have the nudge from an expiry date? Probably not.

Looking at dashboards and metrics become a habit — that’s part of their value — and breaking habits is hard. Which can lead to a huge mess of unactionable and irrelevant pretty graphs — and a false sense of confidence that everything important is tracked and under control.

Which is why setting up little nudges to check whether a metric is still effective is so useful.

TL;DR: Set expiry dates for your metrics ;-)

ttfn.

The Surface Area of Grief

adrianh@quietstars.com (Adrian Howard) — Mon, 31 Mar 2025 11:01:24 +0000

Being somewhat behind on my RSS feeds I just hit an article from a friend who died earlier this year.

It’s so… odd… to be opening a bunch of interesting tabs from their writing — and not being able to thank them, or chat to them about it, or at least drop them a snarky email.

It’s something I’ve noticed before about friends who have died with a large online presence. They pop up in an odd search of my emails, or some bit of their online writing gets reposted and briefly becomes a talking point again, or the phone decides make a new “memory” with their photos in, or some social media channel decides you need to see their face again for whatever weird emergent algorithmic behaviour is being optimised for this week, and so on.

People’s digital lives increase the surface area of grief.

The people in my life who’ve died with a large digital/networked footprint appear in my life so much more often without me prompting it.

You don’t have to open that box of letters, or browse a photo album, or sit down with friends and have that “remember when…” moment. The balance between choosing to remember and being made to remember changes.

That’s not necessarily a bad thing, but sometimes it can feel intrusive. To me at least.

There’s probably a vaguely work related point to be made here. About how these kind of experiences emerge, rather than being designed for. How these kinds of stress cases are rarely (if ever) considered when people are designing digital services. But I don’t have the enthusiasm or energy for that right now.

I just miss my friend.

ttfn.

Bad People Do The Thing You Love

adrianh@quietstars.com (Adrian Howard) — Tue, 18 Mar 2025 09:46:05 +0000

I find it odd when folk act as if their discipline is immune to bad actors, so it must be the fault of The Other.

“A developer would never do X without product managers forcing them.”
“A designer would never do Y, so a developer must have made that decision.”
… and so on …

I can understand the reflexive “I wouldn’t have done that” — I’ve felt it myself — but I find the move to “nobody in my field would do that” strange and unhelpful.

First — when somebody tells you to do something dumb or unethical “no” is a whole sentence.

There’s a quote from Victor Papanek’s “Design for the Real World” I love. It’s not the oft repeated first line of the book (“There are professions more harmful than industrial design, but only a very few of them”) — but later on when he’s talking about “The Myth of the Designer’s Lack of Control”:

I see that lack of control myth in lots of professions ATM.

Yes there will be consequences for that “no” — maybe bad ones — but it’s there as an option.

If I help make something happen then I’m part of the problem. I don’t get to avoid responsibility by saying “somebody told me to”. Folk have been arguing that point for hundreds of years.

Second — what’s at work is almost always a complicated mess of feedback loops, incentives, and motivations — and that system includes me and mine.

I don’t solve anything if all I do is point a finger at one group in that system.

When you dig into the motivations and explanations for particular behaviours you almost always discover a much more complicated story than a moustache-twirling villain.

Yes, those systems are complicated, hard to change, and ever harder to ignore (insert your favourite “it’s capitalism” meme here) — but pretending they don’t exist is not going to work either.

Finally — and most importantly — people do bad things!

Being a developer / designer / researcher / product manager / whatever doesn’t make people magically immune to that.

Developers just want to make good tools. Sometimes those tools harm people. Amazingly smart and talented developers are happily creating ransomware, and social media bot nets, stealing content to train AI models, coding their way around legal & regulatory issues, etc.

UX folk want to understand people, and use that understanding when designing systems. Sometimes they use that understanding to harm people. Amazingly smart and talented UX folk are happily finding ways to trick people into subscribing to things they don’t want to, or gambling more money than they can spare, or finding ways to target vulnerable populations, etc.

(Repeat for product managers, for content strategist, for… whomever.)

This doesn’t happen because of the discipline they’re in.

This doesn’t happen because they’re forced to by The Other.

This happens because they’re unaware of the bad impact, or don’t care about it, or are in favour of it, or value the challenge of the work more, or the paycheck, or some combination thereof.

Because understanding how to use a particular set of skills doesn’t magically make you a good person.

Or a bad one.

Which is why I’m super suspicious when any single group or another tries to own the ethical high ground.

TL;DR: If you think My Discipline is Good, and Other Discipline is Bad then you are fooling yourself — and avoiding the work that needs to be done to make things better.

ttfn.

Scrum Doesn't Say…

adrianh@quietstars.com (Adrian Howard) — Mon, 03 Feb 2025 00:00:00 +0000

I’m not a fan of Scrum (especially the certification industry that’s built up around it — see the CSSTWP for more on that).

Yet I seem to spend some of my time defending it.

Because most of the criticisms I hear are not about things that Scrum mandates. For example:

Scrum doesn’t say stories have to read “As a role I want to goal because reason”.
Scrum doesn’t say you can only release once every Sprint.
Scrum doesn’t say you can only release at the end of a Sprint.
Scrum isn’t an acronym and isn’t spelt SCRUM (okay… I rarely hear complaints about that, but it does annoy the heck out of me!)
Scrum doesn’t say the sprint and product backlogs need to contain the same kind of things.
Scrum doesn’t say you have to have burn down or burn up charts.
Scrum doesn’t say you have to wait until the sprint review to show people things.
Scrum doesn’t say you have to wait until the sprint retrospective to talk about problems.
Scrum doesn’t say you are only allowed to demo or talk to stakeholders once a sprint.
Scrum doesn’t say how you should estimate backlog items.
Scrum doesn’t say you have to have points.
Scrum doesn’t say you should use velocity as a target.
Scrum doesn’t say you must track velocity at all.
Scrum doesn’t say you have to have epics, stories, or tasks.
Scrum doesn’t say that you can’t have any meetings that are not sprint planning, standups, sprint reviews or sprint retrospectives.
Scrum doesn’t say the Product Owner can prevent the team from working on technical debt.
Scrum doesn’t say the Product Owner gets to tell the team how to turn the backlog into releasable code.
Scrum doesn’t say that the Scrum Master gets to tell the team how to turn the backlog into releasable code.
Scrum doesn’t say operations people cannot be on the team.
Scrum doesn’t say testers cannot be on the team.
Scrum doesn’t say designers or user researchers cannot be on the team.
Scrum doesn’t say business analysts, managers, project managers, etc. are not necessary.
Scrum doesn’t say the Product Owner has to make all the decisions by themselves.
Scrum doesn’t say that the Product Owner needs to prioritise the whole product backlog.
Scrum does not say you must work an 80+ hour week to meet the forecast you made at the start of the sprint.
… and probably many many more — do offer suggestions!

As Tim Ottinger concisely said in response to the rant that kicked off this post:

Sadly, there are a lot of people who have no idea what scrum is, and have no awareness of agile beyond what they think is scrum.

I’ve found “Can you talk a bit about how Scrum and Agile relate?” to be a really powerful question to ask. At one end of the spectrum you get confused looks because folk think Scrum and Agile are synonyms. At the other extreme you’ll get a thoughtful discussion about Scrum, other Agile methods, how they relate, and what the trade-offs are.

Many, if not most, of the complaints about Scrum I hear are caused by people mindlessly copying practices from whatever dysfunctional organisation they first learned about agile in.

So, when you hear somebody complain about what Scrum forces them to do encourage them to read the Scrum Guide. They’ll be able to do it in over a lunch break and still have time for a leisurely dessert — it’s less than twenty pages long.

Scrum, at its core, is a really minimal process improvement framework.

Understanding how that framework is put together will help you deal with the ghastly stretch-goal, velocity tracking, eighty-hour-work-week monstrosity that’s often labelled Scrum.

Sometimes that knowledge will be the thing that lets you know that Scrum isn’t what you need.

Because Scrum doesn’t say that it’s the only way to do agile, or the only way to work.

ttfn.

(an earlier version of this post was made on Medium)

One Approach to Beating Conference Stage Fright

adrianh@quietstars.com (Adrian Howard) — Sun, 26 Jan 2025 11:00:55 +0000

(I was having a chat this week about stage fright, and found myself wanting to point to an article I wrote as part of the now defunct Speak Up! group — so moving this out of an old medium post to somewhere more useful…)

TL;DR: Attack the stage-fright separately from the presenting.

First find the level of interaction that you’re comfortable with. Then look for ways you can push the edges of what you can cope with. You can make a lot of progress without actually having to prepare and present a talk. Save that last step until you feel more comfortable with getting up in front of people.

Let me illustrate with the story of “Nick” (not his real name). Nick started out as the poster boy for the stay-at-home asocial geek. This is how Nick moved from being too scared to attend events to presenting.

Initially Nick “virtually” attended local events. Chatted to folk on IRC, looked at their blogs, talked on the mailing list, looked at the slides online, etc.
Then he started attending local events. He already felt like he knew a bunch of folk so this wasn’t too bit of a step for him.
Then Nick started actually talking to people at the local events!
Then he started going up to the speaker at the end of a presentation after the general Q&A to ask a question in person.
Then he started asking questions in the general Q&A (massive step for Nick— since everybody in the room was listening to him ask a question! He was scared witless.)
Next I suggested he run a session at a local Bar Camp. Not a talk — he hosted a discussion. The topic was, if I recall correctly, “How do you get over stage fright?”. This was a big step — because people were coming to a room because of “his” session. However it was much easier than a talk. He didn’t need to prepare slides, or stand up and entertain people that would be staring at him in silence for 30m. It also attracted a group who were naturally sympathetic to the problem.
Next he gave a lightning talk at a local meeting. A demo rather than a talk. Only five minutes of being stared at. No time for Q&A. Scary. Obvious flop sweat. Went fine.
Another lighting talk. This time with slides. And a joke. It went fine.
Finally a 20m talk at a Bar Camp. Which, to be honest, didn’t go that well — but it was because of content and pacing issues rather than abject terror.

If you look at the above list it was only at step 7 where he needed to really prepare a presentation. By taking small steps he managed to learn that the “getting in front of people” part didn’t always — or indeed ever — end badly.

Discussions, fishbowls and panels are great gateways to full talks for people with stage fright problems. They let people get used to the stage fright part without having all the worry of managing the production of a presentation. The attention is split up among several people rather than just being on the speaker.

Last time I talked to Nick he was looking forward to trying the tweaked talk again. He’s still on the scared side of nervous — but it’s at levels he can cope with. I’ve had a couple of folk take this sort of incremental route with good results.

One other bit of random advice that may or may not work for you.

Personally I find workshops and tutorials easier to manage than talks when it comes to stage fright. The former feel like “I’m working with these people” — rather than the “I have to entertain these people and it’s all going to go horribly wrong” feeling I still get from talks.

I know people have the opposite tendencies and vastly prefer talks to workshops so it’s not universal but might be worth considering.

Do you have any tips on overcoming stage fright yourself?

ttfn.

Two Useful Prompts to Explore Intent & Behaviour

adrianh@quietstars.com (Adrian Howard) — Mon, 09 Sep 2024 00:00:00 +0000

People often make assumptions about behaviour, and those assumptions often turn out to be wrong. Something I’m guilty of as much as anybody else.

I use two prompts a lot to get over this. Anybody who has worked with me will have heard them way too many times. Because they’re so darned useful. First:

“What other possible explanations could there be?”

Asking this helps break out of having a single explanation for a behaviour. Keep prompting until there are at least three different explanations.

(I’ve found a minimum of three to be a good number to get people, including myself, to think a bit and break away from the obvious.)

Follow this up with:

“How could we find out whether those explanations are true or false?”

To prevent jumping on another explanation immediately without evidence.

Note: We are not saying which of them is true — because they all might be wrong!

For example: a client of mine — let’s call them Mary — was having problems getting time with her CEO to talk strategy issues.

Mary knew why this was. The technical-founder CEO had a direction in mind for the company’s primary product, had a list of features that he was pushing through to get built by certain dates, and didn’t want to listen to anybody who was bringing news about that approach not working.

(Spoiler alert: the approach wasn’t working!)

Which was naturally very frustrating for Mary. Somebody who had been hired for her strategic expertise by the COO.

“What other possible explanations could there be for the CEO avoiding a strategy conversation?”

With very little prompting we came up with a ton of options including:

CEO thinks the strategy is working (Mary’s working assumption)
CEO has more important things on his calendar we don’t know about
CEO doesn’t understand the impact of not doing the strategy work
CEO had information we didn’t have on the success of this strategy
CEO already having strategy conversations with somebody else
CEO doesn’t see strategy as something he should talk about with Mary
CEO knows about clients relying on these features Mary didn’t know about
CEO doesn’t respect Mary or her skills

Which led us to the next question:

“How could we find out whether those explanations are true or false?”

Which led to… conversations. Lots of them. Mary started reaching out to various folk in the company to try and eliminate some of these options. Which eventually led to a conversation with the CEO & COO about why the CEO wasn’t finding time for this work.

Which led Mary to rapidly discover that the fundamental issue was the CEO didn’t really have a framework for having a strategy discussion, and was desperately trying to come up to speed with that kind of work in the background via reading and conversations with peers in other organisations (who were mostly folk with a very similar background, so didn’t have a lot new to bring.)

He knew the current approach wasn’t working. He was getting a stack of pressure from the board about the current lack of progress in various markets.

But he hadn’t really connected those problems with the things Mary could help with. He was used to being the person who had to solve these problems — because that had always been the way things worked before. He thought he had to have the scope of these problems defined before he talked about it with Mary. Rather than seeing Mary as somebody with the expertise to solve the problem with him.

Getting past that did take a bunch of work – but once Mary identified the actual problem that work became vastly easier. Which took getting past her initial assumption about intent.

Lesson learned.

As with most things — I learned this approach after fouling up badly myself.

More than a few years back a team I was working with had hit quality issues that we believed were being exacerbated by the foolish number of hours worked. Typical startup nonsense.

We made a team agreement to work an 8 hour day. Which we followed through on — and things got a lot better.

Apart from this one guy.

He carried on working long hours. Arrived before everybody else, working late into the night. Which annoyed the heck out of me — since the team was fighting a company culture of long hours, and was getting organisational push back on leaving “early” despite showing increased productivity and better quality.

And he was making mistakes. Lots of them. Mistakes the rest of the team was having to spend time cleaning up. Which was, understandably, causing friction.

So one night I stayed late so I could talk privately with him about how his actions were hurting the team.

My perception of this guy was that he was more than competent, but of the macho brogrammer school of developer idiocy. His reactions to feedback in team contexts were basically “I’ll work how I want to work.” — and I was expecting more of the same.

What I got instead was him breaking down in tears.

Because while I’d been assuming this guy was a bit of an idiot for the last few weeks, what was actually happening was that he was spending as many hours at work as possible because home wasn’t a safe place for him for various reasons.

One of the lessons I learned was what a terrible job I’d been doing addressing problems as soon as they started (Why hadn’t I had a 1-1 chat with him much earlier? Because I’d been avoiding imaginary conflict.)

The biggest lesson was, of course, “don’t make assumptions” — which led to me resolving to find three different explanations for somebody’s behaviour before I think about taking any sort of action.

Again — once we had the actual problem identified we could start working to make things better. I only wish I could have doing that without being a bit of an asshole first.

I prefer these prompts to the sometimes overused advice of “Assume Positive Intent”. Which is a good general rule of thumb, but has some bad failure modes.

Because always assuming a positive intent is absolutely terrible at dealing with Schrodinger’s Asshole and similar bad actors.

Schrodinger’s Asshole: the guy who says awful shit, and decides if he was “only kidding” depending on your reaction.

— Spike Trotman

For me assuming good intent means I’m less likely to probe around alternate explanations. Which means it’s very, very easy for “assume positive intent” to become “find a plausible excuse for the asshole”.

Asshole are well aware of this failure mode and exploit it to the max.

Asking “What other options could there be?” however lets me keep the option of this person being an asshole on the board. Which makes spotting patterns of bad behaviour much, much easier.

TL;DR: Asking “What other possible explanations could there be?” followed up by “How could we find out whether those explanations are true or false?” is a better approach than “assume positive intent”.

ttfn.

Facilitating Your First Wardley Mapping Session

adrianh@quietstars.com (Adrian Howard) — Mon, 12 Aug 2024 11:00:05 +0100

(This is not an introduction to Wardley Mapping in general. If you’re looking to understand what a Wardley Map is, why you would want to use one, etc. I’d recommend checking out some of the resources on wardleymaps.com.)

Recently on the Rands Leadership Slack somebody was looking for step-by-step instructions on how to start using Wardley Maps with a small leadership group.

I think part of the reason it’s hard to find that sort of playbook is that folk use Wardley Maps in many different contexts, and for many different purposes. They’re also generally persistent objects that get continually revisited and revised over time.

So it’s kinda-sorta like asking for a “backlogs playbook”; The going from nothing-at-all to first-board is not something that happens often, and the use cases around those artefacts are so varied that a simple guide is often not of much use.

When I’ve used it, it’s been mostly to help nail down one or more of:

Alignment on the problem being addressed, and the things being currently being used to address it right now — so getting “where are we now” up and on the board, Which means alignment both across “what is in the value chain” and “where are those components commoditization wise”.
Looking at places where that current state is misaligned with reality (we’re building a thing that we can buy off the shelf — why?, etc.)
Getting alignment on how we expect things to change (Bob thinks we need to build WidgetFactory to support some bit of value, Mary thinks WidgetFactory is probably gonna be something we can buy off the shelf in 18 months, etc.)
Using an aligned “now” state to ask ourselves a bunch of “what if” questions about how things are gonna be going in the future — and how that is aligned (or not) with our vision & strategy.

But there are lots of other valuable things you can do with Wardley Maps.

That said — at some point folk will be taking a leadership group and attempting to build a first Wardley Map. Some general things I’ve found useful in that context:

Nail the user need at the top of the value chain first.
If folk are not used to the value chain concept expect a stack of disagreement / alignment issues around that first. If you’ve got multiple markets / products / user groups it’s sometimes easier to focus on the dominant one first.
Work on the value chain(s) first and ignore the commoditization dimension until you get them sorted. Don’t try and have both arguments at once!
When you get to the commoditization discussion try and get components positioned relatively to each other before you start anchoring stuff to specific labels along that dimension.

What follows is not a perfect workshop outline for every context. It’s been thrown together from the agenda of a few different Wardley Mapping sessions I’ve run. Each of those was adapted to deal with local conditions — so what follows is bringing some of the common elements together in one place. Hopefully it should provide a useful starting point that you can tweak for your current situation.

Assumptions

We have a facilitator who is not involved in actually building the map to run the session.
Around half a dozen attendees tops + the facilitator.
About a 120 minute time slot.
We’ve not got “I don’t wanna be here” people in the room (convincing folk this is a sensible activity to try is out of scope and best handled separately.)
We come in with a user group to anchor the value chain on.
I’m assuming an in-person session (which is a big assumption I freely acknowledge). I would imagine something along these lines would work fairly well online — but I’ve not done it, and you’d need to add a stack of structure to a Miro/Mural/whatever board to help folk through it.
Lots of wall space, post it notes, and masking tape.

Before the Session

Send folk a little outline of Wardley Mapping, what the session is trying to achieve, the schedule, and some links to introduce folk to Wardley Mapping (e.g. this 20 min video by Simon Wardley)

Set the Scene (10 min)

As a reminder + to help the ones who have inevitably not done any pre-work — show the 90 second introduction to Wardley Mapping from https://learnwardleymapping.com.
Remind folk of the schedule for the session — and that we’re gonna explore the value chain dimension first, then the commoditisation dimension second.
Big arse post-it note with the anchor for the value chain on it. Get agreement from all that this is what we’re writing the map too.
If you cannot get agreement then two routes:
- Go for “disagree and commit” for the purposes of the session
- Time box 20m to get alignment, and split off everything after the Coffee/bio break at the end to a separate session. There is a temptation to run long rather than splitting stuff up… I’d recommend against it (folk will be tired!)

Build the Value Chain (50 min)

10m: Individual generation of value chain components
- Ask folk to individually generate value chain components for our context — one component per post-it.
- Get a couple of examples of value chains up somewhere visible to give some inspiration — look for the ones that push hard to end up with stuff like “electricity” (because a common failure mode is attendees not breaking down the chain enough — and pushing folk to go too far will drag more information out of the group as a whole.)
- Verbalise a few examples of breaking-stuff-down when folk start slowing down a little.
- If folk are still scribbling at 10m let it run long — more stuff now is good.
- One of the frequent questions I see is “does X count” and the answer right now is “yes”. Folk can always cull stuff later.
- That said — you want to keep the context to “now” rather than “the thing we’re gonna build” or “how we want it to be”.
30m: Merge individual stuff into a single board
- Get a big chunk of wall with the user-need post it at the top.
- Get all folk’s individual post-its on the wall in rough value chain order top-to-bottom, either as a mob of people or one-by-one depending on formality levels.
- Get the group to merge everything into a single value chain.
- Have an ice box area for folk to move things they consider irrelevant or duplicated, rather than throwing things away. (Having the option of changing your mind can make the process easier for people.)
- Make sure folk aren’t actually hiding different levels of abstraction by removing duplication (e.g. keeping “web site” and throwing away “store”, “marketing site”, “support site”, etc.) You want to keep different levels of abstraction not discard them.
- Look out for people who have stuff that is radically different from everybody else. This can be a good thing (perspectives that everybody is missing) or a bad thing (radical misalignment) and you’re gonna need to steer appropriately.
- If folk bring up “what about X” stuff that’s missing from the board encourage folk to add ’em in.
10m: Review Review the board as a group:
- Is there anything that we’re missing?
- Are we aligned on the relative positions in the value chain?
- If folk are radically disagreeing at this point then Something Is Up and I would be wanting to stop now + schedule in something separate to explore that.

Coffee/bio break (10 min)

This a good stopping point if you wanna split this across days and/or have had to run long and need to reschedule the rest of the session.
If you do stop here do a quick round of “things we learned” with attendees before you stop.
Record the current state of the board in case we need to revisit/reset later.

Review / Context setting (10 min)

Ask folk about anything they discovered / were surprised about in the value chain exploration
Review the commoditised dimension with a couple of example maps from other folk.

Align Components Relatively (30 min)

The outcome we want from this section is the components aligned relatively to each other along the commoditised dimension — rather than being in particular buckets.
Can either let folk mob the board, or get folk to go into pairs.
Encourage folk to compare pairs of components — more/less is what we’re after.
If folk have trouble with a pair encourage them to look for something on the board that they are sure that it’s less/more on and then align relative to that
This can sometimes go really fast and you won’t need the full 30m. Or end up in argument hell.
If folk align quickly you can introducing the commoditisation buckets of genesis / custom built / etc. and start talking about climate.
If you end up in argument hell then there is a lack of alignment. I tend to attack that in two different ways
- Encourage folk to articulate “How would we know?” questions, then answer them. This can sometimes resolve things quickly, or highlight that folk have been talking about different things, or that the answers are really “we don’t know”.
- Encourage folk to mark out the breadth of where they think a component could sit — masking tape can be good since it allows folk to move stuff around more.

Final Review (10 min)

By this point we should have a vaguely decent first stab at a map
Ask folk about anything they discovered / were surprised about in the commoditisation exploration
Try and get a prioritised list of ‘what next’ now we have this visualisation. As the facilitator keep track of interesting questions during the session. Do a quick dot vote to get an idea of priorities. Stuff that often comes up:
- How do we align in the places we’re not aligned
- How do would our competitors be placed on this chart
- Do we want to change where are components are placed?
- How does this fit in with our current strategy?
- etc.
If you can get a session booked in to address the biggest issue booked in at the end of the session while folk are engaged.
Record the map with some photos. Then after the session tidy it up into a proper doc.
Copy everybody in with photo & the diagram to double check that you captured everything correctly.
Pay attention to the ice box area — are there things that are potentially useful there that you should be highlighting for future sessions?

Hopefully the above will be a vaguely useful starting point for those planning their own sessions! I want to emphasise again this isn’t a one-size-fits-all session - and you’ll need to tweak it for your organisational context. Think about where disagreements are likely to sit – and places where the alignment conversations may go long — and plan accordingly.

TL;DR: Get alignment on the anchor for the value chain. Independently generate value chain components to get as many perspectives as possible. Merge components and align on a final value chain. Then align components relatively along the commoditisation dimension.

ttfn.

(updates as of Wednesday 21 August 2024)

I’ve been having some lovely conversations with people about this post since it was first published. Some highlights below.

Mark Dalgarno commented:

“Sometimes workshop participants won’t agree on what evolutionary state a system is in because it would be politically difficult to acknowledge it is far more in Genesis than they have told others…”

Which is spot on (I’ve seen the opposite problem too — folk assuming something is somewhere between magic-and-impossible when it’s actually off-the-shelf.) This is why it’s so important to get lots of different perspectives in the room for this sort of exercise.

Christoph Steinlehner suggested using Service Blueprints to help explore the value chain:

“If it is hard to come up with the components a Service Blueprint Session can help to extract components. … I found it especially useful if the components are unclear. Going through the journey and asking which systems are involved is usually easier than starting from a blank spot.”

I’ve never tried doing this — but sounds like it would work well. I imagine that it would be especially successful if the organisation was already using Service Blueprints as artefacts.

Thomas Lissajoux had some suggestions if you’re working with larger groups:

Only differences were working with larger groups of 15-20 in subgroups … I never saw a preparation work happen beforehand … Which takes a little bit too much time on the upper part …

Once there were 2 clear sub chains and we could clearly split & merge. Other times it was messier: one group presented its results & other groups taking turns with diffs.

2 facilitators for 4 subgroups.

I like the idea of identifying sub-chains first and then focusing on splitting work around that. Large groups are always painful — and Thomas was smart to get more facilitators in to help.

Tom Kerwin commented:

FWIW, I’ve found I had the most success when I didn’t mention Wardley Mapping or any of the theory up front, or sometimes even at all, beyond a simple view of the stages of evolution. I noticed that people get all tied up worrying about the theory and doing it “right” and that’s the kiss of death.

Instead I got teams started by having them simply list the “stuff” that’s needed to provide service to a user. Then stack that up, spot links, gaps and puzzles.

Just like you, this is gently getting them to make their first value chain. And I completely agree – figure that value chain out before even contemplating evolution.

I also agree that the anchor is messy and hard, but sometimes I’ve found it’s easier to come at it “backwards” from the value chain, as we’re all often more aware of the details of what we’re doing/building than we are of what people are really buying off us!

Which all makes excellent sense to me — and matches some of my experiences. I’ve also experienced encountered groups surfacing multiple anchors when they dig into the value chain exploration. Which leads to some fun conversations about who exactly we’re supposed to be serving.

Why I Dislike Maturity Models

adrianh@quietstars.com (Adrian Howard) — Mon, 29 Jul 2024 09:24:12 +0100

I’ve recently been hitting some client problems caused by their organisation’s approach to maturity models. So… time for a brief rant…

Maturity models are often framed like this:

A linear path from immature to mature
The start of the path is presented as “bad” (who wants to be “immature”?)
That linear path has an end

Which naturally encourages folk to view the “mature” end of the spectrum as aspirational. When I’ve seen organisations reach for maturity models it’s almost always been with the goal of moving to the “mature” end of the chart, because that end of the diagram is seen as “good”.

Which can be a problem — because all three of those points are at best oversimplifications, and at worst outright lies.

Maturity Isn’t Linear

Organisations are successful in lots of different ways. Organisations fail in lots of different ways. It’s rarely a linear path from one to the other.

For example — this is a pattern I’ve seen a few times.

A developer founded company has pretty darn effective development practice from day one — but sucks on the design side.
Then the development practice get less effective as the development work & customer base scales in ways the old practices cannot cope with.
At the same time the design practices improve radically as a couple of relatively low-status individuals grows into a small team with more senior design leadership.
Then the development practices improve as folk discover how to manage the work more effectively.
Then the design work grows too large for a single team to manage effectively — and the design side starts hitting trouble again…

What happened?

Company size when small > medium > large
Development effectiveness went good > bad > good
Design effectiveness went bad > good > bad

There are dozens of variations on this kind of story. That nice simple journey from immature to mature almost never matches people’s real experiences.

Maturity of Practice & Size of Company Are Not the Same Thing

One of the things I dislike most about maturity models is the way many combine the small-to-large company dimension with the bad-to-good practice dimension .

SmallCo’s practices are not automatically immature because it only has a couple of dozen people in it.

LargeCo’s practices are not automatically mature because it has 50k employees.

A fifty person company is not an immature multinational in the same way a bicycle is not an immature airliner. If successful SmallCo adopted all the practices of successful LargeCo it would fail miserably. If successful LargeGo adopted all the practices of successful SmallCo it would fail miserably.

The things a organisation does to be impactful in a 50 person company and a 50k person company are just different — and that’s a good thing.

It’s not a maturity issue — it’s a context issue.

Small Is Not Bad & Large Is Not Good

Another terrible side effect of those dimensions being mashed together is a tendency to read in a value judgement.

You can only move from bad-practices/small-company to good-practices/large-company. Which means maturity models presented this way cannot answer questions like:

What do good practices at smaller organisations look like?
How do we move from one good place to another good place as an organisation grows?
What do bad practices at larger organisations look like?
How do we move from a bad place to a good place when the organisation is large?

The immature-to-mature metaphor means that folk tend to read the “immature” end of the model as “bad” — and the “mature” end of the model as “good”. Which is nonsense.

Cause and Effect Get Confused

What’s happening when folk try and drive practice adoption with a maturity model:

Does a company change because it adopts a particular practice?
Does a company adopt a particular practice because it has changed?
Was it a messy complicated combination of (1) and (2)?

Because of the immature-to-mature metaphor folk often wield maturity models as if only (1) or only (2) are true — when the real answer is usually closer to (3).

Only Dead Things Stop Maturing

Just because you’re ticking all the boxes of “mature” doesn’t mean:

You cannot continue to improve
You’re doing the things in those boxes well
The context that makes those boxes relevant is likely to continue

Continual improvement is a thing! The work of making things better doesn’t finish. If your organisation is approaching a maturity model as a box ticking exercise you’re missing ways to improve.

So What Do We Do?

Before you start building or researching maturity models — articulate why you want one. Can you answer questions like:

How are we going to be using it?
What problem(s) are we trying to solve?
What forces or context changes are creating those problems?
How is understanding where we sit on a maturity model going to help us?
How do we think changing where we sit on a maturity model is going to help us?
How are we going to measure progress?
What would success look like?

A theme that often pops out of conversations around these questions is “reassurance”. Folk want to know they’re doing “best practice” or “the right thing”. People want to be know that they’re not missing an obvious thing that their competitors are doing.

When this topic comes up (or “if” I guess, but it’s mostly a “when” in my experience) I’d encourage you to dig into why people are seeking it. There are often more fundamental issues — a nagging set of problems driving the need for reassurance.

Next, when you’re assessing maturity models, look for the assumptions built into the model — and figure out whether those assumptions align with how you want to use it:

Are they combining organisation size and good/bad practice into a single dimension?
Do they talk about what forces make adopting a practice successful or unsuccessful?
Do they talk about the problems that adoption a practice solves — and what success or failure looks like?
Look at where you are on a maturity model now — does your experience in getting where you are now match what’s on the model?

Questions like this can get discussion started about the forces and patterns that are driving change in your organisation. Which is often a vastly more useful nuanced discussion than the one that a simple linear maturity model delivers.

If you want some inspiration — take a look at

https://maturitymapping.com — a general framework for practice maturity that tries to make the conversation about context more explicit
https://researchskills.net — a maturity model for user research practices that tries to make explicit the forces and patterns that drive adoption of practices in different context.
http://www.agilefluency.org — especially the bit on losing fluency (thanks to Kristen Belcher for reminding me of this!)

TL;DR: There isn’t a single linear path from immature to mature. Immature does not mean bad. Cause and effect get confused. Maturity is not an end point.

ttfn.

Reflecting on Fourteen Years of Journaling

adrianh@quietstars.com (Adrian Howard) — Sat, 20 Jul 2024 14:41:22 +0100

My annual reminder to reflect on the last year of journaling popped up today — which reminded me of something I wrote in 2022 which I’m gonna repeat here:

In the last year I’ve written 270k+ words. None of which you’ve read :-)

I’ve journaled daily pretty regularly since 2010. Mostly as an end-of-day habit — a few dozen, maybe a few hundred words. A little end-of-day retrospective. Which was super useful.

But a year ago I wrote “Trying journaling in here more regularly during the day … Let’s see how that works.”

Basically — what happens if I turned my journaling up to 11?

For me – pretty darn good things.

I ended up building a habit where I wrote a few sentences when I did a task, or switched contexts, or when some random stuff entered my head. Which meant my little end-of-day reflection had something explicit & concrete to reflect on.

It let me notice when I was wandering off an getting distracted. It let me notice where I was spending more or less time than I thought. It let me notice all the things I was doing — rather than the ones I remembered at the end of the day.

It let me remember the good bits when I’d had a bad day. It let me notice the bad bits when I’d had a good day. It gave me a place for that quick idea and random association so that I didn’t end up forgetting it.

One year, and more than 270k words later, I got my “REFLECT: One year of journaling at 11 - keep it up / turn it down?” reminder.

It’s been useful. So I’m carrying on.

And I have.

It’s nothing complicated. It’s just a markdown file that sits in an open tab of whatever text editor I’m currently living in. Plus a few text snippets that give me a template for the day and some prompts to answer. The details are not that important.

I’m up to 796k words now. That’s about around 1.5x the word count of The Lord Of The Rings trilogy. 265k words a year on average. Hundreds of thousands of words that nobody but me sees.

I’m unsure which direction the causal arrow is pointing… but I find it fascinating that my journal word count drops by a good 20% or so when I have an unproductive week. Do I write less because I’m doing less? Or — am I doing less because I’m not reflecting on what I’m doing?

Is that effort worthwhile? In the decade of semi-regular journaling before I deliberately tried to write more I wrote 46k words in total. Now I write 5x that annually. Most of it is dull and repetitious. Nobody is gonna make a best seller out of my journal without the aid of an extremely vivid imagination.

But I’ve still found it super useful for all the reasons I outlined in 2022. It lets me see things I otherwise miss. I’ve lost count of the little things it’s let me spot — tiny improvements that help me turn up the good and turn down the bad.

Me: “I’m a terrible person for not getting shit done the first week in November.”"

Journal: “Hey! The clocks went back, you were recovering from 2x vaccinations, the weather was foul, and gave you 48hrs of migraines! It’s amazing you achieved anything! FFS! Idiot. Get a grip!”

TL;DR: Having a journal is a great way for Past Adrian and Present Adrian to point at each other and go “FFS. Idiot. Get a grip.”

If you’ve never tried keeping a journal — why not give it a try for a couple of weeks. You might find you like it.

ttfn.

The Self-Service Research Sweet Spot

adrianh@quietstars.com (Adrian Howard) — Mon, 01 Jul 2024 10:24:47 +0100

A recent question on the ResearchOps Community Slack touched upon on how to split work between dedicated user research practitioners vs People Who Do Research (product folk, developers, designers, etc. using self-service approaches.)

FWIW I’ve found it useful to think about this question in terms of risk and cadence:

Risk: What’s the impact of the research work? Are we picking the right colour blue for a link? Are we helping make potential bet-the-company decision? etc.
Cadence: How often are we doing it? Is this a once a year opportunity to talk to a group of of otherwise unavailable valuable customers? Do we have a recruiting pipeline where we’re we’re doing continual research with customers every week? etc.

With self-service research work sitting best in the low-risk and high-cadence area.

Low risk is kinda obvious. The people with less experience will make mistakes — so ideally this needs to be happening in places where the impact of those mistakes is reduced as much as possible. Make things safe to fail.

High cadence can feel like a scary area to put less experienced practitioners in. Doesn’t more-often imply more-mistakes?

But the only way for people to learn and improve is by doing.

There is no way for people to go from no-user-research to good-user-research without going through some bad-user-research. The more often people do research work the higher the chance that mistakes will be seen and corrected (as long as we set up good feedback/learning loops!)

So you get something like the four quadrants at the start of this post.

low-risk/low-cadence — Great place for onboarding / training people with self-service research needs. The downside of any errors is reduced + it won’t suck up lots of researcher time helping with onboarding and training.
low-risk/high-cadence — The self-service sweet spot. Lots of reps so good for learning and improvement + risk of failure lower + removes huge time sink from research folk.
high-risk/high-cadence — Researchers should probably be involved because of the high risk, but the repetition makes this a great learning opportunity for people who might be ready to broaden their research experience.
high-risk/low-cadence — The dedicated researcher sweet spot.

(with the red arrows being the progression of folk’s skills through a People Who Do Research “career” path.)

One of the interesting things that comes up when I work through this model with some people is the spaces enabling good self-service work don’t exist in their organisation. That absence underlies many of the problems they’re having with adopting self-service approaches. For example:

Everything sits over on the “high” risk side — so there is no safe learning environment to onboard People Who Do Research who aren’t already experienced research practitioners.
There is no regular research work – so there are never enough reps for people to build experience and learn from mistakes.

Without those spaces introducing self-service research is going to fail. You cannot solve a “too much high-risk research” problem with self-service models.

Instead you need to look for ways to broaden the kinds of research work that happen. Look to lower the risk of the research work, and/or increase it’s cadence:

Can we break a big research question into smaller ones?
Can we turn a big study into several smaller ones?
Can we turn one-off work into longitudinal work?
Can we find smaller bits of valuable research work that we’re currently ignoring?

Which can feel a little counter intuitive. Since the push towards self-service approaches is often “We don’t have enough researchers for our current workload” — and here we are creating more research work!

But it’s different research work. Research work that more people can do successfully. Research work that makes it easier to spread research skills around. Research work that can start a pipeline of people who can potentially take on more complex work in the future.

TL;DR: Low risk and high cadence activities are the best fit for self-service user research — and sometimes that means you need to change your organisation’s approach to research work.

ttfn.

Three Questions to Help Triage Your Dashboards

adrianh@quietstars.com (Adrian Howard) — Fri, 07 Jun 2024 00:00:00 +0000

I’ve been helping someone recently whose organisation has been overwhelmed by “dashboards” — collections of KPIs, OKRs, and other Important Things that have accreted over time into an unmanageable mess (well… many unmanageable messes in this instance!)

Having hit this problem a few times in the past I’ve a quick and dirty checklist that seems to help when reviewing those big piles of pretty graphs and status signals.

Is it visible at the right time?
Is it actionable?
Is it used?

First of all — is it visible at the right time? The entire point of a dashboard is that it should be in front of somebody at the point they need the information to make a decision.

I want to be looking at a product’s OKRs when we’re planning or reflecting on product work. I don’t want to discover things are off-track in a monthly status update. Often you get the business equivalent of an update on the speed of a car after the speeding ticket has arrived.

Getting information more often that you can act on it is just as wasteful. Are people getting daily updates, but only make decisions monthly (if at all)? This can sometimes be a signal that responsibility for action is getting lost somewhere.

Time to start asking questions:

Who should be using the dashboard to make decisions?
When are they making decisions using it?
Should they be getting fewer/more updates?
Should they make decisions more/less often?

Second is it actionable? Does the dashboard help people make better decisions? Is it actually relevant to the work? Can people affect change?

If it’s something completely out of your control do you need to know about it at all?

If it’s something you’re delegating do you see it as often, or at all?

If it’s something you should be acting on, can you act on it? What’s blocking you? Do you need to pay more attention to that blocker?

Finally — is used? Is there a culture of actually taking action based on the dashboard? If the dashboard is visible, and actionable by the right people — do they actually do anything with it?

Do the OKRs get ignored in retros? Does the slide with velocity numbers and throughput rates always get skipped over in the exec update deck? Supposedly useful dashboards not being acted on is a really interesting signal that something odd is happening. Time to start asking questions again:

Is it actually visible to the right people?
Is something blocking those people acting on it?
Is there something more important driving behaviour?
Is there a better signal that people are paying attention to?
Is it actually relevant at all? Do people ever use it to make decisions?

TL;DR: Is it visible at the right time? Is it actionable? Is it used? If the answer to any of these questions is “no” the value of the dashboard vanishes and you need to probe further:

If it’s not visible then people can’t see when the dashboard changes — so you need to figure out when and where seeing that dashboard is useful.
If it’s not actionable then people cannot do anything when the dashboard changes — so you need to figure out who should see it, and make sure they have the autonomy to act on it.
If it’s not used then people don’t care if the dashboard changes — so you need to figure out what they do care about and why, and how the dashboard fits in.

ttfn.

Turn It Up or Turn It Down

adrianh@quietstars.com (Adrian Howard) — Tue, 21 May 2024 15:30:03 +0100

An issue I’ve been talking through with people recently is when to do certain activities. Or how often. Or how many people to involve.

“How long should discovery take?”, “When do we start and stop interviewing?”, “How many people should we talk to?”, “Hope many usability tests should we do?”, “How many prototypes should we build?”, “How many A/B tests before we decide?”, and so on.

These are usually the wrong questions to ask.

They’re usually wrong because they’re being asked in the context of a timeline or some kind of sequential stage-gated process. Folk want to know when they can stop doing one thing (like talking to customers) and start doing the next thing (like building some software).

Folk are still in the mindset that these are one-off activities. We can discover truth, map out the one-true-timeline, and then be confident of our next steps.

This is, of course, a lie.

User research & product management activities do not deliver truth. They delivers information with some level of risk and confidence. Which helps the organisation make informed bets based on that information.

This means we need to be listening for new information. We need to understand whether our bets are paying off (or not) and steer accordingly.

Which is why one of the biggest lies is the “discovery phase” or the “research phase”. It encourages organisations to think about activities as one-off. Something done once and never revisited.

This mindset cripples the organisation’s ability to make smart decisions when the world changes, or the research turns out to be over general, or over specific, or just plain wrong.

Instead I encourage teams to look for and articulate the cues that let you know when you should start doing more (or less) of something.

Rather than asking when things should start and stop, or how long they should take, ask what value that activity is providing and why we’re doing it.

Think about it like a volume knob — not a stage or switch.

Ask when you should turn an activity up, or turn it down.

Take interviewing customers for example. Let’s say we’re a startup looking for problem-solution fit and we’re talking to customers every day about how their using our new service:

Do we hear the same thing from every customer we talk to? Probably time to turn it down. Move back from daily interviews to weekly.
Does we hear different things from every customer? Probably time to turn it up. Do more interviews. Spot that different market segment we didn’t really understand before. Turn it down on the segment we do understand. Turn it up on the segment we don’t.
Do we see customers behaving differently from the customer journeys and mental models we built from our discovery work? Time to turn up the interviewing up again to explore that issue.
… and so on.

Look for the triggers. Help socialise:

Why are we doing this?
What do we expect to see when it’s working well?
What do we expect to see when it’s working poorly?
What do we see if we need to do more of something?
What do we see if we need to do less of something?

TL;DR: Instead of selling an activity, sell the triggers and cues that show the need for that activity. Help the organisation see when they need to turn it up. Or turn it down.

ttfn.

How Do Candidates Describe Your Hiring Process?

adrianh@quietstars.com (Adrian Howard) — Thu, 09 May 2024 00:00:00 +0000

Question for all my seasoned designer friends:

Think about your last job hunt. What adjectives would you use to describe the hiring process you experienced?

— Jared Spool

This started off as a long rant on twitter a few years back — and since I’ve recently had a similar conversation while helping someone with their hiring process, I thought it worth digging out from the hellsite and putting somewhere more useful.

Jared’s question is a great one. What words would candidates in your hiring process use?

Here are some I’ve heard and used — on both sides of the hiring equation.

The bad:

Long.
Disjointed.
Repetitive.
Unrealistic.
Exploitative.
Opaque.
Anxiety-inducing.

The good:

Short.
Clearly defined.
Informed.
Challenging.
Coherent
Comprehensible.
Balanced.

Lets dig into some of the experiences behind those words.

The Bad

Long — You don’t value your or my time. You spread out interviews & exercises over weeks. Dates get moved. Decisions never get made. I’m always waiting to hear back from somebody. You seem shocked when you finally come back with an offer that I already got another job.
Disjointed — The recruitment process doesn’t feel predictable. Interviewers contradict each other. etc. Job roles and requirements seem to change. Trivial questions get asked, and trivial exclusions applied, at the end of the process rather than the start.
Repetitive — Different people ask the same damn questions multiple times in multiple interviews, wasting your and my time. Nobody seems to be talking to each other inside the organization. You sometimes expect different answers to the same questions. There’s always “one more” person to talk to.
Unrealistic — You want somebody who is awesome at illustration, and JavaScript, and user research, and CSS, and UI design, and usability testing, and interaction design, and service design, and HTML, and survey design, and animation, and customer interviewing, and…
Exploitative — You value your time way more than mine. You want me to jump through take home exercises that would take days to perform at a reasonable level before you even talk to me. You treat me like an idiot and expect to prove otherwise. You don’t answer my questions.
Opaque — You don’t let me know how the recruitment process will work. How long it will take. When I can expect a decision. What the salary range is. Who I’ll be working with (seriously!). What I will be working on. How you work. You expect me to sign an NDA and non-compete.
Anxiety-inducing — I don’t know what’s happening. I don’t know why it’s happening. I don’t know when it’s going to be happening. I don’t know who is making the decisions. I don’t know why.

The good

Short — You know what you’re recruiting for and why. So you only ask me to do relevant things. You value my time, as well as your own. Time spent is appropriate on both sides for how invested we are in working for each other. Commitment builds over time.
Clearly defined — You know what you’re recruiting for and why. So you have roles, and skills, and the behaviours you expect to see down cold. Everything from the job advert to the interview process shows that.
Informed — You know what you’re recruiting for and why. Along with how that fits into the larger UX/design/product world. You understand how those skills fit together. How likely you’re likely to find them in one person. How expensive they may or may not be.
Challenging — You know what you’re recruiting for and why. So you focus on the areas that are actually significant to the role. You can ask tricky questions on how I’ve solved problems in the past, rather than random hypotheticals that bear no relation to real work.
Coherent — You know what you’re recruiting for and why. So I never wonder “why did you ask me that?” or “what’s happening next?”. Every stage of the interview process from start to finish is built to recruit people with the abilities you need.
Balanced — You know what you’re recruiting for and why. So you’re approaching the recruitment process as a conversation. It feels fair. You want me to be confident that I can work with you well. I want you be confident that I can do the job well.

And yes — with different sets of jargon this applies to recruiting product people, or developers, or content people, or data people, or… anybody really.

If you’re having problems hiring go ask candidates how they would describe your hiring process. Ask the people you hired, the people you rejected, the people who you wanted to hire but rejected you.

It will almost certainly be interesting.

TL;DR: Please understand what you’re recruiting for and why.

ttfn.

You Have a Performance Problem

adrianh@quietstars.com (Adrian Howard) — Mon, 21 Sep 2020 00:00:00 +0000

You have a performance problem.

Folk keep pointing out how slow your apps and services are.

You’re not deliberately writing slow code. You boss never asked you write slow code. Your organisation almost certainly doesn’t have “Slowest code that people will still pay for” as one of it’s strategic goals.

And yet — people are continually talking about how slow your code is.

Some people try and find excuses for it.

“I don’t see any speed problems.”
“It’s only slow if you use it this way.”
“I didn’t have time to make it efficient.”
“I didn’t know how to make it efficient.”
“It’s only slow because my boss asked me to deliver this feature on this deadline and there was no other option.”
“My boss told me to write the feature this way.”
etc.

They all might be true statements.

But your code is still slow.

You have a performance problem.

You cannot say that the code is not slow because you didn’t deliberately write slow code. You cannot absolve yourself of the responsibility of writing the slow code because somebody else told you to write it.

The code is still slow. You still wrote the code. It still adversely affects the people who hit those performance issues every single day.

Folk who’ve dealt with these kinds of issue know what needs to happen.

There needs to be a culture change around dealing with performance problems. Performance needs to become a cross-cutting concern. It needs to be mentioned everywhere from the c-suite through to customer support. You might need to bring in some new people who have expertise in addressing performance issues.

The product, dev, and QA folk will all be learning new skills and practices. Everybody will. They’ll be seeing new ways to spot performance issues before they become problems. They’ll be understanding new ways to build systems that don’t have performance issues. They’ll be discovering (or re-discovering) concepts, and processes, and measures, and standards that help them stop those performance problems hitting the streets.

They’ll also be learning better ways to push back and manage up if other folk don’t see those issues.

It will be an ongoing process. Getting better at dealing with performance issues isn’t a one-and-done activity. Anybody who tells you that is lying or selling something. It’s a journey.

And yeah, some people who don’t actually value performance issues will probably be leaving.

Saying that nobody deliberately set out to write slow code doesn’t stop it being slow. Or pretending that slow code is fast.

A pattern of denial never fixes the problem.

In completely unrelated news — y’all should go read the commentary around this big honking racist software problem.

ttfn.

Overlap and Glue

adrianh@quietstars.com (Adrian Howard) — Fri, 28 Aug 2020 00:00:00 +0000

I’ve been having some conversations with clients recently around, for want of better terms, glue and overlap approaches to integrating different communities/disciplines/groups within an organisation.

Advanced warning: This is fuzzy and not well fleshed out — but this blog is all about the fuzzy and not well fleshed out!

Overlap is where there’s lots of active collaboration & cross-functional work. Folk actively reaching out between the disciplines for common ground. Finding new ways of working together. Shifting stuff around.

Glue on the other hand is when folk are really good at defining the point where the two disciplines interact. They work separately and the point where the two meet is well defined, rock solid & immovable.

Overlap doesn’t mean agile. Sometimes folk are working together on very linear waterfall-ish work flows. Sometimes they’re not iterating. But they are collaborating. They are changing who-does-what a lot.

Glue doesn’t mean waterfall. Two-way communication happens. Feedback loops happen. It’s not throwing stuff over the wall. But that communication occurs in a well defined way. Sometimes around an artefact (a design system, some OKRs, etc.). Sometimes around an activity (the monthly c-suite update, the weekly coffee the CPO & CTO have, etc.) Sometimes both.

Glue vs Overlap isn’t global — people can be playing in both spaces at the same time. For example a development team can be all glue with product, and all in the overlap with QA.

I’m biased towards working in the overlap. I love cross-functional spaces and the value that comes from people with diverse skills and experiences working together directly.

That doesn’t mean that glue approaches don’t work. Quite the opposite. The act of defining the areas and mechanisms where groups interact can be a super useful driver to discover more effective ways of communicating and working.

Overlap-Glue feels a little bit like the specialist|generalist continuum when it comes to individual preferences — but bigger than that since it’s more about how groups of people work together.

Overlap-Glue feels a little like some of the things that talked about in the Team Topologies book — but more context driven with people taking up different stances in the same groups depending on who they’re working with and why.

Overlap-Glue feels a little like this crosswise org chart dimension that John Cutler talks about in this tweet - but at different levels of granularity.

Overlap tends to be more high-cadence work, Glue low-cadence work (but not always).

(You see what I mean about “fuzzy” :-)

But people who love glue sometimes seem to hate working around the overlap. And folk who love the overlap sometimes seem to hate working around the glue. Folk especially hate moving from one type to another when contexts change.

And boy, have the last few months caused a lot of context change!

So I’ve been seeing teams that spend most of their time in the overlap having to suddenly deal with other bits of the organisation who spend all their time in the glue.

I’m seeing folk with really, really effective processes around the glue that suddenly having to move to playing in the overlap because the context has changed so much their old ways don’t work any more.

And so… Overlap and Glue. Having labels to talk about those differences — fuzzy as they are — has been helping: “Do we need to start working more in the overlap”, “Do we need to build some new glue?”, etc.

Hope you find them useful as well. If you do, let me know.

ttfn.

A Brief Story About Pizza (and Agile)

adrianh@quietstars.com (Adrian Howard) — Sun, 09 Aug 2020 00:00:00 +0000

Imagine you have recipe for Pizza Margherita.

A really, really good Pizza Margherita.

Some folk use it to make Pizza Margherita. It’s damn fine pizza. They’re happy.

Others hold the basil, add mushrooms and broccoli, and still call it Pizza Margherita. Some people like it. Others do not.

Others give you a cheese and tomato sandwich — and tell you it’s Pizza Margherita. Some people like it. Others do not.

Others tell you the Pizza Margherita recipe describes all possible Italian foods.

Others tell you that you if it isn’t Pizza Margherita then it isn’t Italian food.

None of those things mean your recipe is a bad or that Pizza Margherita is terrible.

(Replace “Pizza Margherita recipe” with “Scrum Guide”. Or any other set process description. Discuss.)

ttfn.

(Variation of an old twitter thread — it had more animated GIFs)

Dumb Hiring Shibboleths

adrianh@quietstars.com (Adrian Howard) — Mon, 27 Jul 2020 00:00:00 +0000

A shibboleth is any custom or tradition, usually a choice of phrasing or even a single word, that distinguishes one group of people from another. Shibboleths have been used throughout history in many societies as passwords, simple ways of self-identification, signaling loyalty and affinity, maintaining traditional segregation, or protecting from real or perceived threats.

— wikipedia.org/wiki/Shibboleth

(I’m going to use development as the example here. The same applies to UX, Product Management, etc. The shibboleths are different. The bad practice is the same.)

Getting more than a little cross with people who turn the way they became a developer into some kind of magic shibboleth on who can code well.

Yeah - I grew up on little eight-bit microcomputers when I was a kid. Typing in programs from magazines and hand-assembling code.

But guess what…

It’s not the 1980s anymore. Not everybody did, can, or should learn development that way.

I know great developers who started off hacking their myspace pages.
Great developers who started off by messing with neopets.
Great developers who started off by wanting to add a contact page to their boyfriend’s band’s website.
Great developers with CS, Maths, and Engineering degrees.
Great developers with History, English, and Philosophy degrees.
Great developers without any degrees.
Great developers who started off via a bootcamp.
Great developers who learned out of books.
Great developers who learned on the job.
Great developers who are lousy at maths & abstract logic puzzles.
Great developers who came from manual testing.
Great developers who started when they were a kid.
Great developers who never touched a computer until they were in their 30s and 40s.
Great developers who spend their spare time hacking on open source and side projects.
Great developers don’t touch a computer outside work.
Great developers who never play computer games.
Etcetera. Etcetera. Etcetera.

So if you’re looking to recruit great developers — or folk who can turn into great developers — and discard people who don’t have active github pages, or play computer games, or whatever other category you think separates “real” developers from the wannabes then you are filtering out great developers.

You don’t have a pipeline problem. You have a “don’t realise people can be good at the same thing you are without having an identical background to you” problem.

Being exacerbated by the great developers you didn’t even look at — or dismissed for foolish reasons — mocking you in all the communities where great developers who aren’t exactly like you hang out.

Which sucks.

What sucks even more is the problem is so easy to start fixing.

(This post is a version of a twitter rant from last year. It has more swears in. It makes me sad this topic comes around every few months as regular as clockwork.)

ttfn.

Pointless Job Requirements

adrianh@quietstars.com (Adrian Howard) — Mon, 20 Jul 2020 00:00:00 +0000

(Originally a rant on twitter preserved here for easier reading)

This isn’t rocket science — but it is apparently something that still needs to be said.

Putting requirements in your job advert that the job doesn’t absolutely require gets you a less qualified pool of applicants.

It’s that simple.

The unqualified bullshit artists will still apply. Because they and their dumb-ass egos don’t care or understand that they’re unqualified.

The mythical perfect candidate who actually has all of your kinda-would-be-nice-to-have “requirements” will probably still apply — because they still meet your actual requirements.

Then again they may just run away — because your random shopping list of requirements has demonstrated that you don’t actually understand what the role needs in the job advert.

The only people a long list of requirements filters out are people who think you’re telling the truth and really need somebody who ticks every item on your list.

Every unnecessary requirement on a job advert is literally making your pool of qualified candidates smaller.

Is fewer qualified candidates your goal? No? Then stop doing this.

Please.

Finally — as FJ points out

It also strongly narrows the diversity of who will apply.

— FJ (@fj) July 15, 2020

For example, see Tara Sophia Mohr’s article on Why Women Don’t Apply for Jobs Unless They’re 100% Qualified.

If you fix your job advert you can make this whole class of problem vanish. Without forcing job applicants to change their behaviour to cope with a long list of unnecessary job requirements.

Rant over.

ttfn.

Vitamins and Painkillers

adrianh@quietstars.com (Adrian Howard) — Wed, 15 Jul 2020 00:00:00 +0000

The metaphor is more than ten years old now, but I still encounter people who talk about “vitamin” and “painkiller” products and seem to take the difference very seriously. With “painkiller” products (solving an direct and immediate customer pain) being seen as better than “vitamin” products (that are just nice to have).

When somebody tells you your product is just a vitamin please remember that it’s just a metaphor. An occasionally useful metaphor when thinking about problem/solution or product/market fit — but just a metaphor.

Please don’t let it rule your life. There is no sharp dividing line between solutions that are vitamins and solutions that are painkillers.

In particular one customer’s vitamin product is another customer’s painkiller product.

To abuse the metaphor a little - if you want to start selling Vitamin C you don’t go to the gym where there are a lot of healthy people — you go find the ship of marooned sailors who are suffering from scurvy.

“Vitamin” products can have “painkiller” customers.

“Painkiller” products can have “vitamin” customers.

“Vitamin” customers can turn into “painkiller” customers as their needs change. And vice versa.

The only thing that matters is whether the business model for your product makes sense.

ttfn.

A Spotter’s Guide to Good Retrospectives

adrianh@quietstars.com (Adrian Howard) — Wed, 08 Jul 2020 00:00:00 +0000

This litte rant was triggered by a question about “Team effectiveness: how do you define and measure it?” in a Product In The Aether meet up.

One blocker for team effectiveness I’ve often seen with clients is that they fail at retrospectives. Even if you’ve got great alignment on the outcomes that should be delivered, it’s pointless if the team lacks the feedback loops to steer them in the right direction.

So how do you know when a team is good at retrospectives?

It’s a “I know it when I see it” thing for me — but I couldn’t easily articulate what I was looking for.

So I wrote a list off the top of my head:

everybody’s engaged
important gets more attention than urgent
folk focus on turning up the good as much as turning down the bad
folk come up with multiple options
folk run experiments
improvements are tracked across multiple retrospectives
folk steer their improvement process with a standard format like the Toyota Kata
pain/gain points are aligned with organisational goals
people talk more about the change they want to see than the particular way of achieving that change
people actually make changes — they don’t just talk about the change
if a problem is small enough to be easily solved, then people solve it in the moment rather than bringing it to the retro — stop the line and all that
public artefacts on the walls / in slack that talk about the changes that are coming out of the retro
more team ownership than individual ownership
no blame
willingness to go “well - that failed”
willingness to push to solve problems outside the teams immediate scope
active outreach to other teams - collaboration on solving larger problems / turning up larger gains
folk willing to put down one change they’re working on if a more important one comes along
folk can change their process without asking for permission first
folk are allowed to fail at improving their process (coz failures are inevitable.)

At this point I stopped because I had to go do the shopping. But that wasn’t the end — because there were some great follow up suggestions including:

they identify & move the highest leverage point within their direct/indirect reach #Meadows

they manage their bottleneck toward a situationaly-aware goal #ToC

they balance short/long term experiments

they care about their contributions & interactions

— Thomas Lissajoux (@thomaslissajoux), July 2, 2020

Absence of big blow ups– of problems and between ppl. They work stuff out when its still small.

— Esther Derby (@estherderby) July 3, 2020

A heuristic: They invite you (a stranger) into their retro & forget that u r there. U want to chime in to their conversation but cant decide when, & never do.

— Dhaval Panchal (@dhavalpanchal) July 3, 2020

I think an important aspect of it is whether the team’s behavior changes based on what comes out of the retro. Unless a meeting of any sort changes future behavior it’s a waste of time. Not all retros lead to massive changes but over time process should improve.

— Laura Klein (@lauraklein) July 2, 2020

If they’re good at retros then they’re steadily getting better over time in measurable ways. Not to say that every individual retro will achieve a positive outcome - some experiments do fail - but overall they will trend towards “better” over time.

— Mike Bowler (@mike_bowler) July 2, 2020

As a razor for being “good at retros” I look to see if they get into double loop learning, questioning their assumptions rather than trying to do the same things better.

— George Dinwiddie (@gdinwiddie) July 2, 2020

folk come prepared and everyone’s feedback is already documented

the team clearly trust each other and speak freely

effort to measure and continually improve moral / life balance.

a feeling of sincerity

— Tim Riley (@timothyjriley) July 3, 2020

Not forgetting my favourite from the ever excellent Sophie Freiermuth:

Try “how do you know a team is BAD at retros " then work to opposite and reverse statements

Alternatively:

everyone is engaged

discussions are flowing

team stays on relevant topics

tough and unpleasant topics are discussed kindly/supportively

people look ☺️ at the end

— Sophie Freiermuth (@wickedgeekie) July 2, 2020

I am a huge fan of using the anti-problem format to find solutions & options — so that’s an exercise for another day!

What do you look for when you’re trying to spot good retrospectives?

ttfn.