Product guy by trade. Engineering leader by way of process.

Some context

I am a non-technical CTO, which I’ve learned to say without flinching. No computer science degree. I never taught myself Java or Python on the side. What I had was a knack for understanding a problem, drawing the system that solves it, and noticing where the process around it leaked time. (Also the ability to reformat a hard drive and rebuild Windows 95 from scratch on about a monthly cadence in my last three years of college, which I maintain counts for something.)

I will say I’m a tinkerer though. I grew up loving to take things apart and put them back together. As a tween, I bought a K mart Mongoose BMX bike from a friend for $20 then proceeded to mow lawns for 2 summers to rebuild it from scratch with custom parts. It was my own personal Ship of Theseus and man that thing was amazing when it was done. I put every piece of that bike together and rode it around town to literally everything I did. I found peace in the chaos of my youth doing these types of things - breaking stuff down and putting stuff back together again.

I wish I could say I parlayed that desire and curiosity of my youth into something cool like a Mechanical Engineering or Industrial Design degree. But that aforementioned chaotic youth left me knowing literally nothing about what to do with an opportunity to go to get my undergraduate degree from the University of Illinois in Urbana-Champaign. So I studied Chemistry. And sucked at it. Then studied Biology. I sucked a bit less at that - but was wondering “why the hell am I studying Biology?” Meandering ensued. But so did a degree in Communications. Ah yes - just what every CTO is proud to hang on their wall - a Liberal Arts degree in Comms. But I’m proud. I struggled and clawed my way to a degree that accidentally solved for something I didn’t know would payoff: someone who could communicate complexity between disparate groups of folks.

My early career was hit or miss, but my timing was beyond lucky. I stepped out into the world in late 1998 as the .com bubble was, well, bubbling, when pretty much anyone with a pulse and a degree could get a decent job in tech. Mine was consulting for companies with legacy systems and a Y2K problem. I got bored fast providing services, but I was absolutely intrigued by what the engineers were doing. They were making money taking things apart and putting them back together again. So I jumped across a few jobs learning how to do just that, and quickly found that part of the process is defining what’s broken or missing and mapping out a path to repair it. I didn’t know COBOL (look it up, kids) or Java or C++. But I had developed a skill the engineering process desperately needed.

Where it clicked

I landed both the best and worst job of my young career when I joined FTD.com (yes, the flower company) in late 2004. With a toddler at home and a brand-new house, I set off to join the world of ecommerce on a massive, revenue-generating website with a ton of complexity. My first week on the job I was assigned the project nobody wanted in their massive, custom-built ecosystem: Order Processing. Nobody wanted to tackle how an order placed online made it to a florist or a drop shipper for delivery. I sure as hell did, and I paired up with one of the smartest engineers I’ve ever worked with to build it. We crushed it. For the first time in my professional career, I felt the rush of building something big, and complex, and high-stakes, and on time. The rest of the project, well, wasn’t. We got it there by working 80-hour weeks for the last six months before go-live, taking on more and more across the overall project to get things finished. That was the not-so-great part. Three months after that amazing and terrible project shipped, I quit FTD for the first time (it took me three tries to quit for real).

A new boss who joined the team took note of how my slice of the project went and talked me into staying. Tony D., one of the most important mentors in my life, noticed something in me. I could take inefficiency and solve for it. Take unpredictable and make it predictable. Be the translator between the business owners who need the thing and the engineers who build it. His extremely convincing argument is how a product person ends up running engineering, and I’ve been doing some version of that job ever since. FTD gave me eight-plus years with smart people who cared deeply about customers. I learned about budgets and getting acquired and RIFs and quarterly earnings reports. I learned how to support scaled production systems, build datacenters from the ground up, hire local staff, and build offshore teams. And compliance. Oh my God, compliance. But I felt an urge to build something of my own. To go small and make a difference. Two quitting attempts later, I finally left.

Coming full-circle

The next most important person of my professional career, Leon H., was then the CEO of a small but growing Ed Tech company called Cappex (now Appily, a part of EAB) based in Chicago. He needed a new CTO to come in to solve 3 problems: (1) Engineering was inconsistent with delivery and out of step with the business; (2) Cappex.com wasn’t mobile-friendly (this was early 2013 and you could see how important the iPhone had become) and I had built mobile-friendly, customer-facing UX at FTD; and (3) Figure out this new thing they bought that does “Scholarship Management” (whatever that meant) and is giving them trouble.

Little did I know that “3rd thing” would become my life.

Cappex needed what I had to offer: process improvement. Make delivery predictable. Meet timelines. But I needed what Cappex had to offer and I had no idea how badly.

The Scholarship Management solution Leon wanted me to dig into, with yet another extremely important person in my life as its General Manager (John C.) was the thing that needed to be taken apart and put back together. It was obtained via acquisition in an attempt to grow horizontally in the space Cappex served (Higher Ed). But it was terribly architected. It couldn’t scale. The business that it needed to run was vastly different than the business Cappex was.

So I did what I do best: John C. and I hatched a plan to spin that business off and rebuild it from the ground up. And it’s been my professional life ever since.

What I got better at over those years wasn’t technology. It was building the machine around the technology: the ceremonies, the estimation discipline, the release rhythm that lets a small team ship like a bigger one. The listening to the customer and formulating a new workflow. Finding signal through the noise of an over-crowded backlog and bug archive. By the time AwardSpring had proven its product-market fit and was a real-life business, I had a fairly strong opinion about what a well-run SDLC for a solid product looks like. We built both. Five-week sprints. Tasks written and estimated by the engineer doing the work. Quality consistent release to release. A product customers loved. A team that was loyal to each other and our customers. It hummed, and I was, in retrospect, a little proud of it.

Why AI adoption

Then in February 2026 I sat in a two-hour demo and watched most of that expertise evaporate. Velocity is no longer constrained by development capacity. For someone whose entire career was built on managing that constraint, that is not a small sentence.

I’m neither an evangelist nor a skeptic. I’m the person responsible for making this work on a ten-year-old codebase with real customers on it, and for measuring honestly whether it did. That’s what the essays here are: monthly notes from that job. What moved, what broke, what I got wrong. The caveats come with.

Well I lied a bit: I’m a least a little evangelist.

Outside the job

I shed quite a bit on who I am in that overview above. But I left out the most important part: I’m a husband and a dad. It’s cliche and I don’t care. Nothing matters more to me than my better half and my two (now adult) boys. Everything I’ve done in my professional career I’ve done for them first and me second.

I live in the Chicago suburbs and absolutely identify with this great city and the midwest. If you’re from Chicago and you ask me where I’m from - I’ll label the burb. But if I meet you and you’re not from Chicago? I’ll say I’m from Chicago. That makes some city-dwellers uncomfortable but I don’t care. It’s my city and I love it. Bear Down. Go Cubs Go.