Throughout my long professional career, I’ve encountered many different forms of employee appreciation — and just as many examples of the opposite.

I’ve experienced appreciation that was genuine and heartfelt. I’ve seen well-intentioned recognition that was communicated poorly. And I’ve witnessed praise that was so transparently insincere that it was difficult to take seriously.

At its core, showing genuine appreciation isn’t complicated. There are a few simple principles that can make all the difference.

Tip #1: Avoid Generic Expressions of Appreciation

One of the most common examples is the end-of-year appreciation speech. These speeches often feel awkward, uninspired, and somewhat embarrassing — whether they come from senior leadership or direct managers.

For employees to feel that you genuinely value their contributions, your appreciation needs to be specific and meaningful.

This applies to every level of recognition, whether you’re addressing the entire organization, a department, a team, or an individual employee.

Here are a few examples of what meaningful appreciation looks like:

• Recognize the commitment employees demonstrate when solving specific challenges or problems in projects or products.
• Appreciate concrete ideas that improve efficiency and productivity across the organization.
• Recognize the development of innovative solutions for new or improved products and technologies.
• Acknowledge the dedication employees show when achieving or exceeding challenging goals.
• Appreciate employees’ flexibility and commitment when meeting demanding customer requirements.

The key is to connect your appreciation to something real. People should understand exactly what they did and why it mattered.

Tip #2: Show Appreciation in a Timely Manner

Recognize exceptional performance and commitment as soon as possible.

Employees are much more likely to notice and value timely recognition than a brief, passing comment made at the end of the year.

When appreciation comes too late, it loses some of its impact. The connection between the employee’s contribution and your recognition becomes less clear.

A simple, sincere acknowledgment in the moment can mean far more than a formal speech months later.

Tip #3: Embrace the Many Ways to Show Appreciation

Appreciating employees means much more than recognizing their performance.

Here are five additional ways to demonstrate that you value your people:

• Show trust. Delegate real decision-making authority to your employees instead of simply assigning them tasks.
• Value experience and knowledge. Recognize your employees’ expertise and incorporate their insights into your decisions.
• Appreciate positive behavior. Acknowledge actions and attitudes that contribute positively to your company culture.
• Welcome honest feedback. Show appreciation when employees give you open, candid, and constructive feedback.
• Communicate transparently. Be open with your employees and avoid withholding information unnecessarily.

These actions demonstrate appreciation through your behavior, not just your words.

And often, that is what makes the biggest difference.

Tip #4: Use Constructive Criticism as a Form of Appreciation

Appreciation doesn’t mean avoiding criticism.

In fact, providing constructive feedback when employees make mistakes can be a meaningful way to show that you value them.

The goal is to help employees learn from their mistakes, develop their skills, or gain a clearer understanding of what you expect from them.

Constructive feedback communicates something important:

I believe you can learn from this. I want you to succeed, and I’m willing to help you get there.

Of course, the way you deliver feedback matters. It should be respectful, specific, and focused on learning rather than blame.

Tip #5: Don’t Overdo Appreciation

Employees aren’t small children who need constant praise.

Appreciation shouldn’t be expressed continuously simply to create a feel-good culture.

When recognition becomes excessive or routine, it risks losing its meaning. Over time, employees may become so accustomed to it that it no longer has any real impact.

Genuine appreciation is not about saying something positive every day.

It’s about recognizing what truly deserves recognition — and doing so sincerely.

The Bottom Line

Employee appreciation is a key driver of motivation and engagement.

But there is one essential prerequisite: It must be genuine.

Managers who believe they can get by with a few generic phrases may end up disappointing their employees just as much as if they had shown no appreciation at all.

People want to know that their work matters. They want to understand how their contributions make a difference. And they want to feel that their leaders genuinely recognize and value them.

The most effective way to show appreciation is not through grand gestures or carefully rehearsed speeches.

It’s through specific recognition, timely feedback, trust, transparency, and a sincere interest in the people you lead.

Because in the end, appreciation isn’t about what you say.

It’s about whether your employees believe you mean it.

Read more of my work here: https://smart-fed.com/en/publications/

How to Make Employees Feel Truly Valued: 5 Ways to Show Authentic Appreciation was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to link your analysis to strategy, so you deliver value, not just documents.

Are You Solving the Right Problem, or Just the Assigned One?

Most business analysts are introduced to a project and immediately start thinking about requirements.

What does the business need?

Who are the stakeholders?

What needs to change?

But there is a more important question that should come first:

Do you understand why the project exists?

It is surprisingly easy to become so focused on delivering requirements that you lose sight of the bigger picture.

You can write an excellent requirements document, run great workshops and deliver a solution that meets every documented requirement.

But if it doesn’t address the organisation’s real needs or support its strategic objectives, have you really delivered value?

This is where great business analysis begins.

It starts with understanding the organisation’s strategy, identifying the business need and defining what success looks like, before you jump into requirements.

What Does Strategic Business Analysis Really Mean?

Business strategy defines an organisation’s direction. It sets out where the organisation wants to go, what it wants to achieve, who it serves and how it will stay competitive and sustainable.

Strategic business analysis focuses on understanding that direction and ensuring projects and solutions contribute to it.

Think of strategy as your compass.

Requirements tell you what to deliver. Strategy tells you whether you are heading in the right direction.

A strategic BA doesn’t simply accept a project brief and start documenting. They ask:

