Patterns

When Good Employees Mask Bad Processes.

hello@kerriequeen.com (Kerrie Queen) — Mon, 26 Oct 2026 21:19:51 GMT

Some of the biggest operational problems are hiding behind your best employees.

You know the person.

The one who always knows what's going on.
The one everyone goes to when they need an answer.
The one who remembers the details, catches mistakes, and makes sure nothing falls through the cracks.

When a client has an unusual request, they know how to handle it.
When something goes wrong, they know who to call.
When a process doesn't work, they find a way around it.

Leadership loves this person.
And for good reason.
They're incredibly valuable to the organization.

But here's the question nobody is asking:
What happens when they're not there?

Because sometimes, the reason everything appears to be working isn't that the organization has great processes.

It's that great employees are compensating for the ones that don't work.

And those are two very different things.

Employee performance and process performance are not the same thing.

Employee performance asks: How well does this person do their job?

Process performance asks: How reliably does the work get done, regardless of who is doing it?

A strong employee can succeed despire a poorly designed process.
→ They can remember what the system doesn't capture.
→ They can recognize mistakes before anyone else notices.
→ They can keep a project moving even when nobody has defined what should happen next.

And from the outside, everything looks fine.
✔️ Projects get completed.
✔️ Clients get responses.
✔️ Deadlines are met.
✔️ Problems get solved.

But behind those results may be an enormous amount of invisible effort.

The organization sees the outcome. It doesn't always see what it took to achieve it.

The employee who holds everything together.

Imagine an account manager who's been with a company for eight years.

They're excellent at their job.

They know the clients personally. They remember the history behind every project. They understand how the different departments work together.

When a new request comes in, they know who should handle it.
When something goes wrong, they can usually fix it before the client notices.

They've developed spreadsheets, reminders, and their own way of keeping everything organized.

And they make look easy.

Now imagine they take two weeks off.
Suddenly, nobody knows the status of several projects.

➕ The team can't find important client information.
➕ Decisions that normally happen quickly are delayed.
➕ Other employees are unsure who to contact or what to do next.

And the account manager starts receiving messages while they're on vacation. Not because the rest of the team isn't capable. But because the process was never really carrying the work. The employee was.

The organization didn't lose its ability to operate when that person left. It discovered how much of its ability to operate had been living inside one person.

How to identify when employees are compensating for bad processes.

High-performing employees should make an organization stronger.

But their knowledge, judgment, and dedication shouldn't be the only things keeping everyday operations moving.

Here are six ways to identify hidden dependencies and build processes that support people rather than depend entirely on them.

01
Look beyond the results.

When organizations want to improve operations, they often start by looking at departments.

→ Sales has its process.
→ Operations has its process.
→ Finance has its process.
→ Customer service has its process.

And each process might work reasonably well on its own.
The problems often happen between them.
Start by choosing one common activity and following it from beginning to end.

It might be:

Onboarding a new client.
Creating and approving a proposal.
Processing a customer request.
Launching a new project.
Resolving a billing issue.

Walk through what actually happens, not just what the documented process says should happen.

Where does the work begin?
Who touches it?
What information is required?
Where does it go next?
When does someone have to stop and wait?
What happens when something doesn't go according to plan?

You may discover that each department has optimized its own part of the process, but nobody has designed how the entire process should work together.

A process can be efficient for one team and inefficient for the organization.
That's why you have to follow the work across the business, not just within individual departments.

02
Find

Most organizations can tell you how many projects they completed, deals they closed, or tickets they resolved.

What they often can't tell you is how much time employees spent simply coordinating those activities.

Think about how often people:

Ask for status updates.
Search for information.
Follow up on unanswered requests.
Clarify who's responsible for something.
Reconcile conflicting information.
Prepare updates for meetings.
Remind someone about a deadline.

These activities may be necessary occasionally. But when they become part of everyone's daily routine, they represent a significant operating cost.

Consider the employee who spends fifteen minutes every morning figuring out what needs their attention. That doesn't sound like much.

But if ten employees are doing the same thing every day, that's 12.5 hours each week spent just getting organized. And that's before anyone begins the actual work.

The question isn't whether employees are busy. It's how much of their time is spent moving work forward versus making the work possible.

Look closely at the second category.
That's often where the biggest opportunities are hiding.

03
Find where work is being done more than once.

Duplicate effort doesn't always mean two people are performing the exact same task.
➕ Sometimes it's the same information being entered in different places.
➕ Sometimes it's the same question being answered multiple times.
➕ Sometimes it's a report being recreated because nobody trusts the existing one.

For example:
→ A sales team maintains opportunity information in the CRM.
→ Finance keeps a separate spreadsheet to forecast revenue.
→ Leadership requests a weekly report to reconcile the two.
→ Now three different activities exist to maintain and interpret essentially the same information.
→ And every time something changes, there's a possibility that one version becomes outdated.

The problem isn't necessarily that the organization uses multiple systems. It's that information and effort are being duplicated without creating additional value.

Look for places where employees regularly say:

"I already entered that."
"Didn't we discuss this last week?"
"Let me update my spreadsheet first."
"I need to check which version is correct."

Those are signals worth investigating.

Ask whether the information needs to exist in multiple places, whether systems can share it, and whether everyone agrees on which version is authoritative. Sometimes a simple change in ownership or process eliminates hours of unnecessary work.

