Haskell — Q&A with Director of Innovation
Few construction companies have had a larger impact on the construction tech ecosystem than Haskell. Through Dysruptek, their corporate venture arm, the company has made a splash by engaging with the wider start-up community and thoughtfully communicating their experience with others around the industry. It’s a win-win-win proposition, and one that’s beginning to bear fruit.
As the Director of Innovation, Hamzah Shanbari is focused on transforming Haskell’s day-to-day work processes by leveraging new technology that will make their work safer, higher quality, and more efficient. Part of his role is to engage with start-ups on Dysruptek’s radar and implement processes that ensure success for the business. We talk here about his approach to piloting and the value of field feedback in construction tech.
Do you mind talking a little bit about your role at Haskell? Your venture arm Dyrusptek plays a part in this too. So maybe if you want to talk a bit about that as well?
Absolutely. So there’s this boom in construction tech that’s disrupting an industry that’s ripe for disruption. And we were fortunate to have executive leadership that recognizes this and stood up a separate unit with dedicated resources to look at these technologies and understand how they can disrupt our workflow and processes. Our investment mantra is to ask if this is something that Haskell can use internally to make us safer, higher quality, or more efficient.
We’re also not only using these technologies to solely make Haskell better — we’re also directing some of that knowledge back to the construction tech world, telling them, actually, if you tweak it over here a little bit, if you change that, if you add this feature, it’ll make it even better. And this way we’re helping the industry more generally.
I actually like Haskell’s model the best because there’s a lot of advantages to having an investor partner rather than just an investor — being able to work with your field teams, as well as the construction tech startups, to make their products as best as they can be. It’s really that user feedback loop that other technology industries take for granted that’s broken in construction. And so iterating quickly on things is actually really difficult to do because of the project-based nature and dispersed field teams. It also hinders scaling…
That’s totally valid. And that’s kind of how we started looking at this when we hit the ground running in 2018. When we look at a new tech or a new start-up, we get to know the team, understand their solution, problem statement, and what they’re looking to solve. Having a structured database that we can compare everything to is also very helpful, so we can quickly identify other competitors working on a similar problem.
Once we’ve made intros, that’s when we get our internal end users involved — whether it’s a superintendent or a project manager, preconstruction or design team, architects, whoever it might be — we become the marketing team for that start-up internally within Haskell and we show our internal users what could be.
Maybe we see some value, but we don’t know exactly how it’s going to fit into the overall workflow or process. So we bring in the start-up team to pilot. That’s not only an opportunity for their pipeline, but we’re also coming back to them with end users that now not only want to learn more and use it, but they’re also giving them valuable feedback on what can be improved.
Having spent time developing start-up engagements at large construction companies, I know the process comes with its own challenges. Success in construction tech pilots, I think, is made difficult by the same issues around project types, project users, and so on that makes the construction industry difficult more broadly. How do you navigate that at Haskell? How do you look at one part of your business like Consumer Packaged Goods and know whether to experiment there versus Infrastructure & Transportation, for example?
We try to talk to each in their own language, so to say. Because they do have different processes and they communicate with their clients differently. One of the main things we do is to make sure that it’s set up well in the beginning. Having an implementation plan and talking about what success looks like, user-wise but also technology provider-wise, ensures that everybody agrees on it.
One of the big examples that I always like to show is Pype Closeout. We piloted a super simple, web-based platform that automates the majority of communication and reminders for all these different trade partners that you have on a project. They’re able to submit specific submittals, OEM manuals, warranties — all of these different elements that you need at the end of a project to close it out. It’s something that our assistant project managers usually spent a whole lot of time and effort chasing down with different Excel sheets to make sure everybody got everything. So that that was one very simple solution that just clicked right away.
Another example is documentation of job site progress. We got a lot of pushback with that early on. When we first started talking to HoloBuilder and StructionSite and piloting some of those on our projects, we’d often hear, “This takes a lot of time!” or “I’m not seeing a lot of value in it!”
It wasn’t until they hit a bump with litigation or some he-said/she-said scenario that they were able to go back and see what actually happened at a specific location. If we didn’t have that documentation, if we didn’t have those pictures that are easily viewable, then we would have been left out to dry. We had one or two incidents like that and now these tools are becoming much more readily available and scalable.
Do you a have a log of what the field needs are? How are you handling the push versus pull of technology implementation?
We pushed a lot in the beginning because nobody really knew who we were. We were going around and talking to people and asking if they could help us test something, like, “See what this looks like and give us feedback.” Around 2019, we started an internal newsletter [called The Update] that we publish monthly that namechecks what we’re looking at and provides an avenue for some project managers or superintendents to reach out to us and say, “Hey, I actually kind of want to use that right now on my project”.
So it’s much easier running it this way because we’re not chasing people. Since each project has so many phases, the pilot has to be within a very specific timeframe. Having that visibility and that communication out there so that individuals around Haskell are aware of all the different technologies, all the different value propositions, and they’re able to reach out to us when they want to test something — it works out so much better.
Nate Fuller is Managing Director of Placer Construction Solutions, advising leadership teams to transform their organizations in ways that improve performance and agility at the field level.
He provides construction companies with a field assessment that delivers transformative information about their field operations and is proven to accelerate innovation & technology adoption for Top ENR contractors.
If you found this article insightful, please consider signing up for my newsletter at placersolutions.io
