Applications… Organised

About This Edition

You’re listening to Applications… Organised: Guide. It’s the audiobook and ebook edition for leaders, and it’s written to be listened to in under an hour.

Here’s how the editions fit together. Applications… Organised is one book in a series. Each book in the series is published three ways. The Full edition is an ebook with everything: the evidence, the reasoning, the method in depth and the case studies. This Guide is the short route. Its job is to set you up to run your own Todoist project for this change, and to lead your people through it. The Support edition is for the people who support you. It takes under ten minutes, and I’ll tell you later how to share it.

If you’re reading rather than listening, everything here works the same way. The sentences are short on purpose, because they were written for the ear.

Why This Matters

What This Change Is

Let me start with an image to hold onto. A King, on a chessboard, looks powerful. It sits at the centre of the action. Every other piece seems to defer to it. But the King can only move one square at a time. Its power isn’t really its own. It’s built entirely out of the pieces arranged around it.

Keep that image close, because it describes your applications.

Somewhere in your organisation there’s a dominant tool. It might be a suite, a platform, a brand name that everyone uses as if it were the name of the whole category. It looks powerful. It sits at the centre. Every other option seems to defer to it. And its power comes less from what it does than from the way everything has been arranged around it.

This book calls that the Application Dominance Effect. It’s the tendency for the first or most prominent application of something to take over an entire category in people’s minds. The dominant tool doesn’t just win the decision. It deletes the other options from the process. People stop asking whether something else would do the job better, because the question has stopped occurring to them.

Here’s the part I’d like you to hear clearly. Nobody is at fault. This is what happens to sensible people when one path through the work is easy and every other path is invisible. So this book is generous to individuals, and critical of systems.

Why It Matters

Think about the last time your organisation chose a tool. Was there a real comparison? Or did someone say “we already have that,” and the conversation ended?

If the second one sounds familiar, you’re in good company. And the cost is quiet. It shows up as a spreadsheet someone keeps because the official system can’t do what they need. It shows up as the same record typed in twice. It shows up as a weekly clean-up that nobody questions, and as a modernisation programme that’s confined to the one system everybody already knows.

Each of those costs is small. Together they’re a permanent tax on everyone’s week.

What Being Organised Will Give You

This series has one job. It helps people change so that they become more organised in one area of life. In this book, the area is how your organisation chooses and uses its applications.

Being organised isn’t about tidiness. It’s about having the time, calm and confidence to lead your own work, and to bring other people with you.

For you, as the leader, that means six things.

First, less mental load. Everything is captured in one place, so nothing important lives only in your head.

Second, clear priorities. You can see what matters now and what can wait.

Third, time back. There’s less duplication, less chasing and less last-minute scrambling.

Fourth, easier delegation. Tasks can be shared with the right people, with clear expectations.

Fifth, visible progress. You can see what’s working, and that keeps motivation up.

And sixth, change that sticks. A system keeps going when willpower runs out.

For the people around you, the colleagues and team members affected by the move to fewer, better-used applications, being organised gives them five things. They get clarity: they know what’s expected of them, and by when. They get fewer surprises. They get an easy way to contribute, because a shared project shows exactly where they can help. They get less friction, because agreed ways of working replace nagging and repeated arguments. And they get recognition, because their contribution is visible, and so is the difference it makes.

In this subject, that translates into very practical things. You get fewer tools, cleaner data and faster decisions, with real alternatives in view. They do less duplicate entry, they build fewer workarounds, and they have one place to find and record work.

The Method in One Minute

Every book in the series uses the same method, and it’s built from two disciplines.

The first is process mining. It shows what actually happens, by reading the digital traces that work leaves behind: tickets, purchase orders, login records, emails. Instead of asking people how a process works, which gets you the process as they remember it or wish it, you look at what the systems recorded.

The second is organisational change management, which people shorten to OCM. It explains how to move people to something better, once you can see what’s going on.

The core move is always the same. You compare the process people believe they run with the process the evidence shows they run. The gap between the two is where the argument, and the change, lives.

That method has four stages. I call them the four Ds. They are Discovery, Dream, Design and Defend. They adapt a four-stage cycle from an approach called Appreciative Inquiry, developed by David Cooperrider and Diana Whitney. Appreciative Inquiry starts from what’s already working. I’ve kept that spirit, and added process mining to Discovery and change management to Defend. We’ll take them one at a time in a few minutes.

A second set of words, the six Cs, is the shared language for you and the people helping you. We’ll cover those after the four Ds.

One caution, and I’ll repeat it later. Todoist is the command centre in this series, because it keeps the whole project in one place. But the principles work with other apps too. Nothing here depends on one product.

The Goal and the New Identity

What Success Looks Like

