DEV Community: Todd 🌐 Fractional CTO

Your Best Prompts Stopped Working

Todd 🌐 Fractional CTO — Tue, 13 Oct 2026 14:00:00 +0000

How a silent model update breaks stable workflows, and the system that catches it

Your best prompt ran beautifully in January. You standardized it, dropped it into the workflow, and moved on. Now it’s June, the prompt reads exactly the same, and the output is worse. Nobody touched the text. So what broke?

The platform did. Most teams treat the AI platform they log into and the model doing the actual work as one thing, when they are two separate parts. The platform is the interface and the account. The model is the engine, and platforms swap that engine often, usually without an announcement. Your prompt sat still while the thing reading it changed underneath. That is where a model update changes your results without changing a single word you wrote.

The Model Is an Input, and It Keeps Moving

In any repeatable process, you track the inputs that affect the output. A factory measures its raw materials. A finance team reconciles its numbers before close. With AI, the model is one of those inputs, and it moves on a schedule you don’t control. A model update can land in the middle of your quarter and shift tone, length, formatting, and accuracy across every prompt you run, all at once.

The common reaction is to blame the prompt. Teams retrain it, expand the library, tweak the workflow, and brace for the same scramble three months later. That work feels productive, and it rarely holds, because the prompt was doing its job the whole time.

Document a Baseline You Can Trust

You can manage this the way you manage any other moving variable. Start with a baseline. Run your core prompts today and save the outputs as your reference standard. Note the date, the platform, and the model version if the platform shows it. Keep a few representative examples for each high-value prompt, the handful your business actually depends on. Screenshots or saved text files both work, as long as you can find them again when you need to compare.

A baseline turns a vague feeling into something you can check. Without it, “the output seems off lately” is a hunch you can’t act on. With it, you hold June’s result next to January’s and see exactly what moved, and by how much.

Run the Audit on a Schedule

Drift arrives gradually, so you catch it on a rhythm rather than by luck. Pick an interval that matches how heavily you rely on the output. Monthly works for most teams. Re-run your baseline prompts, compare the new results against your saved reference, and log anything that shifted.

Most months nothing meaningful changes and the whole review takes twenty minutes. The value shows up the month a model update lands. You catch the drift inside a scheduled check rather than inside a client deliverable or a board-ready report, which is a far cheaper place to find it.

Diagnose Drift Before You Rewrite

When something does shift, hold off on rewriting the prompt first. Work through the diagnosis in order. Confirm the output genuinely changed against your baseline. Check whether the platform announced or hints at a new model version. Run the same prompt on a different model if the platform lets you switch. Only then do you decide whether to adjust the prompt, pin a specific model version, or accept the new behavior as your standard.

Write the steps down once and follow them every time, so the diagnosis takes minutes and never depends on who happens to notice the problem. That sequence keeps you from rebuilding a library that was working fine. Half the time the real fix is selecting the previous model version, and the prompt library never needed touching at all.

Manage It Once Instead of Solving It Forever

Skip all this and every drift becomes a fresh emergency. You re-solve the same problem each quarter and call it maintenance. Build the baseline, the audit, and the diagnosis, and that recurring fire becomes a predictable line item on your operations calendar. The teams I work with who run this stop dreading platform updates, because a model update turns from a surprise into one more thing they already account for. The model behind your platform will keep changing. What changes for you is the ability to see it coming, measure it, and respond on your own terms. That is what separates a workflow you trust from one you keep apologizing for.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

The Fortune 100 AI Skills Library™ includes plug-and-play prompts built to save leaders time and money. Copy, paste, and edit in 60 seconds, then apply them across planning, execution, and reporting.

The AI Time Savings Nobody Is Counting

Todd 🌐 Fractional CTO — Tue, 06 Oct 2026 14:00:00 +0000

How to measure where AI nets you time and where it adds hidden work to your team

A team lead tells you the group saves ten hours a week with AI. The number is clean. It goes straight into the ROI deck and nobody questions it.

Spend a few days watching the actual work and that ten splits in two. Five hours genuinely leave the week. The other five go to catching what the AI got confidently wrong, reworking a draft that read well and said nothing, and re-checking figures that looked plausible. The headline still says ten. The number you can trust is five.

The figure most teams report is the gross one

Workday put a measurement on this gap. In a January 2026 study of 3,200 workers and leaders, the company found that for every ten hours of efficiency people gain from AI, nearly four hours go back into fixing the output. They called it the AI tax on productivity.

The surface story looks great. Eighty-five percent of workers said AI saved them somewhere between one and seven hours a week. Dig one layer down and it gets sober fast. Only fourteen percent came out consistently ahead once the rework was counted. Most teams are reporting the first number and living the second.

There’s a name for what creates the tax

Researchers at BetterUp Labs and Stanford’s Social Media Lab named this in Harvard Business Review back in September 2025. They called it workslop: AI-generated content that looks like good work but carries no substance to move the task forward.

It reads fine. It passes a glance. Then the person who receives it spends close to two hours working out what’s missing and rebuilding it. The effort doesn’t disappear when AI produces the draft. It moves downstream to whoever has to make the draft real.

The ROI question worth asking

Whether AI saves time overall is a question with an easy answer, and the easy answer tells you nothing useful. It almost always saves time somewhere. That fact alone gives you no way to decide where to point it.

The useful question is narrower. Which task types come out net positive after rework, which break even, and which cost more than doing the work by hand? Answer that and you stop debating AI in the abstract and start making decisions about specific work.

