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 do the building. 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

My current interests

&
Technology

Your problem is technologically interesting.

I like software engineering projects where being a standard software development expert isn't enough, where the project is ambitious in scope and the path to get there isn't clear. My work on the iPhone factory is an easy example, I've selected these kinds of projects most of my career.

People

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.

Meaning

The project is meaningful.

I've built out rural cellular coverage. I built part of the factory that produced millions of iPhones. I've designed satellite phones and worked on ICBM defense systems. Tell me about your product, why you're passionate about it, and what it's going to do for the world.

What I do

Tech stack

I don't self identify by my tools. If your team needs a deep domain expert, I can help you find them, but I'm not that guy. I bring very broad technical skills for sure, but the reason to call me is to help you engineer the team. Ok, there is one technology that I do use every chance I can. AI and LLMs are changing the world. Any new team or process needs to lean heavily on this.

I like interesting and meaningful problems and building a well-oiled team that fixes them.

The Craft

Building the vision.

How to build a team.

Step 01 — Set the strategy

Build or buy?

New teams and products need a long term strategy. Build or buy? Cybersecurity plan? Fast prototype or low tech debt? CI/CD or just ship it? No don't do that. Is that new tech real and should we use it? What do customers actually need? How do we hire and mentor? Agile or Scrum? Do I need to rein in the Marketing department again? Can we add more minimum to our MVP? What does the CEO actually need to know about our tech? What do I need to know about the business? My engineering org lives in this larger world, my effort here makes my team less distracted and faster.

Step 02 — Technical Direction

Setting the right direction is important, and adjusting more so.

I like to code. I like having opinions on software design. I'm not going to write all of the code but I will set the direction, and I will keep the design clean. I have the experience to know the difference between what will definitely not work and what might work. Most importantly I have the humility to let go of ideas that aren't working. AI is changing the game of software development. In this brave new world there is huge value in defining behavior outside of code because the AI can rewrite all the code in a new language over the weekend. Using this AI first approach from the start is really important.

Step 03 — 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 options, no promotion path, no challenge. I offer them a role a level or two up, a chance to fully own far more than they have before. They get my expertise to back them up while I show them the ropes. The ambitious ones jump; the mediocre ones don't. That's also how you know when you found one.

Step 04 — Build the culture

How the talented individuals interact is the multiplier. And it can be less than 1.

One Friday night at Apple my team and I integrated, debugged and delivered the product while the customer watched. Our modules had never been run together, we coded to our agreed interfaces and wrote lots of tests. We had no idea if it would work. This was a fairly high pressure moment at a high pressure company. But the team was well oiled. Our technical direction was good, our tools were good, and we worked very well as a team . Our instrumentation gave us good insight into each bug we hit, we tag-teamed the keyboard to fix them, and high fived each other at every bug fix and cheered every time something new worked. We shipped faster and better because everyone supported everyone else; the team was competent, the team was happy, and we crushed it.

Step 05 — We are not alone

The engineering team interfaces with sales, product, CEOs

Defining what the engineering org should do and how they interact with the rest of company is a big deal. Smaller teams at Apple had an organization where everyone could talk to everyone else. It worked well there, but it doesn't work as well for larger teams that don't share a very clear goal. Google's larger orgs used more rigid edges; they traded out some agility to keep everyone going in the same direction. How does the CEO request a change? Is there a path for an engineer to suggest a different UI flow? This depends a little on the org size, but more on the personalities involved. It's a detail I pay a lot of attention to.

Step 06 — Handoff

I like the building more than the running.

Symbiotic. I enjoy and excel at the beginnings when the ideas are nebulous and ambitious and the team culture hasn't been engineered yet. 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 everyone's 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 done.

I've had some fun.

Google
Senior Software Engineer
Getting stuff done at Google is very different than getting stuff done at Apple. Both have world-class software engineering, and somehow they have cultures that are completely different. Google hires you on and says, "here's our monorepo with ALL our code. Find something to build and we'll compare it to what everyone around you built. Hope you are as good as they are. 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. The best technical solution wasn't enough, the personality and ambitions of each person matter more. The second most important thing was being part of Google's interviewing and hiring process. I interviewed a lot of hopeful engineers and how Google selects the best of the best is truly an art form. 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. Giving ownership (to the right people) is a super power of small companies.
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. Building a live production AI system was eye-opening; there are so many technical details that make or break the system. Building useful AI is hard
Where I Help

One craft. Different rooms.

What I like to do is called different things in different situations. In all of them, I bring the experience 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 finding one is taking months. I can help you get the engineering org up and running now and get the team shipping. I know how to hire, and when and how to leverage AI. I stay until the team is running and you've got that full-time engineering leader hired.

a team that owns the product.
Tune

Board Member / Advisor

You have the business people and the finance people. I can be the voice of technical sanity, team health, and realistic timelines. It really would be awesome if we launched everything with every feature tomorrow. I can see past the powerpoints and into the code to tell you what actually makes sense. Someone who can tell you if an AI story is real or hype before it costs you.

sharper technical judgment at the top.
Inspect

Technical Due Diligence

They tell you why the valuation is so high. I can 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, who is a good engineer and which managers are faking it. I can tell you how much of the demo is real and whether the team will be able to keep delivering. All this on a one time C2C arrangement.

the truth before you wire the money.
Unstick

AI Rescue & ROI Audit

When you "added AI" and it hasn't moved a metric other than cost, 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've built real AI systems that people use. It's more an art of understanding people than it is an art of understanding the tech. Although the tech is also young and filled with the potholes of false promises and misguided ambitions.

AI that reduces cost and makes people faster and happier
Different worlds

Hardware + Software

Some projects are interesting because they are not pure software, they include external things that have a separate development timeline and process. Sometimes this is a hardware component, sometimes it is software but it's a product from a vendor that you can't control. I like these things, I find the impedance match (see what I did there) of different development pipelines to be a specific skill that did cause me a lot of problems before I figured it out. I've lined up software development timelines with hardware build schedules more than once.

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.

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.

It's not an either/or thing. I can help out right now, and I want to exit cleanly once you've got the right permanent person.
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 as interesting a metric as the size of my team — I like it in the 5 to 50 range.
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. If you're looking for a big firm with a bench of consultants, that's Deloitte. TeamCraft is Byron, 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 agency fees :)