The Hidden Cost of Skipping Process Before Tools

🧭 Find your weakest productivity vector in 5 minutes: free assessment
🎓 Productive, Not Busy, my live cohort on Maven: join the next one

Your team has good software and the work still feels heavy. The migration finished, the dashboards exist, the vendor sent a case study, and the people doing the work are more tired than they were a year ago. Nobody says it out loud, because the tool was approved, paid for, and announced. Mike Toguchi has spent 25 years in that exact room, and his answer is process before tools.

Mike is Chief Strategy Officer at Tectonic, a digital transformation firm working with universities, nonprofits, foundations and associations. He leads Orchestrate, a platform that runs application and workflow systems for scholarship programmes, grant teams and admissions offices. So he sells technology for a living, and his central public message is scepticism about buying it too early. That tension is what made him worth 40 minutes on the podcast.

In this article you will get three things you can use this week: a way to spot survival mode in a team whose tools are running fine, a test that tells you whether you have approval or alignment before a project goes sideways, and a readiness check for the moment someone drops a renewal quote on your desk. Read it before you sign the next one, because the cheapest version of this lesson is the one you get secondhand.

Process before tools, and why the reflex is so hard to break

I asked Mike the obvious question first. Everybody nods at process before tools, then goes and buys more software anyway. Why does that keep happening?

His answer had nothing to do with intelligence or discipline. “The tool is the bright shiny thing where you’re focused on the features, how you’re gonna use it and what you’re gonna get out of it,” he said. The alternative is slower and less fun: outlining workflows, writing down how the work actually moves, finding the point where it jams. One of those tasks has a demo. The other has a meeting room and a lot of sticky notes.

Then he said the part that reframes the whole decision. “A lot of times the technology ends up being the thing that exposes the fissures in your workflow as opposed to fixing them.” A tool does not arrive with judgement. It arrives with speed, and it applies that speed to whatever workflow it lands on.

Survival mode: when the tools work, and the team does not

Mike uses the phrase “survival mode” for organisations whose technology is running beautifully and whose people are drowning. It is a useful idea because it separates two things leaders usually bundle together: whether the software works, and whether the work works.

His description of it: these can be “extremely smooth running, productive tools, but that doesn’t necessarily mean they’ve put the workflow in place in order to make them useful. The staff hasn’t been told how they’re supposed to use it. It hasn’t been tied back to their mission. People’s incentives aren’t aligned.” So the tool stops creating value, and people get overwhelmed by it.

If you want to check your own team, the signals are specific:

• Nobody can say in one sentence what the tool is for in terms of the mission.
• Two teams are measured on things that pull in opposite directions, and the tool sits between them.
• Decisions queue up at a committee because no single role owns the call.
• People have quietly rebuilt the old way in a spreadsheet next to the new system.

That last one is the loudest signal, and it is the one leaders see last.

Automate a mess, and you get a faster mess

I asked for a real example, and Mike gave one. An unnamed nonprofit runs a very large scholarship programme and gives out serious money to students every year. Good work, real impact. The problem was the award review itself: “too many different layers, complex scoring system, complex rating systems,” in his words, when it could be much more straightforward.

Rather than simplifying any of that, they put AI on top of it. Now an agent summarises every application essay and pulls keywords that match the kind of candidate they want. It got faster, and it got worse. “It’s not making the process cleaner,” Mike said. “It’s only giving reviewers messier information.” Leadership did not get better data for deciding which candidates to award. They got more paperwork, more systems, and what he called “continued mess, faster mess.”

Sit with the shape of that for a second. The automation worked exactly as designed. Review time went down. Output went up. And the organisation got worse at the one decision the whole process exists to make. If you measured this project on throughput, it was a success. Nobody was measuring the quality of the award decision, so nobody caught it.

This is the practical argument for process before tools. Speed applied to a convoluted workflow produces more convolution, and it does so with a cleaner audit trail, which is what makes the damage so hard to see from the top.

