About
J. Kahn Koontz
Why I do this
I've spent most of my career on the inside of systems that were supposed to make things easier. Embedded hardware that has to be right the first time because you can't patch a thousand PCBs in the field. Data platforms that outgrew the design they started with. Security work where the answer has to hold under a nation-state adversary, not just under a demo.
Across all of it, the same thing kept happening. The hard problems weren't hard because the technology was weak. They were hard because the system had grown more complicated than the people maintaining it could hold in their heads. And the fix was almost never more. It was less.
That's the whole idea here. The work is judgment about what to keep and what to cut with decades of experience to know how to do it successfully.
Where I've been
The kind of systems I know from the inside
Embedded and low level
Bare metal and close to the hardware, where there's no framework or operating system to hide behind and every decision is a decision that will be etched in the board forever. From designing nation-level phone systems to securing medical devices, my hardware level foundation is the reason I read a system by what it does, not by the documentation written about it. Component level errors masquerade up the stack.
Security and adversarial thinking
Building and reviewing systems that have to hold up against someone who wants them to fail, not just against a test. Adversaries include rogue actors, governments, and even Mother Nature. From the locks on the doors to the failsafes in the code, my work in Government Regulatory Compliance (and a lot of Defcon events) guides how to balance the security/velocity equation.
Data and pipelines
The plumbing under the dashboards, where the tangle usually starts and where the cost of it shows up. I've scaled the API that answered 900+ million iPhones through Siri, owned global data infrastructure, designed protocol standards, and debugged systems where the issue was one faulty wire 3 continents away. Infrastructure isn't always sexy but it's almost always critical.
Running the shop, not just the code
I've been the person accountable for the whole thing, the product, the team, and the bill, which is why I can tell you what a system costs to keep, not just what it costs to build. My hat-feather collection includes CIO, CTO, & COO but more importantly it includes titles like Lead-Engineer, GRC program manager, and On-Call support. Running solid systems avoids the call that nobody wants to make or take.
This job is judgment, and judgment is what years of decisions you've already made adds up to. I've taught years of knowledge in the classroom but experience in the field is earned one year at a time.
The standard I work to
Elegance is simple. Simple is the standard here, and it's a high bar not a low one. A system is simple when you can explain the part that carries the weight, when the rest of it earns the cost of staying, and when it fails in a place you expected. I hold work to that line before I call it done.
I'm independent, which means the answer isn't shaped by a vendor relationship or a roadmap I'm selling. I take fewer engagements for the same reason. If I say something's a fit, it's because I think I'm the right one to help, not because of a sales quota.
Enough about me. Tall me the the problem.
Send it over and I'll tell you whether I'm the right one to untangle it.
Contact