Every book in the series sets out a goal, and the identity that goes with it. Here they are for this book.

The goal is this. Your organisation speaks its unspoken alternatives out loud and evaluates them, so modernisation is no longer confined to the current dominant system.

And the new identity is this. The number of applications used is kept to a minimum, optimised for efficiency and effectiveness.

Let me unpack both, because they ask for less than people expect.

Unpacking the Goal

Notice what the goal doesn’t say. It doesn’t say “replace the incumbent.” Sometimes the dominant application is the right one, and a fair evaluation will confirm it.

An unspoken alternative is an option that exists but has no voice in the decision. It isn’t on a shortlist, because there isn’t a shortlist. It hasn’t been rejected, because it hasn’t been considered.

Think of the tool that one team uses happily, and no other team has heard of. Or the product category that never appears in a procurement document, because the dominant brand’s name is used instead. Or the idea that someone raised once in a meeting and was told “we already have that.”

The goal asks for two things. First, that these options are spoken out loud: there’s a place, agreed in advance, where an alternative can be named without having to win an argument first. Second, that they’re evaluated fairly.

An organisation that has looked properly and kept what it has is in a very different position from one that has never looked. The first has made a decision. The second has inherited one.

Unpacking the New Identity

Now the identity. Take it phrase by phrase.

“Kept to a minimum.” That doesn’t mean as few as possible. One application for everything isn’t minimal. It’s overloaded. The minimum is the smallest set that does all the work that matters, and does it well.

“Optimised for efficiency.” That’s about effort. How much work does it take to get a result? Duplicate entry, re-keying and reconciling are all effort that produces no result.

“And effectiveness.” That’s about whether the job actually gets done well. A cheap, fast tool that produces data nobody trusts isn’t an economy.

Why an identity, and not just a target? Because a target for the number of applications invites the wrong behaviour. People merge tools that should stay separate, hide tools that should be counted, and stop raising needs for fear of adding to the number.

An identity works differently. “We’re an organisation that keeps its applications to a minimum, on purpose” becomes a question anyone can ask of any decision. Does this earn its place?

It also gives the people you ask to move on from a familiar tool something to belong to. We’ll come back to why that matters.

One refinement. Say the identity as something your organisation does, in words it owns. Not as a label whose meaning someone else can change. “We’re a such-and-such shop” is a label, and the vendor and the market decide what it means. “We choose our tools on purpose” is a practice, and it’s yours.

Setting Up Your Todoist Project

Why One Place

Now for the practical bit. Everything in this Guide turns into a project you can run. And that project lives in one place.

That single place is the point. A project that lives partly in your head, partly in a document and partly in a chat thread is a project that’s going to lose things. In this series, the one place is Todoist.

New to Todoist?

If you’re new to Todoist, I have a request. I’d really appreciate it if you signed up for Todoist through my affiliate link, which you’ll find on my website, ravi8.com. If my introducing you to Todoist helps you become more organised, using my link helps make all the effort I’ve put into these books worthwhile.

And the disclosure. This is an affiliate link, so I may earn a commission at no extra cost to you.

If you already use Todoist, you can skip straight on. And if your organisation already has a project tool, use that. The method doesn’t care.

One note before we set it up. Todoist changes its features, plans and limits from time to time. That includes what’s on the free plan, how sharing works and which platforms support which extras. I’ve described things as they stood when I wrote this. Check Todoist’s current help pages before you rely on any one feature.

Step One: Create the Project

Create a new Todoist project and call it Organise Applications.

That name is used across the series. Every book has a project called “Organise” followed by its subject, so that they’re easy to find and recognise.

Step Two: Create the Four Stage Tasks

Inside the project, create four tasks. One for each stage of the method.

Discovery. Dream. Design. Defend.

Under each one, you’ll add the tasks I’ll read out in a moment, as sub-tasks. Give each one a due date that fits your plan. Set reminders on the ones that are time-critical.

Don’t worry about remembering them all. The ebook edition lists every task, and the Full edition explains each one in depth. For now, the structure is what matters: four stages, each with its own short list.

Step Three: Add the Modernisation Charter

Under the Discovery task, add a note called the Modernisation Charter. In Todoist, the natural place for a note is a comment on the task, so it stays with the stage it belongs to.

The charter is a one-page statement of what this change is, who’s involved and how it will be run. It’s the single document everyone can refer back to. Give it nine headings.

One, purpose: why are we doing this, in a sentence or two. Two, the goal. Three, the new identity. Four, scope: which categories of application are in, and which are out for now. Five, sponsor and team: who’s accountable, and who’s doing the work. Six, what we will stop doing, to make room. Seven, measures: what will we track. Eight, checkpoints: when will we review, and who will we report to. And nine, the six Cs: how we agree to treat each other while this happens.

