The “Lean” Construction Technologist
About a year ago I asked Jake Olsen of LINQ to recommend a book to give me a better idea of how tech startups work, knowing that Jake had a background in successful startups and understood the industry as it relates to construction technologies. He recommended Eric Ries’s book “The Lean Startup.” The book opened my eyes to how many parallels exist between tech startups and what we do as Construction Technologists (CTs). Like most books that are central to a comparable industry, it defined a lot of terminology and provided tips and useful processes that I think we can really benefit from. The book itself espouses an adapted version of lean manufacturing. Basically, it applies lean principles and cultural benefits to the software startup industry. Most significantly, Ries applies a cyclical understanding of continuous improvement to software creation in a way that can be easily adapted to our work in Construction Technology
It was, in fact, such a good fit that I now think CTs within a company as more of an internal tech startup. Functionally, the similarities were overwhelming. Our goals are to produce useful, effective technology for our customers, but in our case that customer is our own business. The success of Ries’s approach has led to countless successes in in the tech industry and has made his book almost required reading for new tech startups.
Lean is not at all new to construction. We have applied lean methodology from manufacturing, to our fab shop, job sites, and buildings and seen great improvements. However, when it comes to construction technology within an organization, I think that the lean focused should favor the tech startup model over the manufacturing model for lean. This is particularly relevant when it comes to financing CT’s endeavors within organizations. It is very hard to fund new and emergent technology through an ROI evaluation because there is not always a traditional return on investment. Reis argues that to be effective at tech innovation you cannot rely on successful implementation of every new technology. Reis explains in his book that we need to accept that learning, knowledge, and understanding have a measurable value to our companies and can provide returns beyond the immediate implementation of a technology by guiding us to better alternatives or helping us adapt technology to better fit our needs. So, for CTs we need to follow a model that can allow us to assign a value to the work they’re doing and track progress, but that does not always rely on the success of any individual tech introduction. For a tech startup, this evaluation is done by measuring success using something called validated learning.
Validated learning is part of a process that Ries refers to as the, “build-measure-learn feedback loop.” This process is my biggest take away from the book. It defines a process that I think can be adapted easily to the CT within an organization, specifically a CT that’s not working on building software for the industry but is working within a company to build its portfolio of technology.
The graphic below shows my version of the feedback loop modified just slightly to described its use in Construction Technology.
The first step is the idea. All of us who engage in construction technology have a passion for new ideas, and if we sit down, we could probably write out 10 or 20 ideas that we think are worth taking the time to look at. Turns out though that there is, in fact, a process that can help us pick the better ideas so that the ideas we do decide to move forward with have a greater chance at being successful. That process is called design thinking. Again, in this article I am primarily looking at the build-measure-learn feedback loop, so I’m forced to ask you to look elsewhere for an understanding of design thinking, and its core principles. But in a nutshell, design thinking is a process that focuses on rooting out real problems in need of a solution, and if we want to be successful, solutions to those problems should be at the heart of the ideas we are seeking.
So, if we were a software startup, once we had identified an idea we would build an MVP — Minimum Viable Product. This is a product that meets the minimum requirements of our idea. This is the area where a CT often differs most from a tech startup. As CTs we are almost never building a product from scratch. So, for CTs the initial MVP relies more on an informed product selection process. We are typically selecting a product from outside our company and combining and adapting them to our company’s use case or need. Many times, this is where “artful use” and even hacking come in handy. As CT’s we often do not have the ability to directly change the products. We instead need to adapt workflow and use or add functionality by other means. This is especially true if we are attempting to use a product or technology in an unconventional way. Regardless, one of our goals, at least in the first round of introduction, should be to avoid a huge upfront investment.
Next up is probably the one we fail at most often — finding measurable outcomes for testing. This is Ries’s ‘validated learning.’ For startups this is often measuring customer response. For CTs, the customer can be the foreman, journeyman, fab shop manager, or project manager using the technology. But I think the biggest part of this for us should be defining real KPI for the technology we are trying to introduce. This KPI can also be an enhancement to other known KPIs within the organization. For instance, the KPI of BIM in my department is how close the model is to the final product, or how much of the model can be fabricated and installed without alterations. So, during the measured phase of my MVP I should be looking for ways in which alterations are being minimized, if that is one of the goals of the technology introduced. Also, as I’m collecting information on my MVP I should be mindful of any misguided or false assumptions made during the build, or anything that simply didn’t work well.
The last step in the cycle, and in part the goal, is to review all the data from testing and decide on what to do with our MVP. This is really the critical step. Often in construction, the goal of a technology introduction is to have a product for implementation within the business, not to learn more about what technology should do for the business. Certainly, the idea that after testing you might simply pivot to something new can give us a little heartburn. Pivoting can appear to be a loss, but something Eric Ries makes clear in his book is that the willingness to pivot and walk away is a necessary part of success. He stresses the fact that the learning has a significant value regardless of whether that learning is passed on to improve the MVP, or simply becomes knowledge used in creating a new MVP. He also stresses though the need to improve your product and the necessity of going through this process of learn, build, measure several times before the product is ready to be passed from development to implementation. Even at that point, we should always be looking for ways to optimize, and true success often comes from an ongoing process of improvement. For those of us with a background in lean manufacturing, none of this should sound new.
Construction Technologists are a relatively new position within construction, and as such a lot of the means, methods, and processes we use to perform our job are not well defined. I do not think the build-measure-learn feedback loop represents CTs final workflow or process, but I do think it can become a good Minimum Viable Process for us to start from. And I think “The Lean Startup” is a great resource to look to for understanding how we can better introduce and implement technologies within our companies.