Matt Weatherford

We had one Lambda per endpoint. That meant thousands of separately deployed functions, a bespoke framework only we maintained, cold starts on every path, and hard ceilings at 29 seconds and 15 minutes that had quietly shaped the product around them.

Now it's a containerized service model built on a single image: one artifact to build, test, and reason about instead of thousands. Long-running jobs just run. Cold starts are gone. The self-invoking-job workarounds are deleted. And because the whole system is one image, developers can stand up test environments on demand instead of queueing for a shared one, which did more for delivery speed than any process change I could have written.

The part that compounds is hiring. New engineers now onboard onto ECS and ordinary container tooling rather than a framework that existed nowhere except inside our company.

A natural-language data explorer that turns "show me course requests from August for these two institutions" into validated SQL and a chart. The interesting engineering isn't the generation. It's the refusal path: read-only enforcement, SELECT-only parsing, blocked sensitive columns, admin-scoped access, a clarification loop for ambiguous asks, and the generated SQL shown back to the user every time.

Same posture in an unattended Gmail triage service that routes mail with a confidence threshold, ships in draft mode until it earns send mode, and emails a digest of everything it decided. I hold the line that AI systems need an auditable trail and a graceful failure mode before they get autonomy. Then I ship them.

Selling infrastructure to universities and Fortune-500 tuition-benefit programs means the security questionnaire is the sales cycle. I ran SOC 2 Type II to attestation, covering controls, evidence collection, BCDR, access review, and vendor risk, then automated the evidence capture rather than re-screenshotting the world every audit window.

The output isn't a PDF. It's that enterprise integrations clear procurement on schedule, without engineering quietly becoming a questionnaire-answering department.

I run several teams, not one, and that changes what the job is. The scarce resource stops being throughput and becomes coherence: whether two teams solving adjacent problems land on one architecture or two, whether a decision made in one corner is discoverable from another, whether standards are genuinely shared or merely published.

I own the org chart and the number attached to it: headcount cases built and defended, promotion and compensation decisions argued on evidence, a blended model of full-time and vetted nearshore engineers, and the unglamorous continuity work of making sure no critical integration has exactly one person who understands it.

I also carry the partner surface directly: funders, consortium partners, and enterprise integration teams. Engineering leadership at this stage isn't only shipping. It's being the person who can hold a technical conversation with a foundation program officer and a registrar in the same afternoon.

The category of problem I know best: hundreds of independent organizations, each with their own system of record, none of whom I can compel to change anything, and they all need to transact reliably. Course catalogs that exist as PDFs. Equivalency tables maintained by hand. Student records that have to move without breaking financial aid.

What that teaches you is defensive systems design: assume upstream data is wrong, make ingest validate at the row level, keep provenance for every record, build to published standards (1EdTech, PESC, CEDS/CIP, IPEDS) so partners can integrate without a bespoke project each time, and design every integration so a partner's outage is not your incident.

It's the same discipline any company needs the moment its product depends on someone else's data. I just learned it somewhere with unusually high stakes and unusually old systems.