• What is the organisation trying to achieve?
• Why is this initiative important, and why now?
• What problem or opportunity are we addressing?
• What is preventing the organisation from reaching its objectives?
• What will success look like, and how will we measure it?

Asking these questions early helps uncover the real business challenges and keeps the project focused on the right outcomes. They seem simple, but they can fundamentally change a project’s direction. Asking them well is a skill, and I’ve written about how to improve your problem-solving skills using neuroplasticity techniques.

My Experience: Understand the Business Before the Technology

One of the most important lessons of my career is that successful transformation starts with understanding the business, not the technology.

In the Australian essential services sector, I worked on a Salesforce implementation supporting business processes for the Victorian Energy Upgrades (VEU) Program. The program involves energy efficiency upgrades and Victorian Energy Efficiency Certificates (VEECs), where regulatory requirements and calculations are central to the work.

The stakeholders were diverse. Some were responsible for regulatory and reporting activities. Others were operational specialists, including case managers with legal backgrounds and a deep understanding of the regulatory environment.

Bringing different stakeholders together takes more than good documentation. It takes trust, which I explore in my article on building resilient teams.

The processes were complex, particularly the certificate requirements, eligibility rules and associated calculations.

Accuracy wasn’t a system requirement. It was a business and regulatory necessity.

I recognised that capturing requirements was only one part of the job. We needed to understand how the business actually operated and make sure the solution reflected that complexity.

So I facilitated observation sessions with key stakeholders to see how they carried out existing activities and calculations. I then involved them in validation, running walkthroughs and show-and-tell sessions where we worked through calculations, business rules and different scenarios.

These sessions let stakeholders examine the calculations, challenge assumptions, clarify requirements and confirm that the expected outcomes were correct.

By involving the people who understood the processes and the regulations, we were able to work through complex calculations, business rules and edge cases early, while they were still easy to fix. The sessions led to simpler processes and a 360-degree view of the customer, with the information staff needed in one place. Just as importantly, stakeholders felt heard and trusted the solution because they had helped shape it.

The lesson? When you understand the business first, technology can simplify it rather than just digitise its complexity.

This is what strategic business analysis looks like in practice: understanding the business well enough to design a solution that serves its real needs.

Strategy vs Business Need: What’s the Difference?

These terms often get blurred, so let’s separate them.

• Strategy is the long-term direction and goals.
• Business need is the problem or opportunity that must be addressed to achieve those goals.
• Solution is how we address the need.

Jump straight to the solution, and you risk solving a problem nobody has.

Practical Tools to Connect Your Work to Strategy

You don’t need a complicated toolkit. Start with these:

• Strategy on a page. Summarise the organisation’s goals, priorities and measures in one view.
• SWOT or PESTLE analysis. Understand internal strengths and weaknesses and external pressures.
• Business model canvas. See how the organisation creates and delivers value.
• Business need statement. Write one clear sentence: “We need to [outcome] so that [strategic benefit], measured by [indicator].”
• Line of sight. Trace every initiative back to a strategic objective. If you can’t, ask why it exists.

Pro tip: If a project can’t answer “which strategic goal does this support?”, pause and find out before going further.

Common Pitfalls to Avoid

• Accepting the solution as the problem. “We need a new system” is rarely a business need. Learning to separate symptoms from causes is a core problem-solving skill, which I cover in article how to use neuroscience to effectively sole problems.
• Ignoring the bigger picture. A great solution to a low-priority problem is still low value.
• Skipping success measures. If you can’t measure it, you can’t prove it worked.
• Treating strategy as someone else’s job. Every BA can influence strategic alignment.

Final Thoughts: Start With Why

Strategy gives your analysis purpose. When you understand the organisation’s direction, you make better decisions, ask better questions and earn a seat at the table where outcomes are shaped.

This is the foundation of the end-to-end BA mindset: moving beyond requirements to focus on value from the very beginning.

So, I’ll leave you with one question:

👉 Can you explain how your current project supports your organisation’s strategy?

Thanks for Reading!

Want to go deeper? Watch Part 2: From the BA Role to Strategic Thinking video, where I explain how to move beyond requirements and think strategically as a BA.

This article is the first in a series based on my end-to-end business analysis masterclass, which covers the full journey from strategy to measurable outcomes. You can also explore more in my book, The Art of Getting Business Analysis Right

Sources / Further Reading

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), especially the Strategy Analysis knowledge area
• Strategyzer, Business Model Canvas
• Victorian Government, Victorian Energy Upgrades (VEU) Program
• The Art of Getting Business Analysis Right
• Leaders Guide to Building Resilient Teams Thorugh Problem-Solving
• How to Use Neroscience to Effectively Solve Problems
• How to Improve Your Problem-Solving Skills Using Well Researched Neuroplasticity Techniques to Rewire Your Brain

If you’d like to explore more about business analysis strategy, courses, mentoring and coaching, visit mariamontgomery.com.au.

Understanding Business Strategy: Why Great BAs Start Before the Requirements was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

People are leaving.

You can see it in the turnover numbers, and you hear about it when you talk to managers. The people who stayed are stretched thin, and recruiting is taking up more time than it used to.

You know something has to change, and you feel like it’s on you to change it quickly. So you start looking at solutions. Better pay? More flexibility? Better manager training? More opportunities for career development? A new engagement program?

Any of these could be the right move, as long as it addresses the reason people are actually leaving. That’s the catch. High turnover tells you something is happening in your organization, but it doesn’t tell you why. And if you act on the wrong explanation, you can spend a lot of time, money, and employee goodwill fixing something that was never the problem in the first place.

