How I think about digital engineering
It starts with a problem / idea
Sometimes it’s clear, specific, and small, like extracting data from a table or creating a complicated 3D model. Other times, teams have a rough idea of what they want but aren’t sure how to get there. They might see some inefficiencies in their work and want to improve them with better digital workflows.
Not all problems are equal
In those cases, I work closely with teams to uncover the real problems. That might mean brainstorming, prototyping, and asking a lot of questions. It’s about doing the work needed to get to the root of the problem. The biggest mistake I’ve made is rushing to solve something before I fully understood it. And honestly, it still happens from time to time. Especially when things are urgent.
Laying it all out
Whether it’s a simple problem or a complicated one, once we know what we’re dealing with, I like to pause and lay everything out. That means documenting it all: the data, models, spreadsheets, assumptions. Everything. I’ll also include the problem and the strategy. Writing things down helps align expectations and keeps everyone accountable to what we're actually building.
Ways forward
Now that we understand the problem and have a few ideas about what the solution might look like, there are usually two paths forward.
Small, Specific Work
For small, focused problems, a lightweight script or tool can go a long way.
It might be a naming convention fix or a simple plugin that exports data into a required format.
This kind of work is usually quick, effective, and helps improve existing workflows without overcomplicating things.
Involved, Systemic work
For messier problems, the kind tied to existing workflows or critical processes, the solution is often a new tool or a completely different way of working.
It might be a Revit plugin that checks model quality as part of the existing QA process. Or a new modeling workflow designed to meet ever-changing BIM requirements.
This kind of work usually takes more upfront thinking, but leads to longer-lasting results.
It's never a straight line
Even though everything here flows from one step to the next, real-world projects are rarely that neat. Real design is almost cyclical in nature.
Sometimes, we think we understand the problem, jump into creating something, and then realize it doesn’t quite solve it. Other times, a "quick" script uncovers more of the problem. What was supposed to be a couple days of work can turn into a couple of months.
From here, it’s all about support
It’s less about building and more about supporting what’s been built.
It's about troubleshooting, refining, and helping teams as they used what we've created. That might mean fixing bugs, answering questions, or making tweaks. Sometimes, it leads to new projects that extend the last tool. Other times, it’s about helping teams adopt the new way of working which sometimes involves training or workshops.