I build and lead engineering teams, or work beside the leader you already have. Experienced technical leadership, practical AI adoption, and a culture where people can thrive. Better products and better workplaces should go together.
Ship the right thing, learn from feedback, and make products people love using.
Give talented people ownership, trust, strong teammates, and AI tools that remove frustrating work.
Get an experienced fractional CTO who can lead change and measure outcomes without building dependency.
Machines build. People direct. Customers decide.
AI should make good teams even better.
AI is changing how software gets built. I help engineering organizations figure out where it genuinely helps, adapt their workflows, and measure the results.
The goal isn't to generate more code. It's to build better products, faster, with people who enjoy the work.
None of them are about the model.
Your engineers adopted AI. Most teams have. Here's what's happening in engineering orgs right now, according to the people who survey them.
of CIOs report more board pressure for measurable AI results than last year. 86% say the CEO tied their job to AI outcomes.
Dataiku / Harris Poll, Sep 2026AI now writes about half of merged code, and median PR size nearly doubled. Senior engineers spend their days reviewing "slop grenades" someone else didn't read.
DX, Q2 2026AI spend per org per quarter, while the share of time spent on new features stayed flat. Uber used up its whole 2026 AI coding budget by April.
DX, Q2 2026 · Inc., 2026of developers trust the accuracy of AI output, down from 40% two years ago. People route around tools they don't trust.
Stack Overflow Developer Survey, 2026of organizations have had an AI-related production incident. Fewer than 4% of leaders think their current process is enough.
Qodo, 2026 (vendor survey)of enterprises are predicted to abandon AI agents that vendors built for them by 2028, because they can't afford to change them themselves.
Gartner prediction, Sep 2026I'm not here for your job.
You don't need a new leader. You need a second pair of hands while the ground moves under you.
Outcomes the business feels. Not activity that looks good on a slide.
The goal was never maximum AI usage. It's better software, delivered faster, for less, by people who still want to work there next year.
Pay people to burn tokens and they'll burn tokens. Incentives matter more than tools.
Pick five or six rows in week one. Measure them. Move them.
The rows come in three groups, in order of what matters: the people who use your product, the people who build it, and the tools they use.
From a customer telling you something to a change in their hands. This is the loop that actually makes money.
Revenue per feature, churn, a launch date. If a metric keeps showing up in board decks, it goes on the card. We agree on it in writing before I start.
AI's biggest problems right now are people problems: engineers who don't trust the output, slop tossed over the wall for someone else to review, seniors burning out on the extra volume, and incentives that reward token use instead of results. I treat those as team problems, and I put a number on them.
This is how "a happy, well-oiled machine" stops being a vibe and becomes something your board can read. Happier people build better stuff and make the company more money.
| Regretted attrition | people you didn't want to lose |
| Developer survey score | same questions, before & after |
| Trust in AI tools | asked of the people using them |
| Offer acceptance rate | do good engineers say yes? |
| Ramp time for new hires | days to first real change |
AI made typing fast. Whether the whole loop from idea to production got faster is a different question.
If writing code scaled and checking it didn't, you're shipping defects faster. This row catches that.
AI spend plus engineer time, per shipped feature. The AI bill alone is the wrong number.
Prototype, test, certification, factory run. AI used well by the team makes every step shorter.
The share of tools and pipelines your own team runs after the handoff. If this isn't high, I didn't finish.
Machines build. People direct. Customers decide.
AI writes it in seconds, so the cost of software moved.
A bug costs roughly ten times more at every stage it survives.
Your best people's attention is the scarcest thing you have.
Engineering is the tool. Fitting the product to more customers is the goal.
If the product can be checked out, built and fully unit-tested in minutes, then fixing a bug takes minutes, for an engineer and for an AI. Agents check their own work before anyone reviews it. New hires ship on day one. Nobody batches fixes because the build takes an hour. Slow builds and flaky tests are a tax on every change, so I treat the development environment as part of the product.
Agents don't argue with a failing test. Use that.
Your best engineers' attention should go to what to build, how it fits together, and the changes that could really hurt. Not to reading AI slop or waiting for builds. Automation protects their judgment.
A mountain of code with every test passing doesn't make a dollar. What does is people learning from customers and adjusting the product, fast, so it fits more of them. Engineering is the tool. The team is how you use it.
That's why my scorecard counts the whole cost of a feature, and starts with the customer.
Measure first. Build with your team. Hand it off. Measure again.
I get into your code, your pipeline, your AI spend and your team. A short survey and a lot of listening. We write down where the rows are today.
Review gates, cost controls, specs and tests outside the code, the hiring loop, whatever the goals call for. Built with your people, not around them.
The tools, gates and dashboards move to the people who'll keep them. I write the playbook and step back while it still has training wheels.
Baseline next to after, in a format you can hand your board. If a number didn't move, it says so.
The first cycle follows the bar private-equity operating partners use: a baseline in 30 days, something working in 60, documented impact in 90. After that, a retainer keeps the loop running. Each month we pick two or three goals, build, measure, and hand over what's ready. The scorecard never stops, and each month starts where the last one ended.
A baseline and the real bottleneck.
Something working, numbers moving.
Documented impact, then the next cycle.
Four ways, from a two-week look to building the whole team.
| Assess | Advise | Accelerate | Build | |
|---|---|---|---|---|
| Who leads | You | You | You | Me, until your hire |
| My time | 2 weeks | ~1 day / week | Several days / week | Half to most of the week |
| Scope | Fixed | 1–2 goals / month | One part of the team | The whole team |
| Ends with | Baseline + plan | Monthly scorecard | Before/after scorecard | A team that runs without me |
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.
Not AI in the device. AI in the team that builds it.
If your company has hardware, a factory production run, and software on the device or in the cloud, that whole cycle can be faster and better with AI used well. Almost nobody is showing hardware teams how. I've worked every stage of that cycle.
| What I've done | Where |
|---|---|
| Tested iPhones to FCC specs; designed factory testing so only compliant iPhones and iPads shipped | Apple |
| RF test station for the iPad lines at Foxconn, concept to production | Apple |
| Cellular and WiFi certification test framework that hardware engineers could maintain themselves | Apple |
| Created the multi-million-dollar wireless lab for Google WiFi | |
| Outgoing quality control overhaul at contract manufacturers in China | |
| Defined the FCC specs for software-defined radio; first Class 3 permissive change | Vanu |
Most AI-for-engineering help stops at the software repo. Hardware teams have the slowest, most expensive loops: lab time, certification, factory runs. That's where a smarter team gets the biggest gains.
I held senior titles on both the hardware and software ladders at Google, so I can sit with both halves of your team and speak their language.
Software only? Still a yes. Your scorecard just skips the hardware row.
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.
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.
Stuff people ask before they reach out.
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.