It’s also unsettling not to know. You have theories, your managers have theories, and so does everyone else you speak to, but nothing you’ve seen really explains it. That’s a hard place to make decisions from.

So before you ask, “How do we improve retention?”, try asking this instead: Do we actually understand why our people are leaving?

Leaders often see the problem differently than the employees who walk out the door. And the reasons people give for leaving can change over time. National studies and benchmarks are useful for generating hypotheses and giving you context, but they can’t explain what’s going on inside your particular organization. Knowing why people leave jobs in general doesn’t tell you why your people are leaving.

Search for reasons employees quit and you’ll find a long list: workload, management issues, better pay and benefits elsewhere, limited growth, better work-life balance, lack of recognition, culture problems, and tense relationships with leaders. Decades of research on employee turnover confirm that many factors can influence whether people stay or leave.

But knowing the possible reasons doesn’t tell you which ones matter in your organization. Pay might be part of the problem. So might employees’ relationships with their managers, their workloads, or their opportunities for advancement. It could be some combination of these.

And the reasons might differ across your organization. A study of nearly 25,000 employees found that what made people want to stay varied across employee groups. What matters in one department or role may not matter as much in another. That’s why a good retention strategy doesn’t start by trying to fix every possible cause. It starts by working out what you need to understand.

What’s beneath the turnover you can see?

When someone decides to leave, it’s usually related to how they perceive the work itself, relationships with managers and coworkers, how the organization runs, changes they’ve experienced along the way, the level of trust, and whether they feel all of these things align with their expectations. Sometimes it has nothing to do with work at all.

All of these things above interact with each other. A heavy workload feels different when you also feel unsupported by your manager. A change in responsibilities hits harder when you already feel stuck. A concern about pay might be about more than compensation when employees also feel leadership doesn’t value their contributions.

Personal circumstances count too: a change in career goals, family needs, health, a move, a new stage of life. Not every departure is the organization’s doing, and not every departure can or should be prevented.

What looks like a resignation is often just the last visible moment in a much longer story. Your job isn’t to guess which story you’re looking at. It’s to actually find out.

I know how hard that can be when your data only tells part of the story. Employee experiences are complex, organizational problems rarely have a single cause, and the most important perspectives aren’t always the easiest ones to hear. My background in organizational and qualitative research taught me how to make sense of that complexity, without rushing toward a quick fix. My role is to help leaders ask the right questions, hear perspectives they may be missing, and spot the patterns that explain what’s happening and why. And you can start doing that before you collect any more data.

Before you try to fix your turnover issue, separate what you know from what you’re assuming

When you’re trying to explain a problem at work, it’s easy to blur together what you know, what you think, and what you’re simply assuming. A good first step is to pull them apart. Take what you currently believe about your turnover and sort it out into four buckets.

We know. What does the evidence actually establish? Maybe your data shows voluntary turnover went up over the past year, with the biggest jumps in two departments.

We think. How are you interpreting that evidence? Maybe you think working conditions in those two departments are contributing. That’s a hypothesis. It could be right, but you don’t have enough evidence yet to call it a finding.

We’re assuming. What are you treating as true without good evidence to back it up? Maybe the word from leadership is that people can’t be leaving for better salaries elsewhere because we think our compensation is competitive. It sounds plausible and it might even be true, but has anything you’ve collected actually shown that?

We don’t yet understand. What can’t your current evidence tell you? You might not know how employee experiences differ across teams, when people first started thinking about leaving, which experiences weighed most in their decisions, or whether the same things are driving departures in different parts of the organization.

Put together, it might look like this:

• We know: Voluntary turnover rose overall, with the biggest increases in two departments.
• We think: Working conditions in those departments may be contributing.
• We’re assuming: Compensation isn’t a major factor because our salaries are competitive.
• We don’t yet understand: What led people to start thinking about leaving, whether employee experiences differ across teams, and which experiences matter most.

Now you can see how a slice of information about your organization can point you to a problem without explaining why it’s happening.

Check out the evidence you already have before you collect more

Once you know what you’re trying to understand, the next urge is usually to go gather more data. Hold off for a minute. You may already have more than you realize.

That could include information from: exit interviews; engagement surveys; open-ended survey comments; turnover broken out by role, team, or tenure; absence patterns; employee relations issues; manager observations; stay interviews; performance information; findings from earlier consulting work, or just the informal feedback people have been giving you.

The useful question isn’t whether you have data. It’s what that data can and can’t tell you.

Some of it may be enough to support a few conclusions. Some of it will contain gaps. Maybe your exit interviews mention pay a lot, but don’t tell you when pay became an issue or what else was going on at the time. Maybe your engagement survey shows low trust in one department, but not what experiences led to it. Maybe your numbers show first-year employees leaving at a much higher rate than others, but say nothing about what their first year is actually like.

Those gaps show you where to look next.

Turn your turnover problem into a question you can investigate

Most organizations start with a question like “How do we reduce turnover?” The trouble is that this question already jumps ahead to the fix. Step back first and ask: What experiences and conditions are influencing people’s decisions to stay or leave?

Then use what you already know to narrow it down. For example:

• What experiences are influencing first-year employees’ decisions to leave?
• How do people in Department X experience workload, management support, and opportunities to advance?
• What changed in employees’ experiences around the time voluntary turnover started climbing?

Questions like these move you away from picking a solution and toward understanding the conditions that need your attention. Once you have a question you can investigate, it’s much easier to decide what evidence will help you answer it.

