The Technology Your New Hire Swears By (And Why It Probably Won't Work)

How many times has this happened to you?

You hire a talented executive from a larger, more successful company. They walk in the door with energy and confidence. And within the first week, they tell you exactly what you need.

"At my last company, we used this technology. It was amazing. We need it here ASAP."

They are convinced. They have seen it work. They know it can transform your business the same way it transformed theirs.

And if you are being honest, part of you wants to believe them.

Because if the problem is just technology, then the solution is simple. Buy the software. Implement it. Watch the results roll in.

But here is what I have learned after making this mistake.

Technology does not solve anything that does not already have an underlying process.

And the technology that worked brilliantly at your new hire's previous company probably will not work the same way here.

Not because the technology is bad. But because the context is completely different.

The Story

I hired an executive from a larger landscaping company.

They came from an operation that had everything dialed in. Clean processes. Documented workflows. A team that executed with precision.

They ran a specific industry software that was the gold standard for commercial landscaping. Purpose built. Proven at scale.

My new executive was confident. "This is what we need. I have seen it work at the highest level."

The argument made sense. We were struggling with operational consistency. Our processes were inconsistent across regions. We needed systems.

And here was someone who had seen those exact problems solved with a specific piece of technology.

So I gave them three months to prove it.

What New Hires Do Not See

Here is what my executive did not tell me, because they genuinely did not realize it themselves.

At their previous company, the software had been implemented years earlier by a dedicated team. Workflows were already built. Integrations were already configured. Best practices were already documented. Training was already systematized.

They walked into a mature system and it worked beautifully.

What they had never experienced was the implementation phase.

The configuration decisions. The integration complexity. The change management required to get a team to adopt a new platform. The months of iteration to get workflows right.

They saw the end state and assumed the path to get there was straightforward.

But implementation is where most technology initiatives fail.

And we learned that the hard way.

Month One: Looks Promising

The first month looked good.

The interface was clean. The industry specific features were exactly what my executive remembered. The support team was responsive.

We started configuring workflows. Setting up templates. Importing data. Training the team on the basics.

It felt like progress.

Month Two: Problems Emerge

The second month revealed the cracks.

Configuring workflows for our specific business model required custom fields and workarounds. What looked simple in the demo turned out to be complex in practice.

Training took longer than expected. The learning curve was steeper than my executive remembered. The team was frustrated because they had to abandon systems that were working and learn something completely new.

Integration with our existing tools was harder than anticipated. Data did not flow cleanly. We were doing manual workarounds to keep things running.

But the biggest issue was something we had not anticipated at all.

The Hidden Switching Cost

We had spent years building a massive pricing spreadsheet.

It was not elegant. It was not simple. But it worked.

Our sales team knew that spreadsheet cold. They could price a commercial property in fifteen minutes by looking at square footage, property type, regional cost variations, seasonal factors, and service mix.

That spreadsheet represented institutional knowledge. Years of won deals, lost deals, margin lessons, and competitive intelligence baked into a system the team trusted.

The new software had its own estimating and bidding module. Sophisticated and feature rich.

And it would have required completely retraining our sales team on the most complex part of their job.

My executive had not thought about this deeply. At their previous company, the team had been trained on this software from the beginning. It was the only estimating system they had ever known.

But our team had different muscle memory. Our spreadsheet was their source of truth.

Asking them to abandon that and learn a new estimating system, especially during a growth phase when we needed them selling, was a massive hidden cost no one had calculated.

Then we discovered the data problem.

The way we bid jobs was a combination of labor and materials bundled together as a single line item for each scope of work. That is how our team thought about pricing. That is how our proposals were structured. That is how years of historical data had been built.

The new platform needed it broken out.

Labor on one line. Materials on another. Every single line item of every single job separated and categorized before it could be imported.

This was not a weekend project. This was not something we could clean up overnight. Years of historical pricing data, hundreds of job types, thousands of line items, all structured in a way that was incompatible with the new system.

To migrate correctly, we would have had to restructure how we thought about bidding entirely. That meant retraining the sales team not just on new software but on a fundamentally different way of constructing a bid.

Then came the vendor problem.

We needed to upload every vendor and their pricing into the system. That sounds straightforward until you realize our vendor pricing was not static.

Material costs varied significantly depending on the time of year. Mulch in spring costs more than mulch in fall. Plant material in peak season is priced completely differently than off season. Hardscape materials fluctuate with supply chain conditions.

A system that assumes stable vendor pricing does not reflect how commercial landscape installation actually works. Maintaining accurate pricing in the system would have required constant manual updates every time a supplier adjusted their rates, which in our business was constantly.

And then we hit the most fundamental problem of all.

The platform had been built for landscape maintenance. Recurring contracts. Predictable scopes. Repeatable line items season over season.

That is a completely different world from custom landscape installation.

Installation is project based. Every job is different. A commercial property renovation involves custom grading, unique plant palettes, site specific drainage solutions, one of a kind hardscape designs. There is no repeatable template. Every bid is built from scratch based on the specific conditions of that property.

The software was not designed for that complexity. It was designed for the predictable, repeatable world of ongoing maintenance contracts where the scope this year looks a lot like the scope last year.

Our business was the opposite. Every project was custom. Every bid required judgment, creativity, and site specific knowledge that could not be templated.

We were trying to fit a custom installation business into software built for a maintenance business. Those are not the same thing. And no amount of configuration was going to change that.

Nobody had mentioned any of this in the demo.

Month Three: Uncle

After three months of working with support teams, managing team frustration, and falling behind on our growth timelines, my executive called me.

"I was wrong. We need to pivot."

To their credit, they said it directly. No excuses. No blame. Just honest acknowledgment that what worked at their previous company was not working here.

We shut it down.

What New Hires Confuse

Here is what that experience taught me.

New hires confuse the technology with the underlying system that made the technology effective.

At their previous company, the software worked because:

Processes were already defined and documented before the software arrived. The team was already trained and aligned on a common methodology. Integrations had been built and tested over years. Workflows had been refined through iteration and failure. Leadership had committed to the platform and enforced consistent adoption.

The software was not the reason those things existed. The software was the tool that enabled those things once they already existed.

But my executive saw the tool and assumed the tool created the system.

It did not. The system created the conditions for the tool to work.

We did not have those conditions. We did not have documented processes. We did not have standardized workflows. We did not have a team trained on a common methodology.

Dropping that software into our environment did not create a system. It created confusion.

Because technology does not solve process problems. It amplifies whatever process you already have.

If your process is good, technology makes it better.

If your process is inconsistent, technology makes the inconsistency more visible and more painful.

What We Did Instead

After the failure, we took a completely different approach.

We did not start with technology. We started with process.

What does our sales process actually look like today? How do leads come in? How do we qualify them? How do we estimate jobs? How do we follow up? How do we close deals?

We mapped the current state. Messy, inconsistent, but real.

Then we asked: what should this look like if we designed it intentionally?

We documented the ideal workflow from lead to close to renewal. Only after we had clarity on the process did we choose technology.

And we chose a platform that fit where we actually were, not where our executive had come from.

We also kept the pricing spreadsheet.

We did not throw away years of institutional knowledge to fit a new platform. Instead we built an AI agent that works directly within the spreadsheet. The agent suggests pricing based on historical data, flags outliers, and pulls regional cost adjustments automatically.

But the sales team still works in the environment they know. The AI makes them faster and more accurate without requiring them to rebuild their muscle memory from scratch.

New technology layered on top of existing knowledge. Not replacing it.

That distinction made everything easier.

The Pattern I See Everywhere

This is not unique to one software or one industry or one executive.

I see this pattern constantly.

A new leader joins from a more sophisticated company. They bring a technology recommendation. They are confident it will solve your problems because they saw it solve similar problems before.

And most of the time, it fails.

Not because the technology is bad. But because the leader is confusing the tool with the system that made the tool effective.

They saw a well oiled machine and assumed the machine was the tool.

But the machine was the combination of process, people, training, leadership commitment, and years of iterative refinement. The tool just enabled it.

When you drop that tool into an environment without those underlying conditions, it does not magically create them.

It just creates expensive shelfware.

The Four Questions to Ask

When a new executive tells you they have the perfect technology from their previous company, here is what to ask before you buy anything.

How long had that technology been implemented when you started using it?

If the answer is "it was already there when I joined," they have never experienced implementation. They only know the mature state. That does not mean the technology is wrong. But it means they cannot accurately estimate what it will take to get there from here.

What processes were already in place before the technology arrived?

If they cannot answer this clearly, they do not understand what made the technology effective. They are confusing the tool with the conditions that made the tool work.

What would we need to change about how we currently operate to make this technology work here?

If the answer is "not much, the technology handles it," that is a red flag. Good technology enables good process. It does not replace the need for one.

What happens if we build the process first and then choose technology that fits it?

If they resist this question, they are more attached to the tool than the outcome. That is worth paying attention to.

The Real Lesson

The problem is never "we do not have the right technology."

The problem is always "we do not have clear, documented, repeatable processes."

Technology is the accelerant. Process is the foundation.

If you pour accelerant on a weak foundation, you just burn faster.

Build the foundation first. Document how things should work. Train people on the process. Get alignment on the workflow.

Then choose technology that supports that process.

Not the other way around.

What Happened With My Executive

My executive became one of the strongest advocates for process first, technology second.

After the failure, they led the effort to document our sales workflows. They built the training programs. They identified where we needed standardization and where we needed flexibility.

They brought something more valuable than the software recommendation they came in with.

They brought hard won perspective on what actually works versus what looks like it should work.

That perspective came from failing. And it made them a better operator and a better leader.

The Bottom Line

The next time a new hire tells you about the amazing technology from their last company, do not dismiss it.

But do not implement it either.

Ask them to help you understand the processes that made that technology effective.

Document those processes first.

Then evaluate whether that technology is the right fit for your context, or whether something different would serve your actual needs better.

Technology is easy to buy.

Process is hard to build.

Do not let the excitement of a new tool distract you from the harder and more important work.

About Molly

Molly Means is a business operator who writes about Traction, operations, leadership, and organizational clarity. Her work is informed by experience building and operating companies and helping teams create structure that actually works.