Tiger Solutions is one year old! It’s been a wonderful (if a bit tiring) year, and I am excited for what is to come. But as part of my year-end reflection, I’d like to address a question that comes to me often: “What does Tiger Solutions actually do?”
If you work in deep technical solutions, you might know the feeling. Sometimes it’s just difficult to explain what you do and why it’s relevant, especially to people who aren’t as deep into the topic. Like your family around the Christmas table.
The easy answer for us, at least in 2025, is “we’re doing AI for Engineering and Construction.” The two magic letters (A for “Actually” and I for “Irritating”) trigger immediate reactions: amazed, annoyed, surprised, disgruntled. It gets the point across to your nosy uncle, but I always feel queasy saying it, because that’s not actually what we aim to do.
I want to explain, more than what Tiger Solutions does, why we do it. Hopefully, with the why, the what will become clearer.
Back in the late 2010s, I was part of an industrial megaproject—capital expenditure over a billion euros. I had taken on additional responsibilities, and I was deeply invested in its success. Late hours, hard work, doing everything I could to get things done the right way.
What came as a bucket of cold water was that the project was a massive financial failure for my firm. In the next all-hands meeting, one of our top executives singled it out as one of the reasons we had a terrible year, and announced a bunch of measures so that “we never have such a terribly executed project again.”
You can imagine my face hearing that.
Of course, my work was just a small cog in thousands of pieces. But still, all that hard work, apparently not worth it? Was that really the case?
After that meeting, I became a man on a mission. Every time I had face time with someone relevant to that project, I’d grab a few minutes and just ask: “Hey, how come that project went so badly? What happened?”
It was a very amusing exercise. Every single time, I’d trigger some sort of breakdown. They’d start babbling about a hundred different things that went wrong. A lot of it was finger-pointing; I’d hear the problem was with other teams, other departments, the client, the contractors, and so on.
I had two critical insights at the end of those chats. The first was: projects don’t fail because of a single thing. There’s no single “oops!” moment where you can say, hey, if you just avoid doing this next time, you’ll be in the clear. It’s a multitude of different things building on top of each other, adding up delays and costs until you eat up your margin.
The second insight, and this was eye-opening: nobody I spoke with mentioned any engineering or design errors. There was no miscalculation on the load on a beam or the flow for a pump. What we had plenty of, however, were problems caused by incomplete or inaccurate information.
Here’s what I’ve come to understand, at least in engineering and construction: the key to having a successful project is in the correct management of the information flowing in and out of the project.
Information flows into the project from external sources: client requirements, vendor specs, site conditions, codes and standards. These usually will constitute design parameters and conditions, determining the constraints for your project. It flows out as engineering output: process design, calculations, drawings, material take-offs.
Most importantly, it flows between teams, constantly. Information is constantly passing from one team to the other, as in engineering design the outputs of one team are the inputs of the next team.
Why is this information flow so difficult to manage? The problem is information almost never arrives when you need it. The whole design process is done, over years, with a shaky foundation of information that is completed slowly from literally hundreds of different sources.
So what do engineering teams do to compensate? They make assumptions and estimates. They move forward because they have to, in order to keep the project schedule.
When information does eventually arrive, the design needs corrections. And they cascade. One incorrect assumption in process design becomes a bigger error in mechanical, which affects civil/structural, which results in having to adjust the layout. Errors compound and snowball, falling through the cracks until they surface in construction, when the cold hard reality of physics meets what you produced in the office. And by that time, the errors are worth millions.
I call these problems, to steal an expression from tennis, unforced errors. They are errors of miscommunication, of information not being stored nor processed properly, of shifting conditions not being properly managed.
Every engineering and construction firm knows this problem exists. They’ve lived it. They’ve complained about it in lessons learned meetings and promised to do better next time. And then next time comes, and the same patterns repeat. Most have accepted this as the cost of doing business—the inevitable friction of complex projects.
We haven’t.
We don’t think the information management problem can be solved with one magic step. But we believe we can mitigate some of these issues using technology. Unforced errors are a symptom of how information moves (or doesn’t) through projects—and we’re building systems that make the right information available at the right time to the right people.
When you consider that engineering and construction is a 10 trillion dollar market and 40% of global carbon emissions, every bit of rock we chip off this mountain makes a difference.
We’re chipping.