Let understanding guide your retention strategy

None of this means the usual retention strategies are wrong. Career development might be exactly what your people need. So might manager training, a change in pay, or a redesigned workflow. Or your investigation might turn up something leadership hasn’t thought of at all.

The difference is how you get there. Research on employee retention shows why context matters: turnover has multiple contributing factors, and a strategy that works in one organization may not address what’s driving people to leave in another. Rather than choosing from a list of retention best practices, you’re deciding what to act on based on what you’ve learned about your own organization.

At Inquiry Practice, I think about this process in four steps: Listen → Investigate → Understand → Move forward.

Listen to what the evidence and employees are telling you. Investigate the questions your current information can’t answer. Understand the patterns and conditions shaping what you’re seeing. Then move forward with action grounded in what you’ve learned.

The goal is certainly not to put off action indefinitely. It’s to make sure the action you take actually goes after what’s causing the problem.

When you understand what is actually shaping turnover, the choices in front of you become clearer. You can focus your organization’s resources where they have the best chance of making a difference. And you can clearly explain to employees why these are the right solutions.

Before you ask “How do we keep people?,” ask “What are we trying to understand?”

High turnover deserves your attention, but dealing with an urgent issue doesn’t require you to guess. You can start by separating what you know from what you’re assuming, looking at the evidence you already have, and naming the questions that evidence can’t answer.

You might find that pay matters. Or management, or workload, or career development. You might find that people from different departments are leaving for different combinations of reasons. And when turnover is one of several problems competing for your attention, deciding where to focus first becomes part of the challenge.

You don’t need to know the answer now. You just need to know what you’re trying to understand. From there you can investigate the right questions and choose retention solutions based on evidence about your organization rather than assumptions about why people leave.

High turnover tells us employees are leaving. It doesn’t tell us why.

Not sure what you actually understand about your turnover problem?

What Are You Trying to Understand? is a free practical guide to help you separate evidence from assumptions, see what your existing information can and can’t tell you, and turn an organizational problem into a question you can investigate.

Originally published at https://www.inquirypractice.co on October 2, 2026.

High employee turnover is a symptom. Here’s how to figure out what’s behind it. was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

“If you adopt only one agile practice let it be retrospectives. Everything else will follow” Woody Zuill

First, the prime directive

Before we go anywhere, I want to start with Norman L. Kerth’s Prime Directive for retrospectives, I am a BIG fan of this…. In basics it asks us to believe that everyone did the best job they could, given what they knew, their skills, the resources available and the situation they were in.

Now, keep that in the back pocket of your brain please as we go through this, because retros can bring out the very best and occasionally (maybe more than occasionally) the very worst in us. If we’re going to reflect on what went wrong, we need to leave the blame at the door. Even Darth Vader, who I feel would have liked the term ‘Prime Directive’ might have benefited from a retro or two, although I suspect the Death Star team had a few issues with psychological safety….

For anyone unfamiliar with agile, a retrospective (retro) is a regular opportunity for a team to reflect on how they’ve worked together, what they’ve learnt and what they might change. They’re often held at the end of a sprint or project, but reflection doesn’t need to wait until the end…. In fact it shouldn’t because as I seem to say repeatedly at the moment ‘Reflection is a skill’ it helps us learn, self-correct, master our roles, and along with a million other things, feeds directly into stronger team performance.

OK back to retros

I’ve facilitated and participated in retros that have been glorious, cathartic learning experiences, where I feel we left understanding each other and our work a little better. I’ve also sat through the icy silences, fixed grins, fake-positive Post-its and the collective agreement that everything is GREAT! REALLLLLLLY GREAT

Dear reader, it was not great…. and it did not get better.

So I asked my beautiful brainy LinkedIn network about their best retros, what made them work and what they’d learnt along the way.

The good: When people feel heard and something actually changes

Vishal Bakshi shared a simple approach. Everyone independently suggests topics, the group votes on what needs discussing now, later or perhaps not at all, and the team works through the priorities together. Vishal also described post-mortems that separate fixing problems from sharing learning across the wider organisation.

IMO I like this because giving people a say in what gets discussed gives them some control and ownership over the conversation, making them more likely to engage in it.

Keith Office talked about capturing wins, frustrations and blockers as they happen, rather than expecting everyone to remember everything at the end. He also emphasised inclusive facilitation, allowing a second session when needed, and leaving with one or two experiments that have clear owners.

I love this, I really feel e often put enormous pressure on a single retro, like a stiletto on ice trying to resolve everything, everywhere all at once…. Sometimes the most useful thing is to identify one small change, try it and see what happens. Little and often, building those muscles of reflection and learning.

The bad: When the format becomes the focus

Amy Hart shared some lovely examples of playful retros, including decorating conkers to represent how people felt and asking what flavour of ice cream they’d be. She also shared a Coronation Street-themed retro that didn’t quite land with everyone, a useful reminder that cultural references aren’t always shared.

Neil Vass recommended a gameshow format he’d learnt from Stephen Mounsey, where people guess how colleagues might answer questions. A playful way to explore how others experience working in the same team.

I’m a fan of a bit of silliness at the right moment, and these both keep it simple, a bit like a lot of ‘fun retros’ Sometimes we need reminding that we’re just fleshy little squirrels hurtling through space on a rock, and perhaps we can loosen our grip on things for a moment. Play can help people relax, connect and see things differently.