Run the audit by task type

Some categories reliably net out. Rule-bound data tasks net out when the inputs are clean and the rules are explicit, work like reformatting, sorting, or pulling fields from a structured source. So do templated communications that follow a known format, and first-draft outlines built from a detailed brief. The common thread is constraint. Give the task tight edges and the model has less room to be confidently wrong, so the rework stays low.

Other categories bleed time. Nuanced brand writing leans on voice and judgment the model can’t fake. Work that depends on current institutional knowledge runs into the simple fact that the model never had it. And anything that has to match one specific person’s voice closely enough to publish usually comes back needing a rebuild. The draft looks finished. It isn’t. Someone reworks most of it while the timesheet still records a saving.

The honest test for any task is small. Track the hours the AI saves on it, then track the hours your team spends correcting, verifying, and rewriting the output. The gap between those two numbers is the only productivity figure that matters, and it varies wildly by task. Two tasks that both “use AI” can sit on opposite sides of break-even.

What to do with the breakdown

Once you can see which tasks net out, the workflow decision gets simple. Point AI at the low-rework work and let it run. Put a tighter review gate on the high-rework work, or keep it human until the brief and the source material are good enough to change the math. Stop counting hours saved and start counting hours saved minus hours spent fixing. That second number is the one that shows up in your margins.

There’s a cost beyond the math. The Workday data found that the most engaged people absorb the most rework, because they’re the ones using AI hardest and reviewing it most carefully. Run that for a year without redesigning the work and your best people are doing two jobs at once, generating output and then validating it. That’s how a productivity tool becomes a burnout engine.

The teams getting real leverage from AI have narrowed it to the work where it nets out, measured the rework honestly, and pointed the tool there on purpose. The ten-hour number felt good. The five-hour number is the one you can build on.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

A Prompt Library Is Not an AI System

Todd 🌐 Fractional CTO — Tue, 29 Sep 2026 14:00:00 +0000

Why saved prompts get abandoned in weeks, and what replaces them

Most teams build a prompt library the same way. Someone opens a Notion page or a shared Google Doc, drops in a dozen good prompts, and asks everyone to add their best ones. For three or four weeks, people use it. Then the page goes quiet, and everyone drifts back to typing requests from scratch.

Where the friction actually comes from

The reason is mechanical, and it shows up the same way across companies. To use a saved prompt, you have to leave the tool you are working in. Open the document. Scroll to find the right entry. Copy it. Paste it into the model. Run it. Then carry the output back to where you started. For a task you do once a quarter, that sequence is fine. For a task you do three times a week, it is too many steps, and people quietly stop paying the tax. As the team at ALM Corp puts it in their breakdown of prompt library burnout, the best AI process is usually the one with the least unnecessary movement.

It helps to be precise about what the actual problem is. The library was built to solve a memory problem. It assumes the hard part is remembering what a good prompt looks like. For most skilled people, that was never the hard part. They can write a decent prompt in thirty seconds. What slows them down is the friction of starting, the small overhead of having to think about how to begin a task before they can begin it. A library does not remove that overhead. It adds a detour.

So the question changes. Instead of asking how to store better prompts, ask where the prompt should live so nobody has to go find it.

Move the prompt to where the work happens

That single shift is what separates a working AI setup from a shared document. Teams that get consistent output have stopped treating prompts as reference material. They embed them inside the tools where the work already happens. The prompt becomes a default template that loads when a task opens. It becomes a slash command that runs in place. It becomes a saved instruction attached to a project, so the context travels with the work instead of waiting in a file somewhere.

A few concrete examples make the difference clear.

The marketing lead who kept a “blog brief prompt” in Notion now has that prompt set as the default template inside the content tool. A new draft opens with the brief structure already in place, with no tab switch and no copy step.

The sales rep who saved a “follow-up email prompt” now triggers it as a command inside the CRM, where the call notes and deal stage are already loaded. The context that made the original prompt work is present by default, so the output stays consistent across reps.

The support team that stored reply prompts in a wiki now runs them from inside the help desk, with account history and policy rules attached to the workflow itself.

In each case the prompt text barely changed. What changed was its location. It moved from a place people had to visit to a place they already were.

From five hundred prompts to twenty that get used

This is why prompt count is a poor measure of progress. A company with five hundred saved prompts and shrinking usage has built an archive that holds instructions without producing work. A company with twenty prompts embedded where work happens has built leverage, because every one of those prompts gets used without anyone deciding to use it.

If your team already has a sprawling library, the move is not to delete it. The useful parts are still useful. Audit it for the prompts that actually get reused, group them by the recurring jobs they support, and then place each one inside the tool where that job gets done. Most of the value was always sitting in a handful of repeated tasks anyway.

A prompt library answers the question of what to tell the model. A system answers a larger one, which is how a specific task gets done, by this person, in this tool, with the context already in hand. Documents wait to be opened. Systems run. That is the whole difference, and it is the reason one keeps getting used while the other slowly empties out.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

Are Your AI Adoption Numbers Wrong?

Todd 🌐 Fractional CTO — Tue, 22 Sep 2026 14:00:00 +0000

Why license dashboards hide what your team is really doing with AI

A team lead checks the dashboard, sees that 40 percent of seats are active, and calls that the adoption number. It feels precise. It usually is not.

Here is what the seat count cannot see. Shadow AI research in 2026 found that 65 percent of employees reach for public AI tools instead of the ones their company approved. Plenty of them are loading real work into those tools, including customer records, financial details, and internal strategy documents. The official dashboard registers none of it.