Readiness: how to know when buying is the right move

Here is where Mike surprised me, because the obvious conclusion from everything above is “plan for a year first”, and he rejects that outright.

“You can’t always wait for that perfect moment where everyone has researched everything, and you’ve meticulously outlined every single little piece of what you do,” he said. “Sometimes you have to jump in with two feet.” Organisations need to be aggressive, innovative and curious, and a year of planning is its own kind of failure.

So what does ready look like? He described it through the work Tectonic does with university disability services, where a centre connects to testing, parking, housing and dining. Bad process is picking the tool, then stapling every campus workflow into whatever features that tool happened to ship with. Students and faculty get a terrible experience out of it.

Ready looks like this instead, in his words: “we’re not going to have a committee, we’re not going to spend a year planning, but we are going to do strategic discovery. We are going to make sure all of our stakeholders are bought in. We are going to make sure we’ve done due diligence.” Then hit the gas.

Three conditions, and none of them takes a year:

1. Strategic discovery done. You can draw the current workflow and point at the specific step that fails.
2. Stakeholders bought in. The people whose day changes know what is changing and why.
3. Due diligence done. You know what the tool does, what it does not do, and what it will cost to connect.

What does not count as readiness: grant money arrived, or a peer organisation announced something. Mike named both as the bad version. “We’ve got grant money, or we need to do this because somebody else is doing it” is a budget event dressed up as a strategy.

He was equally direct about the pressure on public company leaders whose shareholders want an AI headline. You balance it, he said, by mapping a plan that satisfies the three-to-ten-year vision and this quarter at the same time, and by being honest about the alternative: “maybe you’ll impress somebody for the next six months, but that could be hollow.”

AI, time compression and the busywork trap

Mike talks about AI as a time compressor, and he is careful to describe “the good version” of it. Research, writing, data entry, low-level communication with a donor or a student: five percent here and five percent there, taken off a 50-hour week, adds up to real recovered hours. His mantra for nonprofit and higher education clients is a question: “How do we give you your time back?”

He put the argument in a way I have been stealing since we recorded. When your staff signed up for the job, “did they do it because they wanted to serve students and further an educational mission? Or do they do it because they wanted to copy and paste things from Google Sheets into a CRM? And it’s never the latter.”

I pushed back, because the version I keep seeing in companies is different. We are not handing the time back. We are telling people to scale the same task: instead of copy-pasting one row from a spreadsheet into the CRM, ask AI to do 300 rows. Same work, higher volume, no change to the decisions anyone makes.

Mike agreed, and his framing of the failure mode is worth writing on a wall. “Hey, Mike, you previously worked sixty hours a week, and a lot of it was manual, since AI can do a bunch of that, I still want you to work the sixty hours.” The manual tasks get replaced by different manual tasks, or by oversight. Instead of doing your own research, “AI produced six thousand pages that you have to scan through.” His conclusion: “it’s not giving people their time back. It’s ultimately just making them busier in a different and potentially worse way.”

That is the test for any AI rollout aimed at team productivity. Recovered hours are only half of it. Somebody has to decide in advance what the hours are for, and that decision belongs to leadership.

Approval is a signature, alignment is a shared understanding

Mike draws a hard line between approval and alignment, and leaders routinely believe they have both when they have one.

Approval is a sign-off. Alignment is a shared understanding of the problem, the success criteria, and the tradeoffs, sustained over the length of the project. The mechanism that keeps it alive is a feedback loop, and he is specific about what happens without one: “if there’s no feedback loop for that, then it increases people’s fear of failure or criticism.” People stop saying what is broken, and they start running shadow tools and shadow AI instead.

How to test for alignment before you start

Four questions, drawn from how he opens an engagement at the leadership level:

• Who are the core stakeholders, by name, and has each of them seen the plan?
• Can each of them state the problem this project solves in their own words, the same way?
• Have you been transparent about the real goal? He names the uncomfortable version directly: are you doing this for higher revenue, or to reduce headcount?
• Where exactly does someone report that this is not working, and who reads it?