But Ali Hanbury made an ace point….. DO keep it simple and build the trust. My take is that the container should be simple enough for the thinking inside it to become complex. If people are spending their energy figuring out the activity, we’re losing the space for reflection…. Did I mention reflection is a valuable skill? …. Good good remember that my lovelies

Echoing this Amy also rightly reminded us, know your audience. UCD them, whose in the room and deliberately design it round their needs rather than throwing ‘Stop Start, Continue’ at them for the 100th time (SSC has its place, no hate)

OH AND….. Amy and Anna Dahlström Williams mentioned snacks, or a fancier version the Swedish tradition of fika, but yep, if in perso….. snacks. Never underestimate good snacks.

The ugly: When everyone knows something is wrong but nobody says it

Charlie Fountaine questioned whether retros can sometimes be the worst possible environment for difficult conversations. If a team is already struggling, asking everyone to open up in a large online meeting, staring at a Mural board, can feel pretty awful.

I agree. I’ve seen it, the harder the conversation needs to be, the more tempting it becomes to avoid it, but TBH thats the very reason it needs to happen…. the very teams that might benefit most can find themselves trapped in a cycle of surface-level positivity, its designing a retro to break the cycle, bravely and deliberately as a DM/Lead or facilitator

Ray Newman emphasised the importance of leadership modelling openness and rewarding people for speaking up rather than punishing them. Richard S. argued that culture will trump format….. Ali Hambury pointed out “It’s not everyone’s comfort zone and takes some real time and energy to create a safer space, sometimes years. Even in small teams. “ tho not all teams these days are together for years….

All true….. BUT I also think the retro itself can help build that culture, we can microdose discomfort (yep you know I love this), gradually nudging the team towards more honest conversations. The facilitator/DM/Lead has a responsibility to hold that space sit with the silence/tension and help people explore what’s underneath the polite agreement, ask the hard whys

I’ve experienced a rather fractious retro where I disagreed with someone quite strongly, we managed to have a respectful disagreement, and afterwards I found I actually trusted them more, I was very meh about them before, simply as we had not really worked massively together in the team and were remote… I liked that they were honest, there I felt I knew they’d tell me the truth (they did). Patrick Lencioni’s work on trust and productive conflict comes to mind here. Sometimes I feel working through disagreement helps us build trust. INVERTTTTT that triangle life is complex and things do not always follow the order of diagrams

Of course, we need to be careful, discomfort can be useful, but pushing people into conversations they’re not ready for can do damage, thats not the aim here. This is where facilitation, care, empathy and understanding the people in the room really matters.

So, what the hell makes a good retro?

Esther Derby and Diana Larsen, authors of Agile Retrospectives, have long championed creating the conditions for teams to reflect, learn and improve together. Their approach includes setting the stage, gathering data, generating insights, deciding what to do and closing the retrospective, a useful reminder that the conversation needs both care and direction.

Across all these contributions, a few things have swirled in my head brewing like a good yorkshire tea….. None groundbreaking, all important

• keep the structure simple
• design it deliberately for needs of the room
• make participation possible for everyone
• create opportunities for honesty
• pay attention to what isn’t being said
• make sure something happens afterwards.

PLUS remember that reflection has a human purpose too. Susan Wheelan’s work on group development, alongside Tuckman’s adjourning stage, reminds me how important it can be to acknowledge what a team has experienced together. Sometimes a retro gives people permission to make sense of something, recognise each other’s experiences and move on.

One last thing, finishing where I started, with the Prime Directive. No one really mentioned setting the rules or guidelines for the room. Boxers don’t enter a fight without knowing that low blows aren’t allowed, and while I don’t want a fight, I do feel that agreeing a few boundaries, loud and clear, helps get minds and hearts in the right place before you start.

Next time: Getting our hands involved

I’ve also been talking to Francesca (Chess) Marsh and Sarah Norman about more hands-on approaches to reflection, and I’m hoping to pick the brains of Scott Drayton and Eva O’Brien too.

In the next post, I want to explore what makes a genuinely good retro, including how drawing, making, moving and embodied cognition can help us see things differently, get beyond the Post-its and perhaps have conversations we wouldn’t otherwise have.

Because getting from arghhhhh to ahhhhh takes work…. and sometimes the most valuable bit happens right in the middle of the groan zone.

A huge thank you to everyone who shared their experiences.
More to come.

Ray Newman — CGI — Director of Content Design ( Ray Newman )
Ali Hanbury PHD — Adnodd Head of Strategic Engagement and Communication ( Ali Hanbury )
Charlie Fountaine — Service Designer ( Charlie Fountaine )
Amy Hart — Developer Auto Trader
Vishal Bakshi — Data and Machine Learning Consultant
Anna Dahlström Williams — Author Founder Fika (Anna Dahlström )
Kieth Office — Delivery Manager TPXimpact
Neil Vass — Deliver Sessions Meet Up Co Organiser ( Neil Vass )
Richard S — Learning Manager KPMG
Harry Bailey — Grow Inc, Agency Delivery Specialist ( Harry Bailey )

Retros…. The good the bad and… yep you guessed it, those ugly ones was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since Salesforce days, traditional enterprise SaaS software has done the opposite. It charged you for the seats regardless of how much you actually used them. A company paid for 500 licenses or seats for its 500 employees, whether 50 employees logged in daily or 490 did. The model was simple, predictable, and deeply disconnected from value.

Let’s start with the electricity analogy. When a utility company bills you, it does not charge you for the number of appliances plugged into your wall. It charges you for the kilowatt-hours you actually consumed. It does not matter whether you own two lamps or twenty. What matters is how much electricity was used.

