Twenty-five rooms, three complaints

I have two daughters, Ruth and Maggie. Ruth is six and Maggie is four, which means I spend a surprising amount of my life watching two very small people conduct hostile usability testing on systems I thought were perfectly reasonable.

At home, you can make a rule, put something in the "right" place, explain exactly how it is all supposed to work, and feel pretty good about the system you designed. Then a six-year-old and a four-year-old actually use it and expose every flaw in about thirty seconds.

If putting something away takes too many steps, it does not get put away. If they have to walk across the house for something they use constantly, that thing quietly develops a new home somewhere much more convenient. If there is a simpler path from A to B, they will find it, whether it was the path I intended or not.

Somewhere around the four hundredth demonstration, I realized there is a lesson in that for software.

The real world always wins.

I did not come to Bigge as the Director of AI Engineering. I came here as a Senior Developer, and one of the first big things I got to work on was Field Service with the WorkPro team. Looking back, I am glad it happened that way.

Building Field Service taught me Bigge from much closer to the ground, and I should be honest about how. I was not the one sitting next to service managers taking notes. That was Cal and Tommy Huynh. Tommy translated the needs of the business into something a developer could actually build against, and he did it so well that I sometimes forgot I had never dispatched a technician in my life.

My moment came at the demo. Watching the service managers and billers react to software that finally matched their work is one of those moments that reminds me why I work in technology at all. You can go a long time between those. You remember them.

Cal deserves more credit here than one paragraph can carry. He is the one who sat in the rooms, and somewhere along the way he told me that working together reminded him why he was excited to work at Bigge in the first place, and that he believed in what I was doing, on Field Service and beyond it. When the VP of Innovation says that to a developer, the developer remembers it.

There is a huge difference between a workflow on a diagram and that same workflow in the wild, and you do not have to be the one doing the shadowing to learn it. It showed up in every piece of feedback Tommy and Cal carried back.

On paper, a process looks perfectly logical. Step one leads to step two, which leads to step three. In reality, somebody has a customer on the phone, a technician waiting on an answer, eleven browser tabs open, and five other things competing for the same brain.

That is where you find out whether you actually built something useful.

That experience shaped how I think about technology here. It also made something Cal shared with me a lot more interesting.

Before I joined Bigge, Cal had already done an extensive round of discovery across the company. He sat down with twenty-five departments and functions, from Payroll to the HSTX shop to Gulf Coast logistics, and documented the problems people were running into.

When he shared those notes with me, I started reading and immediately recognized the problems, because Field Service had been one long guided tour of them.

Different departments were describing different versions of the same problems.

People enter the same information into multiple systems. The systems holding that information do not always talk to each other, so WorkPro, FastField, Smartsheet, D365, email, spreadsheets, and shared drives can each end up holding a different piece of the truth. And when somebody finally needs the finished product, whether that is a customer document, an inspection record, a service report, or an internal approval, a person pulls all of those pieces back together by hand.

Once you start seeing that pattern, you see it everywhere.

And just like Ruth and Maggie rearranging the house around whatever makes the most sense to them, people adapt. They create spreadsheets. They keep their own notes. They copy and paste between systems. They send themselves emails. They build little workarounds that make an imperfect process survivable.

I do not say that as criticism, partly because most of those workarounds are evidence that somebody solved a problem the tools did not solve for them, and partly because I am one of the offenders. To this day, the fastest way I know to move something between my phone and my computer is to paste it into Teams. Not proud of it. It works.

Those are exactly the things I want us paying attention to.

That does not mean every process needs AI. Here is a sentence I have apparently never actually said out loud to my team, so I am saying it in print where they can screenshot it: sometimes the best AI solution is no AI at all.

Sometimes two systems just need to talk to each other. Sometimes a process needs to be simplified. Sometimes a form needs to disappear. And sometimes the answer really is an AI agent or a model. The technology is the last part of that decision, not the first.

That is a big part of why I am excited about where we are now. AI Engineering is not a team sitting somewhere inventing AI projects and then wandering the company looking for places to put them. The work comes from the problems Bigge already has.

One test I apply to almost everything

If an automation only works because somebody has to remember to fill out another field, upload another file, open another application, or complete some new step that exists purely for the benefit of the automation, I get skeptical fast.

