CTO before buying automation: fix process gaps first

Why more software does not fix a messy process

Operations teams usually notice the pain where it is easiest to see: a slow screen, too many clicks, a report that takes forever to load. Those problems are real, but they are often smaller than the mess around them. A screen that wastes 10 seconds is annoying. A handoff with no clear owner can waste two days.

That is why buying automation before fixing the process often backfires. Software does not decide who approves what, who handles exceptions, or who steps in when a request stalls halfway through. If those rules live in people's heads, the tool cannot save the process.

Missing owners create repeat work fast. One person enters a request, another edits it, and a third asks for the same details again because nobody owns the next step. Teams call this "manual work," but much of it is really "unclear work." People redo tasks because the process never defined who decides, who reviews, and who closes the loop.

Teams also blame tools because tools are visible. It is easy to say, "This platform is too limited," or "We need a better system." It is harder to admit the team never agreed on basic rules like which cases need approval, who can skip a step, what happens when data is missing, and when a task is actually done.

If those rules are fuzzy, a new platform only makes the confusion faster.

This happens all the time. A team buys automation to route requests. A month later, requests still bounce between finance, ops, and support because nobody defined the exception path. The routing works. The process does not.

More software can even make the damage bigger. Once a bad process is automated, it repeats the same bad decision every time, at scale. Instead of one employee making a messy handoff five times a day, the system now sends 50 messy handoffs before anyone notices.

A good CTO starts there. Where does work change hands? Where are the rules vague? Where does ownership disappear? Fix that first, and tool selection gets easier. Skip it, and even expensive automation becomes a faster way to produce the same mistakes.

Where operations teams lose money every week

Most operations losses do not look dramatic. They show up as 15 minutes here, two extra emails there, and one approval that has to be corrected later. By the end of the week, the team has spent hours redoing work it already touched once.

Wrong approvals are expensive because they spread. Someone approves the wrong vendor, amount, or timeline. Another person reopens the task, fixes the record, asks for sign-off again, and explains the delay to the next team. One bad approval can pull in finance, ops, and support at the same time.

Missing details drain time every day. A request arrives without a cost code, contract term, customer ID, or owner, so staff chase the answer in chat, email, and old spreadsheets. If five people lose 20 minutes a day doing that, the team gives up more than eight hours a week.

Unwritten exceptions cost even more. Every team has special cases: split invoices, rush orders, unusual discounts, or customers with custom rules. If nobody writes those cases down, each person makes a judgment call. The result is uneven decisions, repeat questions, and more rework when the same case shows up again.

Reports often make the problem worse instead of clearer. Finance checks one number in the accounting system, operations sees another in a dashboard, and a team lead trusts a spreadsheet someone updates by hand. Then the meeting turns into an argument about whose report is right.

The leak usually appears in a few places:

• work gets approved once, then corrected later
• staff chase missing fields across several tools
• special cases live in someone's head instead of a written rule
• teams compare reports that do not match

This is where a CTO can save more money than another platform. The first job is to look at rules and handoffs, find where data changes, and spot where ownership gets blurry. Once those gaps are fixed, the software choice gets simpler and usually less expensive.

How to tell if the problem is process, not tooling

If work keeps slowing down after a new app or integration goes live, the tool may not be the real problem. Teams usually lose time when nobody agrees on the exact next step, who owns it, or what happens when a case falls outside the normal path.

A process problem leaves a few obvious marks. The same task lands with two or three people before anyone acts on it. Staff keep asking in chat who should take the next step. Someone maintains a private spreadsheet because the main system does not show the full picture. People handle special cases outside the written flow and patch the record later.

Any one of these can look small. Together, they tell you the team does not trust the process enough to follow it as written.

What to check in a normal week

Watch one workflow for five business days. Pick something common, like purchase requests, customer onboarding, or contract review. Count handoffs, repeat questions, manual updates, and exceptions.

If a request spends more time waiting than moving, the rules are weak. If two people approve the same thing because neither knew the other had already handled it, the ownership line is weak. If people rely on chat to explain what the system should already show, the workflow is weak.

A new platform rarely fixes that on its own. It often hides the mess for a month, then the same delays come back in a prettier dashboard.

A fractional CTO usually presses on four points first: where work stalls, where ownership gets fuzzy, where people leave the system to finish the job, and where exceptions break the written rules. Fix those, and software starts helping.

Map one workflow from request to result

Start with the workflow that wastes the most time, causes the most complaints, or creates the most back-and-forth. Do not map 10 processes at once. Pick one. A single messy workflow can show you why buying another tool will not fix the real problem.

