Byron Kubert

I build engineering teams that run like a happy, well-oiled machine.

Fractional CTO Board Advisor Technical Due Diligence AI Implementation

20 years at Google, Apple, Microsoft, Nest, and one small MIT startup. I'm a software staff engineer with deep interests in complex and unusual projects — but more importantly, crafting the teams that build the software. The name of my company might have given that away.

Let's Talk on LinkedIn
Byron Kubert — TeamCraft Software
20 years across
Google
Apple
Microsoft
Nest
Vanu
My Interests

I value building something meaningful — and doing it with great people.

If you need a web server or just a Kubernetes cluster built, I can help you find somebody. :)

&
01

You've got an interesting problem.

I like software engineering projects where being a standard software development expert isn't enough and the project is big, ambitious, and meaningful. My work on the iPhone is an easy example, and most of my career has been these kinds of projects.

02

You genuinely value the people you work with.

More important than technical ambition, for me, is the team I care for and the people I work with. If the people and the culture are good, then ambition and achievement flow so easily. What better way for me to work in the environment I like than to build it myself.

I like nebulous problems — and building a well-oiled team that fixes them.

The Craft

Building the team.

The thing I'm best at isn't any one technology — it's bringing real structure and culture to a team that's growing. Here's what that actually means.

Step 01 — Technical Direction

Setting the right direction is important — and so is adjusting.

Ambitious, nebulous, and impactful projects don't usually provide a clear path to building them. I bring the technical experience to know what to try, and the humility to let go of ideas that don't work.

Step 02 — Find ambitious people

Make it a place good engineers will leave their current job for.

Good engineers can work anywhere, but they're hard to pull out of their current job. I look for the ones who are stuck and bored — no remote, no advancement, no challenge — and offer them a role a level or two up, a chance to fully own far more than before, with my expertise backing them up. The ambitious ones jump; the mediocre ones don't. That's also how you find them.

Step 03 — AI

AI needs its own section.

At Microsoft I built an in-production RAG system that cut report-writing time by 87%. I absolutely believe in AI and that it can be a tremendous benefit to software engineering. I've also used millions of tokens and had only a wasted afternoon to show for it. AI is a wonderful tool, but integrating it into your development workflow and culture requires that the tool provide real value to people — and the social finesse to convince them to try it.

Step 04 — Handoff

I like the building more than the running.

Symbiotic. I enjoy and excel at the beginnings — the nebulous and ambitious ideas, the technical problems to solve, building and mentoring the team. Other people want to take over a well-oiled machine and keep it humming for the long term. The trick is to recognize what each person values and excels at, and build the team with a combination that achieves the goal. When your product is stable and your team is confident, your new ambitious engineers take over and I fade out to find my next beginning. Everyone wins.

Selected Results

A few things I've built.

I've done some fun things. I work best when the direction is known, but the details are not.