04
Identify where decisions get stuck.

Not all operating costs come from tasks.
Some come from waiting.

➕ A proposal is ready, but nobody knows who can approve the pricing.
➕ A client request needs attention, but it's unclear which department owns it.
➕ A project is delayed because two managers disagree on its priority.

Employees aren't necessarily doing anything wrong. They're waiting for the organization to tell them what to do. And while one decision sits unresolved, several other activities may be waiting behind it.

Decision-making is part of the operating system.
If every exception requires a meeting, every approval travels through the same manager, or every priority conflict needs leadership intervention, the organization has created a bottleneck.

Start asking:

Who has the authority to make this decision?
What information do they need?
When does an issue actually need to be escalated?
What decisions could be made without additional approval?
Are people waiting because the decision is difficult or because ownership is unclear?

The goal isn't to remove oversight where it's needed. It's to make routine decisions easier and ensure exceptions reach the right people quickly. A process isn't efficient if the work moves quickly but every decision gets stuck.

05
Put a cost on the friction.

This is where complexity becomes easier to recognize as a business problem rather than just an operational inconvenience.

Organizations often measure the cost of technology, employees, and projects. But they don't always measure the cost of the processes connecting them.

Start by looking at three things.

1. Time spent

How much time are employees spending on duplicate entry, unnecessary meetings, manual reporting, follow-ups, and searching for information?

Even a rough estimate can reveal how much capacity is being consumed.

2. Delays created

How long does work sit waiting for information, approvals, or handoffs?
Does the delay affect project timelines, customer responsiveness, or the organization's ability to generate revenue?

3. Errors and rework

How often does information need to be corrected?
How many activities have to be repeated because instructions were unclear, ownership changed, or the wrong information was used?
And what does correcting those mistakes require?

The real cost of complexity is rarely one large expense. It's the accumulation of small inefficiencies repeated across the organization.

Not every lost minute translates directly into recoverable savings. But the exercise reveals where capacity is being consumed and what the business might gain by improving the process.

That might mean serving more clients without adding headcount.

It might mean reducing project delays.

It might mean giving managers more time to lead instead of chasing information.

Or it might mean employees can finally focus on the work they were hired to do.

The goal is to understand not only what complexity costs, but what it prevents the organization from accomplishing.

06
Simplify the process before adding more technology.

This is an important one.

Organizations often respond to operational complexity by introducing something new.

➕ Another platform.
➕ Another workflow.
➕ Another dashboard.
➕ Another approval process.
➕ Another automation.

Sometimes that's exactly what's needed.
But sometimes the new solution is simply being added on top of everything that already exists.

Now employees have another place to enter information, another notification to monitor, and another process to remember.

The organization may have invested in improvement while actually increasing complexity.

Before adding something new, ask:

What can we remove?
Does every field need to be collected?
Does every approval need to happen?
Does every meeting serve a purpose?
Does the same information need to live in multiple places?
Can several variations of a process become one standard approach?

Then ask what can be consolidated, clarified, or automated.
Technology should reduce the effort required to operate the business. Not create more of it.

Don't automate a process simply because it exists. First make sure the process should exist in the first place.

07
Make simplicity an ongoing operating responsibility.

Here's the challenge.

Even after you've simplified a process, complexity can slowly return.
➕ A new client requires a slightly different approach.
➕ Someone adds another approval after a mistake.
➕ A department creates a spreadsheet to track something the system doesn't show.
➕ A new manager introduces a report.
➕ A team builds a workaround rather than addressing the underlying problem.

Each individual decision may seem reasonable.
But nobody is looking at what happens when all those decisions accumulate. And eventually, the organization is right back where it started.

Complexity grows when no one is responsible for managing it.

That doesn't mean every change needs to go through one person or committee. It means establishing a practical way to evaluate how the organization operates.

When a new process is introduced, consider what it replaces.
When a system is added, clarify what information it owns.
When employees create workarounds, understand why.
When a process becomes more complicated, ask whether the added complexity creates enough value to justify it.
And when something no longer serves a purpose, retire it.

Build regular process reviews into how the organization operates.

Ask employees where work is getting harder.
Review activities that consistently require unnecessary coordination.
Look for recurring exceptions, delays, and manual effort.
Assign someone responsibility for evaluating and addressing what you find.

Simplification shouldn't be a one-time cleanup project. It should be part of how the business evolves.

Growth doesn't have to mean more friction.

As organizations grow, some complexity is inevitable.

➕ More clients create more demands.
➕ More employees require coordination.
➕ More services introduce different workflows.
➕ More decisions require structure.

But growth and unnecessary complexity aren't the same thing.

An organization shouldn't need twice as much internal effort simply because it's handling twice as much work.

And employees shouldn't have to become experts at navigating the business just to do their jobs. The operating model needs to evolve as the organization grows.

That means periodically questioning not only whether the work is getting done, but how much effort it takes to get there.

A growing business needs more capability. It doesn't necessarily need more complexity.

The best process is often the one nobody notices.

Nobody celebrates that they didn't have to send a follow-up email.
Nobody talks about the approval that didn't require a meeting.
Nobody notices the information they didn't have to enter twice.
Nobody marvels at how easily a project moved from one team to another.

They just work.

A client makes a request.

✔️ The right person knows what to do.
✔️ The information is already available.
✔️ Decisions happen without unnecessary delays.