Keep it to one page. Its job is clarity, not completeness. You’ll fill it in as you go, and you’ll see in the next sections where each heading gets its answer.

Step Four: Turn On the Habit Tracker

Now, a request I’m making of every reader and listener in this series. Please enable Todoist’s Habit Tracker integration.

Here’s why. A change like this doesn’t fail on the first day. It fails in month three, when the first burst of enthusiasm has gone and nobody is checking. The Habit Tracker turns your check-ins into a visible record. Each time you complete a recurring task, that’s a check-in. The number of check-ins in a row is your streak. And the streak is a quiet, honest signal of whether the change is holding.

According to Todoist’s documentation, here’s how to turn it on. Open Settings. Go to Integrations. Choose Browse. Select Habit Tracker, then add it and confirm. The first time you use it, it asks you to authorise your Todoist account.

To track a task, open the task, open its menu, and choose Track habit.

Two things to know. First, it works with tasks that repeat on a daily or specific recurring schedule, so the tasks you track need to be recurring ones. Second, if a tracked task becomes overdue, or you postpone or reschedule it, the streak starts again. Check Todoist’s help pages for which repeat patterns, platforms and plans it supports, because those can change.

Where does it fit in this book’s process? Mostly in Defend, the fourth stage. That’s where the work moves from a project with an end date to a practice that runs for as long as you want the change to hold. We’ll point out the recurring tasks worth tracking when we get there.

And a gentle word about streaks. A broken streak is information, not failure. It usually means the rhythm is too heavy, or that someone’s overloaded. The right response is to adjust the rhythm, with kindness. That’s the first of the six Cs, and we’ll come to it.

Step Five: Share It Later

You’ll invite your people to the project once you’ve done the first stage. I’ll cover how in the section on leading your people. For now, just create it, name it, and add the four stage tasks.

The Four Ds

How to Use This Section

Now the heart of the Guide. Four short sections, one for each D. In each, I’ll tell you what the stage is for, and then walk through its tasks in plain language.

Each stage has its own list. You’ll add those tasks to your Todoist project as sub-tasks under the stage. Do them in order. Each stage depends on the one before.

Discovery

What It’s For

Discovery is the first working stage. Its job is to find out what actually happens, what already works well, and where it breaks.

You build what process mining calls an event log. That’s just a list of things that happened. Each entry has three pieces of information.

The case: the thing the process is about. In this book, a case is one decision about an application. One need that someone raised, and what happened to it.

The activity: a step that happened to that case. Need raised. Options searched. Shortlist agreed. Default chosen. Workaround built. Tool abandoned.

And the timestamp: when it happened.

That’s the whole structure. A case, an activity, a time. Process-mining software can read a log of that shape from almost any system, and rebuild from it the process as it really ran.

The most interesting thing a log can show you is something that isn’t there. Suppose your policy says a new application must be chosen after comparing options. In the log, you’d expect an activity like “options evaluated”. If most cases go straight from “need raised” to “default chosen”, then the step the policy expects never appears. The dominant tool hasn’t won a contest. It has removed the contest.

A person asked “do you consider alternatives?” will often say yes, and mean it. A log can show the step was recorded in only a small fraction of decisions. Neither person is lying. One is describing intent. The other is describing behaviour.

One point on care. Logs about work involve people. You almost never need to know which individual made a choice, and you shouldn’t go looking. The aim is to understand a process, not to assess a person. Aggregate patterns are enough. Check your organisation’s data-protection rules, and involve the people who own the systems, before you begin.

Here are the twelve Discovery tasks.

The Tasks

One: Note what already works well, and why. Start here, on purpose. Which decisions followed a genuine comparison? Which tools do their job so well nobody thinks about them? Which workarounds work so well they deserve to be made official? A picture of an organisation that contains only its failures is a distorted one, and the people who work there will know it. This also builds trust. People are far more willing to listen to the case for change if their good work has been seen first.

Two: Pull system logs of tool use and purchasing. Gather what the systems already recorded. Purchase orders, tickets, access logs, expense records. You’re not creating new data. You’re collecting the traces that already exist.

Three: Map the approved versus the actual buying process. Draw the process in the policy. Then draw the one the logs show. Where they differ, you’ve found the gap.

Four: Interview users about what they actually reach for. Logs tell you what happened. Conversations tell you why. Ask open questions. What do you use for this job? What did you try first? What’s the thing you wish you could use?

Five: List alternatives never evaluated. Write down the options that exist but never reached a shortlist. Don’t judge them yet. Just list them.

