Construction Doesn't Have a Technology Problem. It Has an Adoption Problem.

We've spent years building better technology for construction. Maybe it's time to spend more energy figuring out how to get people to actually use it.

For most of my career around construction technology, we've talked about construction as an industry with a technology problem.

It was behind. It hadn't digitized. Too much of the business was still being run on spreadsheets, paper, phone calls and information stored inside people's heads while other industries raced ahead.

That criticism was probably fair for a long time.

I'm not sure it is anymore.

There is a ridiculous amount of good construction technology available today. There are sophisticated tools for estimating, scheduling, project management, accounting, procurement, surveying, reality capture, safety, quality, workforce management and just about anything else you can think of. Now we're layering AI across all of it.

Construction companies are buying this stuff, too.

The problem is what happens next.

Because buying technology and actually changing the way an organization works are two completely different things.

And I'm increasingly convinced that construction doesn't have nearly as much of a technology problem anymore.

It has an adoption problem.

Same technology. Completely different ROI.

At one point in my career, I worked for a technology provider that had a large construction customer using our product pretty broadly across its organization.

We had a good relationship with the company and they believed in the technology. But when we started looking closely at usage and talking to people throughout the organization, we found something interesting.

There were power users who absolutely loved us. They were in the platform constantly, had incorporated it into the way they worked and couldn't imagine going back. Ask them about the ROI and there was no hesitation.

Then there were regular users who liked the product and saw plenty of value.

Then occasional users who were more ambivalent.

And finally there were people who barely logged in at all. Ask them whether the company should keep paying for the technology and, unsurprisingly, they weren't particularly enthusiastic.

Same company. Same technology. People doing essentially the same kinds of work. Completely different perceptions of ROI.

The biggest predictor of whether someone thought our technology was valuable was pretty simple:

Did they actually know how to use it, and had they incorporated it into the way they worked?

Obvious, right?

It turned out to be considerably harder than it sounds.

We were training people on the wrong thing

Like a lot of technology companies, we'd historically approached training by teaching people our software.

Get everyone on a Zoom call. Walk through the tools. Answer questions. Send them on their way.

Sometimes it worked great. Sometimes people remembered two things and forgot the other fifteen when they went back to their actual jobs. Sometimes somebody was technically on the Zoom call while answering emails or dealing with something happening in the field and logged off having learned basically nothing.

Turnover compounded the problem. Good users left, replacements hadn't been trained and usage slowly declined.

Eventually somebody looked at the bill and asked the obvious question:

Why are we paying for this?

So we changed our approach.

Instead of training people on our software, we started training around their work.

What are you actually trying to accomplish? What problems do you deal with every day? What process does your company already expect you to follow?

Okay. Here's where our technology fits. Here's when you use it. And here's how it makes that thing you already have to do easier.

We didn't stop doing live training, but we stopped assuming one Zoom call was enough. We created different ways for people to learn and refresh their knowledge when they actually needed it.

We also got much more serious about measuring adoption. Who had been trained? Who was using the product? How often? What were they using?

Suddenly adoption wasn't something everybody hoped was happening.

We could see it. And once we could see it, we could manage it.

Usage went up. More people became power users. Occasional users became regular users. The population that barely used the product got smaller. Not surprisingly, the customer's perception of ROI improved too.

But the biggest lesson was that this wasn't simply their adoption problem. It was ours too.

As the technology provider, we had to get better at helping them change the way they worked.

This isn't just something I've observed

FMI put some numbers behind this in a study of construction technology users.

When contractors were asked about problems they'd experienced with technology they'd implemented, 34% of the challenges mentioned were that the technology wasn't adopted by everyone.

That was easily the biggest problem. Only 17% cited ease of use, 16% lack of integration, 13% said they'd had to buy something else to make the technology work and 12% said it hadn't delivered what was promised.

In other words, adoption was reported twice as often as ease of use as a problem.

FMI made another observation that jumped out at me. Poor implementations, they argued, often result from a mismatch between what the customer thinks the technology provider is responsible for and what the provider thinks the customer is responsible for.

That's exactly the lesson we learned.

