Two branches sent their managers to the same training. Three months later, one branch still follows the new process. The other stopped in week three.
If your company runs several branches, stores, plants or shifts, you have probably seen this. The content was the same. The results were not.
The training is the same. The conditions are not.
Most companies respond by looking at the program. Was the content good enough? Was the facilitator strong enough? Usually, the program is fine. The difference is what happens at each site after the session ends.
Four things change from one site to the next:
What the manager’s own boss asks about after the training.
How full the weekly schedule is.
How daily work is set up: the forms, tools and approvals managers deal with.
Whether anyone checks that the new practice is happening.
A new practice survives only where those four things support it. Where they do not, the old habit wins, because the old habit is faster on a busy day.
What uneven results cost you
Customers get different service depending on which branch they walk into. Leaders cannot tell which parts of the program work, so they approve another program. And the money keeps going out.
Training is no longer rare. The World Bank’s 2023 Enterprise Survey found that 62.1% of surveyed Philippine firms with 100 or more employees offered formal training. Having a program is not your edge anymore. Getting every site to use it is.
Compare your best site with your weakest site
Do not review the whole program. Pick two sites that took the same training but got different results. Then do this:
Ask a manager at each site to show you one real example, from last week, of using the new practice. (A manager practice is a specific action a manager takes at work, such as a 15-minute check-in with each team member every week.)
Ask each manager’s boss what they asked about after the training.
Ask what gets in the way: schedule, tools, approvals or staffing.
Put the answers side by side.
The gap usually shows up within an hour. Say the strong branch’s supervisor reviews the practice every Monday, and the weak branch’s supervisor never mentions it. Another workshop will not fix that. A short briefing for that supervisor, and a weekly question, will.
How this fits a wider plan
At POC Management Execution, we start with one business result the company wants to improve. We choose a few manager practices that can move it. We ask each manager’s supervisor to check on those practices. Then we compare sites to see where the practice holds and where it does not.
Consistent results come from consistent conditions, not only consistent content.
Which of your branches or sites applies your last management program best, and do you know why?
If you want to think this through for your own company, message me and we can brainstorm it together.
Your weekly report costs almost seven hours a week, and nobody has asked whether anyone reads it.
You know the one. Five department heads each write a status update every Friday. A coordinator collects the five updates, merges them into one document, fixes the formatting, and sends it to the leadership team. Then someone spots a wrong number, two managers fix their sections, and the whole thing goes out again.
Nobody designed this process. It grew. A leader asked for an update once, the update became a habit, and the habit became a rule. Today it runs on its own, like a meeting that outlived its purpose.
What one report really costs
Let’s put numbers on it. These figures are illustrative, so replace them with your own.
• Five managers, 45 minutes each: 3.75 hours
• One coordinator merging and formatting: 2 hours
• Corrections and resends: 1 hour
Total: 6.75 hours every week. Over 50 weeks, that is more than 330 hours, or about eight full working weeks spent on one document.
Most companies have several reports like this. Each one looks small on its own. Together they take a real share of the week, and nobody sees it because no one has ever added it up.
There is also a cost the arithmetic misses. Managers who write a report nobody reads learn that reporting is theater. They start writing what looks safe. The report gets longer and says less.
This is not a complaint about managers. They write the update because someone asked for it, and they do it carefully, which is exactly why it takes 45 minutes.
The question to ask before you buy anything
When people see seven hours of work, the first idea is usually a tool. Let AI collect the updates, merge them, and format the document. That would help.
It would also give you a faster version of a report that may not need to exist.
Ask this first: what decision did anyone make last month because of this report?
If leaders can name one, the report has earned its place. If the answers come slowly and vaguely, you have found work that can go away. A report nobody acts on is not communication. It is a weekly ritual with a deadline.
Three steps, in this order
1. Remove. Ask who reads the report and what they do with it. If the honest answer is “no one,” stop sending it. Tell people you are pausing it for a month, then watch who complains. In many companies, nobody does.
2. Simplify. If the report survives, ask what the reader actually needs. Often it is three numbers and two risks, not five pages. Shrink the template to match. Five managers who write five lines each need ten minutes, not forty-five.
3. Automate. Only now hand the leftover mechanical work to AI: collecting the updates, putting them in one format, and drafting a short summary for a person to check before it goes out.
What a short report looks like
A useful weekly update can fit on half a page. Three headings are usually enough: what changed this week, what is at risk, and what needs a decision from the reader. Everything else is detail that belongs in a folder, not in a leader’s inbox.
Ask managers to write to those three headings and the report shortens itself, because most weeks only a few items need real attention. A quiet week produces a short report, and that is a feature. A leader who receives two lines saying nothing has changed has learned something worth knowing.
What the numbers look like after
Run the same example again. Managers now spend 10 minutes each, about 50 minutes in total. The coordinator reviews an AI-assembled draft in 30 minutes instead of building the document from scratch in two hours. Corrections drop to 15 minutes because the simpler template leaves less room for mistakes.
That is about one and a half hours a week instead of almost seven. Over a year, roughly 250 hours come back.
Look at where the savings came from. More than half of the time saved comes from the simpler template, which arrived before any AI touched the report.
A drafted summary still needs a human eye. AI can merge five updates in seconds, but it cannot tell that one manager’s “on track” has quietly meant “late” for three weeks. Keep a person on the final read. In this example that check takes 15 minutes, and it is time well spent.
Why teams skip the first two steps
Buying is exciting and removing is uncomfortable. A new tool gets a launch email and a training session. Stopping a report gets you a few awkward questions.
There is a quieter reason too. Some reports exist because a former leader asked for one, and that leader moved on years ago. The report stayed behind, like a houseplant nobody remembers buying but everybody keeps watering.
Automating that report does not solve the problem. It just makes the watering faster.
When someone defends the report
Expect the objection: “Leadership might need it someday.” Fair enough. So test it instead of arguing about it.
Pause the report for four weeks. Tell the leadership team it is available on request, and keep the template ready. Then count how many requests arrive. If the count is zero, you have your answer. If the count is two, you have learned which two readers matter, and you can send the report to them alone.
Either result is cheaper than another year of Friday afternoons.
The same test works on other recurring work
Weekly reports are only the start. Run the same questions on meeting minutes nobody opens, monthly dashboards that get a quick glance, status decks rebuilt from scratch every cycle, and spreadsheets that one employee updates by hand because the system never quite fit.
Each one has a cost in hours, a reader who may or may not exist, and a smaller version waiting to be found. Most of the time, the smallest useful version takes a fraction of the effort.
AI earns its place at the end of that process, not the beginning. By then you know what the work is for, what a good version looks like, and how to tell when a draft is wrong. A tool is far more useful to someone who knows what they want from it.
Try it on one report this week
Pick one recurring report in your department. Write down how many people touch it, how many minutes each person spends, and how often it goes out. Then multiply.
Answer three questions. Who reads it? What did they decide because of it? What is the smallest version that would still support that decision?
You do not need a consultant for this. You need a calculator and a willingness to hear the answer. Seven hours written on a page is hard to argue with, which is usually the point.
If the report passes the test, keep it and simplify it. If it fails, you have just found seven free hours a week without buying anything.
Delete what nobody uses, simplify what remains, and automate only what is left. Most teams do it in the opposite order.
Which recurring report in your company takes far longer than it should, and who would actually notice if it stopped?
If you want to compare notes on a report like that, I’d be glad to hear your thoughts.
I’m Jordan, I help managers in Philippine companies turn what they know into what they do on a normal Monday. After managing people for more than 30 years, one problem keeps showing up in nearly every team I look at: nobody on the team can say, in one sentence, what comes first.
The manager says everything is important. The team hears that and does something sensible. They pick for themselves. Some pick the loudest request. Some pick the easiest task. Some pick whatever their manager asked about last. Nobody is being lazy. They are guessing, because guessing is the only option left.
What the numbers say
A workplace survey by Slingshot found that 62% of workers who carry too many projects lose at least one to two productive hours every day. Asked what would help most, 42% said clear priorities. Gallup has reported for years that only about half of employees strongly agree they know what is expected of them at work. These are not new problems. They are old ones that many managers still treat as a personality issue in their team, when it is usually a clarity issue in the manager’s own instructions.
Why managers avoid choosing
Choosing a top priority means saying no to something. Most managers do not like to say no to a customer, a boss, or a favorite project. So they say yes to everything and let the team sort it out. That feels kind. It is not. It moves the hardest decision from the person who has the authority to the person who has the least.
Another reason is plain fear. If I name one top priority and I’m wrong, that is on me. If I leave it vague, nobody can say I chose badly. Vague protects the manager. It costs the team.
A simple fix: One. Not now. Monday.
You do not need a new tool. You need three small habits.
One. Name the one thing that comes first this week. Not three things. One. If your team had only one hour, what would you want them to spend it on? Say that out loud.
Not now. Write a short list of things that are real but can wait. This is the part most managers skip. The list gives your team permission to stop worrying about those items. Without it, everything stays half-done and heavy.
Monday. Spend five minutes at the start of the week checking that what you said is what your team heard. Ask each person: what is your top priority this week? If their answer is not yours, the problem is not them. Your message did not land. Fix it now, not on Friday.
What this looks like in practice
Picture a team leader whose staff are handling a customer complaint, a month-end report, and a new hire’s training, all marked urgent. If the leader names the complaint as the one thing, puts the training on the not-now list until Wednesday, and tells the team the report can be sent a day late, three people know exactly where to start. Nothing was added. Something was only made clear.
What this is not
It is not a rule that only one thing ever gets done. Work is messy. Emergencies happen. The point is that when everything is urgent, your team is left to rank the work alone. A clear top priority and a not-now list put that ranking back in the hands of the person who should hold it.
Here is a question to carry into this week. Think about your team’s current list. What is one item that everyone calls important but nobody would be upset to see wait until next month?
If you want to talk through your own list, send me a message. I’m glad to think it through with you, no pitch attached.
I’m Jordan Imutan. I train managers across Philippine companies through LeadDaily, a management-execution practice built around one belief: most managers don’t need more leadership theory, they need help applying what they already know to the decision sitting in front of them this week. One of the most common things I see undoing good intentions is delegation that isn’t really delegation at all.
A manager hands someone a task. The task comes back a few days later for approval. It gets sent back with changes. It comes back again. Everyone involved — the manager and the employee — genuinely believes the task was delegated. Neither one notices that the authority to actually decide never left the manager’s hands.
Delegating the work is not the same as delegating the decision
This is the gap that quietly breaks delegation in most companies. A manager says “you own this now,” hands over the task list, and feels like they’ve let go. But if every meaningful choice inside that task still has to come back for sign-off, nothing was actually transferred. The employee is doing the labor of the decision without the authority of it — and that combination produces exactly the bouncing-back pattern most managers complain about.
DDI’s manager-readiness research found that only 19% of manager candidates show strong delegation skills — making it one of the rarest competencies in the entire manager population, rarer than strategic thinking or even difficult conversations. This isn’t a Philippine-specific gap. It’s a global one. But it compounds faster here, where many SMEs are still run by founders who built the company by deciding everything personally, and never had to unlearn that instinct.
What employees actually want, and why it matters to the manager
Gallup has found that 74% of employees say they would take more initiative if they had more decision-making authority. That statistic should reframe how most managers think about the “my team doesn’t take ownership” complaint. In most cases, it isn’t a motivation problem. It’s an authority problem. People do not take initiative on decisions they’ve learned, through experience, will get overridden anyway.
And the cost is not just morale. Forrester’s research on delegation found that tasks delegated without matching authority took 43% longer to complete than tasks where authority moved with the work — because every one of those back-and-forth approval loops is dead time, waiting for someone else’s calendar.
The test that actually tells you whether you delegated
Here is a simple way to check, on any task you think you’ve handed off: if the outcome came back different from how you would have done it, and you let it stand — you delegated the authority. If you would have corrected it, you delegated the labor and kept the authority, whether you meant to or not.
A founder I worked with had handed her operations lead full ownership of the weekly vendor schedule — on paper. In practice, every schedule came back to her for a look before it went out, and about half the time she’d quietly adjust something. Her operations lead noticed the pattern within a month and started sending drafts earlier and more tentatively, asking more questions before committing to anything. The founder read this as a confidence problem. It was actually a completely rational response to watching her own decisions get overridden.
The fix was not a pep talk. It was the founder naming, explicitly, three specific categories of vendor decisions she would never touch again regardless of outcome — and holding that line for two full months, including through two decisions she privately disagreed with. That’s the part most managers skip: the letting-it-stand has to survive a decision you don’t love, or the employee learns the real rule is still “check with me.”
The question to sit with
Think about the last task you delegated that came back for your approval. If the answer had come back different from what you expected, would you have let it stand? If not, what you delegated was the work, not the decision — and that’s worth naming honestly, because the fix is specific, not a personality change.
If you’re working through where to draw that line on your own team, message me. I’m glad to think through the specific decision with you — no sales pitch, just the conversation.
A leadership pilot program — a small test run of a training initiative with one group of managers before it goes company-wide — can prove the idea works. It doesn’t prove the company can run it at ten times the size.
Enterprise scale should be earned through proof, not assumed in the proposal — and that’s true even after the proof shows up.
Why a proven pilot program still isn’t a scaling plan
A pilot program with 20 managers and a rollout to 400 managers aren’t the same program at a different size. They’re two different delivery problems wearing the same curriculum. The pilot ran with one skilled facilitator who knew the material cold, one sponsor paying close attention, and a group small enough that quality control happened naturally. None of that survives multiplying the program by ten without deliberate design.
Three things that quietly break at scale
Facilitator consistency. The pilot facilitator — the person who actually delivers the training — was excellent, maybe the best in the building. At scale, you need five or ten facilitators delivering the same standard, and “find more people exactly like the first one” isn’t a plan.
Measurement discipline. Tracking adoption and evidence for one group of 20 managers is manageable by hand. Tracking it across ten groups of 40 requires a system, an owner, and a rhythm — or the dashboard quietly turns back into a simple attendance report.
Sponsor attention. One executive sponsor could realistically pay attention to one pilot program. Spread across ten sites or functions, that same attention gets diluted fast, and the thing that made the pilot program work — someone who actually cared about the result — gets lost in the handoff.
What earning the right to scale actually requires
Scaling well isn’t bigger budget and more sessions. It requires:
Facilitator enablement — a way to train and calibrate multiple facilitators against the same standard, not just hand them the same slides.
Group-by-group ownership — a named person accountable for each new group added, with clear authority to make changes mid-rollout.
A reporting rhythm that survives size — a dashboard and review schedule built to handle ten groups as cleanly as it handled one, not a spreadsheet someone updates when they remember.
Skip these, and the thing that made your pilot program credible — real evidence, real adoption, a sponsor who cared — quietly erodes with every group you add, until the company-wide version looks a lot like the attendance-driven programs you were trying to avoid in the first place.
The question worth asking before you scale up
If you multiplied your pilot program’s delivery model by ten tomorrow, would the same quality, the same measurement discipline, and the same sponsor attention survive — or would you be scaling the slides and quietly losing everything that made the pilot program work?
If the honest answer is “we’d lose something,” that’s worth designing for now, not discovering after the sixth group has already started. Message Jordan if you’d like to think through what your proven pilot program actually needs to scale without losing what made it work.
The best AI tool for your team is probably one you already pay for and have never properly opened.
That’s not the answer most companies want to hear. It’s a lot more satisfying to picture a custom-built system, something engineered specifically for your workflow, with your logo on the login screen. But for almost every team asking “how do we get started with AI,” the honest answer is smaller and already sitting in their software budget.
The custom-build instinct, and why it backfires
When a company decides to take AI seriously, the instinct is usually to go big. Hire a developer, scope a custom system, connect it to a few internal databases, build something that looks like a real investment. It feels like the responsible, strategic move — the kind of decision a board slide can be built around.
The problem is sequencing. A custom build is the right answer to a question you can only ask after you already know exactly what you’re automating, how people actually do the task today, and whether the time it saves is worth the build. Most companies skip straight to the build before they’ve answered any of that.
I sat with a company last quarter that was six weeks into scoping a custom system for their client onboarding process. Real budget. Real developer hours. Nobody had actually tested whether the core idea — using AI to draft the onboarding packet from a client’s intake form — even worked. They were building the expensive version of an idea nobody had tried the cheap version of yet.
Test the idea before you fund the build
We paused the custom scope for a week and tested the same idea using a tool they already had a license for. One person built a simple AI assistant, fed it five real past onboarding packets as examples, and tried it on the next three new clients.
It wasn’t perfect. The first drafts needed real editing. But within a week, they knew three things the six-week custom scope hadn’t told them yet: the idea actually worked, the time saved was real and worth pursuing, and exactly which part of the draft needed a human’s editing every time.
That’s the information a custom build needs before it gets funded, not after. And it cost them a week with a tool they already owned, instead of a developer contract they hadn’t finished scoping.
Off-the-shelf isn’t the compromise. It’s the test.
There’s a quiet assumption that off-the-shelf tools are the beginner’s version, something you graduate out of once you’re serious. In practice, they’re closer to a prototype: fast to try, cheap to abandon if the idea doesn’t hold up, and genuinely useful if it does.
A custom build locks in assumptions early, because someone has to specify exactly what the system should do before a single line of code gets written. An off-the-shelf tool doesn’t ask you to know that yet. You can change your approach mid-week based on what you’re actually seeing, instead of waiting for the next development sprint to catch up with what you just learned.
For most teams, that flexibility is worth more in the first month than any amount of custom engineering.
The same test works everywhere, not just onboarding
A logistics company I worked with wanted a custom system to summarize daily driver reports for dispatch. Before writing a single requirement document, someone tried feeding a week’s worth of real reports into a tool they already had, just to see if the summaries were usable.
They were, with a bit of editing. That one week of testing told them more about what the eventual system needed to do than the original planning meeting had, and it cost nothing beyond an afternoon.
What actually earns a custom build
None of this means custom development is never the right call. It sometimes is — when a task needs to run thousands of times a day, pull live data from several systems automatically, or write results back into another platform without anyone touching it. Those are real reasons to build something custom.
But notice what they have in common: they’re all things you can only know for certain once you’ve already proven the underlying task is worth automating at all. A custom build is what you fund after the off-the-shelf version has already shown its hand — not instead of it.
A simple test before your next AI decision
Before approving any custom AI project, ask one question: has this exact idea been tried with a tool we already have, even in a rough, unpolished way?
If the answer is no, that’s the next step, not the development brief. A week spent testing the rough version will teach you more than a month spent specifying the polished one — and it will tell you, cheaply, whether the polished one is even worth building.
Most of the AI wins available to a team right now are sitting inside tools already paid for and barely used. The custom build isn’t the beginning of the AI journey. It’s what you earn once the cheap version has already proven itself.
Useful advice. Zero behavior change, until someone tests the rough version before funding the polished one.
Which AI idea on your team has been stuck in the “we should build something for this” conversation, without anyone trying it the cheap way first?
If that question sounds familiar, I’d welcome hearing your thoughts on it.
A leadership pilot program — a small, time-limited test of a training initiative with one group of managers before rolling it out company-wide — can succeed on paper and still tell you nothing. That’s not a contradiction. It’s the most common mistake in program evaluation.
Stop or redesign a pilot program when the conditions it ran under make the result impossible to trust.
Why a “successful” pilot program can still be worthless
Picture this: a 90-day pilot program wraps up, the business indicator moved in the right direction, and everyone’s ready to recommend rolling it out to the whole company. Except the group of managers who took part — the cohort — was hand-picked by supervisors who chose their strongest performers. Or half the cohort missed more than a third of the sessions, and nobody tracked who actually participated versus who showed up once. Or a new system rolled out in the same quarter, and nobody can say how much of the movement came from that instead.
None of these pilot programs failed in the usual sense. They “worked.” The problem is nobody can actually say why — and a result you can’t explain is not evidence you can build a company-wide investment on.
Three conditions that quietly poison a pilot program’s results
Before trusting any pilot program’s result, check for these:
Selection bias. Were participants chosen because they were likely to succeed anyway, rather than representing the real population this program needs to work for?
Inconsistent participation. Did everyone actually complete the assignments and reviews, or did completion vary so widely that the cohort isn’t really one group?
Uncontrolled change. Did something else happen at the same time — a new system, a leadership change, a seasonal swing — big enough to explain the result on its own?
If any of these are true and nobody accounted for them, the honest conclusion isn’t “it worked.” It’s “we don’t actually know.”
The harder, more credible move
It takes real discipline to look at a pilot program with a positive-looking number and say, “this doesn’t prove what we hoped it would prove.” It’s uncomfortable in a room full of people who want a win to report upward. It’s also the only position that protects you six months later, when the company-wide version doesn’t deliver the same result and someone asks why.
A redesigned pilot program — same business priority, cleaner conditions, a real baseline measurement, participants chosen by criteria instead of convenience — costs less than a company-wide rollout built on a number nobody can defend.
Three questions before you recommend scaling up
Before taking any pilot program’s result to leadership as proof, ask:
Were the participants representative of the population this needs to work for, or were they the easiest group to succeed with?
Can we actually account for who did and didn’t engage with the practice, not just who was invited?
Is there anything else happening in the business during this window that could explain the result on its own?
If you can’t answer these with confidence, the pilot program isn’t finished. It’s inconclusive.
A question worth sitting with
If someone challenged your last pilot program’s result and asked you to defend exactly who participated and how consistently — could you?
If the honest answer is “not really,” that’s worth fixing before the next recommendation goes to your board. Message Jordan if you’d like a second opinion on whether your next pilot program’s design will actually hold up to scrutiny.
I train managers across Philippine companies for a living. I’m Jordan Imutan, and I run LeadDaily, a management-execution practice that helps managers apply what they already know on the actual Monday-morning problem in front of them, instead of sitting through one more workshop they’ll forget by Friday. One habit shows up in almost every team I sit in on: the manager who jumps in and solves the problem for the employee, instead of helping the employee solve it themselves.
It looks like good leadership. The manager is fast, decisive, available. The problem gets fixed in minutes instead of hours. Everyone moves on.
But watch the same team a month later, and the same problem comes back — to the same manager’s desk. Nothing was actually learned the first time, because nothing was actually handed over.
The rescue feels like help. It functions like a tax.
Every time a manager solves a problem instead of coaching someone through it, they are not saving time. They are borrowing it from their future self, with interest. The employee learns one lesson very clearly: when something gets hard, hand it up. The manager becomes the single point of failure for every decision that matters, and the team’s actual capability never grows past whatever the manager personally has bandwidth to carry.
Forrester’s 2025 workplace research found that 54% of employees now describe their manager as a coach, up from 50% the year before — and the employees who experience real coaching are roughly 8 times more likely to be highly engaged, and 1.7 times more likely to stay with the company. The gap between a manager who fixes and a manager who coaches is not a soft, feel-good distinction. It shows up directly in retention and output.
Why managers rescue, even when they know better
It is rarely laziness or ego. It is almost always one of three things: the deadline is real and coaching takes longer than fixing today; the manager was never shown what coaching actually sounds like, so “helping” defaults to “doing”; or the manager has been burned before by delegating and watching the result come back wrong, so they stopped trying.
All three are solvable. None of them require a personality change. They require a different first move.
The first move: ask before you answer
The shift is smaller than it sounds. When someone brings you a problem, the rescuing response is to ask “what’s wrong?” and then start solving. The coaching response is to ask “what have you already tried?” and then “what do you think the next step is?” before you say anything close to an answer.
This does three things at once. It surfaces how much the person already understands, which is usually more than the manager assumes. It gives the manager a chance to correct direction without taking over the wheel. And it puts the decision — and the ownership of the outcome — back where it belongs.
A supervisor I worked with in a logistics company used to personally re-route every delayed shipment herself, every time, because “it was faster if I just did it.” The team’s planners never built the judgment to re-route on their own, because they never had to. Six months after she switched to asking two questions before touching the problem — what’s the constraint, and what’s your call — her planners were resolving 70% of delays without escalating to her at all. She didn’t become a softer manager. She became a less necessary one, in the best possible sense, and that is what freed her to actually run the operation instead of patching it.
What this is not
Coaching is not standing back while someone fails badly on something that matters. It is not refusing to answer a direct, reasonable question just to prove a point. If the building is on fire, you put it out. The distinction is between problems where the cost of the person figuring it out is worth paying — which is most problems, most of the time — and the rare one where it genuinely is not.
Most managers already know this distinction intellectually. The habit of rescuing survives anyway, because nobody ever sat them down and asked: on the last ten problems your team brought you, how many did you actually need to solve yourself?
The question worth asking this week
Pick one recurring problem that keeps landing on your desk from the same person or the same team. Before you touch it next time, ask yourself: if I don’t solve this today, who on my team is closest to being able to solve it — and what is the one question I could ask them instead of the one answer I’m about to give?
If you want to think through that specific situation, send me a message — I’m glad to help you work out what the right next question actually is. No pitch, just a conversation.
You don’t need AI to do your job. You need it to do the part of your job you’ve stopped noticing you hate.
That’s the mistake behind most AI rollouts that quietly go nowhere. Someone pictures AI taking over a whole role — the thinking, the judgment calls, the relationships that come with the title — and when that doesn’t happen cleanly, the whole effort gets written off as “not ready yet” and shelved.
But a role was never the right unit to automate. A task is.
Every job is really two jobs stacked together
Look closely at almost any role, and you’ll find it’s made of two very different kinds of work. One part is judgment: reading a room, deciding what matters, weighing a trade-off nobody wrote down the rules for. The other part is repetition: pulling the same numbers, writing the same kind of update, reformatting the same report, answering the same three questions in a slightly different order every time.
The judgment part is what the person was actually hired for. The repetition part is what quietly eats their week.
Most companies try to hand AI the whole job at once. A smaller number hand it nothing at all, worried about losing the judgment part entirely. Almost nobody stops first to separate the two.
A finance manager, not a finance job
I worked with a finance manager recently whose week revolved around a Friday report. The report itself required real judgment: flagging which numbers mattered, deciding what to escalate, framing a recommendation for leadership. That part was the job. Nobody wanted AI anywhere near it.
But building the report took her close to four hours every week — pulling data from three different systems, formatting the same tables the same way, writing the same three boilerplate paragraphs that opened each section. None of that required her judgment. It required her patience.
So we didn’t ask AI to write her recommendation. We asked it to assemble the raw report: pull the numbers, format the tables, draft the boilerplate. That freed her four hours to spend on the one hour of actual thinking the report had always needed from her.
That’s the twenty percent. Not twenty percent of her time — twenty percent of the task. The mechanical slice sitting underneath the judgment slice. The part that was never really her job to begin with, just the toll she paid to get to it.
The same pattern shows up almost everywhere
Once you start looking for it, the pattern repeats across every department.
An HR coordinator screening résumés isn’t really being paid to read five hundred of them. She’s being paid to recognize the dozen worth a second look. The first pass — checking for basic requirements, sorting by years of experience, flagging obvious mismatches — is the mechanical slice. The judgment happens after that, in the dozen she actually reads closely.
A sales manager isn’t paid to type up call notes. He’s paid to notice which deal is quietly slipping and decide what to do about it. The notes are the toll. The read on the deal is the job.
In every case, the twenty percent looks different, but the shape is the same: a mechanical task that has to happen before the real thinking can start, consuming hours that were never buying anyone anything.
Why the whole-job approach keeps failing
When companies try to automate the entire role instead of the mechanical slice, three things tend to happen.
The judgment part gets automated badly, because AI doesn’t actually have the relationship history, the political context, or the accountability a person carries into that decision. The team notices the output feels shallow, and trust collapses — not just in that one task, but in AI generally, for everything that follows. And the real time-waster, the repetitive mechanical slice, never actually gets touched, because everyone was too busy arguing over whether AI should be allowed anywhere near the judgment call in the first place.
Meanwhile the twenty percent just sits there, quietly costing four hours a week, untouched the whole time.
How to find your own twenty percent
You don’t need a consultant in the room to spot this. Pick any task on your plate that regularly eats more time than it should, and ask one question: which parts of this would look identical no matter who did them, and which parts would look different depending on who’s in the chair?
The parts that would look identical no matter who’s doing them — the formatting, the pulling, the first draft of a paragraph everyone writes the same way — are your twenty percent. The parts that would look different depending on the person are not. Those stay exactly as they are.
Try it on one task this week. Write down the steps, start to finish. Circle the ones that only exist because of who you are — your judgment, your relationships, your accountability. Everything left uncircled is worth a second look.
What this actually buys you
The finance manager didn’t get her whole week back. She got four hours back, every week, that used to disappear into formatting and assembly. She still owns the report. She still makes the call. She just stopped paying a four-hour toll to get there.
Multiply that across a team, and the math gets interesting fast — not because AI did anything dramatic, but because somebody finally separated the boring twenty percent from the job that actually mattered.
There’s a second benefit that’s easy to miss. When a team sees AI take over the four hours nobody wanted and leave the one hour that mattered untouched, trust builds fast. Nobody has to defend the judgment call, because AI was never anywhere near it. That’s often what makes the next task worth looking at — not a bigger rollout, just one more twenty percent, proven the same simple way.
The instinct to protect judgment work from AI is the right instinct. The mistake is assuming that protecting it also means leaving the mechanical slice untouched. They are not the same thing, and treating them as one is why so many AI efforts quietly stall before they start.
Useful advice. Zero behavior change, until someone sits down with one real task and actually draws the line between the two.
Which twenty percent of your own week is mechanical enough that it shouldn’t need you — and how long has it been sitting there anyway?
If this made you think of a task worth pulling apart, I’d be glad to hear your thoughts on it.
Some organizations aren’t ready for a leadership program. They’re ready for an inspirational afternoon, and that’s a different purchase.
There’s nothing wrong with wanting a good speaker and a motivating day. The problem is buying that experience and expecting it to behave like a program that changes how managers work. The two rarely disappoint for the same reasons, but they disappoint for entirely predictable ones.
The readiness check most companies skip
Before committing to a leadership program, a handful of honest questions will tell you more than any vendor’s proposal:
Is there a business priority — cycle time, complaints, rework, sales follow-through — that this program is actually meant to move? Or is the goal just “better leaders,” with no number attached?
Is there an executive sponsor willing to require participation and make the result their own, not just approve the invoice?
Will managers actually get access to baseline data and time to apply what they learn, or is everyone already stretched thin with no room for anything new?
Is the desired change something managers can actually control, or does it depend on decisions made two levels above them?
If most of these come back “no” or “not really,” the honest answer isn’t “don’t invest in your people.” It’s “this isn’t the right investment yet.”
What an unready organization usually looks like
A few patterns show up again and again in organizations that aren’t ready, even when the intent is genuinely good:
The desired result is vague and politically unsafe to measure — everyone agrees “we need stronger leaders,” but nobody can name the specific number that would prove it worked, because naming it would mean someone has to be accountable for it.
The only thing everyone can agree on is the inspirational event. There’s real enthusiasm for a keynote speaker and a workshop day, and real resistance the moment anyone suggests homework, follow-up, or measurement.
Nobody with real authority is willing to require participation. The program becomes optional in practice, even if it’s mandatory on paper — and optional development gets deprioritized the first time a deadline collides with it.
None of these are reasons to give up on developing your people. They’re reasons to fix the conditions first, so the investment actually has a chance to work.
What to do if you’re not ready yet
If your organization is short on one or two of these conditions, that’s fixable, usually faster than you’d expect: name the one number this initiative should move, even roughly. Find the one executive willing to own that number publicly. Agree, before you spend a peso, on how you’ll know if it worked.
That’s a shorter conversation than most companies expect — and it’s far cheaper than discovering the gap after the program has already launched.
A quick honest check before you spend the budget
Before your next leadership program is approved, ask the room: if we ran this exact program today, would anyone be able to tell us, in plain numbers, whether it actually worked?
If the honest answer is no, that’s the conversation worth having first — not a reason to cancel the idea, just a reason to fix the foundation underneath it. Message Jordan if you’d like a second opinion on whether your organization is ready for this investment, or what needs to be true first.
