Rose, thorn, bud is a simple tool for reflection for yourself or your team. The basic idea is to look back at a recent project or how things are going and consider each aspect of a rose:

Rose: what are the successes? What's gone well?

Thorn: what are the challenges? What could we do better?

Bud: what are opportunities with potential? What could we explore or try?

If running as a team retro activity or retrospective, you might spend a few minutes individually adding thoughts for each prompt, then talk through each of the thoughts in Rose, Thorn and Bud.

A separate but no less important step is often to capture actions from the reflection—what you'll do as a result. If you're conducting retros regularly, consider revisiting actions from previous sessions.

I like "rose, thorn, bud" as it's beautiful to consider that a rose contains such different facets, like so many things.

I've come across many retro and reflection activities that are variations of these three prompts: "What went well?", "What didn't go well?" and "What else?" A few to mention:

The sailboat retro: Goal/vision, Rocks, Wind, Anchor — a nice feature for a team is that this activity places you all in the same boat

Strengths, Weaknesses, Opportunities, Threats (SWOT)

A reader suggested a fourth aspect of the rose analogy to reflect on as its leaves or roots: what are the unnoticed or behind-the-scenes things that contribute to the rose's success?

I've come to consider that it doesn't matter too much what activity you choose to get a discussion going. What matters most is regular reflection, hearing all the voices in a team, and making progress together. One teammate ran an excellent retro by us all finishing early and heading to the pub.

I didn't intend it, but some of the products and prints for rose, thorn, bud out to be some of the nicest I have.

Also see: Information radiator, MoSCoW prioritisation, RACI, How to peel a Post-it so it doesn't fall down, the upward spiral

Rose, Thorn, Bud

Chickens and pigs is a metaphor for who's got skin in the game. Or to leave metaphors behind, who's involved in a project vs who is fully committed.

Also known as the bacon and eggs principle, it's from the old joke (sometimes told as a short story), "In a bacon and eggs breakfast, the chicken is involved, but the pig is committed."

Many people may be interested in and share their opinions on a project or decision. But only some will be responsible for delivering the project and directly accountable for its success.

Everyone may be interested in a bet, but only some players have money to lose.

The chickens and pigs metaphor used to be part of the scrum guide for developing software but was removed. While it memorably distinguishes accountability in a project, there's a danger that it alienates or diminishes valuable input that might make a project successful.

For a more conventional grouping of stakeholders in a project, see RACI

Chickens and pigs

The XY Problem (or X-Y Problem) often comes up in software development or customer support, where someone asks for help to achieve a solution (X) that they have chosen as a way to solve a different problem (Y). Helping with their solution may not help them solve their actual problem if it's not a good approach in the first place.

An example from software development is a person asking how to extract the last three characters of a filename (solution X), because they want to know the file type (problem Y). After helping them do solution X, it still wouldn't solve problem Y as some files have extensions of more than three characters.

Another example is a customer asking for help accessing their online account without realising that what they really want to do has to be done over the phone anyway.

There's art and skill in respectfully answering questions and helping with what's asked while seeking to understand the real goal. And if you're asking questions, providing more context may help others provide better answers.

In development, it saves time and effort. In customer support, it leads to happy customers. In design, it may be uncovering unmet needs.

The name is indirectly from Eric Raymond in How to Ask Questions the Smart Way:

A: If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation."

Also see a better hierarchy of needs, the metrics onion, challenge and clarification questions, prefer open-ended questions, ask the question at talks, don't fill the silence.

The XY Problem

VUCA stands for Volatility, Uncertainty, Complexity and Ambiguity.

The VUCA framework is a reminder to consider how to lead and adapt to the challenges of living in a volatile, uncertain, complex and ambiguous world.

In his book Leaders Make the Future, futurist Bob Johansen provides counterpoints to each that leaders can use:

We live in a VUCA world, but we can handle it.

The VUCA framework originated in the US Army War College.

VUCA is an acronym, as opposed to an initialism. Also see OODA Loop.

VUCA

Saying "no" isn't easy. But there are different ways to say "no" to someone's requests without feeling like you've let them down while being realistic and constructive and ensuring the requester feels heard.

I really like this framework of three types of "no" from Judd Antin:

With the Yes No, you say "yes" to the need and "no" to the specific ask. 