The work moves forward. And nobody has to spend half the morning figuring out how to make it happen.

That's what an effective operating model looks like.
Not more tools. Not more rules. Not more people coordinating the same work.
Less effort spent navigating the business. More effort spent moving it forward.

The Hidden Operating Cost of Complexity

hello@kerriequeen.com (Kerrie Queen) — Mon, 26 Oct 2026 17:40:49 GMT

Complexity doesn't always look like a problem. Sometimes it looks like a team working really hard.

The business is growing.
More clients. More employees. More projects. More technology.
And somehow, everything is getting harder.

➕ A client request that used to take one conversation now requires three emails, two approvals, and a meeting.
➕ Employees spend more time tracking down information than acting on it.
➕ Managers need regular updates just to understand what's happening.
➕ And the people who know how everything works are constantly being pulled into conversations to help everyone else figure it out.

The work is getting done.
But it's taking more people, more coordination, and more effort than it should.
That's the hidden operating cost of complexity.

Complexity and workload are not the same thing.

When teams are overwhelmed, the natural assumption is that they have too much work.

Sometimes that's true.
But there's an important distinction.

Workload asks: How much work needs to get done?
Complexity asks: How much effort does it take to get that work done?

And those are two very different problems.

→ You can have a growing sales team, yet closing a deal still requires someone to manually reconcile information across three systems.

→ You can hire additional project managers, yet everyone continues attending status meetings because nobody trusts the project data.

→ You can expand your customer support team, yet resolving a simple request still requires employees to track down the right person to approve it.

In each case, the organization may have enough people to handle the actual work.
What it doesn't have is an efficient way for that work to happen.

The work you see. And the work happening around it.

Consider something as simple as onboarding a new client.

On paper, the process looks straightforward.

The deal closes.
The client is introduced.
The team begins work.

But behind the scenes?

Sales emails the project manager with the details.
The project manager asks for information that's missing.
Someone creates a project in another system.
Operations copies information into a spreadsheet.
A manager reviews the scope because nobody is sure what was promised.
The account manager sends another email to confirm the timeline.
Everyone attends a kickoff meeting to get aligned.
And someone still has to follow up afterward to make sure everyone knows what they're responsible for.

None of these activities may seem especially expensive on their own. But across hundreds of clients, projects, requests, and decisions, they add up. The organization isn't just paying for the work. It's paying for all the work required to coordinate the work.

And that cost rarely appears as its own line item on a financial statement.

How to Find and Reduce the Hidden Cost of Complexity

Not all complexity is unnecessary.

As organizations grow, they naturally need more coordination, specialized roles, controls, and structure. The goal isn't to eliminate every step or simplify everything at the expense of quality. It's to identify where complexity is actually creating value and where it's simply consuming time, resources, and attention.

Here are the 7 places to start looking.

01
Follow the work, not the organizational chart.

When organizations want to improve operations, they often start by looking at departments.

→ Sales has its process.
→ Operations has its process.
→ Finance has its process.
→ Customer service has its process.

And each process might work reasonably well on its own.
The problems often happen between them.
Start by choosing one common activity and following it from beginning to end.

It might be:

Onboarding a new client.
Creating and approving a proposal.
Processing a customer request.
Launching a new project.
Resolving a billing issue.

Walk through what actually happens, not just what the documented process says should happen.

Where does the work begin?
Who touches it?
What information is required?
Where does it go next?
When does someone have to stop and wait?
What happens when something doesn't go according to plan?

You may discover that each department has optimized its own part of the process, but nobody has designed how the entire process should work together.

A process can be efficient for one team and inefficient for the organization.
That's why you have to follow the work across the business, not just within individual departments.

02
Look for the work happening around the work.

Most organizations can tell you how many projects they completed, deals they closed, or tickets they resolved.

What they often can't tell you is how much time employees spent simply coordinating those activities.

Think about how often people:

Ask for status updates.
Search for information.
Follow up on unanswered requests.
Clarify who's responsible for something.
Reconcile conflicting information.
Prepare updates for meetings.
Remind someone about a deadline.

These activities may be necessary occasionally. But when they become part of everyone's daily routine, they represent a significant operating cost.

Consider the employee who spends fifteen minutes every morning figuring out what needs their attention. That doesn't sound like much.

But if ten employees are doing the same thing every day, that's 12.5 hours each week spent just getting organized. And that's before anyone begins the actual work.

The question isn't whether employees are busy. It's how much of their time is spent moving work forward versus making the work possible.

Look closely at the second category.
That's often where the biggest opportunities are hiding.

03
Find where work is being done more than once.

The problem isn't necessarily that the organization uses multiple systems. It's that information and effort are being duplicated without creating additional value.

Look for places where employees regularly say:

"I already entered that."
"Didn't we discuss this last week?"
"Let me update my spreadsheet first."
"I need to check which version is correct."

Those are signals worth investigating.

04
Identify where decisions get stuck.

Not all operating costs come from tasks.
Some come from waiting.

Start asking:

Who has the authority to make this decision?
What information do they need?
When does an issue actually need to be escalated?
What decisions could be made without additional approval?
Are people waiting because the decision is difficult or because ownership is unclear?

05
Put a cost on the friction.

This is where complexity becomes easier to recognize as a business problem rather than just an operational inconvenience.

