Work

Scheduling & messaging for a healthcare-interpreting firm

2012–13

A healthcare-interpreting firm — about twenty people across two offices — ran its scheduling on spreadsheets plus two dedicated mobile phones carrying a text thread per interpreter. The scheduler's role was so cluttered and brittle that only two people in the company could do it competently. I worked there in marketing. I saw the operational pain anyway, proposed the build, and designed and built the whole thing solo, iterating quick prototypes with the coworkers who'd be using it.

Two systems shipped, both from one imperative: de-stress the scheduler. First, a scheduling system built for the realities of a live phone call — find an available interpreter by language, actual availability with travel time, and geography, with color-coded regions making "where is this interpreter coming from, and headed to, around that time?" an at-a-glance read. Interpreters checked their schedules on their own phones, cutting the messaging lag. Second, a browser-based two-way messaging hub that retired the two physical phones: faster input, a single source of truth, and no more "who has the phone?" between schedulers.

The hard part was interface design — surfacing the right points of flexibility for each request out of a large space of constraints, and ending up with a clean, learnable interface anyway. A job only two people could do became one almost anyone could pick up in an afternoon's walk-through, while taking live calls. Both systems ended up beloved by the people who used them.

An OpenADR prototype for energy utilities

2014–15

OpenADR is the open standard that lets energy utilities dynamically control equipment in response to market events — outages, price changes, time-of-day consumption patterns. I was the backend engineer on a two-person contract team: my counterpart built the device-facing side ("virtual end nodes") and shaped the spec with the customer; I built the hub side — the "virtual top node" that governs it all.

The discipline the work demanded was complexity management.

What shipped was a working VTN prototype: subscriber management, the governing logic with its admin and configuration UI, and the mapping from many varieties of trigger signal to the control messages sent to the right end nodes. The discipline the work demanded was complexity management — the space of triggers and resulting actions was large, and the governing logic had to stay configurable without becoming unmaintainable. Along the way, I brought my teammate up to speed on Ruby on Rails.

A CRM & automation platform for real-estate brokerages

2015–20

A platform serving real-estate brokerages at real scale — thousands of brokerages, tens of thousands of agents, millions of contacts. I joined as technical lead, contracted through a software-development shop, working with three in-house engineers and an internal product owner. The client later hired me in-house to continue the technical leadership as the team grew; by the time I left, eight to twelve engineers were focused primarily on the product. Five years end to end.

The product kept outgrowing its category. It began as a transaction-management tool — deal flow, agents and parties — then grew CRM features: conversations managed across SMS and email, incoming-lead routing, agent-activity metrics for brokers. Then it evolved again, into outreach and response automation — buildable logic chains of triggers and actions. That automation layer was the trickiest transition, and it was primarily another engineer's direct build; my job by then was technical leadership across the team — the interface with product and company leadership, and technical quality across everyone shipping.

The trust signal: a client who converted their outside technical lead into their in-house one.

Five years with one product, through two category shifts, on a team that kept growing. And the part I'd point at as the trust signal: a client who converted their outside technical lead into their in-house one.