Six: Log every workaround and shadow tool. A shadow process is an informal step or side tool that grows up around a dominant system to fill the gaps it leaves. The spreadsheet kept because the official tool can’t do what someone needs. The email thread where the real decision was made. Nobody builds these out of defiance. They build them because a task needed doing, the approved tool didn’t do it, and the route to a better one was slow or closed. Treat each as a message. It points, quite precisely, at a gap.

Seven: Identify sponsors tied to the incumbent. Almost every application change has a sponsor or two whose careers, reputations or relationships are tied to the system being questioned. They’re often senior and expert. You’ll want to know who they are early, so you can work with them rather than around them.

Eight: Map process variants from the logs. A variant is a distinct route cases take through a process. Most processes have a few routes that carry most of the cases, and a long tail of rare ones.

Nine: Quantify how much flow runs through the default path. This is the number that makes the case. In an organisation where the effect is strong, one variant, the default variant, carries almost everything. It’s short, because it skips the comparison. It’s fast, taking minutes where an alternative takes weeks. And it’s rarely questioned, because it works well enough. A fast, reliable path is a good thing. The problem is when it’s the only path.

Ten: Trace each workaround to the gap it covers. For each shadow tool, ask what the official tool can’t do that made someone build this. Taken together, the answers are a requirements list, written by the people who understand the work best.

Eleven: Confirm which alternatives were never evaluated, and why. Go back to your list from task five. For each, find out whether it was never raised, raised and dismissed, or evaluated against criteria that the incumbent was always going to pass. That last one has a name: conformance theatre. It’s a process that performs the steps without doing the work they stand for. The consultation happens, but its outcome was settled before it began. This is rarely dishonesty. It’s what happens when the incumbent is the default, and the path of least resistance runs through a ceremony that confirms it.

Twelve: Rank conformance gaps by cost and risk. Not every gap matters equally. Rank them. Where is the rework heaviest? Where is the risk highest? That ranking tells you where to start.

A word on two patterns you’ll meet along the way. The first is rework. When a tool is stretched across jobs it wasn’t chosen for, people fill the gap with manual effort. Re-keying. Reconciling. A weekly clean-up. In the log, these show up as loops, and a loop that’s frequent, costly and unplanned is a symptom that the tool doesn’t fit the work.

The second is the operating system problem. The shared, mostly invisible layer of assumptions an organisation runs on is hard to replace, because everything has been built on top of it. When you ask “why won’t they move?”, try asking instead, “what exactly would they be giving up?” Often it’s something the organisation never listed: a habitual way of working, a set of relationships, a sense of competence.

When Discovery Is Done

You’ll know it’s done when you can say, with data, how many decisions skipped a comparison, which workarounds are widespread, which loops are costing time, and which alternatives were never evaluated. You’ll also know what works well and should be protected.

The full detail of Discovery is in Part One of the Full edition.

Dream

What It’s For

Dream says where you’re going, and why it’s worth the effort. It has three parts: the goal and new identity you’ve just heard, the effort it will take and who’s involved, and then communicating all of that to the people it affects.

A change that nobody has been told about is a change nobody can support. So Dream isn’t finished until the people affected have heard it, in words they recognise.

Dream is easier, and more honest, when it starts from what Discovery found working. Go back to your note on what already works well. If a team made a good tool choice, how did they do it, and could others copy the method? If a workaround works well, is it pointing at a gap the organisation should fill properly?

What a Fair Evaluation Looks Like

Since the goal is to evaluate alternatives, it helps to know what a fair evaluation looks like. It has five features.

One, criteria first. Write down what the work needs before any candidate is on the table. Criteria written after the favourite is known tend to describe the favourite.

Two, the same questions for every option, the incumbent included. The incumbent is a candidate, not a baseline.

Three, a small number of real options. Three or four serious candidates is usually enough.

Four, a time limit. A comparison with no end date becomes a reason to do nothing.

And five, a recorded decision, with reasons, including when the answer is “we looked, and what we have is right.” That’s the step that puts the missing activity back into the log.

The Tasks

Here are the seven Dream tasks.

One: Write the new identity in your own words. Take the sentence about keeping the number of applications to a minimum, and make it yours. How would you say it to a colleague? If you can’t say it simply, it isn’t clear enough to share yet.

Two: Define what success looks like in twelve months. Be concrete. Not “better tools” but something you could check. For example: every new application decision includes a recorded comparison, and every application has a named owner.

Three: Estimate the time and budget needed. A dream without a cost is a wish. Estimate the hours for evaluation, pilots and learning, and any money for licences, migration or support. Treat the first figures as ranges, and be honest about the uncertainty. Underestimating the effort is the commonest way for a promising change to lose goodwill in its second month.

Four: Name the sponsor and who else must be involved. Someone must be accountable. Beyond them, name the people whose work will change, the people whose permission you need, and the people who built the workarounds. They understand the gap better than anyone.

