VP of Business Administration Kristin Emmet breaks down our end-of-project process for picking apart the pain points of every job and making sure they don’t crop up again in the future. Since we started scaling up as a company, she’s been our expert on how we turn growing pains into growing “gains”.

As an operations strategist, I’ve always defaulted to process. It’s how I make sense of things: if something isn’t working, or we’re experiencing a problem as a team, there’s usually a gap, a breakdown, or a missing step somewhere underneath it. If a system needs to be implemented, I can usually figure out where and why.

When I first got to Downtown FabWorks, one of the first things I gravitated toward was our Lessons Learned log.

A Process That Looked Good On Paper

At a glance, it seemed like we were doing it right: every project had a Post-Mortem Meeting, and everyone who touched the job had a voice, from the sales person who confirmed the project to the driver who delivered it. There was space to reflect, to call things out, and to say “this could’ve gone better.” That, in and of itself, is rare.

But the more I sat in those meetings, the more I realized something wasn’t clicking. The logging structure was too simple. We were using a spreadsheet with just four columns:

1. Item
2. Occurrence
3. What We Learned/Solution
4. Who

Everyone involved would fill it out before the meeting and come prepared to talk it through. In theory, it should’ve worked. But there were these quiet, consistent comments coming from the team:

“We keep making the same mistakes.”

“Nothing actually changes.”

“This info just dies here.”

And they weren’t wrong.

The System: Break it Down to Build it Back Up

What we had here was reflection, but no retention. There was no way to zoom out, no way to connect patterns across jobs, and no way to turn individual frustrations into something actionable at a company level. So, I went about rebuilding it in a way that forced us to be more honest and more specific about the difficulties we were experiencing during builds.

Instead of settling for four vague lines, I started asking different questions:

• What is this really about?
• How often is it happening?
• Where does it live?
• Who actually owns fixing it?
• Is this already part of our process, or is it a blind spot?
• What’s the real issue, and what could we do differently?
• How urgent is this, really?

‍

Next, I organized everything into buckets that reflected how we operate:

• operations and task management
• quality control
• purchasing and inventory
• workforce and labor
• client satisfaction and delivery…
• …and a catch-all for the things we didn’t quite understand yet.

‍

‍

Patterns Emerge

The new system slowed things down at first because people had to think more. You couldn’t just write “communication issue” and move on; you had to decide where it lived, how often it was happening, and whether it was actually a process failure or something else.

We had our big push for Super Bowl LIX in New Orleans at that time, and so we quickly saw our systems at work and could clearly spot where friction tended to materialize. During that time, something shifted. Patterns started to show up. Not just within a single project, but across multiple projects, and once we got a chance to see a pattern clearly enough, it became harder to ignore it. It also changed the tone of our Lessons Learned conversations.

Ownership + Teamwork > The Blame Game

Since our perspectives around pain points changed, the conversations about them also shifted. Questions became less focused on “what went wrong on this job and whose fault was it?” and more about “what are we doing, as a system, that keeps creating this outcome?” The script flipped. Fingerpointing was out; teaming up to face and fix a problem was in.

These big shifts mattered more than I think people realized. We started to get more clarity around ownership. It turns out that fixing system-level problems isn’t about who clocks the issue and logs it, but who is actually responsible for fixing it, and how the rest of the team can support them in doing so.

Enter another small addition we made to the process: asking others to weigh in on whether a problem is actually worth solving. This little move created alignment in a way I didn’t expect. It turned isolated observations into shared accountability. Suddenly, we could see how an issue flagged in one place often turned into a different (and sometimes bigger) problem for someone else downstream.

How Little Changes Led To Actual Culture Shift

In these ways, our Lessons Learned conversations slowly became more than one-time, die-on-the-vine callouts. They became data–something we could revisit, sort, and prioritize. What’s more, they became tangible talking points I could bring into leadership spaces to inform conversations about process flow, staffing, scheduling, and even financial performance. It gave weight to things that used to feel anecdotal or based on “vibes”.

Most importantly, the rehauling of our Lessons Learned process made it hard to hide from reality, which I’ve recognized as a true culture shift. When the same issue shows up ten times across ten different projects, it’s not bad luck—it’s something we need to own. We’re still not perfect at it. There are still gaps. And the reality of our industry is that we’re never going to stop running into problems.

But it no longer feels like we’re just talking in circles. Now we can proudly say that we’re learning in a way that sticks.

____________________________________________________

Discover how our intentional growth behind the scenes sets us apart from other fabrication partners and leads to excellent outcomes for our clients and the experiential spaces we bring to life for them. Give us a shout today to team up with us and tackle the big ideas you’re working on!

‍