I grew up in this industry. Before I was designing software systems, I was learning what happens when the tools, the process, and the people using them don’t quite line up. A few early jobs still shape how I think about the work.
In 1998, I was a network administrator for a dialup ISP inside a local PC manufacturer in Milwaukee. Over the holidays and into 1999, I was also manning the company phones. A customer called after picking up her PC: the monitor was missing. After my shift, I went to the warehouse, retrieved the monitor, and drove it to her. She called my boss afterward. That led to me becoming Corporate Customer Service Manager at nineteen.
I wasn’t thinking about a career lesson when I delivered that monitor. Someone had bought a computer and couldn’t use it. The work wasn’t finished because our part of the transaction looked finished. There was still a person at the other end who needed the thing to work. I’ve carried that with me into software: the handoff matters, and so does what happens after it.
A powder coating shop in Billings taught me about process from a different angle. Preparation, masking, racking, coating, and curing all had to fit together. The oven had limited space. A big job or an expedite changed what could move through the shop and when. You couldn’t understand the schedule by looking at one step in isolation. Quality and reputation depended on the whole process, including the work that was easiest to overlook.
At twenty-one, I was a Loss Control Coordinator at CompUSA. I counted inventory with paper and a clipboard, then entered the counts into a different form in SAP, in the same application. The tools didn’t fit the work. Shrink also crossed the boundaries between departments, in a retail business with thin margins. It wasn’t something one person or one form could explain. That experience made me pay attention to the work people actually do, including the duplicate effort a system quietly asks them to accept.
Those experiences are part of why I care about architecture, engineering, and operations together. A technically sound component can still sit inside a process that makes everyone’s job harder. I want to understand the constraints, talk to the people doing the work, and follow a change far enough to see whether it helped. Sometimes that means writing software. Sometimes it means questioning the handoff, the measurement, or the way we’ve organized the work.
I’ve learned a lot of ways never to do things. I’ve also learned that doing the right thing can be ordinary, practical work: finish the delivery, understand the bottleneck, remove the duplicate entry. I grew up in this industry, and I’ve never stopped wanting to do the right things for the right reasons.