I build the piece that's missing, then hand it to the people who'll keep it.
In hindsight, most of my career has been fitting together things that don't naturally fit: hardware and software, people and systems, engineering and the business. At Vanu it was a radio department that didn't exist. At Apple it was test software nobody asked me to rebuild, still running a decade later. At Google it was a wireless lab and a test platform. At Microsoft it was AI that people actually trust.
I could make more money selling bigger teams. I have enough money. I'm in this because I like building things, building teams, and building up the people on them. Happier people build better stuff and make the company more money. The scorecard is just how I prove it.
Things I started that nobody asked for, and that are still running.
A production AI system for investigators who spent 40 hours writing each report.
A clandestine software project I started and led: about 50,000 lines that replaced the incumbent test software. It's still being used more than a decade later.
Senior titles on both the hardware and software ladders at Google. Two separate promotion committees, both passed. In ten years I met no one else who'd done it.
I defined the technical specs the FCC adopted for software-defined radio. An entire class of hardware now operates under rules I shaped.
A new radio modulation added through a software update, the first time that had ever been certified. It's the cert that let the company book revenue for the quarter.
The test platform I built became the org-wide standard at Nest, with services that pushed trillions of test results into BigQuery.
A software-defined radio startup with, somehow, no radio engineers. I was hired as a field engineer and ended up inventing the department. I defined the specs the FCC adopted for the whole industry, and the CEO and COO were counting on my projects to keep the lights on.
Find the gap nobody owns, and build what fills it.
I was hired to build the software that ran the RF tests. I saw a better architecture and toolset that would speed up development for everyone, so I quietly led a project to replace the incumbent software. About 50,000 lines and a team I ran for two years. It became so popular that it's still in use more than ten years later.
Nobody directed it. Once it proved itself, it became the standard.
I tested iPhones to FCC specs and designed the factory testing so that only FCC-compliant iPhones and iPads shipped. I built the RF test station for the iPad lines and spent real time on the Foxconn floor, on the highest-production phone ever made.
Get close to where the product is actually made.
I joined the Google WiFi team when it was six people. I planned, budgeted and built the multi-million-dollar wireless lab for what became Google Nest WiFi: decided what to measure, wrote the code to run the lab, and wrote the analysis tools. The product's performance rode on those choices.
Build the thing the team will depend on for years.
The customers weren't engineers. I spent the early weeks sitting with the investigators, learning how they actually think, and designed the AI around their workflow, keeping them in control of its output. That's why they trust it, and why it got used.
Adoption is the metric. Cleverness isn't.
A vision for a data platform and no team to build it. I shaped the strategy with the CEO, architected and shipped a terabyte-scale platform, then hired and mentored the permanent team that runs it today.
The handoff is part of the job, not the end of it.
People first, then culture, then tools. AI is one of the tools.
I install the engineering culture of Google and Apple in teams being built today, but only the good parts. (Apple's shouting matches at sprint planning? Leave those.)
Good engineers can work anywhere. I look for the ambitious ones who are stuck, bored and under-leveled somewhere else, and offer them a role a level up with real ownership. The great ones jump; the mediocre ones don't. That's how you know. I was part of Google's interviewing and hiring machine, and how they pick engineers is an art form.
Real ownership with the authority to match. A path to grow. And the high-five-at-every-bug-fix camaraderie that makes hard work feel good. One Friday night at Apple my team integrated modules that had never run together, live, with the customer watching, and shipped. The team was happy, so we crushed it.
Code got cheap. The hard part moved: knowing what to build and knowing whether it works. So the engineering goes into specs and tests that live outside the code, review gates and spend limits. Point AI at the drudgery engineers hate and leave them the art. AI is a mech-suit, not a replacement.
You own what gets built. Vendors can ship fast and leave you a system you can't afford to change. I build with your engineers, in your repos, on your accounts, so the team that has to live with it is the team that made it.
When your team is confident and the numbers are moving, your own people take over the process I built, and I fade out to find my next beginning. Everyone wins.
I'm selective about the work I take. Here's what I'm looking for.
Projects where being a standard software expert isn't enough: ambitious scope, an unclear path, and work that spans data, vendors, factories, radios and morale.
Does this need leadership across diverse areas?More important than technical ambition is the team. If the people and the culture are good, ambition and achievement flow easily.
Tell me how you take care of your teams.I've built rural cellular coverage, part of the factory that made millions of iPhones, satellite phones and missile defense systems.
What is it going to do for the world?These days I'm probably not the best coder in the building. I understand the product, the business and the customers well enough to shape the engineering org around them.
What does the CEO need from me?The Agile Manifesto is brilliant. Heavy Scrum isn't how FAANG teams work. I build teams of empowered individuals who ship 2–5× faster.
Would I have room to build a culture like that?Not AI theater. Tools your engineers trust and pick up on their own, because they make the work better and leave them the fun parts.
What would your team do with a mech-suit?A CTO got hired to build something new at a fairly large company, big enough to spend tens of millions on a new engineering org. His pitch: he'd solved this exact thing before, for the competitor.
At Google, the project would have taken a team of about ten engineers. He hired maybe 200. I was on a call with 50 of them at once. Teams were measured on story points shipped: not code quality, not features, not regressions. Ship too few and you were fired.
He had a 10-person problem. He solved it by drowning 200 people in fear.
He treated the people as tools. I treat the tools as tools.
By his boss's measure he was a success: a giant team, a giant bill, and the project got built. At ten times the cost in dollars, in the people who left, and in the people who stayed and spent half their time shipping story points.
I only watched from the sidelines. It showed me who I am by showing me who I'm not.
My approach: hire great people, treat them really well, build great things.
Machines build. People direct. Customers decide.
Happy team, happy customers. Let's have some fun and make some money.
If you are growing a team, changing how engineering works with AI, or navigating a difficult technical transition, I would love to hear what you are building. Based in Denver; working with teams across the U.S.