So the 40 percent is wrong in two directions at once. Some of those active seats belong to people who open the tool, poke around, and accomplish almost nothing. Meanwhile, a chunk of the people counted as non-adopters are running careful, repeatable workflows on personal accounts you cannot audit. Real usage is higher than you think and messier than you hoped.

What the dashboard actually measures

License activity tells you who logged in. It says nothing about who built something useful.

That gap matters because the two groups need opposite things. The person with an active seat and no output needs help finding a first real use. The person running a private workflow on a personal account needs that work brought into the open before it creates a problem. Treat them as one number and you serve neither.

The legal and reputational exposure sits with the second group. When someone pastes a client contract into a consumer chatbot, the data leaves your control and the record of it leaving never reaches you. You find out when something breaks, not before.

Why the security conversation stalls

The usual response is a policy memo. Stop using unapproved tools. Stick to the approved stack. Compliance signs off, the memo goes out, and very little changes.

It stalls because the memo asks people to give up something that works without handing them anything better. The marketer drafting campaigns in a personal account is faster with it than without. Telling that person to stop, with no replacement, asks them to choose between the rule and their own output. Most people just choose their output.

This is where I see leaders lose the thread. They frame a workflow problem as a discipline problem. Discipline problems get solved with rules. Workflow problems get solved with better workflows.

The real issue is consistency

Picture ten people on a team, each running a separate unofficial AI setup. Different tools, different prompts, and different standards for what good looks like. Nobody can see anyone else’s process, so nobody can borrow it.

That fragmentation costs more than any single data leak. There is no shared quality bar, so output swings wildly between people. There is no repeatable system, so a strong method one person discovers stays trapped with that person. There is nothing common to improve on, which means none of the private wins ever compound. You have ten experiments and zero shared progress.

A team that shares one workflow gets the opposite. A prompt that works gets refined by the next person who uses it. A weak output gets caught against a known standard. The system improves because everyone feeds the same system.

Build the version worth switching to

The fix starts by accepting what the data already shows. People want these tools and will use them with or without permission. The job is to make the sanctioned path the obvious choice.

That means building an official workflow that beats the personal one on the merits. It should run faster on the tasks people actually do, come stocked with prompts and templates tuned to your work rather than generic ones, and connect to your real context so the output needs less cleanup. When the approved option genuinely wins, the personal accounts empty out on their own, and the data risk drops as a side effect rather than a fight.

Start by finding the people already running good private workflows. They have done the hard part for you. Ask what they built, why it works, and what made them skip the approved tool. Their answers are the spec for the system everyone should be using.

The number on your dashboard was never the real story. The real story is whether your team shares a way of working that gets sharper every week, or ten separate ones that go nowhere. One of those scales, and you get to decide which.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

How to Decide Which AI Platform Gets Which Creative Work

Todd 🌐 Fractional CTO — Tue, 15 Sep 2026 14:00:00 +0000

A decision method for marketing teams who keep buying tools instead of making the call

You already pay for three AI platforms. One of them is open in a tab right now, and that tab is about to catch the next campaign brief for no reason other than it was closest. Nobody chose it. Proximity chose it.

Do that a few dozen times a week across a team and you get exactly what you’d expect. Output that swings in quality, a vague sense that the tools are inconsistent, and a running argument about whether to buy a better one. Skip that argument. Decide which tool you already own does which job, and write it down where everyone can see it.

You see it in the work. A landing page that reads sharp one week and flat the next, same writer, same brief, different tool. A deck that looks polished until someone clicks through and half the structure doesn’t hold. The team chalks it up to the AI being unreliable. The AI was fine. The routing was random.

Stop asking what each platform is good at

The marketing pages already answered that, and the answer is “everything.” More useful is knowing how each one fails, because failure is consistent and you can build around it.

Run one real task through all three and the differences land fast. Claude produces visually complete work with genuine design instinct, and will happily overcook something you wanted fast and rough. ChatGPT reaches for the generic and hands back pieces that look right and don’t actually function. Gemini gets it done and stops at functional, skipping the refinement that makes work feel finished.

None of that stays in the design lane. The platform that over-polishes a logo over-polishes your positioning. The one defaulting to generic layouts defaults to generic copy. Ask the generic one for a competitor teardown and you get a tidy summary with no teeth. Ask the one with instinct and you get a read you can actually use, or argue with. Pick the strength you want and you inherit the blind spot attached to it.

Decide which failure you can eat

Here’s the whole method. Take the work your team does most, and ask which failure you can live with on it.

High-volume social copy? A generic first draft is fine, because someone edits it anyway, and speed beats polish. Client-facing campaign concepts? You can’t ship something that looks right and breaks on contact, so you pay for the stronger instinct even when it runs slower. The middle stuff, research synthesis, recaps, drafts you’ll rewrite regardless, goes wherever, because your edit covers the gap.

Put it on one page

The map is boring to look at, which is the point. Concepts, mockups, and positioning go to the platform with instinct. Volume copy, recaps, and first drafts go to the fast one. Everything you rework anyway goes wherever’s convenient. One page, listing the work, the tool, and the reason, because the reason is what lets the next person fix the map when a model changes under them.

What you get for the trouble

Better output from the same people, the same subscriptions, the same prompts, because each task lands on the tool least likely to wreck it. The weekly tool argument dies, since the call already lives on the page. New hires inherit it on day one instead of learning it the hard way over a quarter.