The shift to token-based pricing is the software industry’s version of switching to the electricity model. It is not a feature update. It is a fundamental reimagining of what the unit of value actually is.

It is a huge paradigm shift!

What Is a Token?

A token is a chunk or fragment of text that a large language model processes. Additionally, input and output tokens are both billed at different rates.

• The word “unbelievable” is one token.
• The phrase “the quick brown fox” has four tokens.
• A paragraph of business writing contains roughly 100 to 150 tokens.
• A detailed legal contract might contain 40,000.

When you ask Claude to analyze a contract or ask ChatGPT to write a marketing brief, input tokens: the AI model processes every word you send, and output tokens: generates every word it returns. Both cost money.

Real, variable, infrastructure money that scales directly with how much you use. This is the economic reality that makes the seat-based model almost impossible to survive and even sustain in an AI-first world.

The Seat-based Model’s Flaw in an AI World

Under seat-based pricing, the SaaS vendor’s cost of serving a customer is essentially fixed. One more user logging into Salesforce costs Salesforce almost nothing. The marginal cost of software delivery in the SaaS era was, for practical purposes, zero.

AI destroyed that assumption.

When a power user executes 1,000 AI queries per day, generating thousands of tokens of processing, and a light user runs only ten queries per week, the infrastructure cost of serving those two users differs by a factor of 100. Yet under seat-based pricing, both users pay exactly the same monthly fee.

As you can see, from a SaaS vendor perspective, it is a losing proposition as more and more users are using AI at work and becoming power users, and therefore the shift is inevitable and more of a survival strategy for traditional SaaS vendors.

Interestingly, none of the top traditional SaaS vendors bills customers in raw tokens the way Anthropic and OpenAI do. Most of them have moved AI onto metered units, but they wrap tokens in their own credit or action currency.

Only Salesforce references a token count at all, as a size threshold inside its action price. AI Billing units are Flex Credits, 20 credits ($0.10) per action, and an action covers up to 10,000 tokens.

It is a unit economics problem. And it is why the most important AI-native companies are abandoning the seat-based pricing model.

The direction is consistent. Seats-based pricing survives as a base, and the accelerated growth is in metered usage.

The seat-to-token transition in the last 12 months.

Business Glance at the top three token companies:

1. Anthropic: Extremely high NRR reported in S1.

• Revenue: $16.3 billion in the first half of 2026, versus $1.2 billion in the first half of 2025. Q2 2026 alone was $11.6 billion.
• Net revenue retention: approximately 900% as of September 30, 2026.
• Pricing direction: the risk factors warn of a possible move toward outcome-based or task-based pricing as agentic products become more compute-intensive.
• Current Claude API prices per million tokens (input / output):
• Fable 5.1 at $10 input / $50 output,
• Opus 5.5 at $4 input / $20 output,
• Sonnet 5.5 at $2 input / $10 output,
• Haiku 4.5 at $1 input / $5 output.

2. OpenAI: large incumbent base

• Revenue: about $13.1 billion recognized in 2025. Annualized revenue was around $20 billion at year-end, approaching $50 billion by late September.
• IPO: Filed confidentially in June 2026, but Sam Altman has reportedly ruled out a 2026 listing.
• Latest models (October 5, 2026), per million tokens:
• GPT-6 Astra at $10 input / $50 output,
• GPT-6.1 Sol at $2 input / $10 output,
• GPT-6 Luna at $0.10 input / $0.50 output.

3. One more token-priced player: Google Gemini

Gemini is priced per token like the others. Google made its Pro models paid-only from April 1, 2026.

• Gemini 3.1 Pro is listed at around $2 input / $12 output per million tokens, with cheaper Flash and Flash-Lite tiers and batch discounts of about 50%.

Token price convergence is happening:

• At the middle tier: Sonnet 5.5 and GPT-6.1 Sol are both $2 input / $10 output.
• At the top tier: Fable 5.1 and GPT-6 Astra are both $10 input / $50 output.
• Prices have converged, and they keep falling. Opus 5.5 is the first Opus model priced below $5 input / $25 output.

The token-based pricing continues to be a strategic and tricky problem; when the unit price drops and competitors match it within days, it is really hard to build sustainable differentiation on it. AI-native vendors respond by cutting cost per task so customers consume more.

An evolution to outcome-based/task-based pricing is waiting around the corner!

Touched on this topic using Intercom and Zendesk as examples in my post: From Seats to Tokens: The SaaS Pricing Playbook Is Being Revised

Key Takeaways:

1. A token is the unit of AI work, and it carries real cost to the AI-native vendor every time it is used.
2. Seats are surviving as a base and not as the growth engine. The traditional SaaS leaders are lagging behind, and the AI-native vendors have moved the expansion lever to metered usage.
3. Token-based AI-native companies can grow extraordinarily fast, with much higher NRR even compared to the consumption-based companies such as Databricks.

What is a Token and Why Token-based Pricing is Replacing “Seat-based”? was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

At school, when I was 18, I wrote an analysis of one of Bertolt Brecht’s plays, and in working on it I made the acquaintance of his use of Verfremdung — making the familiar strange — and of dialectics. Both are techniques for getting an audience to relate critically to the action on stage and to believe that the world can be changed. The point of Verfremdung is to render the familiar strange by means of unconventional effects; dialectics is a method in which contradictions are laid bare, so that we can explore what happens in the field of tension between them. At the time, I hadn’t the faintest idea that these two notions would come to matter to me many years later, in my day-to-day work with digital transformation as a business analyst and product owner.