Five: Agree what you will stop doing to make room. Nobody has spare hours waiting for a change. If the plan adds work and removes none, it will be quietly abandoned. Decide what goes.

Six: Set checkpoints and how progress will be reported. Agree when you’ll review, what you’ll look at, and who it’s reported to. A date in the diary is the cheapest protection a project has.

Seven: Communicate the dream to sponsors, leaders, affected teams and potential new recruits. Each audience needs something slightly different. Sponsors need to know what you’re asking of them, and what you’re not. Teams need to hear it from you before they hear it indirectly. The people who built the workarounds need to hear that their work is being treated as evidence, not as a breach. And potential recruits need an invitation they’ll want to accept.

A good description of the dream is short and concrete. In short, a good dream reduces ambiguity. After hearing it, a person should be less unsure about what’s changing, what isn’t, what’s asked of them, and what happens next. It says what’s changing in their working week, and what isn’t. It says what you’re asking of them, and by when. And it asks for objections, in the agreed place, early.

Put it in terms of what people gain, as well as what they’re asked to give up. The people who’ll be asked to move on from a familiar tool already know what they’ll lose.

When Dream Is Done

You have a goal, an identity, an estimate of effort, the people involved, a way to communicate it, and a way to tell whether it’s working. The full detail is in Part Two of the Full edition.

Design

What It’s For

Design is where you decide what to do about it. The discipline of this stage is restraint. You’re not redesigning the organisation. You’re choosing the few changes that matter most, and defining what the process should look like once they’re made.

The classic mistake is to copy the incumbent into a new tool. The result is a migration that moves the data and keeps the problem. The new tool is judged against a checklist of the old tool’s features, and succeeds or fails on how closely it resembles what it replaces. Organisations then wonder why a major platform change brought so little benefit.

The remedy is to design from the work, not from the tool. Start with what people are actually trying to achieve, using what Discovery revealed, and describe the process that would serve that, as if no tool existed yet. Only then ask which applications could support it.

The Tasks

Five Design tasks.

One: Define the to-be process with alternatives built in. Describe how the organisation will find, compare, choose, adopt and retire applications, built so alternatives stay visible. It should be easy to raise a need, simple to find out what already exists, quick to compare a small number of real options, and clear who decides. It should also be normal to retire a tool when its job has gone.

Two: Separate beliefs from values about the incumbent. This is an idea from the psychologist Milton Rokeach. A belief is something you hold to be true, and it can be updated by evidence. A value is something you hold to be important, and it changes slowly. When someone says “we’re loyal to this tool”, ask whether they mean a belief, such as “it’s the most reliable”, or a value, such as “we protect our data”. Beliefs can be tested. Values can be honoured by whichever tool you end up with. Separating the two stops a debate about a product turning into a fight about who people are.

Three: Shortlist alternatives worth piloting. From your Discovery list, pick the small number that deserve a real trial. Use the criteria you wrote in Dream.

Four: Choose the few changes with most impact. You’ll be tempted to fix everything. Don’t. Choose the changes that remove the most rework, or close the biggest gaps, for the least disruption.

Five: Set measures of success. Decide how you’ll know it’s working. I’ll give you four measures when we reach Defend. Whatever you pick, write down the numbers and the dates before you start.

One more idea for Design: seeing around corners. Process data doesn’t only describe the past. It can hint at the variant that will matter next: the small group quietly doing something different, the category that’s changing fast. Look for it, and say what you see.

Before You Move On

A design is a proposal until people adopt it. Test it with the people who’ll live with it. Ask them what would make it hard to follow. Their answers tell you where the effort to move people needs to go. The full detail of Design is in Part Three of the Full edition.

Defend

What It’s For

Defend has two jobs. The first is moving people. The second is keeping them moved.

A good design that nobody adopts is a drawing. This is the stage where organisational change management earns its keep, and it’s where most programmes spend almost all of their effort, often before the earlier stages have been done. Done in sequence, it’s easier. You arrive with a clear dream, a log of what happens, evidence of where it breaks, and a design with a small number of changes.

The second job is protecting the change. Left alone, a well-designed process slides back towards the path of least resistance, and that’s nearly always the old default. Physics has a name for the general tendency: entropy. Order takes work to create, and it takes work to keep. Organisations aren’t isolated physical systems, so treat entropy as a metaphor, not a law. But it’s a useful one. A well-chosen set of tools, left alone, drifts away from the work. That’s why the method is a loop, not a line. Defend ends by returning to Discovery.

The Tools for Moving People

Here are the ideas you’ll draw on, in plain terms.

Kotter’s dual operating system. John Kotter argued that organisations facing constant change need two systems running together: the familiar hierarchy that keeps the business running, and a more flexible network of volunteers that finds opportunities and acts on them. The hierarchy tends to defend the incumbent. A network of willing people can run pilots without needing every manager’s permission first.