That’s the trade. Ten minutes of testing and one page against a quarter of uneven work and a subscription you were about to buy for no reason. Make the call once. Then go do the work.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

4 Ways Team Leads Can Model AI Use to Drive Adoption

Todd 🌐 Fractional CTO — Tue, 08 Sep 2026 14:00:00 +0000

The visible habits that drive AI adoption faster than any all-hands announcement

When managers actively model AI use, their teams report a 17-point lift in how much they value AI, a 22-point lift in critical thinking about it, and a 30-point lift in trust in agentic systems. Those figures come from a Microsoft People Science study of 1,800 workers, cited in the 2026 Work Trend Index. The same report found only one in four employees say their leadership is clearly and consistently aligned on AI.

Most team leads have already done the obvious work. They approved the tools. They sat through the kickoff and sent the all-hands update. What they have not done is change how they work in front of the people watching them.

Executive sponsorship tells a team that AI matters. Modeling shows them what working that way looks like at their own level. That gap is most of what separates real AI adoption from a stalled rollout. Here are four habits that make your AI use visible without a single announcement.

1. Run Your Briefings With AI in the Room

Most leads prepare the summary, the analysis, or the plan in advance, then walk in with a clean result. The team sees the output and learns nothing about how it came together.

Open the tool live instead. Start the briefing by building the first pass while everyone watches. Type the prompt in front of them. Let the draft come back rough, then refine it on the screen.

What the team picks up is the part that usually stays hidden. They see how you frame a question, where you push back on the model, and how many passes a decent answer actually takes. That is the reference point they have been missing.

Pick a recurring, low-stakes briefing to start. A weekly status roundup or a project recap works well, since the cost of a clumsy first attempt is close to zero. Once the rhythm feels natural, bring it into higher-stakes rooms where the modeling matters more.

2. Share the Prompt and First Output on High-Stakes Work

When you send around a polished deliverable, you teach the team that good AI work arrives finished. They have no idea what it took to get there, so they assume their own messy drafts mean they are doing it wrong.

Attach the prompt and the raw first output next to the final version. A short note is enough. Show what you asked for, what the model gave back, and what you changed before it was ready to ship.

That mirrors how careful AI users already work. In the Work Trend Index, 86% said they treat AI output as a starting point and stay responsible for the thinking. Sharing your own process gives the team a working template they can copy on their own deliverables.

Save this habit for work that carries real weight. A board summary, a customer proposal, a technical decision document. The higher the stakes, the more your visible process reassures people.

3. Say It Out Loud When AI Gets Something Wrong

The instinct is to fix a bad AI answer without comment and move on. That habit hides the single most valuable skill you can model, which is judgment.

When the model invents a number, misreads the context, or confidently produces something off, name it in the moment. Tell the team what looked wrong and how you caught it. Walk them through the check you ran before you trusted the output.

Doing this in the open reframes what competence with AI means, away from clean first-try answers and toward knowing when to push back. Your team learns that catching the model’s mistakes is the job, and that the people who do it well are the ones worth following.

Quality control of AI output and critical thinking now rank as the two human skills professionals say matter most as AI takes on more work. You cannot lecture those skills into a team. You can show them every time you question an answer out loud.

4. Use AI Live During Team Reviews

Plenty of leads use AI heavily and still do all of it offstage. The team never sees the tool touch the work that gets reviewed, so they file it under personal productivity rather than real decision-making.

Bring it into the review itself. During a roadmap discussion or a design critique, pull up the model and pressure-test an assumption in front of everyone. Ask it to argue the opposite case. Have it surface the risks nobody in the room has raised yet.

You want AI participating in the decisions that count, while a group of people watch and weigh in. That positions the tool as something you reason with, rather than a shortcut you hide. Used this way, it raises the quality of the conversation instead of replacing it.

Start with reviews where the team already trusts your judgment. When they see you treat AI as another voice in the room, one you still overrule when it earns it, they start doing the same in their own work.

The Reference Point Only You Can Set

Every one of these habits does the same work. It gives your team a picture of what working with AI looks like at their level, performed by someone whose judgment they already respect.

Tools and training tell people AI is available. Your behavior tells them it is safe, expected, and worth getting good at. That signal carries further than any policy, because people copy what their lead does long before they act on what their lead says.

You do not need a new initiative to start. Pick one of these four for next week and let the team watch you work. The lift in trust, thinking, and value comes from watching you do the work, which lands harder than anything you could announce.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

Why You Should Stop Trying to Be a Better Prompter

Todd 🌐 Fractional CTO — Tue, 01 Sep 2026 14:00:00 +0000

Framing the problem now matters more than crafting the prompt

In 2024, the person on your team who wrote the cleanest prompts got the best output. They knew the role-play openers, the few-shot examples, the formatting tricks that nudged a model toward a usable answer. But those tricks eventually stopped working because the models got better at the thing the tricks were compensating for.

For example, “think step by step” gave older models a measurable bump because their default reasoning ran shallow. Today’s reasoning models do that work internally whether you ask for it or not.

Andrej Karpathy started using “context engineering” in place of “prompt engineering,” and the change in language tracks a real change in where the value sits. Here is where most teams are stuck. They are still running training built for the 2024 version of the problem, the prompt libraries and magic-phrase cheat sheets and internal workshops on how to talk to ChatGPT. All of it sharpens a skill whose return shrinks every quarter.

The question worth handing AI

The more productive structure in 2026 reads less like an instruction and more like a brief. How might we achieve this objective, given these constraints?

That framing does three things a polished prompt does not.