In the spring I was in Japan with my family, and we had booked a full-day excursion by bus, guide included. The group had settled into their seats, departure was two minutes away, and two passengers were missing. “We don’t wait for people who arrive late,” the guide announced in a tone that brooked no discussion. Fortunately, they made it. The guide looked after his group well — as long as they stayed within the constraints he had set: constraints not in the sense of limits, but in the sense of what allows a group of strangers spend a good day together. He made sure everyone sat with their own family at lunch, checked that everyone knew when the bus was leaving and was aboard before it did, saw to it that we knew where to find him while we wandered around the museum, and kept the group from spilling too generously across the pavement and becoming a nuisance to others. And even as all this was managed with a firm hand, I also noticed that if you were part of the group, you were seen and you were heard. I had heard about Japanese collectivism and wondered whether that was what I was experiencing. In my corner of the world, collectivism is often taken to be a limit on free will, but that wasn’t quite how it felt to me.

Back at the office in Copenhagen, our union representative had called the staff in my department to a meeting about the forthcoming negotiations to renew our collective agreement. A little while earlier she had sent round a questionnaire to map out what mattered to people, so it could be carried into the negotiations; and on this late afternoon, in the meeting room on the fourth floor, she wanted to hear our department’s view of the questionnaire results. That would serve as input to a consolidated negotiating position. I knew the routine, having been through it before. The negotiations with management would get under way, and would most likely drag on a bit, but they would arrive at a result that the union representative would recommend we vote yes to. We would hold a general meeting, where she would highlight what we had won, and add that it wasn’t perfect, but that it could have been considerably worse. Some would think it a terrible deal; most would think it perfectly fine. When it went out to a vote with five working days to respond, the majority would end up voting for it, and it would be adopted. As for me, I would follow the union representative’s recommendation, trusting that she had done her best under the circumstances. Just as on our day trip in Japan, everyone in the group was seen and heard — as long as they stayed within the constraints.

So I followed the trail

There was something fundamental I recognised across the two experiences. But I was also aware that a random day’s excursion is a very different thing from situations where something is actually at stake. The visit to Japan was fleeting, and I knew the culture only superficially. And yet: might there be a clue here to a more considered, more collaborative way of approaching digitalisation? In any case, I needed a counterweight to all the breathless headlines I kept seeing — not only on LinkedIn, but also in my old-fashioned paper newspaper — about the revolutionised world of work, the jobs that would disappear, and the demented gains in efficiency. I needed thoughts on how we might digitalise in a way we can ourselves live with over the long run. I knew that agile (via Lean) shares intellectual ancestry with ideas that emerged at Toyota in Japan, and that Design Thinking, which is kin to Participatory Design, grew out of a collaboration with Scandinavian trade unions. So I followed the trail from my two experiences and went back in time to understand the origins of the Toyota Production System and of Participatory Design more deeply. Could these two traditions — born in wildly different environments on opposite sides of the earth — have something in common that might tell us how to get past the cliché and actually digitalise with people as the starting point? I watched Pelle Ehn’s lectures from 2018 on the history of Participatory Design: Design, Democracy and Participation: Exploring the Scandinavian Participatory Design Tradition. And I read the first two chapters of The Birth of Lean, where Taiichi Ohno and Michikazu Tanaka recount the development of the Toyota Production System. What follows is based on those two sources.

The Toyota Production System: kaizen as an answer to post-war scarcity

At Toyota’s factories after the Second World War, a new way of organising work emerged. Toyota had no choice but to fundamentally change how work was organised in order to produce more cars without expanding the production apparatus or hiring more people. Taiichi Ohno (who worked his way up from engineer to top management) was responsible for what became the Toyota Production System. He implemented kaizen and developed kanban, both of which have been carried forward in, for example, Lean. Kaizen is about small, continuous improvements. And to identify possible improvements, you have to observe how the work is actually done and talk with the people who do it. They are the ones who can put their finger on the heart of a problem, and who therefore have the insight needed to propose solutions. Alongside the reduction of waste, quality is utterly central to Ohno’s approach to production. It is quality in each sub-process that allows the next sub-process to run efficiently too, and that prevents work flowing backwards. It makes for a quality product, and in the long run that is what leads to improvements in productivity. The foundation for improvement is transparency about how the work is carried out, and standardisation of it. That is how problems become visible.

Participatory Design: when the workers shape the technology

Pelle Ehn researches Participatory Design and is among other things known for his contribution to the UTOPIA project in the 1980s, which developed a computer program for graphic designers. Participatory Design is rooted in Scandinavia and in the 1970s ideas about workplace democracy — the notion that workers should contribute to the decision-making process at their workplace, which would thereby be democratised. The trade unions realised that they had to involve themselves in how new technology was designed, in order to ensure that it led not only to greater efficiency but also to benefit for the people working with it. They entered into this work actively, because they wanted technology to be used in a way that amplified the workers’ skills rather than stripping them away. This democratisation, the designers wanted to build into the design process itself, as the processes of the workplace were being automated and digitalised.

he practitioners of Participatory Design worked from the principle that the design should take as its starting point the the existing professional tradition. That could only be done by observing the work and involving the workers. They focused on designing IT systems that supported products of high quality, because quality in the product and quality in working life are bound together.

