Voice becomes software
Telephony spent a century as copper and switches, then became configuration. I spent eleven years on the bridge between the two — and the view from there shaped everything after.
Context
I started in 2007 administering VoIP systems at Tel4Tel: call flows, SIP trunks, codecs, gateways. The century-old empire of copper was being rewritten as applications, and real customers depended on the rewrite working. In 2011 I moved to FCP — technical support first, network engineering a year later, then years of VoIP specialization and eventually managing the VoIP function through 2018.
The problem
Voice is unforgiving product territory: people notice a broken phone call instantly, everyone from a CEO to a grandmother is a user, and the system spans analog handsets, ISDN lines, IP networks and carrier interconnects — each layer with its own failure modes. When a call breaks, 'the network' is blamed; finding which layer actually broke is the work.
Why it mattered
For the businesses we served, telephony was not a feature — it was revenue, safety, and sometimes the only line to their own customers. Reliability was a form of respect long before I could articulate it as a product principle.
My role
Across the years: administering production VoIP platforms; answering the phone when things broke; engineering the networks voice ran over; designing NGN and Cisco voice platforms; and finally leading the people who kept them alive. The progression mattered — support taught me how systems actually fail, engineering taught me why, and management taught me that coordination is its own discipline.
Constraints
Legacy everywhere: equipment designed decades before IP, interconnects with monolithic carriers, customers who could not describe their own call flows, and the hard realtime constraint of voice — latency and jitter are not degradeable UX, they are broken calls.
Discovery
Answering the support line was the best product education I ever received, before I knew the word 'discovery'. Every ticket was a lesson in how systems actually fail — and how people experience failure. Reproduce, isolate, verify: the skill that outlived every technology I've used since.
The decision
When I led the VoIP function, the standing decisions were about where to standardize: which platforms to build on, how to structure the team so knowledge lived in the systems and documentation rather than in one expert's head, and how to keep the analog discipline — physical-layer thinking — alive in an IP world that preferred to forget it.
Trade-offs
Deep specialization in voice was narrowing; the compensation was mastering a whole vertical end to end — signaling, transport, switching, and the human organization around them. The clearest trade of the management years: solving problems through people instead of through my own keyboard, which felt slower and turned out to scale.
Outcome
Voice platforms designed and operated for real customers over years, a team structured to survive its own expertise, and — in the direction that mattered most to my later career — a firsthand understanding of what it means when a network service becomes a product: the promises, the failure modes, and the user on the other end of a silent line.
What I learned
Voice was my first infrastructure product: invisible when working, binary when broken, judged by everyone. Every product principle I hold now — defaults, promises, operational honesty — has a telephony ancestor.