ADKAR. Jeff Hiatt, who founded Prosci, built this model on a plain premise: organisations don’t change, people do, one at a time. Each person moves through five steps. Awareness of the need. Desire to take part. Knowledge of how to change. Ability to do it. And Reinforcement to sustain it. If someone hasn’t moved, there’s usually a specific step they haven’t reached.

With a dominant application, Awareness is hard, because the old path is frictionless. You can’t become aware of a need with no symptom. So your Discovery data, the workarounds, the loops and the missing comparisons, is how you make the symptoms visible.

Bridges. William Bridges described transitions as having three phases: an ending, a neutral zone, and a new beginning. People have to let go of the old before they can take hold of the new. The neutral zone feels uncomfortable, and that’s normal.

Prochaska and DiClemente. Their model describes readiness for change in stages, from not yet thinking about it, through considering it, preparing, acting and maintaining. It tells you when to push and when to wait.

Motivational Interviewing. Developed by William Miller and Stephen Rollnick, it replaces the urge to correct people with open, curious questions that invite them to think about their own position. People rarely resist their own conclusions the way they resist someone else’s.

And one more thing about identity. Anyone who has led a platform change has heard the sentence, “We’re an X shop.” It’s rarely offered as an argument. It’s offered as a description of who the organisation is. Psychologists describe a related mechanism called identity-protective cognition, associated with the researcher Dan Kahan: people tend to process information in ways that protect their standing in the groups they belong to. The research was about politics and risk, not software, so apply it with some caution. But the lesson for a change leader is useful. If a platform has become part of how a team sees itself, more evidence can harden the position instead of moving it. Lower the identity stakes before you raise the evidential ones. Praise what the incumbent has done. Offer an identity that can survive a change of platform, such as “we’re a team that picks the right tool for the job”.

The Tasks

Ten Defend tasks.

One: Form a guiding coalition beside the hierarchy. Recruit volunteers who believe in the change, ideally from the teams that already felt the gaps. The people who built the workarounds are natural members.

Two: Coach sponsors tied to the incumbent using Motivational Interviewing. Find out what they want. Ask open questions about their experience. “What has made the current system work for you?” “What would need to be true for another option to be worth a look?” Reflect back what you hear. Offer information with permission. And let them reach the conclusion. Not everyone will respond, and that’s fine. Spend your effort where people are ready.

Three: Run ADKAR assessments for affected teams. For each team, ask which of the five steps they’ve reached. It tells you whether they need information, motivation, training or reinforcement.

Four: Pilot one alternative with a willing team. Not a big bang. One alternative, one team, a defined scope, a sponsor and an end date for review. A pilot is the cheapest way to turn an opinion into evidence.

Five: Retire the shadow tools the pilot replaces. This is the point at which many projects quietly fail. If the old route stays open as an easy fallback, the new one has to compete with a frictionless default for ever. Close the old route when the new one is ready.

Six: Set up continuous mining dashboards. The same traces that revealed the problem are still being produced every day. Researchers call the underlying phenomenon concept drift: a process doesn’t stay the same over time, and the changes can be detected in the log. Four measures cover most of what matters. The comparison rate: what share of new decisions included a comparison of more than one real option. The orphan count: how many applications are in use that can’t be traced to a recorded decision. The workaround volume: how many exports, manual updates and re-keying events are appearing. And the default share: what proportion of cases follow the single most common route. What matters is the direction over time, and the thresholds at which you act.

Seven: Define alerts for drift back to the incumbent. Agree the thresholds in advance, and write them down, so a drift triggers a routine response and not a debate.

Eight: Schedule regular re-mining. A practical rhythm is a short monthly look at the four measures, a fuller quarterly re-mining, and an annual refresh of the whole picture. This is where the Habit Tracker earns its place. Make the monthly look a recurring task, and track it. Do the same for the quarterly re-mining, and for a weekly check-in with the pilot team while the pilot runs. Completing each is the check-in. The streak shows whether the rhythm is holding. Drift tends to speed up at particular moments: when a new technology arrives, when a senior sponsor leaves, when a budget is cut, when a crisis demands speed. Plan to look harder, not less, at those times.

Nine: Keep at least one alternative live. The deepest protection is never again to have only one path. Nassim Nicholas Taleb distinguished fragile systems, which are harmed by shocks, from robust ones, which withstand them, and antifragile ones, which gain from them. His barbell idea is a useful heuristic: put most of your resources in something safe and reliable, and a small amount in speculative options that cost little if they fail. For applications, that’s a small, well-chosen core, plus one deliberate alternative: a pilot, a small team on a different tool, a periodic proof of concept. A small core with one live alternative is still a minimum, chosen on purpose.