Use the real version of the work, not the version people wish they had. Sit with the person who does it every day and ask, "What happens first?" Then keep going until the work ends. If the team says, "It depends," write down what it depends on. Those exceptions usually cost more than the normal path.

Write each step in plain language. Skip diagrams at first. Simple sentences work better because everyone can challenge them. "Sales sends request." "Ops checks stock." "Manager approves spend." Clear beats pretty.

For each step, capture four things: who owns it, what input they need, what output they produce, and when they must finish it.

That small checklist exposes gaps fast. You may find that two people think they own the same step, or nobody owns it at all. You may find that one team waits for information another team never knew it had to send.

Approvals need extra attention. Write down every approval, who gives it, and what rule they use. Then note every exception. If orders under $500 skip finance, say that. If urgent requests jump the queue, say that too. Vague rules create delays because people stop and ask, then ask again.

A simple example helps. Say a company handles customer refund requests by email. Support receives the request, finance checks the payment, a manager approves refunds over a set amount, and ops updates the order system. On paper, that sounds fine. In practice, support often forgets one screenshot, finance uses a different customer ID, and managers approve only twice a week. The refund takes six days even though the actual work takes about 20 minutes.

Circle the steps where people wait, chase missing details, or redo work. Those marks matter more than the software stack. Once the rules and handoffs are clear, the right automation choice gets much easier.

A simple example: invoice approvals that keep stalling

A supplier emails an $8,400 invoice on Monday morning. Accounts payable logs it that afternoon and sends it for approval. The payment term is 14 days, so the clock starts right away.

The first delay has nothing to do with software. Nobody wrote the approval limits clearly. The department manager thinks she can approve up to $5,000. Finance believes department heads can approve up to $10,000. The invoice lands in her queue, she hesitates, and the team loses a day while people ask who owns the decision.

By Wednesday, she forwards it to the finance director. He is traveling. He does not see the request until late evening, and there is no backup approver. Accounts payable sends reminders, then waits again. By Friday, the invoice misses the weekly payment run.

Now the damage shows up in small but costly ways. The supplier sends a follow-up. The team spends 20 minutes checking status in email and chat. Finance may lose an early payment discount or pay a late fee. None of that happened because the tool was slow. It happened because the rules were vague.

This is where teams make an expensive mistake. They start shopping for a new automation platform. A better system might move the invoice from one inbox to another more neatly, but it will still route bad rules faster. If spending limits are unclear and nobody covers an absent approver, the stall stays.

A few small fixes change the outcome fast:

• put approval limits in one written policy
• name a backup approver for each step
• set a timeout, such as 24 hours, before escalation
• route invoices above a set amount straight to finance

With those rules in place, the same invoice moves cleanly from arrival to payment. Accounts payable logs it, the right person approves it, the backup steps in if needed, and finance pays on schedule.

The cheaper win is usually a rule change, not another subscription.

What a CTO does before comparing platforms

A good CTO starts with the work itself, not vendor demos. If a team says, "we need automation," the first question is what should happen, who decides, and where work gets stuck.

Most teams use vague goals like "move faster" or "reduce manual work." A CTO turns that into rules people can follow. For example: when an order is over a set amount, finance approves it; if the customer is overdue, sales cannot push it through; if data is missing, the request goes back to the person who sent it.

That sounds basic, but many operations teams skip it. They buy software first, then discover nobody agrees on handoffs, exception cases, or what "done" means.

Ownership comes next. A CTO names one owner for each decision point and one owner for exceptions. If nobody owns exceptions, they pile up in email, chat, and side spreadsheets until the team starts inventing workarounds.

A CTO also looks for duplicate tools that hide the real problem. It is common to find the same workflow split across a form tool, a shared inbox, a spreadsheet, and Slack messages. Removing even one layer can cut delays without buying anything new.

Not every step should be automated right away. Good CTOs separate tasks into two groups: steps that happen often and follow clear rules, and steps that are rare, messy, or need judgment. The first group is worth automating now. The second group usually stays manual until the team sees a stable pattern.

Before comparing platforms, the team needs a simple scorecard:

• cost per workflow or per request
• average time from request to result
• error rate, rework, or missed handoffs

That scorecard stops tool shopping from turning into opinion fights. It also makes small wins obvious. This is the sort of work Oleg Sotnikov is known for: cut waste first, make ownership clear, then choose tools that fit the process instead of forcing the process to fit the tool.

Common mistakes when teams shop for automation

Teams often spend weeks comparing tools when they have not agreed on the work itself. That is why a new platform can look great in a demo and still disappoint a month later. The tool did what it promised. The team bought it for a process that was still fuzzy.