1) It generates options rather than one rigid answer. Ask for the answer and you get the answer. Ask how you might get there and you get three or four routes worth comparing, which is what you actually want when the path is not obvious yet.

2) It forces real constraints into the room. Budget, timeline, the headcount you actually have rather than the one you’d staff in a perfect world. A prompt tuned for the cleanest possible output tends to assume that perfect world exists. A well-framed problem carries the friction with it.

3) It keeps AI in strategist mode before it drops into executor mode. The fastest way to get a confident, wrong answer is to hand a model a task before anyone has agreed on the objective. Framing first, execution second. The order matters more than the wording ever did.

What this changes for a team lead

If you run a function, the implication lands close to home. A team of skilled prompters scales only as far as its most patient member can sustain. Real leverage shows up when the whole team can hand AI a well-framed problem and judge what comes back.

Those are two separate skills, and the second is the rarer one. Framing a problem well means stating the objective plainly and naming the constraints honestly. Evaluating the output means knowing enough about the domain to catch where the model is confidently off. Neither skill lives in a prompt library. Both of them carry across every model you will ever use, which is the part that makes them worth building.

I have watched capable teams pour months into prompt training and come out with people who can coax a decent paragraph out of a chatbot. Useful, briefly. Then the model updates, the old tricks stop landing, and the training starts over. The teams that invested in problem-framing and output evaluation never had to rerun anything. Their skill survived the version bump.

Make it the default, not a personal habit

Most people reading this already frame problems this way on their best days. The work now is moving it from a personal habit to the team’s default.

That shows up in what you ask for in a meeting. When someone brings you an AI result, the question to ask is what objective and constraints they handed the model, and how they checked what came back. Ask that consistently and people start framing before they type, because they know the framing is what you will inspect.

Prompt skill was always going to be temporary. It was a feature of one particular moment in the technology, and that moment is closing. The skill underneath it, defining a problem clearly enough that a capable system can solve it, has been valuable for as long as people have delegated work. AI just raised the price of doing it badly.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

More Connections Won’t Make Your AI Smarter

Todd 🌐 Fractional CTO — Tue, 25 Aug 2026 14:00:00 +0000

Why a leaner tool stack outperforms a maximally connected one, and how to trim yours

In June, David Cramer did something that looks like a mistake. He nearly halved the number of tools his company’s AI could see at once.

Sentry’s AI agent used to see 14 tools every time it ran. Cramer’s team cut that default down to 8 and tucked the rest behind a layer the agent only reaches for when a task actually needs them.

The agent did not get weaker. It got sharper, with fewer wrong calls, faster responses, and more reliable output.

Most mid-market teams are running in the opposite direction. Marketing and ops leads are wiring their AI into Salesforce, HubSpot, Slack, the CMS, the analytics dashboard, and the project tracker, working from the idea that more connections means more capability. The research keeps landing on the other side of that bet.

Why more tools make your AI worse

The numbers are blunt. Independent analyses of production agents point the same way. They run best with three to five tools, and quality drops sharply once the count passes twenty. A separate test watched accuracy fall off a cliff rather than slide down a ramp, holding strong at ten and twenty tools, then collapsing around a hundred. In one experiment, a strong model’s accuracy on a scheduling task dropped from 43 percent with four tools to 2 percent once the count climbed past fifty. Somewhere along that curve, adding capability stopped helping and started breaking the thing you built.

Picture a sharp new hire on their first day. Give them one clear task and the two tools they need, and they move fast. Hand them that same task plus a hundred-page binder describing ninety other tools they could theoretically use, and watch them slow down. They read the binder. They second-guess. They reach for the wrong thing. Your AI behaves the same way. Every connection you add is another page in the binder it has to consider on every single request.

So the real question for a team lead stopped being how much you can connect. The better question is which connections actually carry weight in the work you do. That sounds abstract until you run the audit.

Run the audit before you add anything else

Open a document and list every AI integration you currently have live. Next to each one, write the specific task it performed in a real workflow this week. Real tasks only. “Pulls the deal stage from Salesforce into the Monday pipeline summary” counts. “Connected to HubSpot” just tells you a wire is live somewhere in your account.

Most teams find half their list falls into that second group. The connection exists because it was available and easy to switch on, never because a repeatable workflow leans on it.

Decide what is load-bearing

A load-bearing integration is one where a real process breaks if you remove it this week. That is the whole test, and you run every item through it.

If pulling an integration would stop a report from generating, block a handoff, or leave a customer waiting, it stays. If pulling it would change nothing you would notice by Friday, it goes on the cut list. Be honest about the gap between a connection you use and a connection you simply like having around. Your AI does not care that the Slack integration feels modern. It sees one more option competing for attention every time you ask it to do something.

Most stacks have three to six integrations doing genuine work, plus a long tail doing nothing but adding noise.

Trim, then retest

Turn off everything that failed the load-bearing test. Do it in one pass rather than gradually, so the difference is easy to feel. Then run your normal tasks for a week and watch response speed and error rate. Both should improve. If some workflow you forgot about does break, you have just learned that integration was load-bearing after all, and you switch it back on with evidence instead of habit.

Cramer’s team did not guess their way to a leaner setup. They measured, cut back what the agent had to weigh, and watched the output improve. You have the same option, and it costs you nothing beyond the comfort of a long integration list.

The instinct to connect everything comes from a good place. You are trying to build leverage, to get the AI doing more of the work so you can do less of it. A bloated stack hands you the feeling of leverage while taxing every output behind the scenes. A lean one hands you the real thing. The fastest, most reliable AI setup in your business is almost certainly smaller than the one you are running today, and getting there is mostly a matter of deleting.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