Organizations often measure the cost of technology, employees, and projects. But they don't always measure the cost of the processes connecting them.

Start by looking at three things.

1. Time spent

How much time are employees spending on duplicate entry, unnecessary meetings, manual reporting, follow-ups, and searching for information?

Even a rough estimate can reveal how much capacity is being consumed.

2. Delays created

How long does work sit waiting for information, approvals, or handoffs?
Does the delay affect project timelines, customer responsiveness, or the organization's ability to generate revenue?

3. Errors and rework

How often does information need to be corrected?
How many activities have to be repeated because instructions were unclear, ownership changed, or the wrong information was used?
And what does correcting those mistakes require?

The real cost of complexity is rarely one large expense. It's the accumulation of small inefficiencies repeated across the organization.

Not every lost minute translates directly into recoverable savings. But the exercise reveals where capacity is being consumed and what the business might gain by improving the process.

That might mean serving more clients without adding headcount.

It might mean reducing project delays.

It might mean giving managers more time to lead instead of chasing information.

Or it might mean employees can finally focus on the work they were hired to do.

The goal is to understand not only what complexity costs, but what it prevents the organization from accomplishing.

06
Simplify the process before adding more technology.

This is an important one.

Organizations often respond to operational complexity by introducing something new.

➕ Another platform.
➕ Another workflow.
➕ Another dashboard.
➕ Another approval process.
➕ Another automation.

Sometimes that's exactly what's needed.
But sometimes the new solution is simply being added on top of everything that already exists.

Now employees have another place to enter information, another notification to monitor, and another process to remember.

The organization may have invested in improvement while actually increasing complexity.

Before adding something new, ask:

What can we remove?
Does every field need to be collected?
Does every approval need to happen?
Does every meeting serve a purpose?
Does the same information need to live in multiple places?
Can several variations of a process become one standard approach?

Then ask what can be consolidated, clarified, or automated.
Technology should reduce the effort required to operate the business. Not create more of it.

Don't automate a process simply because it exists. First make sure the process should exist in the first place.

07
Make simplicity an ongoing operating responsibility.

Here's the challenge.

Each individual decision may seem reasonable.
But nobody is looking at what happens when all those decisions accumulate. And eventually, the organization is right back where it started.

Complexity grows when no one is responsible for managing it.

That doesn't mean every change needs to go through one person or committee. It means establishing a practical way to evaluate how the organization operates.

When a new process is introduced, consider what it replaces.
When a system is added, clarify what information it owns.
When employees create workarounds, understand why.
When a process becomes more complicated, ask whether the added complexity creates enough value to justify it.
And when something no longer serves a purpose, retire it.

Build regular process reviews into how the organization operates.

Ask employees where work is getting harder.
Review activities that consistently require unnecessary coordination.
Look for recurring exceptions, delays, and manual effort.
Assign someone responsibility for evaluating and addressing what you find.

Simplification shouldn't be a one-time cleanup project. It should be part of how the business evolves.

Growth doesn't have to mean more friction.

As organizations grow, some complexity is inevitable.

➕ More clients create more demands.
➕ More employees require coordination.
➕ More services introduce different workflows.
➕ More decisions require structure.

But growth and unnecessary complexity aren't the same thing.

An organization shouldn't need twice as much internal effort simply because it's handling twice as much work.

And employees shouldn't have to become experts at navigating the business just to do their jobs. The operating model needs to evolve as the organization grows.

That means periodically questioning not only whether the work is getting done, but how much effort it takes to get there.

A growing business needs more capability. It doesn't necessarily need more complexity.

The Best Process Is Often the One Nobody Notices.

They just work.

A client makes a request.

✔️ The right person knows what to do.
✔️ The information is already available.
✔️ Decisions happen without unnecessary delays.

The work moves forward. And nobody has to spend half the morning figuring out how to make it happen.

You Implemented the New Tool. Now You Have to Make It Stick.

hello@kerriequeen.com (Kerrie Queen) — Mon, 26 Oct 2026 16:16:39 GMT

Organizations spend a lot of time selecting and implementing technology. But the real goal was never to launch a tool. The goal was to change how work gets done.

The new project management system is live. You've built your workflows, configured and mapped your fields, and the team has been onboarded and completed training.

Now, three weeks later:
Projects are still tracked in spreadsheets, client requests are sitting across inboxes, someone created their own way to use the system, and every status meeting starts with "So...where are we with this?"

The implementation? Done.
The adoption? Not so much.
And that distinction matters.

Implementation and adoption are different things.

Implementation asks:
Is the system ready for people to use?

Adoption asks:
Is this actually how people work now?

And those are very different milestones.

You can configure a help desk perfectly, yet still have employees emailing requests directly to their favorite person.
You can build a beautiful project management system, and account managers continue maintaining private spreadsheets.
You can automate client onboarding, and someone keeps a handwritten checklist beside their computer because they trust it more.

None of those necessarily mean you chose the wrong technology.
It shows the new system has not replaced the old behavior yet.
And that requires more than training.

Training teaches the tool. Enablement changes the work.

Training usually sounds something like this:

Here is how you create a project.
Here is how you update a status.
Here is where you assign a task.
Here is how you submit a request.

Useful? Absolutely.
Enough? Usually not.

Because most employees do not need to know everything a tool can do.
They need to know what they are expected to do differently on Monday morning.

