I’m Nathan Slaughter, a software engineer with more than a decade of experience building and operating software. My work spans fintech, observability, data pipelines, and global infrastructure. Before software became my main work, I managed portfolios for ultra-high-net-worth clients.
The through line
Investment research taught me to ask what a number represents, when it was available, and what evidence would make me trust it. A convincing backtest can fall apart on data the strategy has never seen. A technically successful response can still give someone the wrong input for their decision.
That habit carries into engineering. Passing tests is useful evidence, but I also want to know whether the running system delivers what the people relying on it actually need. Observability, measurement, and verification keep bringing me back to that question, whatever the industry.
Selected engineering work
Integrating the metrics ecosystem
At Lightstep, shortly after its acquisition by ServiceNow, the observability product was expanding across metrics and logs. I managed a team of contractors building integrations for infrastructure including Kafka, Cassandra, and RabbitMQ. The work included two OpenTelemetry Collector receivers, one of them the initial SSH receiver.
Those integrations connected infrastructure telemetry to the observability system. The work meant understanding each source, preserving the meaning of its metrics, and making that output useful to the people operating it.
Moving metrics into a data lake
On a platform team within the organization, I built and operated a metrics pipeline delivering more than 50 MB/s into a data lake. I also ran the logs and metrics stack supporting the platform.
That work put implementation and operation in the same hands. The pipeline had to keep moving data, and the telemetry had to help us understand what the system was doing. Building a system and being responsible for its operation has shaped how I think about reliability.
Operating a global platform
I operated a Kubernetes platform spanning more than 50 datacenters and supported workload teams from their first Helm chart through the life of their services. That included helping teams get deployed and instrumented, alongside the work of running the shared platform.
The useful result was other teams being able to operate their software. A team lead later told me their workload had reached the platform because of that support. Helping a customer or another engineering team succeed with what I deliver is a part of the work I value.
How I got here
I started building software in 1997, writing tools to research and implement investment selection and portfolio management strategies. From 2001 to 2003, I took small contracts while studying, including stock selection research for equities funds and backtesting for asset managers.
I then moved into managing money for ultra-high-net-worth investors, eventually with responsibility for over $2B. In 2013, I became a proprietary trader, owning several short time horizon equities strategies from research through execution.
In 2015, I joined Honest Dollar, a seed stage fintech startup, responsible for investment algorithms and portfolio management across hundreds of accounts. I learned to test, deploy, and operate software, and to build the SaaS infrastructure around it. Goldman Sachs acquired the company, and I stayed two years to see the migration through to completion.
After that, I contracted on two trading systems and infrastructure for a stock exchange. I worked on datacenter operations and automation at a banking software company, then data pipelines and analytics for a rideshare analysis tool whose market data reports were sold to asset managers.
That last project sharpened my interest in observability. I wanted to know query latency, which queries customers used, and pipeline throughput. Coming from a field where I was expected to defend every number, I wanted the same visibility into the software producing them. That led me to Lightstep and then to operating the global platform and metrics pipeline described above.
How I approach engineering
I start by understanding who depends on a system and what they need it to do. That gives the implementation, tests, and operational measurements a common purpose. I want acceptance criteria that describe an observable result and telemetry that lets the team check whether it is still true after deployment.
I like the enabling side of engineering as much as the building: helping other teams deploy their services, understand their data, and operate what they own. The people closest to a product often know which behavior matters most. Working with them is part of getting the engineering right.
I’ve worked through acquisitions from both sides, staying through Honest Dollar’s migration into Goldman Sachs and joining Lightstep after its acquisition by ServiceNow. Re-platforming a running system calls for careful changes and continuous evidence that it still serves the people relying on it.
What I’m exploring
I continue to experiment with AI-assisted development, agents, and evaluation. My personal projects operate homelab infrastructure, manage documents, and curate unstructured data. These give me domains where I can judge the results myself and investigate where generated code, tests, or evaluations are wrong.
The statistical side of evaluation is an area I’m still developing. I want my writing about AI to show the actual change, the mistakes I caught, and the evidence behind the result. The same standard applies to any engineering claim I ask a colleague or client to trust.
Get in touch
I’m open to engineering roles where I can help teams build and operate reliable software, across industries. My independent practice focuses on API and SDK development for financial data companies. I also offer scheduled checks of their APIs to report whether customers can retrieve the expected data, including new releases and revisions.
Contact me on LinkedIn with a note about the role, team, or project you have in mind.