You may object that the changes we face today are completely different and cut far deeper into the way we organise work than ever before. To that I would draw your attention to the fact that the pioneers of Participatory Design designed together with people who had never used a computer. They didn’t know what a mouse was. Close your eyes for a moment and imagine what a radical change that must have been.

If Ohno and Ehn had met…

Suppose we imagine that Ohno and Ehn had actually met — how might it have gone? What if one could invite them to Västra Hamnen in Malmö, Sweden on a long, light midsummer evening, with nobody in a hurry? On their little stroll around the district, they would have passed the small boats in the packed marina. Ohno would have remarked how a crew in many ways practises kaizen on its journey. And Ehn would have followed up with the observation that a journey by boat is in many ways like a design process that can never quite be predicted, where you have to adapt as you go. They would have found somewhere to eat where they could get matjes with new potatoes, dill and crème fraîche. Over the meal, they would have had plenty of time to tell each other about their experiences and the thinking behind them. Sadly, it would not have been possible to invite either a worker from Toyota or a member of the graphic designers’ union, since my sources contain no first-hand accounts. But Ohno and Ehn would have talked their way to agreement on the importance of firm constraints for innovation, transparency about the work, observation of the work, and participation from the workers. They would also have agreed on quality as a virtue. That despite the fact that Ohno’s work sprang from the post-war scarcity of the factory floor, while Ehn’s sprang from the welfare state’s growing prosperity among educated specialists. But the differences would also have stood out plainly. Ohno’s starting point was efficiency to secure the company’s survival, even if a good working environment is a precondition for employees being able to contribute to kaizen. Ehn’s starting point, by contrast, was a meaningful and sustainable working life, even if efficiency gains would have been a welcome side effect. I don’t imagine this meeting would end in any new, shared insight; rather, they would have appreciated getting to know each other’s perspectives better, and their own work would have stood out more sharply for them through this new prism. In my optimistic fantasy, they would agree that quality was the place where their starting points met.

What if the conversation began with quality?

There is, precisely, a dialectical relationship between efficiency gains and meaningful work. I see it often in my work with digital transformation. And like Brecht, I wish we dared to put that relationship into words and see what turns up in the field of tension between them. Perhaps that is exactly what is needed for us actually to begin talking about which qualities the digitalisation initiatives we set in motion are meant to bring forth — instead of starting with minutes saved, full-time equivalents, or job titles. That is what is needed for the conversation to become about what we would like to create, rather than what we don’t want. For that is precisely where the users’ professional expertise becomes indispensable, and there is no alternative but to involve their professional capacities from the moment the initiative’s first headline is written.

To think that a trip to the other side of the earth had the Verfremdung effect that set this whole story in motion.

Ohno and Ehn: Constraints for innovation, and quality as a virtue was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most people have promised a report by Friday and delivered it the following Wednesday. The pattern is common enough that psychologists gave it a name: the planning fallacy.

What the research found

Daniel Kahneman and Amos Tversky described the planning fallacy in 1979. A later study by Roger Buehler, Dale Griffin and Michael Ross, Exploring the Planning Fallacy, asked university students how long they would take to finish their senior thesis. The students estimated about 34 days on average. They actually took about 56 days, and only around 30 percent finished within their own estimate.

Why it happens

When people plan, they tend to picture the project going well. They imagine the steps in order and rarely imagine the delays, the interruptions or the day they feel unwell. Kahneman calls this the inside view, a forecast built from the details of your own plan.

The alternative is the outside view, which asks how long similar projects have taken for other people. The outside view is less flattering and usually more accurate.

What it looks like in practice

The fallacy shows up in large projects as well as personal ones. The Sydney Opera House was scheduled to open in 1963 and opened in 1973. Software releases, home renovations and public infrastructure often run late in the same way, and the people involved were rarely careless. Each estimate looked reasonable when it was made.

Here is a small example. Suppose you estimate a report at four hours, and your last three reports took six, five and seven hours. The outside view says to plan for about six. If you break the report into outline, draft, edit and formatting and estimate each step, you will probably land close to the same number.

How to estimate better

Start with the outside view. Before you estimate a task, look up how long comparable tasks took, whether in your own records or in the experience of colleagues, and treat that number as your starting point.

Break the project into smaller pieces and estimate each one. Research on this tends to show that listing the steps surfaces work you would otherwise forget, which reduces the underestimate.

Track the real time for a few weeks. Write down your estimate before you start a task and the actual time when you finish. After a month you will have your own correction factor, for example if your tasks usually take half again as long as you expect.

Add a buffer that matches that factor, and tell stakeholders about it. A buffer you plan for is cheaper than a deadline you miss.

Avoiding the opposite mistake

It is tempting to respond by padding every estimate. Padding without information can backfire, because work tends to expand to fill the time available, an observation known as Parkinson’s law. A buffer works best when it comes from your own tracked data rather than a flat guess, and when you review it every few months to see whether your correction factor has changed.

Teams can apply the same idea. Before a planning meeting, ask each person to estimate alone and in writing, then compare the numbers. Disagreements usually point to hidden assumptions, such as who reviews the work or which approvals are needed. Surfacing those assumptions early is often worth more than the estimate itself.

The goal is not perfect prediction. It is a plan you can trust enough to build commitments on, so that other people can rely on the dates you give them.

Pick one task you are about to start, write down your estimate, and compare it with the real time afterward.

The Planning Fallacy: Why Projects Take Longer Than You Expect was originally published in Analyst’s corner on Medium, where people are continuing the conversation by highlighting and responding to this story.