The new process may be technically better. But if employees still think: "When something is urgent, I'll just message Sarah," then nothing has really changed.

Your software has simply become another place information is supposed to go.

Design a system people actually use in 7 steps.

The best time to think about adoption is before implementation begins.

But even if the system is already live, the same principles can help identify why people aren't using it and what needs to change.

01
Start with the behavior that needs to change.

If you cannot clearly describe the behavior that should stop and the behavior that should replace it, the team probably cannot either.

Before any configuration begins, document the old behavior and the behavior that should replace it.

These changes may sound simple, but they're the foundation of the entire system. The goal isn't to recreate the old process inside new software. It's to establish a better way of working and use technology to support it.

02
Design around the moments people actually need the system.

Most people do not wake up thinking:
"I would really like to use our project management platform today."

They are thinking:
What needs my attention?
What am I waiting on?
What does the client need?
What is overdue?
Who owns this?
What happens next?

Those are the questions your system should be designed to answer.

Before configuring dashboards, workflows or automation, walk through how people actually work, what information they need, and what actions they need to take.

1. What does each role need to know and do?

An account manager needs visibility into their clients, project status, upcoming milestones, and blockers.

An operations manager needs to understand workloads, ownership, deadlines, and exceptions.

Leadership needs to identify projects at risk, resource constraints, and potential client impact.

Same system. Different responsibilities. Different needs.

2. How should that information be presented?

Rather than asking everyone to navigate the same dashboards, records and reports, create an operating view designed around their daily decisions.

For example:

Account Manager
My active clients → Current projects → Status → Next milestone → Blockers

Operations Manager
All active work → Owner → Priority → Due date → Capacity

Leadership
Projects at risk → Delayed milestones → Client impact → Resource constraints

The goal is to make the right information immediately accessible, without requiring people to search for it.

3. What actions should people be able to take?

Visibility alone isn't enough.

If an account manager sees that a project is delayed, can they quickly identify the blocker and who owns the next step?

If operations sees an overdue task, can they reassign it or adjust its priority?

If leadership identifies a project at risk, can they understand the impact without scheduling another status meeting?

The system should help people move work forward, not just report on what happened.

Good system design starts with the decisions people need to make and the actions they need to take.

03
Make the new way the easiest way to work.

Organizations sometimes design a new process but leave the old habits and workarounds intact.

That creates a choice.

Submit a ticket or send an email.
Update the project or tell someone in Slack.
Add the client note or keep it in your personal document.
Check the system or ask someone for an update.

Guess which option people choose when they are busy?
Usually the one they already know.

Adoption becomes much harder when the official process requires more effort than the workaround.

The new system should remove work, not simply relocate it.

If submitting a request requires twelve fields, people will avoid it.
If project managers have to update the same information in three places, one of those places will eventually stop being updated.
If account managers cannot quickly see the information they need, they will create their own tracker.

When adoption is low, do not immediately blame the users.
Study the friction.
Find out what makes the intended process harder than the alternative, then fix it.

04
Define where information lives.

One of the biggest reasons systems lose credibility is that nobody agrees on where information should live.

A project status exists in a spreadsheet. A deadline changes in an email. An approval happens in Slack.

The problem isn't necessarily that people are using different tools. It's that no one knows which one holds the most current, reliable information.

Define a source of truth for each type of information, and make it clear who is responsible for keeping it accurate.

That doesn't mean every conversation needs to happen inside the system.

People can collaborate in Slack, discuss projects in meetings, and communicate through email. But when those conversations result in a decision, a new task, a change in ownership, an updated deadline, or a client commitment, that information needs to be reflected in the appropriate system.

Otherwise, decisions happen in one place while the information people rely on lives somewhere else. And eventually, those two versions diverge.

A system becomes valuable when people can trust the information inside it. And that trust depends on clear ownership, consistent updates, and knowing where to find the truth.

05
Enable people around how they actually work.

Once you've defined the new operating model and designed the system around it, you need to help people make the transition.

This is where enablement goes beyond traditional software training.
Instead of organizing training around features, organize it around real work.

An account manager shouldn't just learn how to update a project record. They should understand

Where to start their day?
How to identify clients needing attention?
How to manage blockers or request help?
Where to find information?

Operations managers and leadership will need guidance designed around their own responsibilities and decisions.

Teach people the workflows they'll actually use, in the situations where they'll need them.

That might include role-specific walkthroughs, short tutorial videos, simple process documentation, or hands-on practice with real examples.

But enablement also requires clarity around expectations.

What information must be entered?
Who is responsible for entering it?
When does it need to be updated?
What should someone do when a situation doesn't fit the defined process?
And who should someone contact when something doesn't work as expected?

People should leave training knowing more than how to navigate a platform.
They should understand how their work fits into the larger process and what is expected of them.

The goal isn't to make everyone an expert in the software. It's to make everyone confident in the way they're expected to work.

06
Make the system part of how the organization operates.

You tell the team that everything needs to be updated in the new system.

Then Monday rolls around, and leadership asks everyone to send over their spreadsheets.

Or a manager messages the team: "Can everyone send me their project updates?"

The team learns very quickly what actually matters.

If managers continue requesting information outside the system, employees have little incentive to maintain it accurately.

