Before starting my career as a Customer Success Manager at DADO, I was a construction technologist for a mechanical contractor. Like many trade contractors, we struggled with making project documents, and the information therein, accessible to field operations – especially those without laptops. As a solution, I was able to ‘hack’ together a project-based document dashboard complete with hyperlinked PDFs that had an element of interconnectedness, and as a result enabled iPad users to find the information they needed in a familiar manner. Success was mine, and it was on to the next challenge…or so I thought.

It was an exciting time filled with innovation and problem solving. I built rapport and credibility with the field ops teams and, in return, they were more willing to explore other technology beyond their comfort zones. Executives within the company began to open up to other opportunities as well. The hand-crafted solutions had a glaring flaw though; due to the overly-technical nature of my dashboards (and admittedly, my possessiveness over the initiative), I was the only person in the company who was able to maintain them. As the number of projects with custom dashboards grew, so too did the time requirement: a couple of hours a week became several days a week. The cure to the initial problem quickly mutated into a curse.

This dilemma isn’t uncommon for construction innovators. When a problem exists, the innovator knuckles down, burns some midnight oil, and builds a solution that might not be the most elegant, but gets the job done. In that effort, an undue expectation begins to form. Because the solution is a smashing hit, leadership wants more of it – and that’s what they get.

In the short term, everyone wins. For the innovator, however, the curse of a successful custom-built solution can be that they become the shopkeeper, someone tethered to the all-consuming endeavor of maintaining the thing they created. The stagnation of innovation can have long-term consequences that cost the company valuable talent as technologists move on to other opportunities where they can once again flex their creative, problem-solving muscles.

What a Construction Technologist Does

The Construction Technologist (ConTech) role blends an affinity for tech with expertise in construction. The role involves creative problem solving by way of tech implementation, and researching the latest trends to identify solutions that ease the organization’s pain points. Oftentimes, the ConTech’s efficacy hinges upon their ability to both listen and communicate – they are the “human API” – integrating both digital and human resources. They must champion the very idea of innovation throughout the ranks in their business – from president to apprentice.

Success for a ConTech isn’t only defined by the progress that has been made within an organization to date, but also the progress of progress itself.

Shopkeepers or Innovators?

ConTechs risk getting themselves into a professional pickle when their inventiveness impedes innovation. This is a distinction that I’ve become more attuned to in my role as a Customer Success Manager: inventiveness refers to a person or organization’s ability to create with the resources they have; whereas, in this context, innovativeness refers to a person or organization’s ability to apply inventiveness for the benefit of the masses.

The product of inventiveness absent innovation is a killer solution everyone wants but only the creator can maintain. This is when the innovator becomes the shopkeeper, diverting their resources away from new initiatives in order to maintain their creation.

A green ConTech may be quick to charge into these with little thought; as they develop their craft, the savvy among them check their closets for these kinds of initiatives before going to bed each night. The seasoned ConTech understands that, in order to avoid becoming a shopkeeper, they need to focus on implementing solutions which democratize support and maintenance as much as possible. When contemplating opportunities to solve a problem, they hold the question “what can I scale” in equal importance to “what can I do” and “what can I implement”.

The Four Traits of Highly Scalable Technology

While scaling technology is more of an organizational feat than a finite list of characteristics, there are observable traits a discerning ConTech can be on the lookout for when hunting down a solution: repeatability, teachability, compatibility, and supportability.

Repeatability: As the solution proliferates throughout your business, is it reasonable to expect that users will be achieving the same level of quality that you, as a tech-savvy individual, would? Let’s take everyone’s favorite technology, project folder structures, for example. You will often find that, even at construction firms with well-defined standards, each project has a varying quality of contract drawing organization (especially for those companies that use decentralized project administrators). A lot of times, these structured document sets are copied directly to cloud storage providers like Box or Dropbox to be distributed to field users’ iPads. Since document distribution and iPads are often the ConTech’s domain, he or she may be tempted to manage the organization of project documents in order to control quality, which is a problem.

Teachability: If you host a training on an application, how likely is it that you will need to re-train on the same material in the near future? When technology is teachable, a ConTech can show people how to save time or add value to their work instead of trying to get their audience to commit nuance to memory. A number of factors can play into how teachable a solution might be – the most obvious is usability. But ponder this: have you ever used an app that explained itself? Maybe it welcomed you with a new tutorial on the first run, or perhaps it dropped hints throughout the course of your day. Oftentimes, teachable applications at work emulate how people use technology in their everyday lives… like searchbars 😏.

Compatibility: Incompatible technology causes friction for an end user – and I’m not just talking about “tech that speaks to each other”, but I’ll get to that soon. Imagine the following scenario:

You’re a foreman, and you have to fill out a daily report. It’s not your favorite part of the job, but part of the job nonetheless. You accomplish this by grabbing a copy of the Daily Report form from the job trailer, filling it out in ink, then you email it via scanner to your project manager and supervisor.

One Monday, the general foreman that you report to sent out an email to the whole team explaining that there’s a new, digital version of your daily report that you’ll need to fill out on your iPad. It’s an Excel spreadsheet. You can find a copy of the template by opening up the Z-Drive, clicking “zz-SUPERVISION”, “06-FORMS”, then finally “02-FOREMAN FORMS”. You are to fill that out every day and email it to the necessary parties.

What’s wrong with this picture? How compatible is the foreman’s current hardware (an iPad) with the new workflow? Sure, he or she is technically able to get the job done, but the precedence given to digitizing a workflow over providing a compatible workflow will add a level of unneeded complexity (and therefore friction) to an otherwise simple task.

As promised, a sub-component of compatibility is interoperability, or a solution’s ability to send information to or from other solutions. An example of interoperable software is a BIM viewer that lets a foreman create in-model design issues that automatically appear in the project manager’s software. The project manager can respond to the issue, and the foreman’s model will be updated in turn. Each has their own tool, neither needs to be savvy in the other’s.

Supportability: The more supportable your tech is, the easier it is to crowdsource troubleshooting and training. When onboarding customers, I often ask their DADO champions if they would like to establish “local champions” on each jobsite, or someone who is connected to the day-to-day operations on-location who can do some troubleshooting before calling IT or the Construction Technologist. Decentralizing support in this way allows problems to be handled as they arise; which also reduces the likelihood of needing to dedicate a sole-resource to maintaining the system over a protracted period of time. Though delegating in the manner described is just as much of an organizational strength, a supportable solution will have straightforward workflows, and easy-to-navigate help resources (how-tos, FAQs, etc) available.

Go and Cure Without Being Cursed

At this point, you may find yourself thinking that I am against pure inventiveness – this isn’t true. Oftentimes, it’s pure inventiveness that enables closet dorks to develop into the technology thought leaders of the industry – it has certainly enabled me.

Instead, I am asserting that ConTechs can prevent their “cures” from devolving their roles into shopkeepers by employing their acumen to develop inventive MVP’s (minimum viable products) into innovation at scale. As the “human API”, they must communicate with their organization’s leadership so that they’re prepared to support a pivot of research into more sustainable opportunities. They need to remain cautious of solutions that don’t demonstrate the “four traits of highly scalable technology” – especially their own! The mobility of their career may depend on it.