The first mistake is shopping from demos instead of real workflows. A polished demo skips the awkward parts: missing approvals, messy handoffs, duplicate records, and exceptions that happen every Tuesday. If your team cannot describe the exact path from request to finished result, you are judging software in a vacuum.

Another common mistake is trying to automate every exception on day one. Teams pack the first project with special rules for rare cases, old habits, and one person's preferred workaround. That usually slows setup, confuses users, and turns a simple rollout into a rebuild of the whole department.

Data gets ignored more often than people admit. Names do not match. Status labels mean different things to different teams. Customer records sit in three places with three formats. No automation platform fixes that by magic. It just moves bad data faster.

Choice gets worse when one department picks the tool for everyone else. Operations may own the budget, but finance, support, sales, and engineering often touch the same workflow. If one group makes the call alone, the rest of the company ends up adapting to someone else's shortcut.

A few warning signs show up early:

• people say the new tool will force a better process later
• nobody owns naming rules, statuses, or field definitions
• success means go-live by a certain date, not fewer errors or less rework
• the vendor knows more about your workflow than your managers do

Launch dates are easy to report, so teams cling to them. But a fast launch with low adoption and daily manual fixes is still a bad result. Measure something that matters in normal work: approval time, number of handoffs, rework, or hours saved each week.

An experienced CTO can save a lot of money before the contract gets signed. The job is simple to describe and hard to fake: ask uncomfortable questions, cut extra scope, and make teams agree on rules before they buy software that will lock those rules in.

Quick checks before you approve a new platform

A new tool can hide a messy process for a month or two. Then the same delays come back, but now you also pay license fees, setup costs, and training time. Before you approve any platform, ask the team to walk through one real workflow from request to final result in plain language.

If nobody can explain that path in five minutes, the issue is probably not the software. People may jump between email, chat, spreadsheets, and memory just to finish one task. That is not automation. It is guesswork with extra tabs open.

Use these checks on the workflow that causes the most repeat pain:

• Ask one person to explain every step out loud. If they need three other people to fill gaps, the workflow still lives in people's heads.
• Give each step one owner. Shared ownership sounds nice, but stalled work usually sits where nobody feels fully responsible.
• Write the exception rules. Normal cases move fine. Late invoices, missing fields, rush requests, and duplicates eat the time.
• Pick one source of record. If sales trusts a sheet, finance trusts the ERP, and support trusts email, the platform will copy confusion faster.
• State what the platform will not solve. A tool cannot fix unclear approval limits, weak data habits, or policy fights.

Try one small test before any purchase meeting. Pull up yesterday's stuck task and ask why it stopped. If the answer is "waiting for approval," ask whose approval and what rule triggers it. If the answer is "bad data," ask who owns that field and where it should be corrected.

That is the logic behind bringing in a CTO before buying automation: first make the process clear enough that software can follow it. If the team cannot do that yet, a bigger platform will only make the same mess run faster.

What to do next if your team feels stuck

Pick one workflow that wastes real money every week. Do not start with the noisiest complaint or the messiest inbox. Start with the flow that delays revenue, creates rework, or keeps people chasing approvals instead of finishing work.

A good first target is small enough to map in an hour and painful enough that everyone already knows it hurts. Invoice approvals, refunds, purchase requests, customer onboarding, and contract sign-off usually fit. If one delay eats 30 minutes a day across four people, the cost adds up quickly.

Before you book vendor calls, review the process in plain language. Who starts the work? Who owns each handoff? What rule decides yes, no, or escalate? Which exceptions keep breaking the flow? Teams often learn the same hard truth: the tool is not the main problem. The rules are fuzzy, ownership is split, and nobody agrees on edge cases.

A short review usually shows where money slips away. One manager approves requests only in email. Another wants everything in chat. Finance has one rule for normal work and another for rush requests. Staff then spend their day translating, reminding, and correcting. New software can make that look cleaner, but it does not fix the confusion.

A practical next move is to write the workflow from request to final result on one page, mark every owner, approval rule, and exception, count delays and manual touches for two weeks, and compare the cost of fixing the process with the full cost of a new tool, setup, training, and support.

That comparison matters more than most teams expect. A clearer rule set, one accountable owner, and fewer exceptions can save more than another subscription.

If your team is too close to the problem, an outside review helps. Oleg Sotnikov at oleg.is advises startups and smaller businesses on process design, architecture, infrastructure, and practical AI adoption. Sometimes the answer is light automation. Sometimes it is a policy change. Sometimes you do need a new system, but you can make that call with a much clearer view of the real problem.