Shane Sturgeon

The sturgeon is one of nature's great survivors: prehistoric, unhurried, essentially unchanged for over 200 million years. While currents shift and the water churns above, it holds its line. It doesn't chase the surface. It does its work in the deep.

That's the kind of engineering leader I try to be. Not the loudest voice in the room. Not the one chasing the next trend before the last one shipped. The one who shows up consistently, holds the team steady under pressure, and creates the conditions for other people to do their best work.

The name isn't accidental. It's a description of how I lead.

I wrote my first line of code in the early 1990s and haven't really stopped since, though what I build has changed considerably. The early years were hands-on: enterprise applications, web development, consulting work. Around 2013, I made a deliberate shift into engineering management. Not because I wanted to stop building things, but because I found I could create more impact by helping teams build things better.

Most of that work has been in healthcare and federal systems: Medicaid platforms, Healthcare.gov, CMS programs, regulatory environments like HIPAA and FedRAMP. It's a domain that rewards precision and penalizes shortcuts, which suits me fine. I've led teams ranging from a handful of engineers to organizations of 25+, and the through-line across all of it has been a stubborn belief that teams do their best work when they're trusted, equipped, and not buried in process overhead.

For the full career picture, the resume is here.

This site is where I think out loud. The topics I keep coming back to:

• ·Engineering leadership — how teams actually function, what managers get wrong, and what good looks like when you can find it.
• ·Agile in practice— not the framework, but the discipline. What it looks like when it works and what it looks like when it's just renamed ceremony.
• ·AI and tooling — building with LLMs, leading AI engineering work, and thinking carefully about what the technology actually changes vs. what it just accelerates.
• ·Healthcare systems — operating software at scale under compliance constraints, and what that teaches you about priorities.
• ·Building things — projects, experiments, and the occasional barn.

Start with the blog, or browse projects if you'd rather see what I've shipped.

I play indoor soccer one to three times a week. I've been renovating my wife's childhood home since we bought it from her parents in 2019: new roof, 36×36 horse barn, front porch, back deck, a garage converted to living space, a kitchen remodel, an upstairs bathroom, and probably another five to ten years of projects ahead. Almost all of it done by hand.

I find the same satisfaction in framing a wall correctly that I find in a clean system architecture. Getting the structure right so everything built on top of it holds. This is not a metaphor I invented; it just keeps being true.

I've been running hdtvmagazine.com since the early 2000s, originally out of genuine enthusiasm for HDTV technology and a desire to learn PHP and MySQL in production. It's been through every architecture era since and is currently running a multi-service AWS setup with an AI-powered content pipeline. Having a live site with real traffic that I'm fully responsible for end-to-end keeps me honest about what it actually means to operate software.

I also run a home NAS and Docker lab for the same reason. There's always something to try before recommending it to a team.

There's also a growing list of project ideas that haven't shipped yet, which I maintain as stub repos with enough notes to pick up when I have bandwidth. A few of those will eventually land on the projects page.

If any of this is useful or interesting, the blog is the right place to start. If you came here to evaluate me professionally, the resume has the details, or you can ask the AI anything you'd ask me in a first call.