Ten: Refresh the coalition annually. People move on. Enthusiasm fades. Once a year, bring in new members, and thank the ones who are leaving.

When Defend Is Done

It never is, and that’s the point. Entropy is why the loop never ends. The work of staying organised is not a project with an end date. It’s a practice. Keep it light, make it somebody’s job, and budget for it from the start. Then, when the picture has changed, you return to Discovery. The full detail of Defend is in Part Four of the Full edition.

The Six Cs

The Shared Language

The four Ds are your method. They tell you what to do, and in what order. The six Cs are something different. They’re a shared language that you and the people helping you both use while the change happens. They describe how everyone treats one another along the way.

They matter because change is rarely derailed by a lack of method. It’s far more often derailed by the way people behave towards each other when it gets uncomfortable. You can run all four Ds flawlessly and still lose the room, if the people around you feel ignored, overloaded or blamed.

Here are the six, in this book’s terms. For each, I’ll say what it means, and how you, as the leader, can model it.

One: Compassion

People are attached to familiar tools; respect that while moving on.

A tool is never just a tool. It’s a set of skills someone worked hard to master, a routine they trust, and sometimes a piece of their professional identity. Asking someone to move on from it asks them to give up something real, even when the case for moving is strong.

Compassion means assuming good intent, treating hesitation as information rather than obstruction, and being as kind to yourself as to others when things slip. It doesn’t mean giving way. It means moving on without making anyone feel foolish for having valued what they valued.

How you model it: thank the people who built expertise on the incumbent, and say so in public.

Two: Communication

Raise workarounds and overlooked alternatives openly, instead of hiding them.

The Application Dominance Effect lives in what goes unsaid. The workaround nobody mentions, and the alternative nobody has spoken aloud, are exactly what this book asks you to surface. That only happens if people feel they can say these things early and clearly, in an agreed place.

In this series, the agreed place is usually the shared Todoist project. If something isn’t working, it goes in the project. If someone knows of an alternative, it goes in the project. Nothing important should live only in a hallway conversation.

Communication also means being clear. Short written messages are where ambiguity creeps back in, because tone doesn’t travel. There’s an online argument about “lol” at the end of a message. Many millennials use it to soften a request. Reports say some younger people read it as insincere, and a bare thumbs-up as curt. I can’t verify how widely that’s true, and slang changes. But the point survives: the same words can land differently for different people.

So make messages explicit. Say what you need and by when. Agree what a thumbs-up means in your project: seen, or agreed? And when it matters, write it in full, as a comment.

How you model it: make it safe and easy to raise a workaround, respond to what’s raised, and reduce ambiguity. State the ask, the date, and what done means.

Three: Capacity

Agree realistic time for learning new tools alongside day-to-day work.

Nobody has spare hours waiting to be filled with change. Learning a tool, running a pilot, or retiring an old one all take time on top of a full job. A plan that ignores that will be quietly abandoned.

Capacity means being honest about the time and energy people really have, and agreeing what’s realistic before committing to it.

How you model it: build learning time into the plan, and remove something to pay for it. That’s the task in Dream where you decide what you’ll stop doing.

Four: Commitment

Once a tool is chosen, use it and retire the old one.

The change only holds if people do what was agreed. A decision to move to a chosen application is undermined every time the old route stays open as an easy fallback. Commitment means doing what you said you would, or saying early if you can’t.

It also applies to the decision itself. If the evaluation was fair and the choice was made, the organisation owes it a proper trial before judging it.

How you model it: close the old route when the new one is ready. Don’t leave both open indefinitely.

Five: Consideration

One person’s shadow spreadsheet creates rework for everyone else.

In an application estate, nearly every action affects someone else. A private spreadsheet means a colleague can’t see the real numbers. A tool adopted without telling anyone creates a security and support burden for people who didn’t choose it. A change of platform in one team lands in the workload of another.

Consideration means thinking about how your actions affect others before you act.

How you model it: consider the downstream effects of each change, and ask the people downstream.

Six: Consistency

Record work in the agreed system every time, so the data tells the truth.

An organised estate depends on trustworthy data, and data is only trustworthy if people record work in the same place, in the same way, every time. A system that’s used most of the time is a system that can’t be relied on, and so people go back to their own spreadsheets.

Consistency means keeping to the agreed way of working even when no one is checking. It’s the C that turns the other five into results.

How you model it: do it yourself. If you bypass the system, everyone else will.

How the Cs and the Ds Fit Together

The Cs run underneath all four stages. Compassion and Communication matter most in Discovery and Dream, when people are deciding whether to trust you. Capacity is the central issue in Dream and Design. Commitment and Consistency carry the weight in Defend. Consideration is needed throughout.

