Thomas Howard

About

I'm Thomas Howard, CTO of Snap eHealth, an engineer, and the founder of BusyNow. I work across product engineering, platform architecture, infrastructure, reliability, developer experience, and AI-native engineering systems.

I'm particularly interested in how much of an engineering organization can be encoded into software. Not just using AI to write code, but building the system around it: agents, testing, deployment, observability, infrastructure, policy, governance, and the feedback loops required to operate software safely. That's the idea behind what I call an Engineering OS.

BusyNow

I'm the founder and engineer behind BusyNow, a production application I'm building and operating on Kubernetes. It's also where I test many of the ideas I write about here. I want the infrastructure, automation, and abstractions I build to have an actual job rather than exist only as demos.

BusyNow has become the proving ground for Engineering OS: an experiment in whether a very small engineering organization can operate software at a level that historically required a much larger team. The engineering underneath can be sophisticated, but the experience of operating it should become increasingly simple.

Go and Kubernetes

I came to Go through platform engineering and Kubernetes, and it changed how I think about both. I'm particularly interested in moving beyond operating Kubernetes to building software that extends it: controllers, custom resources, reconciliation loops, operators, and platform APIs.

Becoming a CTO hasn't made me less interested in the engineering. If anything, it's expanded the system I'm trying to understand, from a reconciliation loop inside Kubernetes to the architecture and operating model of an engineering organization.

Writing

This site is where I write about engineering leadership, AI, platform engineering, Kubernetes, Go, reliability, governance, Engineering OS, and what I learn from building and operating real systems. I'm more interested in documenting what survives contact with production than presenting a polished version where every decision was obvious and everything worked the first time.

I don't publish on a schedule just to publish. When I've built something interesting, gotten something wrong, changed my mind, or learned something worth explaining, I'll write about it.