Why Your AI Output Sounds Like Everyone Else’s

Todd 🌐 Fractional CTO — Tue, 18 Aug 2026 14:00:00 +0000

Building the AI context layer that turns generic answers into brand-specific work

Most teams that bought AI tools this year came away disappointed. The 2026 State of AI for GTM report, where Kyle Poyar and Maja Voje interviewed thirty leaders and collected forty working plays, put a number on it. Fifty-three percent of go-to-market leaders said AI delivered little to no impact. Only 24 percent reported real returns.

Read that again. Three out of four teams spent money and saw nothing move.

Here is the part that should bother you. Everyone in that survey had access to the same models. Same ChatGPT, same Claude, same Gemini. The teams seeing returns and the teams seeing nothing were typing into identical tools. So the gap was never about who had the better software.

What “generic” actually means

Open your last AI-written email or landing page. Read it as if a competitor sent it. Would you know the difference?

For most teams, the honest answer is no. The output reads like it could have come from any company in the category, because it was built from the same raw material every other company is using. A request goes in, a general answer comes back, someone polishes the surface, and it ships.

That output is the average of the internet on your topic. It is competent. It is also indistinguishable from what the team across the street produced the same morning.

When you swap tools and tighten your prompts and still get bland, interchangeable copy, the tool is doing its job. You handed it generic inputs and it gave you generic results. The machine is a mirror.

The teams getting real work out of AI feed it something different

The 24 percent are not better at writing prompts. They have built a habit the other teams skipped. Before they ask AI to produce anything, they make sure it already knows the business.

Kieran Flanagan at HubSpot described his version of this. He built what he calls a customer digital twin, a model he tests campaigns against before launch. It runs on real sales call transcripts, real G2 reviews, real objection notes from the CRM. His warning was blunt. Synthetic data in, synthetic insights out. The twin is only as sharp as the voice-of-customer you train it on.

That principle holds for everything, not just customer simulations. The AI writing your outbound, your blog drafts, your positioning, all of it inherits the quality of what you put in front of it. Feed it your actual customer language and it writes in your customer’s voice. Feed it nothing and it writes in the voice of the average.

A context layer is a curation job, not a coding job

This is where teams talk themselves out of the fix. They assume building this kind of system means a technical project, a data engineer, a six-month integration.

It does not. The report’s own conclusion was that you do not need to be an AI expert or a software engineer to start seeing value. The highest-leverage move a functional team can make is a documentation project. You decide what the AI needs to know, gather it, and write it down in a form the model can read. Most of that work is judgment, and your team already has the judgment. They just have it scattered across people’s heads, old decks, and a hundred Slack threads.

Maja Voje described the simplest version of this in the report. She has the teams she works with build a content assistant inside a single AI project. They upload their messaging and brand guidelines, a knowledge base describing the company, and examples of their best-performing content. Then they write instructions that define the voice and spell out what to do and what to avoid. That is the whole setup. No special platform, no engineering ticket.

What goes into the layer

Build it from the intelligence you already own:

Your ICP, written down. Not the aspirational version on the website. The real one, including the segments that close fast and the ones that waste your time.

Real customer language. Pull exact phrases from call transcripts, reviews, and support tickets. The words your buyers use to describe the problem, copied verbatim.

Your best work. Three to five examples of copy, posts, or pages you were proud of. The model learns your voice from samples, not adjectives.

What has failed. The campaigns that flopped, the messaging that confused people, the angles that never landed in your market. Telling AI what to avoid is as valuable as telling it what to chase.

Your market position. How you differ from the obvious alternatives, in one honest paragraph.

Once it exists, the same prompt behaves completely differently. The request that produced generic filler last week now produces something that sounds like you, references your customers correctly, and reflects how you actually win. You did not get better at prompting. You gave the model a memory.

Start with one workflow

You do not need to document the entire company before you see a return. Pick the one task your team runs most often. Outbound email, social posts, first-draft blogs, whatever eats the most hours.

Joey Maddox at Verisoul makes the case for this with meeting prep. His team loads prior transcripts, email threads, and CRM history into a custom GPT before every call, and his takeaway was simple. The more relevant data the AI can reach, the more useful it gets. Start there. Gather the context for one workflow, load it into a project, and run your normal prompt against it. Compare the two outputs side by side. The difference is usually obvious enough to settle whether this is worth your time.

Then do the next workflow. The layer compounds. Every document you add makes every future task sharper, and you build it once.

The teams in that report who saw nothing are still treating AI like a search engine, asking strangers for answers and accepting whatever comes back. The teams seeing returns gave their AI a home, a memory, and a clear picture of the business it works for. The tool was never the variable. What it knew was.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

Your Best AI User Says the Least

Todd 🌐 Fractional CTO — Tue, 11 Aug 2026 14:00:00 +0000

How to find the people rebuilding their work around AI

On most teams, the loudest voice about AI and the most valuable person using it are rarely the same human.

One demos a new tool in every standup. They ask for more licenses, forward the latest model announcement, and bring AI up in every meeting. They’re easy to spot, which is exactly why they end up with the training budget and the leadership attention.

The other person says almost nothing. They quietly turned a two-day task into a four-hour one and moved on to the next thing. You’d never know unless you went looking at what they actually shipped.

When the time comes to scale AI across the team, most leads fund the first person. That’s the expensive mistake.

