New Software, Old Routines: What Your Team Will Keep Doing

When new software arrives, the team keeps doing some of the old work anyway, sometimes because that work was protecting something nobody wrote down. That's true whether you're bringing in AI after acquisition or after twenty years of running the place. Change how the work gets done before you understand what keeps the business running, and you break things you didn't know were there.

Why a fresh look is useful, and where it goes wrong

An owner who looks at the work with fresh eyes, whether new to the business or stepping back from it, notices things the team has learned to live with. Someone copies an update because a colleague can't see it. A manager answers the same question every week because the answer lives in their head. People wait for the owner to interpret information they already have.

Those are good places to start a conversation. They aren't proof that the routine is unnecessary or that AI should take it over. You see the activity before you understand the reasons for it, and an awkward exchange may be carrying information the official record leaves out.

Change also costs something while it happens. A loan brokerage founder warns buyers that a plan to shake up a business should allow for a dip in earnings while the changes take effect. The improvement you're hoping for doesn't remove the strain of getting there. The same holds for an owner reorganising work around software: budget for the disruption, not only for the result.

Take a routine where staff gather updates for a manager. The owner sees repetition and pictures software preparing the information. But the employee doing it also knows when an update is incomplete, whom to ask and whether a customer is waiting. If software takes over the gathering, those jobs still need a home: someone has to interpret the information and own the response.

AI-native operations in a small business covers people directing and supervising software. Here that idea meets existing expectations about who knows the work and who decides.

You can be curious about a different arrangement without treating the current one as a failure. That leaves room for employees to explain why work looks the way it does, and for you to find that a "technology problem" is really a question about authority, information or competing demands.

What old routines quietly protect

A routine can look inefficient because its purpose is hard to see. A phone call may reconcile two versions of a customer's request. An experienced manager may spot that an ordinary-looking job needs attention. A handwritten reminder may hold context that never reached the shared system.

That doesn't mean keeping every habit. It means separating the form of the work from its purpose. The form may be clumsy while the purpose is valuable.

If you bought the business, the seller may remember why a responsibility sits with a particular person, or why staff ask before answering. That context helps, but it doesn't make the inherited arrangement the only sensible one.

Employees hold useful habits too. People learn to notice an ambiguous request, catch a missing detail or keep a colleague informed. If you describe that work as "admin", you miss the judgment inside it.

An AI proposal should keep that judgment visible. If software prepares a summary, someone still needs to know what the summary leaves uncertain. If it drafts a reply, someone still owns what the reply means to the customer.

A useful question: what would be lost if this activity disappeared? The answer might be customer context, coordination, or a decision someone has been quietly making. It might also be nothing: a habit whose purpose has faded. Either answer is more useful than calling the business old-fashioned.

You don't need to understand everything before acting. But don't confuse incomplete understanding with permission to guess. Say which parts of the routine you understand and which you don't.

Which outcomes to aim for

The case for change should say what gets better for the people doing the work or receiving it. "Using AI" is an activity. A customer getting a clear answer, an employee knowing who can decide, or a manager seeing what's unfinished: those are outcomes.

Take the customer explanation. A draft can exist while the customer still lacks a useful answer; the remaining work may be interpreting the request or deciding what the business can responsibly say. Calling the draft done hides that work.

Management updates are the same. A polished summary makes unfinished work easier to read, but polish isn't completeness. The manager needs to know who can explain an omission or settle a conflict. If nobody can, the new arrangement leaves the manager less sure where to turn than before.

What to automate first starts with the work problem. Add one question here: does the change help people understand what they own? If you can't answer that, you have more to learn about the change.

Sometimes the useful change is in responsibility, with the software staying familiar. An employee might be asked to interpret prepared information instead of just assembling it. Say that out loud and talk about judgment, support and authority; don't bury it inside a general announcement about AI.

Different software arrangements leave different decisions with people; AI agents versus automations covers that. Whoever is responsible for an outcome should be able to explain what the software is there to do.

How to raise it with the team

The team has to absorb your ideas while still serving customers. You may experience a new idea as progress. They may experience it as another change in what they're supposed to do.

A business guide describes bringing a changing mix of management ideas from books and old bosses to his own team, and the confusion and whiplash that caused until he committed to one consistent way of working. New software announced on top of last quarter's new process has the same effect.

Explain the concern in words the team recognises. "Requests lose an owner between the office and the field" gives people something concrete to discuss. "We need to become more advanced" doesn't.

Say what the current routine does well. Employees shouldn't have to defend the whole history of the business to explain a useful habit.

Answer the direct questions. Who interprets software-prepared information? Who handles a request that's still unclear? What authority comes with that responsibility? Some answers may stay open. Say so, rather than implying the team should work it out around the software.

Disagreement can point to a missing purpose. An employee who objects may be describing a customer expectation or a decision you haven't run into yet. That doesn't settle the question in favour of the old routine, but it's information you need before calling the new arrangement better.

Pick one inherited routine and write down what it protects before you change it.

Source notes

Guest remarks are paraphrased from interviews with a loan brokerage founder and a business guide; examples are our own.