Hi, I’m Nigel. Technology and engineering have interested me for as long as I can remember, but a career in finance and operations left little time for either. (Those who know me know I don’t stop pulling a thread until I get to the end…and that’s exactly what happened.) What began as a quest to make my Ring doorbell tell my TP-Link porch light switch to turn on, 12 months later produced what I share on this site. I learned a great deal along the way. If you find something useful here, good. You don’t have to agree with any of it.
The short version of my career is three industries—fleet leasing, distribution, and payments—and three domains: finance, product, and operations. Across each, I kept returning to the same questions: how does the business work as one operating model, how is value created, how does cash move, and where are decisions really made?
That perspective developed across different seats at the table. At Ryder, audit taught me to question the assumptions behind financial performance; treasury brought decisions back to cash flow; and planning connected them to the business that had to deliver. At HD Supply, serving as Treasurer and leading FP&A brought capital, operating performance, and expectations into the same frame. The IPO work added the responsibility of explaining how the business created value and which measures mattered.
Moving into payments at First Data and Fiserv required learning a different system for creating value. My responsibilities expanded across finance and into general management and operations, reinforcing that the operating-model view transfers even when the industry, economics, and obligations change.
My career was not in engineering.
After Fiserv, I built a lab to examine the technology through which operating models are increasingly implemented. Identity, networking, virtualization, AI, and automation became practical ways to test how policy, controls, business rules, and user experiences become working systems.
A lab reveals limits by allowing boundaries to be pushed in ways a production enterprise cannot permit. But freedom alone produces toy problems. For the learning to transfer, the lab had to reflect corporate constraints: identity, decision rights, segregation of duties, engineered controls, audit transparency, resilience, recovery, and real operating consequences.
Within the constraints of an enterprise, but without the constraints of an enterprise.
The enterprise requirements stayed in place; organizational permission cycles, legacy commitments, and production risk did not prevent the experiment. That made it possible to follow failures across seams, understand LLM and AI behavior directly, and see how a decision in one layer changes the whole operating model.
This site keeps the evidence, the writing, the revisions, and the open questions. The projects show what was built. The larger lesson is how to work across boundaries while keeping authority, controls, and accountability visible.