So, a child asking for an ice cream may indeed need something to eat even though they might not get an ice cream. Or the request to make the sign-up button larger might well indicate that it's easy to miss, though a better solution may be to change its colour or the layout of the page.

With the Material No, you are saying yes to the request if you have the time/budget/people/tools to do it.

So, you would love to get the kite out of the tree if you had the tools to reach it. Or the request to make an additional change might be possible on the basis that you can push back the launch date or add another person to the team.

With the Priority No, you are saying yes, we can do it as long as we're happy to drop something less important.

So, you can take the extra cuddly bear in the car if we can choose a different one to leave behind. Or that you can do that project on the basis that we postpone another we had planned.

In each type of "no", the intent is to support and meet the needs of the person requesting while clearly explaining the reasoning for what you'd need to get it done. In each case, the "no" leads to valuable discussions of larger issues of what the real need is, what's required to get a job done, and what's really important.

Read Judd Antin's article, How to Say No, in his series One Big Thought.

Here's a version with all three types of "no" in one image and individually The Yes No, The Material No, The Priority No.

Three Types of "No"

Cake Wrecks is the blog and book of when professional cakes go hilariously wrong, by Jen Yates. But a cake wreck is also a useful metaphor for how easy it can be to misinterpret instructions—often by simply taking something literally when it was expected to be interpreted. Examples from Jen's collection include a smart-looking cake with "Nothing" written across the front, a graduation cake with "I want sprinkles" next to a graduation cap, or a cake sporting a full "Happy birthday on a gluten-free cake." If you haven't seen them, you could do much worse than look some up now. It's easy to laugh at these examples, but it's also easy to find real examples in day-to-day work.

I learned about cake wrecks from Jeff Patton's excellent book User Story Mapping. He gives cake wrecks as an all too common example of communication in software development. For example, a user story or specification for a feature is written and passed on to developers who, in the absence of other communication and with perhaps cultural or status barriers, may carefully build exactly what is written rather than what the writer intended. Cake wrecks are funny and silly—except if it was for your special occasion—but mistakes in projects are expensive in time, money and relationships and are worth avoiding.

The recipe for avoiding a cake wreck is, in principle, simple:

Don't assume that what you see is what someone else will see

Use stories and specifications as tools for talking about what's needed and not as equivalents of it

Create a safe space for everyone to question what they don't understand or don't agree with

Give everyone the 'why' behind a project and autonomy and flexibility to suggest other ways to meet the goal

Check in during a project and adjust as needed

Cake wreck

The frog boil metaphor illustrates how it's easy to miss small changes that build up over time until it's too late. The scenario, as told, is that of a poor frog who would leap away from hot water but, if put into cooler water that is gradually warmed, won't respond in time to getting boiled.

As a metaphor, it describes a powerful and pernicious shortcoming in how we perceive the world. A student kitchen that gets messy mug-by-mug, a business with gradually slowing sales, software that builds up with tech debt, a river that is slowly polluted, a road that gets busier each day, a bay that sees fewer fish each year, content that drifts, cancer that slowly spreads, a story or behaviour that becomes normal, a website that gets slower feature-by-feature, or a climate that slowly warms are all cases where we may not be happy where we end up, but we didn't notice how we got there.

It's hard to respond to gradual change, especially when it spans generations. Jared Diamond called it out as a potential fate of the Easter Islanders and how they could have cut down the last tree. One barnacle is nothing, but many barnacles can cause significant headaches for big ships.

Fortunately, there's a flip side. Many, many things are getting better without us realising. Small positive changes, such as in attitudes, education, or healthcare, add up over time—the Destiny Instinct can mislead us. Fast and slow layers make a system, like a forest, more robust. Getting one percent better each day leads to a 37x improvement in a year. And enough molehills can make a mountain.

What a frog does, in this case, is not, apparently, true—don't try it—it's much better as a metaphor, not an experiment.

The frog boil metaphor

The bus factor is how exposed you are if key people, perhaps with critical knowledge or skills, were hit by a bus.

Examples might include the only people able to keep a company running, restore a server from a backup, or someone who held the only key to unlock crypto assets of its customers. As a result, many places are set up with, or required to have by investors or insurers, some redundancy — say two experienced developers with knowledge of how a service works — to minimise the risk of a tragic accident also being a severe problem for a company or its customers.

As a metaphor, the bus factor may be helpful to consider without the need for people to actually be hit by a bus. It may be worth thinking through how you might operate if someone was late, missed their flight, was ill on the day, or simply quit. In operational roles, this will often lead to a minimum of two people for each key position if nothing else to allow one to take a break from time to time.

