Is Your Tech Stack too Wicked to be Kind?

Last week I took part in an exercise that sought to work out a vision for the future of construction. I have participated in this type of exercise many times over my career with a host of different groups. The specific takeaways are always different, and always very interesting, but almost all share two common themes.

First is that construction projects, and in particular the jobsite, are extremely difficult to standardize. Goals, procedures, materials, standards, and even building methodology tend to be very different from project to project. The contractor, and even more the specialty trades, are often not in the position to set standards and must adjust their practices and standards to match those imposed upon them by the project requirements.

The second common theme is that the fab shop offers a much easier environment to standardize. The idea of modular construction, off-site fabrication and manufacturing is likely the future of construction and answers many problems of the jobsite.

So, I often leave these exercises with one question in my mind: what is the fundamental difference between the jobsite and the fab shop?

Not so much what the specific differences are, which can be obvious. One is inside, one is outside, etc. But what is at the base of the difference, and how can I use that knowledge to build a better tech stack?

Recently, I read a book that I think may have captured that base difference and given me some direction in building a better tech stack. The book was called “Range: Why Generalists Triumph in a Specialized World” by David Epstein. It’s based in part around work done by Robin M. Hogarth, Tomás Lejarraga, and Emre Soyer on the psychology of learning environments.

The studies and the book establish two environments. These are labeled the wicked and the kind, and these labels are applied to both environments and the type of problems within them. Understanding these two environments seems to me to be at the heart of understanding the difference between the jobsite and fab shop environments.

Put simply, the kind environment is one where the rules are relatively fixed and repeatable. Efficiencies are gained by working a known process or procedure faster. It lends itself to incremental improvements that are strict and targeted. This closely matches the environment of the fab shop and manufacturing.

The wicked environment is one in which the rules are very dynamic and there are fewer opportunities for fixed and repeatable solutions. In this environment, efficiencies are gained by having very dynamic processes and procedures or having a huge range of them to draw from. This wicked environment more closely matches field construction and project management, where success often hinges on the dynamic range of those leading operations and their ability to adapt.

So how does this relate to your software stack and the future of construction?

If most people think that the future of construction will be closer to manufacturing (a kind environment) but the current state of construction is primarily on the jobsite (a wicked environment), then our stacks need to tame the wicked environment, using kind tools or those that are suited for a kind environment. To do this, we need to pull together a number of programs in our software stack that provide enough range to support the a wicked environment, the jobsite, but taken individually work well in the kinder environment of our fab shops.

How can we do this?

The first step is to sort our stack. Break the software into kind and wicked. Programs that are strict and targeted support a kind environment, and those that have integral dynamic range are wicked.

For instance, a program that simply does timecards versus a program like Excel. Excel is a wicked program that can be set up to do a huge range of functions. One of those functions could be timecards. Other programs exist that specialize in time cards and offer functionality specifically targeted at doing time cards simply and efficiently. These targeted programs are typically simple to manage and straightforward to use, while programs with a lot of dynamic range are often more difficult to manage and use. The range means that there are often a huge number of options to configuring them for a specific task. Also, the unused options can cause confusion for people seeking to use them for a single specific task. So the lesson is If you do not need the range, it is often best not to have it.

This lesson even applies to programs that seem wicked in nature. People learning Revit vs. Autocad for doing AEC will usually learn faster in the Revit environment because that environment has been targeted to AEC and is, at some level, kinder for those tasks.

Now, before you start sending me hate mail telling me how much better AutoCAD is, please realize that Revit and AutoCAD are in the same stack. Over the last few years, Autodesk has successfully moved from offering individual programs to offering software suites — a stack as opposed to single products.

Also, more specific to construction, Procore offers a similar stack format with a central program and a number of point solutions and integrations, using a stack of mostly kind solutions to provide its dynamic range.

The problem with these brand-specific stacks is they may not offer the best solution for a given task. As end users, we have no need to cater to a brand. We should pick the solutions that best fit our projects. When doing this, we should favor the kinder solution where possible to help enable efficiencies in our shops, but always provide enough solutions to enable our jobsites to adapt to conditions.

In my new position as a Construction Technologist at CAISSON, I will help firms pull together the best kind solutions to tame wicked environments, and present the wicked programs we need in a kind way. So when we get to the shop we are ready to manufacture and when we are on the jobsite we still have the tools we need to conquer a wicked environment.