If you can’t answer the fourth question, you have approval, and the project will run on hope from there.

He added a second failure that happens later, after everyone has relaxed. Teams treat the launch as the finish line, when “the finish line is really just the start”. Hitting the KPI is fine. The question nobody schedules is what happens in the six months after: are you getting the data you needed, are you seeing the gains you forecast, and how are you evaluating that. Instead, groups move on to the next project, and the fatigue sets in.

Prescriptive versus descriptive: you are running two processes

I raised something I see constantly. Every company has the process documented twelve years ago, and the process actually happening today, and the drift between them is enormous. Mike had better words for it than I did: “prescriptive is what it’s supposed to be, descriptive is what is actually happening.”

His description of the legacy layer underneath it: “there’s a lot of legacy workflows, legacy tools, legacy processes that exist. Sometimes people don’t even know where they came from or why they were there. That’s just how things have been.” And even when the documentation is good, nobody is curious enough to ask whether it is still the efficient way. So the new tool gets moulded on top of the legacy process rather than replacing it.

How he surfaces the gap: find the friction. Are there managers who are not collaborating? Staff who are frustrated with manual steps? Then work through champions and stakeholders so everyone on the team understands what changes and how their day gets better, because otherwise people stay with what they know.

I used my usual example on him. Go to any household, and people sit in the exact same spot for dinner. Tell them to change seats, and you will see drama at that table that night. Mike pushed back on blaming human nature, and his reason is a better insight: at universities he watches staff see a new initiative, a new tool and a new project every single year, and they burn out. Their resistance comes from pattern recognition. “I’ve seen this show before. It didn’t end up helping me, it didn’t make me more productive, it didn’t make me more impactful. It just was more work and more exhaustion, and more technology stapled on top of itself.”

He also made the point that the surfacing only works if leaders stay out of punishment mode. People create workarounds and use tools they are not supposed to use. You want those on the table, which means finding them “without being punitive about it”.

Live cohort on Maven

Productive, Not Busy

5 live sessions and 2 one-on-one sessions to create a system that makes your work enjoyable and easier to navigate. A system that puts you in control.

For managers who lead a team and still deliver their own work.

See how the five weeks run

Live on Maven · Small group · Built on your own calendar and your own team

5live sessions, 90 minutes each

2private 1:1 sessions with Santiago

12seats per cohort

Low adoption is a leadership issue

When a project underperforms, the standard explanation is poor change management or weak adoption. I asked Mike whether that is an excuse. He did not soften it: “I think adoption is a leadership issue.”

His reasoning runs backwards from the symptom. If people are not adopting a system you designed, implemented, and paid for, then they were never bought in and never aligned, and nobody explained how it would add value to their school, nonprofit, or company. What non-adoption actually communicates, in his words, is “I don’t believe you. I don’t have faith or trust. We’ve done these things before, these initiatives have not helped me, and therefore I’m gonna keep doing things my way.”

I asked the sceptic’s question: is alignment even possible in an organisation with 85 departments and 3,500 people holding different beliefs and leadership styles? His answer was no, immediately and twice. You will never get everyone to sign off on the same thing, and making those calls is part of the job.

What you can do instead has three parts. Make people feel genuinely heard, even when the decision goes against them: “I heard you, we’re not gonna do that, we’re gonna do it this way, and that’s our decision.” Build the top-level vision and let sub-processes live inside each group, with the silos connecting at the critical junctures. And accept the limit he states plainly: you can fix a bad process or replace a bad tool, but if you have people who do not support your decision making, you are in trouble.

What nonprofits get right

One answer that surprised me: Mike thinks nonprofits are handling this transition better than many for-profit companies, and the reason is structural. A nonprofit is mission driven, answers to a board and donors, and has what he called “the luxury of moving a little bit slower”. They feel less obligation to run at breakneck speed announcing that they are AI first, and less fear of falling behind on public perception.