Enthusiasm is loud. Output is quiet.

The numbers make the gap obvious. One analysis of more than 400 companies found AI tool usage climbed 65 percent while median pull request throughput rose only about 8 percent. A lot of motion, very little progress.

That disconnect is the whole story. Most teams measure who talks about AI, not who has been changed by it. Training flows toward the vocal users. Budget follows enthusiasm. The people who genuinely rebuilt their workflows stay invisible the entire time, because real change rarely announces itself in a standup.

A vocal user adopts the tool. A real contributor redesigns the work around it. Only one of those compounds when you scale it.

Output reveals what behavior hides

You’ll find the signal in the work itself. Standups won’t hand it to you.

Pull the last quarter of output and look for the curves that bent. Find the person whose turnaround time dropped with no loss in quality, whose revision counts keep falling, who now ships the same volume in half the hours or double the volume in the same time. That person changed something structural about how the work happens.

Someone who compressed a multi-day process into an afternoon has built something you can study and reuse. Someone who gives a polished demo has built a presentation. For a scaling strategy, the first is worth ten of the second.

Interview the workflow itself

Once you’ve found them, resist the urge to ask which tools they like. That question gets you a product review and nothing more.

Ask how they actually do the work now. Walk me through the last time you ran this end to end. Where does AI come in, and where do you still work by hand? What did you stop doing completely, and what broke before you got it right?

You’re after the sequence, the judgment calls, and the small corrections they’ve stopped noticing they make. Most people who have rebuilt a workflow can’t explain it cold, because it has turned into instinct. Your job is to slow them down until the instinct becomes steps again. Record the conversation. The throwaway comments are usually where the real method hides.

Extract it before it lives in one head forever

A redesigned workflow that exists only in one person’s head is a liability. They take two weeks off and the speed leaves with them.

Document it while you’re still in the room. Capture the prompts they reuse word for word, the order they work in, the checks they run before anything ships, and the moments where they override what the AI suggests. Write down the failure modes too, because half the value sits in what they have learned not to trust. Keep all of it concrete enough that someone else could follow it next Monday without coming back with a single question.

Turn one person’s process into a system

A personal workflow becomes leverage the moment it survives a handoff.

Give it to one other person first and watch where they get stuck. Their confusion will expose the steps the original owner skipped, the ones so obvious to them they forgot anyone would need them spelled out. Fix those gaps, then widen the circle. Fold the prompts into shared templates. Wire the quality checks into your existing review process so standards hold steady as more people run the same play.

Do this well and the four-hour workflow quietly becomes the team default. The person who built it finally gets credit for the thing that moved the needle, rather than the colleague who demoed the most tools.

That’s how AI workflows actually scale. You find the quiet ones who already cracked it, then make their work repeatable for everyone else. Your most valuable AI user has probably already transformed how they work and never mentioned it. Look at what shipped, and you’ll see them.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

3 AI ROI Metrics Executives Keep Getting Wrong

Todd 🌐 Fractional CTO — Tue, 04 Aug 2026 14:00:00 +0000

The measurement frameworks built for SaaS produce misleading signals when applied to AI investments

Executives are bullish on AI. They’re spending more, reporting business value, and telling boards the investment is paying off.

Harvard Business Review’s executive benchmark survey confirms the optimism, while noting that organizations still struggle to demonstrate ROI. The researchers attribute the gap to change and human and organizational readiness rather than the technology itself.

That diagnosis is useful. It’s also incomplete. Before readiness becomes the answer, there’s a measurement problem worth examining.

Most organizations are reporting AI ROI on metrics built for a different category of investment. Those metrics worked for SaaS rollouts, headcount decisions, and infrastructure spend. They produce signals that look like progress while obscuring what’s actually working. Let’s dive into why these metrics are failing, and what they are truly hiding.

1. Time Saved Per Employee Hides Quality Degradation

Time saved tells you how fast something got done. But it says almost nothing about whether the output held up.

A marketer who used to write a brief in 90 minutes and now writes one in 20 has saved real time on paper. If that brief comes back for revision twice and pulls additional reviewers into the loop, the savings evaporate and the surrounding work absorbs the cost. The metric doesn’t capture that loop.

A more useful measurement looks at completed quality. Track end-to-end cycle time on work that meets the same quality bar as before, measured against your previous baseline. If a deliverable used to require one round of review and now requires two, the time simply moved further down the pipeline. The signal worth reporting is the time from task start to task accepted by the next downstream owner, including all revisions.

This takes more work to instrument. It requires defining what “accepted” means for each workflow and tracking handoffs across teams. Most organizations skip that effort and report the easy number. The result is a confident chart in the board deck and a slower, lower-quality operation underneath.

2. Adoption Rate Mistakes Access for Value

Adoption rate is a metric showing up in nearly every executive update. You count licenses issued, divide by active users, and call that percentage your AI maturity score. Some companies pair it with usage frequency. Most stop there.

The number tells you whether people opened the tool. It says almost nothing about whether the tool changed their work in a way that produced business value.

Adoption became the proxy for transformation in most organizations, which is how the metric ended up so prominent. Procurement bought seats, IT deployed them, change management sent training emails, and the dashboard turned green. Leadership reported success on a metric that captures activity at the entry point while saying nothing about outcomes downstream.

A better measurement asks what shifted because of the tool. Pick three to five workflows where AI was supposed to change the work. Define what success looks like in each one before you start, with a baseline metric tied to revenue, cost, cycle time, or customer outcome. Then track whether that metric moved after deployment.

