I help teams build software that serves millions
I'm a principal engineer who's spent 15 years learning that the best technical solutions come from understanding people—the users you're serving and the teams you're building with. Currently, I lead development on Angular applications serving 32 million Charter Communications customers, where I've discovered that working at scale teaches you what truly matters: reliability, clarity, and systems designed for the long haul.
My sweet spot is translating complex technical problems into solutions that teams can execute and maintain. I believe great architecture balances immediate needs with future growth, mentorship matters more than hero code, and the best technical decisions serve business objectives without compromising engineering principles.
What I'm doing now
I work on Charter's Spectrum product, building the router and network management tools that 32 million households depend on. The scale has been humbling—handling real-time network data for millions of concurrent users, designing architecture patterns that accommodate wildly complex network topologies, and ensuring reliability when any outage affects entire cities.
This scale forced me to level up. I've learned GraphQL, built micro-frontend systems that multiple teams can work on simultaneously, and built analytics systems that actually help us make better decisions. More importantly, I've learned what principal-level work really means: it's less about what you build yourself and more about multiplying the effectiveness of everyone around you.
I train and manage offshore development teams, mentor senior developers through architectural decisions, and balance large-scale refactors with greenfield feature development. I've presented at internal tech summits, but the work I'm proudest of is the AI integration training I designed and delivered across the organization. I pitched the strategy to VP-level leadership, built the framework, and helped teams move from "AI is scary" to "AI is part of how we work." Adoption rates jumped significantly—not because I forced it, but because I helped people see how it could make their jobs better.
How I got here
Teaching teams to scale (2020–2022)
Leading a development team at an ed-tech company taught me that architecture isn't just about code—it's about establishing patterns that help teams move faster together. I built a component library that became the design and engineering standard across the organization, which sounds dry until you realize it meant designers and engineers could finally speak the same language.
We achieved WCAG AA compliance across the entire application, which taught me that accessibility isn't a feature—it's a design constraint that makes you build better software for everyone. We also reduced bundle sizes by 65% through strategic optimization, which mattered because our users were often educators on slow school wifi. Performance optimization isn't vanity metrics; it's respect for your users' reality.
The real learning: mentoring the team and establishing sustainable practices mattered more than any individual technical contribution. Good systems outlive good code.
Building with constraints (2015–2017)
At myStrength, I worked on a digital mental health platform serving users nationwide through their insurance providers. HIPAA compliance wasn't a checkbox—it was a constant design constraint that taught me to think through the full lifecycle of user data. I learned to collaborate across product and engineering teams to balance compliance requirements with genuine accessibility for people seeking mental health resources.
The stakes were real. This wasn't optimizing conversion funnels; it was building tools for people in crisis. That changes how you think about reliability and trust.
Leading small teams (2017–2020)
Running a team of five engineers at By the Pixel was my crash course in leadership at a design agency. I learned to translate client needs into technical architecture, built a JavaScript loading system that improved performance across multiple projects, and discovered that Google PageSpeed scores above 90 are possible if you're willing to make performance a first-class concern from day one.
The biggest lesson: small teams need systems even more than large teams do. When everyone wears multiple hats, clear architectural patterns are the difference between sustainable growth and constant firefighting.
Finding my footing (2011–2015)
I started through freelance work and startup incubators—Startfast, Z80 Labs, and eventually a lead product design role at FDBK, a CRM platform. These early years taught me what I didn't know, which turned out to be almost everything. I learned the hard way that building engaging social features for business applications requires understanding both the social dynamics and the business problems you're solving.
This period was messy and invaluable. I made every mistake you can make with small codebases and lived to refactor them.
What I believe
Software is a team sport. The best technical solutions come from understanding the problem deeply, communicating clearly, and building systems that teams can maintain long after you've moved on.
Architecture isn't about picking the "right" framework—it's about understanding tradeoffs and making decisions that serve both immediate needs and long-term sustainability.
AI is transforming how we work, but tools are only as good as the strategy behind them. Adoption without understanding creates chaos; thoughtful integration creates leverage.
Documentation and mentorship aren't "nice to have"—they're how you scale yourself and build teams capable of solving problems you haven't anticipated yet.
Beyond work
I live in Denver and spend my free time hiking, rock climbing, perfecting pour-over coffee technique, and participating in book clubs with friends. I maintain a personal website at elliottregan.com where I occasionally write about engineering, strategy, and the things I'm learning.