Instead, make the system part of regular operations.
✔️ Run meetings from the project dashboard.
✔️ Review overdue work directly from the system.
✔️ Use ticket queues to discuss customer issues.
✔️ Review ownership, priorities, and deadlines where they're recorded.
✔️ When a status is missing, ask why it wasn't updated rather than simply requesting a verbal update.

This shifts the system from being a place where employees are told to enter information to the place where the organization actually manages its work.

And it creates a practical reason for people to keep information current.

If someone knows their project status will be reviewed directly in the system every Monday, maintaining that status becomes part of their regular responsibilities.

Adoption gets stronger when leadership starts operating from the system, not just expecting everyone else to use it.

07
Measure real behavior and continuously improve.

Your first version of the system won't be perfect. That's fine.

The people using the process every day will discover things you didn't anticipate.

A field is confusing.
A status is missing.
A notification arrives too late.
Two categories mean almost the same thing.
Someone has to click through four screens to answer a question they get ten times a day.

These aren't necessarily signs that the system is failing.
They're opportunities to improve it.

1. Create feedback loops immediately.

During the first few weeks after launch, actively collect feedback from the people doing the work.

But ask specific questions.

Where did you leave the system to get something done?
What did you have to enter twice?
What information did you need but couldn't find?
What steps felt unnecessary?
What did you have to ask another person because the system couldn't tell you?

Those answers are far more useful than asking, "Do you like the new tool?"

But don't stop at collecting feedback. Establish who is responsible for reviewing feedback, prioritizing changes, and making sure problems are addressed. Otherwise, employees stop reporting issues and gradually return to their old workarounds.

2. Measure adoption through behavior, not logins.

A login isn't adoption.
Neither is completing a training session.

Look at whether the intended behavior is actually happening.
For a project management system, that might mean measuring:

Are active projects being updated?
Are owners assigned?
Are deadlines current?
Are overdue tasks being addressed?
Are teams using the agreed statuses consistently?
Are managers running meetings from the system?

The question isn't simply, "Are people using the tool?"

The better question is:
"Is the work now happening the way we designed it to happen?"

3. Don't automate around bad adoption.

This is an important one.
Organizations often see inconsistent usage and respond by adding more automation.

➕ More reminders.
➕ More required fields.
➕ More workflows.
➕ More rules.

Sometimes that helps.
Sometimes it just automates around a process nobody understands.

If people are not updating project status, first understand why.

Maybe they forget, or the status options do not match reality, or ownership is unclear, or updating the project requires too much work, or nobody actually uses the status after they enter it, or the organization has not agreed on what "On Track" means.

Automation can reinforce a good operating model. It cannot create one.

The goal is to keep learning from how people work, remove friction, clarify expectations, and improve the system over time.

Because adoption doesn't happen all at once.
It happens as the designed system meets reality, and the organization adjusts.

The rollout is not finished when the tool goes live.

A successful rollout isn't a single event.
It's a continuous cycle:

Design the process around how work should happen.
Enable people to follow that process.
Use the system in daily operations.
Improve what isn't working.
And repeat as the organization's needs evolve.

This is the part that many organizations miss.
They treat implementation as the finish line, when it's really the beginning of a new way of working.

Technology changes quickly. Teams grow. Responsibilities shift. Processes evolve.
A system that worked perfectly on launch day may need to change six months later.

Building adoption into your approach means creating a system that can adapt along with the organization.

A good system eventually becomes boring.

That is probably the best outcome.

Nobody celebrates that they successfully updated the project status.
Nobody marvels at the ticket routing workflow.
Nobody talks about how exciting the client request form is.

They just work.

A request comes in.
The right person gets it.
Everyone can see what is happening.
The next action is clear.
The client gets an answer.
The project moves forward.
Nobody has to ask where the spreadsheet went.

That is what successful technology adoption looks like.

Not more people using software.
A better way of working becoming the normal way of working.

Before You Buy Another Tool: Run This Systems Diagnostic First

hello@kerriequeen.com (Kerrie Queen) — Fri, 25 Sep 2026 19:11:06 GMT

A new tool can feel like progress. But too often, that hoped-for progress turns into wasted time, wasted money, and a team pulled away from meaningful work just to implement something new.

Why? Because the tool is not always the problem. Sometimes it simply exposes the problem that was already there.

Can you answer these 6 questions?
If not, do not start with technology.
Start with the system.

Who owns this?

Who is fully responsible for its success?

Who owns the process from beginning to end?

Who is responsible for moving each stage forward?

Who decides when something is ready for the next step?

Who fixes the process when it stops working?

Who owns the technology supporting it?

That person owns the outcome.
They make sure the right experts and roles are doing their part, and they are accountable when the process succeeds or fails. If several people believe someone else owns the work, a new system will not solve the problem. It will just give the confusion a new place to live. This becomes especially important when automation is involved.

Automation needs a defined point of responsibility. If the system identifies an exception, routes a lead, or flags bad data, someone still needs to own what happens next.

Do your definitions actually mean the same thing?

A system depends on shared definitions.

Consider a sales team using terms like: Lead. Qualified. Warm. Opportunity. Active. Closed. Those labels may appear perfectly clear until you ask five people what they mean.

👱‍♀️ Libby says a lead is warm because they opened an email
👨‍🦳 Jason labels warm after a conversation.
👩‍🦰 Ashley says anyone she personally believes is interested is labeled warm