3. Cost Per Task Automated Misses the Cost of the System

A task automated by AI rarely sits alone. It connects to upstream inputs, downstream consumers, monitoring, error handling, exception escalation, model updates, and prompt management. Each of those activities carries a cost. Some are obvious, like the engineer maintaining the integration. Others stay hidden, like the senior reviewer who now spot-checks output, the team that built a fallback process for when the model fails, or the compliance review added when an audit flagged the workflow.

A more useful measurement is total cost to deliver the outcome. Define the business outcome the AI is supposed to produce, then sum every cost required to produce it reliably at the quality level your customers expect. Compare that total against the previous total. If the new number is lower, you have a real efficiency gain. If it’s higher or flat, you’ve built a more sophisticated machine that costs the same to operate.

The Measurement That Actually Earns Trust

Time saved per employee, adoption rate, and cost per task automated produce defensible numbers from data your systems already capture. They also produce a story that’s less accurate than executives believe.

The harder measurements force a definition of outcome before deployment starts. They require connecting AI to a business result, instrumenting the workflow end-to-end, and accepting that some investments will show no return. The same measurement that confirms a deployment is working flags the failing ones for redesign or retirement. That symmetry is the point.

Boards will start asking for it. The executives ready with an answer will be the ones who measured the right thing from the start.

. . .

Want to save hours each week by turning work into repeatable AI workflows?

The AI Skills Gap Is Harder to Fix Than You Think

Todd 🌐 Fractional CTO — Wed, 17 Jun 2026 13:27:44 +0000

Why Most Upskilling Initiatives Fail Before They Start

You bought the licenses, shared the training links, and gave the team time to learn. Six weeks later, almost nobody had changed how they work.

This is one of the most common frustrations I hear from leaders trying to build AI capability inside their organizations. They invest in upskilling, see polite participation, and then watch everything snap back to the old workflow within a month.

The instinct is to blame motivation or resistance, but the real issue is usually simpler and harder to see.

The Perception Problem

Research published by the World Economic Forum in early 2026 found that workers across multiple economies recognize AI as a disruptive force but consistently underestimate its impact on their own roles. The contrast was especially sharp in the UK, where 70% of workers expressed concern about AI’s broader economic impact while only 39% believed their own jobs were at risk.

Psychologists call this optimism bias, and it shows up everywhere. But it’s especially damaging in the context of AI upskilling for teams because it makes the problem invisible to the very people who need to act on it.

If someone believes their role is safe, they treat training as optional. They’ll attend the workshop and nod along, but they won’t change a single workflow because in their mind there’s nothing that needs fixing.

Training Fails When People Can’t See the Gap

Think about the last time your organization rolled out a new capability-building initiative. Chances are, someone built a curriculum, picked a platform, and scheduled sessions.

The assumption behind that entire sequence is that people already understand why they need to learn, and for AI upskilling, that assumption falls apart almost immediately.

Stanford’s AI Index Report found that 78% of organizations reported using AI in 2024, up from 55% the prior year, yet only 20 to 40% of workers were actually applying AI in their day-to-day work despite widespread organizational investment. The tools are available, but the people aren’t engaging with them in any meaningful way, and the reason has very little to do with access or willingness.

A study by KPMG and the University of Melbourne found that 83% of people are interested in learning more about AI. While interest in AI is high, the report highlights that urgency around training, education, and organizational preparedness remains relatively low.

Diagnosis Before Curriculum

If you’re leading AI upskilling for a team or an organization, the first move should never be a training plan. It should be a clarity exercise that helps people see, specifically, where AI intersects with their actual responsibilities.

One approach that works well is asking each team member to document their top ten recurring tasks over two weeks, then sitting down together to identify which of those tasks have viable AI-assisted alternatives right now.

The conversation shifts immediately when you go from “AI is important” to “AI can handle 30% of what I spend my week on.” That’s when attention sharpens and people start engaging with the idea of change on personal terms.

Build the Upskilling Around the Diagnosis

Once people see where AI touches their work, training has somewhere to land. The design of the program matters, but it matters less than the sequencing. Diagnosis first, then curriculum.

A few principles hold up consistently across the organizations I’ve worked with:

Start with the workflow, not the tool. Show someone how AI fits into a process they already run every week rather than leading with what the technology can do in the abstract. When the entry point is familiar, adoption follows more naturally.

Make the first win small and visible. One automated report, one faster research cycle, or one draft that used to take two hours and now takes twenty minutes. Early proof compounds quickly and builds momentum that generic training sessions rarely generate.

Let the confident users teach. Every team has one or two people who are already using AI effectively, and giving them a role in the training process accelerates adoption faster than any external course. Peer credibility carries weight that outside expertise often can’t match.

Measure behavior, not completion. Track whether people actually changed their workflow after training rather than whether they finished the course. Completion rates are vanity metrics when it comes to AI upskilling, and they tell you almost nothing about whether the investment produced real capability.

The Real Cost of Skipping This Step

Teams that don’t build AI capability fall behind on efficiency, and consultants or founders who skip the diagnostic step with their clients lose credibility when the training investment doesn’t translate into changed behavior. Organizations that keep funding generic programs quarter after quarter wonder why adoption stays flat while their competitors pull ahead.

The fix is rarely more training. It’s a better diagnosis. Help people see the specific gap between where they are and where AI could take their output, then give them something targeted to close it. That sequence, diagnosis before curriculum, is the one that actually produces results.

. . .

Want to save hours each week by turning work into repeatable AI workflows?