Where they have seen real gains: making grant processes more efficient, and communicating with donors through targeted outreach where every message used to be written by hand. He described an agent scanning a donor list to spot that a platinum donor had posted about something, then drafting a specific, relevant message. Same tool, applied to a workflow somebody had already thought about.

In the quickfire round, he added that universities are harder to change than nonprofits, and he was fair about why: compliance obligations, state or federal funding, more liability and risk, and a fickle customer base. They need to move slower. Nonprofits answer to a board and donors and have more room.

His pick for the one tool every company needs, by the way, was internal chat: “such as Slack or Teams. Preferably Slack, I’m not a huge Teams guy.” And his book recommendation went outside business entirely, to Alexis de Tocqueville’s Democracy in America, because, in his words, civil society “is not driven by regulation or top down orders but by people working together for a common purpose”. This is the same argument he had been making about 3,000 employees for the previous 40 minutes.

Where this connects to the 4 Productivity Vectors

Everything above is organisational, and it maps cleanly onto personal work, which is why this episode sits in Decision Making under Effectiveness in the 4 Productivity Vectors methodology.

Think about how people handle their own week. They buy an app, skip the process design, and wonder why nothing changed. The prescriptive version of your week lives in your calendar. The descriptive version is what actually happened to your Thursday. If you have never compared the two, a new tool will do for you exactly what it did for that scholarship programme: speed up a workflow nobody examined.

The practical move is the same at both scales. Find the one step that jams, fix that step, measure whether it moved, then repeat. Small win, measure, repeat. It is unglamorous, and it is the only sequence that compounds, for an organisation and for individual team productivity.

If your own week has no baseline, that is the place to start. The productivity quiz scores sixteen elements across the four vectors and takes five minutes. It tells you which vector to fix first. If the symptom you recognise is capable people quietly disengaging, why high performers quit covers that pattern specifically. More tools and templates live in the productivity hub.

Frequently asked questions

What does “process before tools” actually mean?

It means understanding the real workflow, identifying the specific step that fails, fixing that one step, measuring the result, and then repeating, before you choose software. Mike Toguchi’s position is that a tool amplifies whatever process it lands on. Buying first means paying to run your existing problems faster.

Why do digital transformation projects fail?

Mike puts it down to leadership alignment. Teams get approval, which is a signature, and mistake it for alignment, which is a shared understanding of the problem, the success criteria, and the trade-offs. Without a feedback loop people can safely use, nobody reports what is broken, workarounds spread, and the project is labelled an adoption problem afterwards.

How do I know when my team is ready to buy a new tool?

Three conditions: strategic discovery is done, and you can point at the step that fails, the stakeholders whose day changes are bought in, and due diligence on the tool is complete. Grant money arriving or a competitor making an announcement are not readiness signals.

What are the common AI adoption mistakes?

Two stand out from this conversation. The first is automating a convoluted workflow, which produces faster output and worse decisions. The second is recovering hours and then refilling them with different busywork, so the team is busier in a new way. Decide what the recovered time is for before the rollout, not after.

Is resistance to change just human nature?

Partly, and Mike argues the larger share is earned. Staff who have been handed a new initiative every year have evidence that these projects add work without adding impact. They are reading a pattern, and that responds to transparency, feedback loops, and visible wins.

Listen to the full conversation

Mike Toguchi is Chief Strategy Officer at Tectonic, and he has talked about this framework elsewhere, including a Building Better Developers episode on process before tools. You can reach him on LinkedIn, and he said on air that he is happy to hear about the challenges you are facing even with no business on the table.

The full episode is 40 minutes, and the quickfire round at the end is worth staying for. If you want a number on your own working week before you buy anything else, start with the free productivity test. If you would rather work through it with a group, Productive, Not Busy is my live cohort on Maven.