Now imagine asking your CRM to automate what happens when a lead becomes warm.
The technology cannot resolve a definition the organization has never resolved itself.

A " priority customer "

A " completed project "

A " ready for review " task

An " active client "

A " marketing qualified lead "

An " urgent request "

Before automating around a status, category, lifecycle stage, or field, ask:
Could two reasonable people look at the same situation and choose different answers?

If the answer is yes, define the term before you automate it.

Are the handoffs clear?

Most operational problems do not happen while one person is doing the work.
They happen between people.

Marketing hands something to sales →

Sales hands something to operations →

A coordinator hands something to leadership →

A prospect becomes a customer →

A strategist finishes the plan and implementation begins →

A request gets approved and someone else needs to execute it

Look closely at those transition points. For every important handoff, you should be able to answer:

Who sends it? Who receives it? What information must be present?
What event triggers the handoff? How does the next person know they now own it?
What happens if nothing happens?

If the answer is "we usually send them a message," the problem may not be your software.

The problem may be that the system is relying on humans to remember that another human needs to do something. That is exactly where structured workflows and automation become valuable, but only after the handoff itself has been defined.

Can your data support the decision you want the system to make?

Every automation is ultimately a decision.
If this happens, do that.

If this person meets these conditions // then route them here.
If this record reaches this stage // then send this communication.
If this account matches this profile // then prioritize it.

If the data required to make that decision is missing, inconsistent, outdated, or stored in a notes field, the automation will fail even if the technology works perfectly.

Before building anything, identify the data the process depends on.

Is the information being captured?
Is it stored in a structured field?
Is the field consistently completed?
Does everyone use it the same way?
Is the data current enough to trust?
Does the information live on the right record?
Can the system actually access it when the decision needs to happen?
This is why data cleanup often becomes part of systems work.

It is not glamorous, but neither is building an elegant workflow on top of unreliable information.

Automation does not fix bad data. It accelerates whatever your data already tells it to do.

Where are people working around the system?

This is one of the most useful diagnostic questions you can ask:
What are people doing outside the system because the system does not work for them?

Look for:

📊 Spreadsheets someone maintains on the side.
📝 Notes copied into personal documents.
💬 Slack messages used instead of updating records.
✅ Manual reminder lists.
📧 Information stored in email threads.
👎 Fields nobody uses.
👀 Processes everyone technically follows, except in practice.

These workarounds are not always signs that employees are resisting technology. Often they are evidence.

They tell you where the official system does not match the way the work actually gets done. Do not immediately eliminate the workaround → → → Study it.

Why does the spreadsheet exist?
Why does someone keep a personal tracker?
Why is the team messaging each other instead of using the workflow?
Why does nobody update that property?

The workaround may reveal a missing field, an unnecessary step, a bad interface, an unclear process, or a legitimate need the current system never accounted for.

Your unofficial systems are often the clearest map of where your official system is failing.

Is the tool actually the constraint?

Finally, ask the question organizations often skip:
What specifically can we not do because of the technology?

Be precise.

"We hate the CRM" is not a constraint.
"It requires six manual updates to move a deal from signed contract to onboarding" is.

"Our project management system is terrible" is not a constraint.
"There is no reliable way for account managers to see which client deliverables are overdue" is.

"We need AI" is not a constraint.
"Our team spends eight hours every week manually categorizing requests that follow the same predictable rules" might be.

Once you name the constraint, you can evaluate whether technology is actually the right intervention.

Sometimes the answer is a configuration change.
Sometimes it is a better workflow.
Sometimes you need cleaner data.
Sometimes you need to remove three steps instead of automating them.

And sometimes, yes, you genuinely need a different tool.
The difference is that now you know why.

How to Understand What Your Organization Is Telling You

hello@kerriequeen.com (Kerrie Queen) — Tue, 18 Aug 2026 14:13:35 GMT

Organizations are constantly sending signals about what's working, what's getting in the way, and what's ready to change.

Sometimes these signals are obvious:

→ "Our CRM is a mess.”
→ “Decisions are taking too long.”
→ “People keep creating workarounds.”
→ “Our teams aren't communicating.”
→ “We've hired great people, but we're still struggling.”

Sometimes these signals are quieter:

➕ Meetings multiply.
➕ Information starts living in spreadsheets.
➕ Leaders become the bottleneck.
➕ People develop their own ways of doing things.
➕ A new system is introduced, but everyone keeps using the old one.

It's tempting to treat each of these as an individual problem.
But if he visible problem isn't always the real problem. How do you find the real problem?...

Start by listening.

Listen to leaders and teams, looking at how work actually happens, understanding how decisions get made, seeing where information moves or gets stuck, and paying attention to the systems and tools people rely on.

What's the end game?

Start at where they want to go.

Understand the roadblocks.

What's getting in the way?
How are people actually working?
Where does work get stuck?
How do decisions get made?
Are the systems supporting the way people work?
What's changing around the organization?

The goal isn't to collect information for the sake of collecting it. It's to connect the signals.

Signals become patterns.

A CRM problem → that might actually be an ownership problem

A communication problem → that might actually be a decision problem.

A process problem → that might actually be the result of teams designing their own solutions because the organization never established a shared way of working.

An AI problem → that might actually be a process problem.

Once the patterns become clear, we can make better decisions about what actually needs to change. And that's the point.