Microsoft
AI Implementation Lead
I got to build a real, in-production AI system for Microsoft. The key detail on this project: the customers were not engineers, which meant I really needed to understand their workflow and what they wanted. The big takeaway was that AI is wonderful, but it's not a panacea to apply to every problem. In this case I understood the users, and my product got adopted by the team. Real production AI that people actually use — which is the hard part.
Google
Senior Software Engineer
Google culture is interesting — let's talk about that. Getting stuff done at Google is very different from getting stuff done at Apple. Both have world-class software engineering, and somehow they have cultures that are nearly opposites. Google hires you on and says, "here's our monorepo with all the code. Find something to build and we'll compare it to what everyone around you built. See you in 6 months." This was fun. I spent (exactly) one million dollars. I joined the Google WiFi router team when it was 6 people. I played with trillion-row databases. I got to lead engineering conferences — sometimes accidentally. The most important skill I developed was how to get things done in a very autonomous, fluid environment full of independent, very talented engineers. Google's engineering culture is filled with gems.
Apple
Senior Software Engineer
The Apple culture in the early iPhone org was something. When you start there they say, "welcome to Apple. Here's your piece of the product — you own it, you have the responsibility AND the authority for it. Your job is to make it the best in the world. Here's a problem; have an impressive solution built by Thursday at 3pm." This was wild. I owned parts of the iPad factory. I spent (I don't know how many) millions of dollars. I started up an internal software product and ran that team for two years. There were, literally, shouting matches at sprint planning meetings. I don't recommend that part. Apple's obsession with quality permeates everything — and it really works.
Vanu, Inc.
Member of Technical Staff
Vanu was an MIT research project spun out into a company — a Software Defined Radio startup with, somehow, no radio engineers. So I invented the department, despite being hired as a field engineer. This company was small enough that the CEO and COO were counting on my projects to recognize enough revenue to keep the lights on. Which is kind of a lot of pressure on a kid in his late 20s. I got to see how small businesses make deals, and how those deals work out well sometimes and poorly other times. I owned major parts of the main product. I helped write some new FCC rules. I negotiated performance margins with the vendors, and sometimes pricing. It was a wonderful, supportive culture that let me grow and take on as much responsibility as I wanted — I even invented a few software products in addition to the department. Small companies really have to pay attention to culture.
Where I Help

One craft. Different rooms.

What I like to do is called different things in different situations. In all of them, I know how to build the team that will build the thing.

Build

Fractional CTO

You need to start hiring and start shipping that new product, but you don't have a strong engineering leader yet — and can't wait the four months it takes to hire a good one. I get the engineering org working — structure, hiring, culture, delivery — and get the team shipping, and I know when and how to leverage AI. I stay until the team is running and you've got that full-time engineering leader hired.

You're left with: a team that owns the product.
Tune

Board Member / Advisor

When you want a technical voice in the room who's watching whether the team is actually healthy, not just how fast it looks like it's going. Someone who can tell you if an AI story is real or hype before it costs you. I can help you avoid a lot of the engineering potholes.

You're left with: sharper technical judgment at the top.
Inspect

Technical Due Diligence

When the valuation rests on tech you can't really check. I'll tell you whether the code, the team, and the AI are real. I've actually built the things they're claiming to have built — I know what good code is, what good culture is, and I can tell you how much of the demo is real and whether the team will be able to keep delivering.

You're left with: the truth before you wire the money.
Unstick

AI Rescue & ROI Audit

When you "added AI" and it hasn't moved a single number, and now the board wants to know why the tokens are costing more than the engineers. AI is amazing. And it's a tool. It has to be used for the right thing in the right way. I can line it up with how people really work.

You're left with: AI your team actually trusts and uses.
Different worlds

Hardware + Software

When the hardware and software sides aren't talking — timelines that don't line up, fuzzy interfaces, two teams that don't trust each other's estimates. I'm one of the few people who held senior titles on both the hardware and software ladders at Google, so I've genuinely lived on both sides.

You're left with: one system, one shared roadmap.
Quality

Hardware & Software Instrumentation

When you've got LabVIEW, Python, PyVISA, SCPI, Datadog, AWS logs, and BigQuery logs — and you still don't have visibility into how your product is performing without manually digging for the data or getting paged. I've worked with the largest set of test results in the world and built visibility systems to catch errors before anyone has to look. Quality is built on having access to good data.

You're left with: good data that lets you ship good products.
In Byron's Words

Rather just hear me talk?

Video coming soon

A few videos for your entertainment.

The Rare Stuff

Stuff that's hard
to fit on a résumé.

How I Work
"The goal is to mentor and build a team that I want to be a part of."

I'm never trying to make you depend on me. I get in deep enough to really understand the people and the code, make the hard calls that need someone senior, and build the team that'll own it after I'm gone. When I leave, nothing breaks. That's how I know it worked.

I started TeamCraft on a simple idea: the hardest technical leadership problems don't always need a full-time hire. They need the right person, in deep enough, for long enough — and then a clean exit.

I could make more money selling bigger teams and fancy consulting packages. I have enough money. I'm in this because I genuinely like the work — building things, building teams, building up the people on them. And here's the not-so-secret part: happier people build better stuff and make the company more money. So let's make some money AND enjoy doing it.

My whole career has been the problems that sit between things — hardware and software, people and systems, engineering and the business. I've been through enough to be fluent in all those languages. So many problems just fade away when I can connect two people who are speaking, living, and experiencing different sides of the same coin.

Based in Denver. Working remotely with companies everywhere.

Career
  • TeamCraft Software2022 – Present · Founder
  • Google / Nest2013 – 2023 · Sr. Software & Hardware Engineer
  • Apple2009 – 2013 · Sr. Software Engineer
  • Vanu, Inc.2004 – 2009 · Member of Technical Staff
Common Questions

Stuff people ask
before they reach out.

A full-time CTO at this stage runs $350K–$500K plus real equity — and that's before you even know exactly what you need. Working with me costs less, takes no equity, and is built to wrap up cleanly once you've got the right permanent person. And if the right moment to make that hire shows up while we're working together, I'll help you find and vet them.
Your VP of Engineering is probably excellent. But maybe they're overworked right now and could use some help — some outside perspective, or a hand interviewing or mentoring. In that case I'm more like a senior partner to your executive who helps out while things are hot. I'm not there to replace your VP — I'm there to lend a hand and get them through the crunch.
Smart isn't the whole story — how you incentivize smart people matters. Don't pay them to waste tokens, for example. AI has amazing potential that some companies are starting to realize, but it's also a magic pit you can endlessly shovel time and money into. Pick the low-hanging fruit and build tools that solve that problem for everyone. I've seen the insides of AI and I know what the technology can do. I've built internal tools and know how to get them widely adopted. Good AI tools and good adoption will be a big deal for every company soon.
The size of the company isn't an interesting metric for me. The size of my team is — I like it in the 5-to-20 range. Larger than that and I don't feel like I can know everyone well enough.
If you need a permanent, full-time CTO with equity, that's not me. If your real problem is product strategy rather than engineering, a product person will serve you better. If you want someone to just write code, I can introduce you to a few excellent engineers. And if you're looking for a big firm with a bench of consultants, that's Deloitte. TeamCraft is me, with a few trusted people I bring in when the work calls for it.
I like to start with a free phone call to see if we're a match, then a two-week deep dive that ends with a report you can take and use without me. If we like each other, I prefer to work on C2C monthly retainers for a set number of days a week. And if you contact me directly, we won't have any head hunters or agencies taking half the money. :)