You can build something technically impressive that fails very quietly that way. Nobody announces the failure. People just stop using it.

Or, more often, they route around it.

That is the part my daughters have made impossible for me to unsee. You cannot win a fight against human behavior by adding another instruction. If the easiest path is not the path you designed, people will find the easier one, usually within the week.

The best automation meets people where the work already happens.

1. 01If a technician already completes a service report, use the service report.
2. 02If somebody already sends an email, use the email.
3. 03If WorkPro already knows something, go get it from WorkPro.
4. 04If D365 already has the customer data, do not make somebody type it again because our shiny new system wants its own copy.

That sounds obvious written down. It is surprisingly easy to violate about ten minutes into building.

Field Service reinforced that lesson over and over. The closer the software matched the way the team actually worked, the better the result. That idea carries straight into everything my team builds now, whether it is an integration, an automation, an internal application, or something powered heavily by AI.

The one thing I will always ask you for

It is not because we expect everyone to have perfect metrics sitting around. Almost nobody does. A reasonable estimate is completely fine to start. But we need some kind of baseline, because otherwise it is incredibly easy to confuse building something with improving something.

If a task takes thirty minutes and happens twice a month, automating it might be nice. If it takes thirty minutes and happens two hundred times a week across the company, we are having a very different conversation.

The baseline also surfaces the workarounds. Sometimes the official process says a task takes five minutes, and everybody actually doing it knows it takes twenty. Sometimes there are three unofficial steps nobody documented because people have been doing them so long they barely register as steps anymore.

That is the equivalent of discovering that the toy bin I thoughtfully placed across the room has been empty for three weeks because Ruth and Maggie unanimously decided right in front of the couch works better.

The spreadsheet somebody made, the email folder somebody depends on, the checklist taped next to a monitor: those might look like workarounds. To us they are information. They tell us something the official process is missing.

The baseline keeps my team honest too. If we say we saved the company time, we should be able to show how. If we say a process is faster, we should know what it was before. If we say we removed manual work, the person who used to do that manual work should actually feel the difference.

I care about that a lot more than I care about how something looks in a demo.

What I want from the rest of Bigge

You do not need to understand AI to bring something to us. You do not need to know whether the answer is an agent, an integration, an application, or a workflow. That is our job.

What I want to know is where the friction is.

1. 01What do you have to type twice?
2. 02What spreadsheet does your department secretly depend on?
3. 03What report takes somebody half a day to assemble?
4. 04What information do you know exists somewhere at Bigge but can never find when you need it?
5. 05What task makes you think, every single time you do it, there has got to be a better way?

And maybe most importantly: where has your team already invented a better way on its own?

Those are the conversations I want my team having.

One of my favorite parts of working here has been getting away from the computer, walking the yard, and learning how this company actually works from the people doing the work. The best of those so far was a yard walk with Weston Settlemier, watching the owner of this company get hands on with the cranes himself. I have thought about it a lot, and the most precise professional language I can find is that it was freakin' badass.

I have found great teachers in Brian Noga and Weston, mostly by paying attention to how they lead this organization. And connecting with Hunter Settlemier has been one of the genuine joys of the year: a kindred spirit who is as excited as I am about the world of possibilities this technology keeps opening up, and another person who has made it clear he believes in this work.

Bigge is a complicated place in the best possible way. There are 110 years of processes, knowledge, equipment, relationships, and people behind what we do. You cannot understand that from a database schema.

You have to see the work.

That is probably the bigger lesson I have taken from Bigge and from being a dad. Designing the system is the easy part. Watching real people use it is where you find out whether you were right.

Cal's discovery sessions gave us twenty-five rooms worth of evidence. Field Service gave me the chance to build against those problems myself. Now, as Director of AI Engineering, I get to put a team on them.

There is going to be plenty of cool technology involved. I am a developer at heart, so I would be lying if I said that part was not fun. But the goal is not to make Bigge look like a company that uses AI.

The goal is to make Bigge a better company to work in because we use it well.

One last thing I am especially happy to share. James Iorio moves from intern to Associate AI Engineer on August 24. The WorkPro connector work featured in this issue is his. He has been operating above the intern title for a while now, and I am excited to have him officially continuing with us on the AI Engineering team.

See you in September.

Keenan Chiasson
Director of AI Engineering