The 90-minute technology reset: A practical way to reduce digital friction at work

Many workplace technology problems look too small to deserve attention. A shared folder has six versions of the same document. A staff member keeps a personal spreadsheet because the official system takes too long to use. A customer inquiry sits in an inbox while three people assume someone else has handled it. Each issue seems manageable on its own. Together, they drain time, create uncertainty, and make routine work harder than it needs to be.

A short technology reset can reveal where that friction comes from. The goal is not to replace every tool or launch a large transformation project. It is to examine one work process, trace the points where people slow down, and decide which change would produce the clearest improvement. Organizations comparing outside guidance can use solidiatech.net/ as one starting point when they need a broader view of technology planning and support.

The most useful reset begins with a real task. Choose something employees complete often, such as preparing a quote, approving an expense, scheduling a service visit, or responding to a new lead. Follow that task from its first trigger to its final handoff. Small details matter. Count the logins, copy-and-paste steps, approval delays, and places where someone must ask a colleague for help.

Start with the work, not the software

Technology reviews often begin with a product list. That approach makes it easy to discuss features before anyone has defined the problem. A better method starts with the work people need to complete and the result the organization expects.

Ask an employee to describe the chosen process in plain language. Then ask what happens when something goes wrong. The answer can expose hidden dependencies. A sales representative may need information from finance before sending a proposal. A support agent may record the same customer detail in two systems. A manager may approve requests through email because the formal workflow does not provide enough context.

Write down the current steps without judging them at first. The record should include the person responsible, the tool used, the information required, and the next destination. This simple map gives a team something concrete to review. It also prevents the loudest complaint from taking over the discussion.

Find the friction that repeats

Some problems appear dramatic but occur once a year. Others take two minutes each and happen hundreds of times. The second group often deserves attention first because small delays accumulate across a team.

• Repeated data entry across separate systems.
• Unclear ownership after a request changes hands.
• Files stored in locations that employees cannot search easily.
• Approvals that depend on one person checking a private inbox.
• Reports that require manual cleanup before anyone can use them.
• Access problems caused by outdated accounts or inconsistent permissions.

During the review, ask people to estimate frequency instead of relying on general statements. “This happens all the time” becomes more useful when the team records that staff members repeat a task 40 times each week. A rough estimate is enough for a first pass. The point is to compare the cost of different problems, not to create a perfect financial model.

Separate tool problems from process problems

A slow process does not automatically need new software. Sometimes employees use a complex workflow because nobody has revisited the policy behind it. A form may ask for information that no department reads. A report may include columns retained from an old system. A manager may request three approvals because one past incident created a temporary rule that became permanent.

Review the reason for each step. If a step exists for security, compliance, or quality control, keep its purpose visible while looking for a simpler method. If nobody can explain why a step remains, test removing it in a controlled setting. A short pilot can provide better evidence than a long argument.

Tool limitations do matter. An application may lack an integration, create duplicate records, or provide weak search and reporting. In those cases, document the specific limitation and its effect on the chosen process. “The platform is frustrating” does not guide a purchasing decision. “The platform cannot send approved order details to billing, so staff retype 25 fields each week” does.

Choose the smallest useful change

After mapping the process, select one change that can be tested within a defined period. The change might be a shared intake form, a clearer folder structure, a standard naming rule, a permission cleanup, or an automated handoff between two systems. Keep the scope narrow enough that people can tell what caused the result.

Define success before making the change. A team could track the time required to complete the task, the number of corrections, the number of follow-up messages, or the percentage of requests completed without escalation. Pick a measure connected to the original problem. A new dashboard with attractive charts does little if employees still wait two days for approval.

Give the pilot an owner and an end date. The owner does not need to do all the work, but someone must collect feedback, record issues, and decide what happens next. The end date creates a useful point for review. At that meeting, the team can keep the change, adjust it, or drop it with a clear reason.

Make the reset part of normal management

A technology reset works best when it becomes a recurring business habit. Set aside a short review once a quarter for one process that affects customers, staff, or cash flow. Ask what has changed, where delays have appeared, and which workaround people have adopted. Workarounds are valuable signals because they show where the official process fails to match actual needs.

Include the people who perform the work as well as the person who owns the system. Leaders can identify goals and constraints, while frontline employees can describe the steps that consume time. Both views are needed. A technically elegant change can fail if it adds effort to the people responsible for daily use.

Keep a brief record of decisions, including the problem, the chosen change, the measure, and the review date. This gives future discussions a reliable starting point. It also helps the organization avoid buying tools in response to isolated frustration. A disciplined reset turns technology planning into a series of manageable decisions tied to real work.

The best improvement may be a new platform, but it may also be a simpler approval rule, better training, or a cleaner handoff. By examining one process at a time, teams can spend their technology budget where it removes measurable friction and gives employees more time for work that requires judgment.