The Signals Framework isn't about finding problems. It's about understanding what those problems are telling us.

From there, the work becomes much more practical:

Understand → Identify → Design → Build → Measure → Transfer

Your Business Has Changed. Has the Way You Work Changed With It?

hello@kerriequeen.com (Kerrie Queen) — Tue, 18 Aug 2026 13:58:21 GMT

Growth is exciting. Until the way you've always worked starts getting in the way.

👏 The team gets bigger.
👏 There are more customers.

But, there's also

More meetings.
More decisions.
More tools.
More information.
More people involved in every decision.

And somehow, things that used to be easy become harder.

The informal communication that used to keep everyone aligned starts breaking down.

✔️ A founder who once knew everything now can't possibly stay involved in everything.
✔️ A process that worked with five people doesn't work with fifty.
✔️ People create workarounds.
✔️ Departments develop their own processes.
✔️ Information starts living in different places.

Nobody necessarily did anything wrong.
The organization changed. The way it works didn't.
And, that's often where the real problem begins.

Growth creates new organizational demands.

The answer isn't always to add another tool, another meeting, or another person. Sometimes the organization needs to redesign how work happens.

❓ Who owns what
❓ Who makes which decisions
❓ Where does information live
❓ How do teams hand work to each other
❓ What needs to be standardized
❓ What should remain flexible
❓ What does leadership actually need to see
❓ What does the team need in order to move without waiting for leadership

These are organizational design questions. And they're easy to overlook because the symptoms show up somewhere else.

You might think you have a technology problem when you actually have an operating problem
You might think you have a people problem when people are working inside a system that makes their jobs harder.
You might think you have an execution problem when priorities and decision ownership aren't clear.

The goal isn't to make the organization more complicated. It's the opposite.

The goal is to intentionally design the way the organization works so people can do their jobs, leaders can make decisions, and the business can continue moving toward what comes next.

Your organization doesn't have to stay the way it was just because that's how it got here.

Patterns

When Good Employees Mask Bad Processes.

Employee performance and process performance are not the same thing.

The employee who holds everything together.

How to identify when employees are compensating for bad processes.

01Look beyond the results.

02Find

03Find where work is being done more than once.

04Identify where decisions get stuck.

05Put a cost on the friction.

1. Time spent

2. Delays created

3. Errors and rework

06Simplify the process before adding more technology.

07Make simplicity an ongoing operating responsibility.

Growth doesn't have to mean more friction.

The best process is often the one nobody notices.

The Hidden Operating Cost of Complexity

Complexity and workload are not the same thing.

The work you see. And the work happening around it.

How to Find and Reduce the Hidden Cost of Complexity

Here are the 7 places to start looking.

01Follow the work, not the organizational chart.

02Look for the work happening around the work.

03Find where work is being done more than once.

04Identify where decisions get stuck.

05Put a cost on the friction.

1. Time spent

2. Delays created

3. Errors and rework

06Simplify the process before adding more technology.

07Make simplicity an ongoing operating responsibility.

Growth doesn't have to mean more friction.

The Best Process Is Often the One Nobody Notices.

You Implemented the New Tool. Now You Have to Make It Stick.

Implementation and adoption are different things.

Training teaches the tool. Enablement changes the work.

Design a system people actually use in 7 steps.

01Start with the behavior that needs to change.

02Design around the moments people actually need the system.

1. What does each role need to know and do?

2. How should that information be presented?

3. What actions should people be able to take?

03Make the new way the easiest way to work.

04Define where information lives.

05Enable people around how they actually work.

Teach people the workflows they'll actually use, in the situations where they'll need them.

06Make the system part of how the organization operates.

07Measure real behavior and continuously improve.

1. Create feedback loops immediately.

2. Measure adoption through behavior, not logins.

3. Don't automate around bad adoption.

The rollout is not finished when the tool goes live.

A good system eventually becomes boring.

Before You Buy Another Tool: Run This Systems Diagnostic First

Can you answer these 6 questions? If not, do not start with technology. Start with the system.

Who owns this?

Do your definitions actually mean the same thing?

Are the handoffs clear?

Can your data support the decision you want the system to make?

Where are people working around the system?

Is the tool actually the constraint?

How to Understand What Your Organization Is Telling You

Start by listening.

What's the end game?

Understand the roadblocks.

Signals become patterns.

Your Business Has Changed. Has the Way You Work Changed With It?

Growth creates new organizational demands.

The goal isn't to make the organization more complicated. It's the opposite.

01
Look beyond the results.

02
Find

03
Find where work is being done more than once.

04
Identify where decisions get stuck.

05
Put a cost on the friction.

06
Simplify the process before adding more technology.

07
Make simplicity an ongoing operating responsibility.

01
Follow the work, not the organizational chart.

02
Look for the work happening around the work.

03
Find where work is being done more than once.

04
Identify where decisions get stuck.

05
Put a cost on the friction.

06
Simplify the process before adding more technology.

07
Make simplicity an ongoing operating responsibility.

01
Start with the behavior that needs to change.

02
Design around the moments people actually need the system.

03
Make the new way the easiest way to work.

04
Define where information lives.

05
Enable people around how they actually work.

06
Make the system part of how the organization operates.

07
Measure real behavior and continuously improve.

Can you answer these 6 questions?
If not, do not start with technology.
Start with the system.