[Source: FMI, “The Industry's Top Challenges with Construction Technology,” 2020 Industry Report. LINK]

The field wasn't built around software

A lot of the most valuable technology in construction ultimately depends on gathering information from the field.

That's where things get difficult.

Construction has a workforce that hasn't necessarily had the same professional exposure to technology as people in industries where almost every job has been computer-centric for decades.

That's not an intelligence issue. Spend a day watching a great superintendent manage a complicated jobsite and tell me that person isn't solving incredibly difficult problems.

It's an exposure and workflow issue.

Their expertise is building things.

Now we're saying: Good news. This technology is going to make your life easier.

First, download the app. Learn the workflow. Enter this information. Remember to update it. And do it while you're also trying to get the project built.

And often the person we're asking to create the data isn't even the person who gets the most value from it.

Someone in the field enters the information. Corporate gets the dashboard.

Finance gets better forecasting. Operations gets benchmarking. Executives get visibility. Increasingly, AI gets the data it needs to tell us something useful.

That's a tough bargain if the person doing the work doesn't get anything back.

If we want adoption in the field, technology has to create value in the field, not just three levels up the org chart.

McKinsey identified essentially this problem in its research on construction technology deployment. It found that even when pilots were successful, companies often struggled when they rolled technology out broadly without enough explanation of the benefits or sufficient training.

The result? On-site crews and foremen could see the technology as a

headquarters-driven imposition that made their jobs more complicated.

[Source: McKinsey & Company, “The New Age of Engineering and Construction

Technology,” 2017. LINK]

There's never a good time to change

Implementation is also often horribly disruptive.

The project doesn't stop because the company bought new software.

The concrete is still coming. The inspector is still showing up. The subcontractor is still late. The schedule is still the schedule.

And now we're asking everyone to change the way they work.

There's an irony I've seen repeatedly:

Construction companies can be too busy dealing with the problems technology is supposed to solve to properly implement the technology that might solve them.

McKinsey described a large contractor that had spent five years experimenting with new software and digital ways of working. Some initiatives worked during pilots. But when the company tried to scale them, employees eventually abandoned the new systems and returned to their old ways of working.

Productivity barely improved.

McKinsey's conclusion wasn't that the technology didn't work. It was that digital transformation requires much more than installing technology.

In fact, McKinsey recommended companies spend “as much time, if not more, on operational change as they spend on technology.”

They even have a great term for what happens when companies don't do this: digital “organ rejection.”

The organization basically rejects the technology.

[Source: McKinsey & Company, “Decoding Digital Transformation in Construction,” 2019. LINK]

Somebody has to own it

There's one more problem construction has to solve.

Somebody usually owns buying the technology.

Who owns getting everyone to use it?

Those aren't the same job.

Larger contractors and builders increasingly have CIOs, technology groups, innovation teams and business systems leaders who understand this. But there are still plenty of companies where technology implementation is basically somebody's side hustle.

They have a real job. And they're also the person who's supposed to make the new software work.

Someone has to notice when usage drops. Someone has to train the new employee six months later. Someone has to understand why one team loves the technology while another ignores it. Someone has to determine whether the problem is training, workflow, management or the product itself.

Without that ownership, adoption becomes everybody's responsibility, which usually means it's nobody's responsibility.

We're getting better at this

None of this means construction is destined to lag technologically.

Quite the opposite.

Commercial construction has come a long way. Residential is moving quickly.

Technology is increasingly becoming part of running the business rather than something the innovation team plays with off to the side.

And the industry's labor challenges are only going to accelerate that. We aren't going to solve the labor shortage by finding an endless supply of additional people. We have to make the people we have more productive.

Technology—and especially AI—is going to be a huge part of that.

But buying more technology isn't enough.

I wrote recently that builders are becoming data companies. I believe that. But you don't become a data company because you bought a data platform. You don't become an AI company because somebody turned on Copilot.

And you don't become a technology-enabled construction company because you have an impressive tech stack.

You become one when the technology actually changes the way your people work.

That means choosing technology that solves real problems. Giving someone responsibility for making it successful. Training people around their jobs rather than around the software. Measuring whether adoption is actually happening.

And making sure the people being asked to use the technology get value from it themselves.

It also means technology providers accepting some responsibility for the outcome.

Selling the software isn't enough.

We have to help customers actually use it.

For years, construction needed better technology.

We built it.

Now comes the harder part.