An alternative framing, with fewer fatalities, is 'what if we all won the lottery?' and so decided to go do something else.

Bus factor

Groupthink arises from the desire of a group to maintain harmony and consensus. Groupthink can reduce the diversity of ideas and opinions — people can seek to avoid conflict, or avoid expressing unpopular views, and end up thinking down the same path. When psychological safety is low and people feel they may experience disapproval, particularly from people with higher ranking or status within the group, groupthink can get worse.

It can be uncomfortable to express opinions different from a group. Perhaps you remember that feeling when a teacher asked a question in class and if everyone raised their hand to one answer it wasn't always easy to be the only hand up for a different one.

Fortunately, there are some solid ways to minimise the tendency to groupthink. These include:

Generating ideas separately before coming together — can be effective remotely too

Increasing psychological safety so everyone feels comfortable expressing contrarian views

Establishing the norm of a shared work product rather than individual credit/blame

Groupthink

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

There's an old story about the statistician who drowned after seeing that the average depth was 3ft. Averages, or in this case the mean, necessarily hide some data, but very often they also hide what's really going on.

Let's say you run a delivery service and have an average delivery time of one day, it could be that most deliveries are actually a few hours while a few particular ones have people waiting for a week. Or a figure of average incomes might hide that most people have low salaries and a few are millionaires. But just looking at the average you can't tell. Sometimes a different measure of central tendency, like the median, can provide a clearer picture.

Sheldon Zedeck, a UC Berkeley psychology professor who taught me about the design of experiments, gave wise advice: spend time with your data. Sometimes it's the only way to know what's happening for sure.

Sneaky averages

Lagging metrics are usually the ones we care about most. In business, they're things like revenue, sales, or profit. The trouble is, we can't act always act on those directly. By the time we assess our revenue everything we did to get there has already happened, so if we don't like it, it's too late.

Leading metrics are what we need to focus on to drive the lagging metrics. If we want to lose weight we might be better off focusing on eating less and eating healthier, working out more, and sticking to our workout schedule. To increase our revenue we may want to look at deal size, ease of sign-up, or our referral rate.

Paying attention to and improving the leading metrics gives us leverage over the lagging metrics we may really care about.

Leading and lagging metrics

Yak shaving describes how when setting out to do something, you found you had to first do something else, which needed you to finish this other thing, and so on until you found yourself shaving a yak, or equally unrelated activity, to do the first thing you set out to do.

It's pretty frequent in life — tidying your room? — and particularly resonates in software development, where when tackling one thing, you often find yourself fixing something else, which needs you to fix something else, and so on. Here's the ever brilliant xkcd on fixing problems.

Yak shaving features, lovingly polished, in my book Big Ideas Little Pictures.

Here's a brilliant 40s clip of Hal changing a lightbulb from Malcolm in the Middle, classic yak shaving

Early yak shaving features in the song There's a Hole in My Bucket in which fixing a bucket requires straw, which requires a knife to cut it, but the knife needs sharpening, which needs a stone, which is too dry and needs wetting with water, which needs fetching...with a bucket

The first I found of yak shaving was a short article on productivity in the first issue of Make magazine by Danny O'Brien and Merlin Mann.

Yak in the style of Alison Green and Adam Stower's excellent children's book, What can you Stack on the Back of a Yak?

Yak shaving

Sentences that have been written in a passive voice are generally less powerful than sentences that have been written in an active voice.

Active writing hits harder than passive writing.

It's easy for passive writing to slip in. Here's a handy technique to help you spot passive writing in your sentences. Try adding "...by monkeys" to the end of the sentence. If it still makes sense, then there's a good chance it's passive.

In the example in the sketch: "The bug will be fixed" you can tack on "...by monkeys" and all makes sense. It's passive. Passive writing is an easy way to distance ourselves and our opinions from what we're writing. Active writing takes ownership and responsibility and connects with the reader. "We'll fix the bug. Sorry about that."

I love the "...by monkeys" example for spotting passive writing as it vividly shows how responsibility disappears.

This super example and technique is from Monzo's excellent tone of voice guidelines. Handy for writing copy on the web, for your brand, and for everyday life.

You might like the excellent Hemingway app to spot other non-Hemingway slips in your writing. I ran this post through it and cut out a lot of fluff.