If you only remember one thing, remember this. The Ds are what you do. The Cs are how you do it.

Leading Your People

Who the Support Edition Is For

You’re not doing this alone, and you shouldn’t. The people around you are affected by the change, and many of them will be asked to do something differently. For this book, those are the team members and colleagues affected by the move to fewer, better-used applications.

There’s a short edition written just for them. It’s called Applications… Organised: Support. It takes under ten minutes to listen to or read. It explains the terminology, what’s expected of them, and the dos and don’ts of working with you, including how to use the shared Todoist project.

How to Share It

Share the Support edition when you communicate the dream, in the Dream stage. That’s the natural moment, because it’s when people first hear what’s changing. Send it with a short, personal note. Say why you’ve asked them, and that it’s ten minutes. Say that nothing in it blames them.

Don’t send it as a way of telling people off. The Support edition is warm and practical. It exists so that nobody has to guess what you need.

How to Share the Todoist Project

Once you’ve completed Discovery, and you’re ready for people to see what’s expected of them, share the project.

In Todoist, open the project, choose Share, and invite people by name or email address. People who don’t yet have an account are invited to sign up for free.

Three things are worth knowing, according to Todoist’s documentation. First, people you invite can see the tasks and comments, and can add, assign and complete tasks. So invite only the people you want to be able to change things. Second, each task can be assigned to only one person. If a task needs several people, split it into sub-tasks. Third, sharing a project doesn’t share any projects nested beneath it. So share the project itself, not a parent of it.

And check Todoist’s current help pages. Sharing rules and plan limits can change.

Make sure each person can see what’s expected of them, and by when. That’s the single biggest thing a shared project gives the people who support you. They stop guessing.

Ask them, too, to enable Todoist’s Habit Tracker integration if they own any recurring tasks. The Support edition asks the same.

Leading by Example

A few habits make leading easier.

Model the six Cs, especially the last one. If you record work in the project, they will. If you don’t, they won’t.

Keep the project light. It’s tempting to build an elaborate system. Resist that. The best project is the one you’ll actually open. If it starts to feel like a burden, remove things.

Be the person who reduces ambiguity. A practical view of leadership is that it goes to whoever makes a confusing room clearer. After you’ve spoken, is the room less uncertain? If not, say it again, more simply. And look for the people who already do this. The ones who built the workarounds, or wrote down the real criteria, are often natural leaders of your guiding coalition, whatever their job title.

Thank people publicly, and early. The contribution of each person is visible in the project, and so should be your appreciation.

And when you meet resistance, remember what you’ve learned. It’s rarely about the tool. It’s usually about identity, habit, or a fear of losing something real. Ask open questions. Listen. Don’t win the argument and lose the person.

One last point. If the change is going to take more than a few months, put the recurring tasks in the project, and track them with the Habit Tracker. A change that’s only held up by your memory will fade. A change that’s held up by a visible rhythm tends to last.

Next Steps

What to Do This Week

You’ve heard a lot. Here’s the shortest route to starting.

Create the Todoist project and call it Organise Applications. Add the four stage tasks. Turn on the Habit Tracker. Add the Modernisation Charter as a comment under Discovery. Then do the first Discovery task: note what already works well, and why.

That’s an hour or two, and it’s enough to begin. Everything else follows from it.

Go Deeper

This Guide is the short route. The Full edition, Applications… Organised: Full, is the long one. It’s an ebook with the whole argument: the psychology of why dominance works, the plain-English primer on event logs, shadow processes, conformance and rework in depth, the frameworks for moving people, a worksheet called the Innovation Audit, a glossary, and the sources behind the claims. If you want to understand why this works, or you need to convince a sceptical sponsor, start there.

For ongoing research and updates, and to learn about the other books in the series, visit my website, ravi8.com.

The same method is applied to other parts of life in other titles in the series, including Habits… Organised, Relationships… Organised, Parenting… Organised, Roti… Organised, Bhangra… Organised, Dance… Organised, Veganism… Organised, Fat Loss… Organised and Exercise… Organised.

New to Todoist?

One more time, in case you skipped it earlier. If you’re new to Todoist, I’d really appreciate it if you signed up through my affiliate link, which you’ll find on my website, ravi8.com. If my introducing you to Todoist helps you become more organised, using my link helps make all the effort I’ve put into these books worthwhile.

And the disclosure again. This is an affiliate link, so I may earn a commission at no extra cost to you.

Before You Go

Remember the King on the chessboard. It looks powerful, but its power is built from the pieces arranged around it. The same is true of the dominant tool in your organisation. Change the arrangement, and the picture changes.

Make change, or else change will make you.

Thank you for listening.