I also love the classic The Elements of Style by Strunk and White.

By monkeys

A manager or leader can be an umbrella or a funnel.

An umbrella shields the team from distractions, last-minute changes, and conflicting priorities, creating a protective space where they can focus and thrive. This umbrella management style ensures the team has the clarity and autonomy needed to do their work.

A funnel, however, allows every request, deadline, and distraction to pour straight through, leaving the team overwhelmed and struggling to keep up.

As organisations grow, the demands on a team often increase dramatically—especially in areas like product management at tech companies. Left unchecked, these demands can drain a team’s time, energy, and ability to focus on what really matters.

Todd Jackson, former product manager of Gmail, captured this perfectly with the umbrella and funnel analogy: great managers act as umbrellas, shielding their teams and enabling progress. Poor managers, by contrast, become funnels that overload their teams.

All of us want autonomy to choose our own actions, but none of us want to be overwhelmed.

Manager time, maker time (or Manager's Schedule, Maker's Schedule)

Umbrellas and funnels

The accountability ladder is a framework for taking accountability for a situation in which we can move from a powerless victim mindset to a powerful, accountable mindset.

There are many ways to respond when things go wrong or need to be done. If you choose a victim mentality, it’s easy to ignore the situation, blame others for it, declare your powerlessness, or just wait and hope. Or you can consider yourself accountable and adopt a mentality of power, acknowledging the situation, owning it, looking for solutions, and taking action to do your best.

Bruce Gordon explains the accountability ladder (grainy, slightly odd video) with a fun story about him and his son in which they realise his son has homework due tomorrow that’s not done.

Most of us have more power over our situations and more potential for impact than we usually give ourselves credit for—whether it's our jobs, our friends, the environment, or local issues. Perhaps considering your position on the accountability ladder is a good place to start.

I love this quote from Erling Kagge, the first person to walk to the Triple Poles:

"Most people underestimate the possibilities you have in life. And that’s a bit sad…But don’t underestimate yourself. Also, like I said: Get up in the morning."
— Erling Kagge

There are many versions of the accountability ladder. I couldn’t find a definitive source. If you know, please get in touch.

The accountability ladder

Perhaps, like me, you’re used to thinking about bringing customers onboard as a funnel. It’s a very natural metaphor for thinking about customer acquisition. For example, you market to 10,000 people, 500 people visit your website, 50 of them put something in the basket and 10 of them buy. If you draw it out it looks like a funnel. And the next time you market you start fresh with a new 10,000. But the real world isn’t like that. Delivering a good service to your customers helps the next customers come in. Hence the flywheel model.

A flywheel is typically a big heavy wheel that stores and releases energy from an engine or vehicle. The flywheel metaphor is about happy customers driving your growth. And when you think about your business this way it can cause you to make different decisions. Having more customers is like a bigger, heavier flywheel containing more energy. Happy customers speed you up, unhappy customers slow you down. Making it easier for customers to try your product reduces friction, as does making it easier for for customers to talk about and share your product. Get your flywheel big, heavy and spinning like crazy and your business is doing well.

The flywheel model is from Brian Halligan at Hubspot. I’ve thought about customer funnels for literally years and I wish I’d known about the flywheel long ago. Check out Hubspot’s flywheel intro for more.

The business flywheel

Rubberducking is a problem-solving technique where you explain your code or task to a rubber duck—or any inanimate object—and discover the solution yourself through the act of explaining. It's brilliant because it works and is effectively free.

Rubberducking, or rubber ducking, is most commonly associated with debugging in software development but can be applied to any problem-solving process.

The name comes from the book The Pragmatic Programmer by Andrew Hunt and David Thomas. In it, the authors suggest using a rubber duck as a conversation partner to clarify one’s thoughts. This is an accessible and effective way to troubleshoot problems without requiring someone else’s time.

Have you ever been called over to someone’s desk to help them solve a problem, and as they explain the problem to you or demonstrate it, they figure out the answer themselves? It happens all the time to me, particularly when someone's showing me how something doesn't work, and it magically works just by having me watch over their shoulder.

The rubber duck technique is as simple as that, except that instead of calling someone over, you can simply replace the person with a rubber duck, teddy bear or heck, even your stapler.

The psychology behind rubberducking relies on how explaining a problem forces you to process your thoughts more clearly, often revealing gaps or errors in your understanding. Here’s how you can try it yourself:

1. Set up your “duck”: Place a rubber duck, teddy bear, or any object on your desk.

2. Explain your problem: Describe your code, logic, or issue to the duck, step by step, as if you’re teaching it.

3. Watch for insights: In explaining it aloud, you’ll often uncover what’s wrong or identify a new approach to solving it.

For example, a developer struggling with a bug might explain every line of code to the duck. Verbalising their logic can highlight an overlooked detail that resolves the problem.

Rubberducking works because it forces you to articulate your thoughts clearly, moving them from abstract notions in your head to concrete statements. This shift can:

• Help you identify assumptions you didn’t realise you were making.

• Mimic the process of pair programming without needing another person.

Rubberducking a problem also reduces dependency on others for problem-solving, making it a cost-effective—basically free!—and time-efficient tool for debugging.

Here are some situations where it’s particularly useful:

• Debugging code: Talk through an error or bug in your program.

• Explaining logic: Test the clarity of your solution by explaining it step by step.

• Learning new concepts: Summarise a concept to the duck to check your understanding (see the Feynman Learning Technique)

• Decision-making: Walk through the pros and cons of a decision.

In software development, rubber duck debugging has become a recognised term for this process. It’s so common that some developers keep an actual rubber duck on their desks to symbolise this practice. Teams might 'joke' about needing “a duck” for the simplest bugs.

Debugging is an integral part of coding, and the rubber duck technique makes it less daunting. By verbalising your thought process, you streamline problem-solving without needing external help.

Frequently Asked Questions about Rubberducking

Nope. While a rubber duck is the classic choice, you can use anything nearby—your coffee cup, a stapler, or even a photo on your desk.

Q: What if talking out loud isn’t possible?

Writing out your explanation or saying it in your head can work just as well. The key is clarifying and articulating your thought process.

Q: How is this different from pair programming?

Pair programming involves working alongside another person on the same task. Some people swear by pair programming, and to be honest, I've always found it effective whenever I try it. However, rubberducking is a solo activity where the act of explanation itself is the solution.

Next time you're stuck on something, grab a rubber duck and give it a try.

Rubberducking is similar to the empty chair technique for psychotherapy, which involves speaking to an empty chair as if addressing a person.

It's also easily confused with "rubbernecking," which is slowing down to look at an accident as you drive past—a common cause of traffic jams.

What is Rubberducking? An Explanation of the Rubber Duck Debugging Technique

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for determining what to release to your customers and when.

The idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. In the beginning, they’ll probably have to put up with a lot if they want to use it, but with each successive release, they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning, and all along the way, the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it requires rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

This diagram is explained in the brilliant product management book User Story Mapping by Jeff Patton.

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

More value will likely be found through analogy than the shipping situation. Watch out for barnacles on your project. One by itself is nothing, but enough of them can cost you.

Watch out for barnacles

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Yesterday’s weather

Hofstadter's Law is “It always takes longer than you expect, even when you account for Hofstadter’s Law.”

Hofstadter's Law is one of my favourites, and I share it time and time again.

We are bad at estimating. We don't allow for the unexpected. We don't know the unknown unknowns. We are overly optimistic. We suffer from recency bias. Generally, we struggle with big, complex things.

In the law's recursion, it's a little like this guidance from Clean Code:

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”—Clean Code

Or omit unnecessary words from Steve Krug

Given how easy it is for us to underestimate how long things will take, be kind to each other.

From Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid (1979)

Hofstadter’s Law

I regularly find the Kano model a useful way to think about design.

Kano highlights 3 different types of benefits your product can provide:

Threshold
  These support the minimum requirements of the product. Like the brakes on a car, you’re not going to buy one without them, and yet no matter how good you make them they are unlikely to thrill people about the car. But if you do a bad job, people will sure notice.


Performance
  these benefits are appreciated the more you deliver on them. For a car this may be acceleration or fuel efficiency. The better you make them the happier people will be, and the worse they are the least satisfied they’ll be.


Delighters
  these are the fun benefits that get people to love a product, but if you only had delighters you wouldn’t have a product. For instance, if you car is slow, not fuel efficient and the brakes don’t work, it doesn’t matter if it has the best stereo on the planet, for almost everyone it just won’t help. But if your car has serviceable brakes, reasonable acceleration and fuel efficiency, and the best stereo on the planet then it could really delight.

Product management sketches