Byron Kubert

I build engineering teams that are happy, well-oiled machines.

Fractional CTO Board Advisor Technical Due Diligence AI Implementation

20 years at Google, Apple, Microsoft, Nest, and one small MIT startup. I'm a staff software engineer with deep interests in complex and unusual projects, but very interestedc in crafting the teams that do the building, and being the person who sits between the business and the engineering so the two actually talk. The name of my company might have given that away. I bring the way Google and Apple run their teams and install it in yours.

Let's Talk on LinkedIn
Byron Kubert — TeamCraft Software
20 years across
Google Apple Microsoft Nest Vanu
Who This Is For

You're probably in one of these rooms.

Different companies call me in for different reasons.

i.

You need to grow an engineering team

Maybe you're hiring and shipping, but there's no senior engineering leader yet or the team you have is scattered. Or maybe you don't have any team yet at all, only a budget and a vision. I've seen a lot of different team dynamics across Google and Apple, and I can build you a great culture with solid engineering practices.

How I build a team →
ii.

You're about to wire money on an acquisition.

They tell you the valuation is really high, and the deck is gorgeous. I can tell you whether the code, the team, and the AI are actually real. I've built this stuff, so I know what good code looks like under the hood, which engineers are the real load-bearing ones, and which managers are just good at talking. I can tell you how much of the demo actually works and how much is held together with tape for the meeting. Better to find out before the money leaves your account than after.

Technical due diligence →
iii.

You added AI, and only the cost moved.

We are inside the part of AI history people will write about; I beleive in using AI tools as much as I can, but, has this happend to you yet? The money spent on tokens now exceeds the cost of the engineer, morale is down, lines of code is up, and prod is breaking more often. I belive in 'AI first', but it is easy to jump to far and loose control, and it's easy to lag too far behind. Staying on the 'stable cutting edge' is both an oxymoron and exactly where you want to be. I've built production AI that people use every day, and I know how to make a team measurably faster with it.

Fix the AI problem →
iv.

Your product is hardware and software but nobody speaks both.

I held senior titles on both the hardware and software ladders at Google (I haven't met anyone else to have done this). I line up software timelines with hardware build schedules, and I find the impedance match (see? I WAS once an RF engineer) between teams that don't speak the same language.

Hardware + software →
My Interests

My current interests

&
Technology

Software and...

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 was mostly software engineering, but also big data, vendor relations, factory yields, production speed, radio systems, circuit design, project management, team building and morale. My time at Google was similarly varied. Are you after just a software developer, or does this project need leadership across diverse areas?

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 really easily. What better way for me to work in the environment I like than to build it myself. Tell me how you take care of your teams.

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. I like software engineering, I love being involved with something meaningful. I want to hear about your vision, why you're passionate about it, and what it's going to do for the world.

What I do

The CTO part

These days I'm probably not the best coder in the building, I bring broad experience that lets me understand the product, the business model, and the customers well enough to know how to shape the engineering org to get it all done. I'm whoever the CEO needs me to be when the problem is even vaguely technical.

Autonomy

Scrum.... isn't great

Hear me out on this. Scrum DOES work in a top down bureaucratic organization. But FAANG companies don't really do any of that. To be clear: the Agile Manifesto is brilliant. Shipping often and getting customer feedback really works. I build teams of empowered individuals that are 2-5x faster than full Scrum allows. And so this is a detail we should talk about. What is the culture of your company? Would I have space to create an engineering culture like 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?

I also like to own all of the technical issues around the team; it's how I build the environment in which the team works well. 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 — Build AI-native from day one

Code generation got cheap. The engineering moved somewhere else.

When an AI can rewrite all the code in a new language over a weekend, the job stops being typing and starts being encoding behavior and function in a way that lets the code be regenerated. Which means the "old-fashioned" engineering — good abstractions, clean interfaces, real design matters more now, not less. That's exactly what lets a section of code get thrown away and rewritten without fear. I build teams that work this way from the first day, so they're fast because they're AI-native — not because they're cutting corners.

Step 04 — 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, bored, and under a perpetual layoff threat — 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 05 — 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 06 — 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 07 — 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 the process and structure I built while 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 from 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 — it cut the time on their reports by something like 87%, which honestly surprised even me. Staying close to the customer and keeping the codebase easy to change really does work. 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. And when what you want isn't going to happen, I'll tell you the closest we can actually get and how to get there. I'd rather hand you a real option than a problem.

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

You "added AI," it hasn't moved a metric other than cost, and now the board wants to know why the tokens cost more than the engineers. I can fix your AI problem. I've built real production AI that people actually use, and it's more an art of understanding people than understanding the tech, though the tech is young and full of false promises too.

Roughly how: I treat code generation as cheap and put the engineering into encoding behavior so the code can be regenerated. Old-fashioned fundamentals are more important now, TDD, red/green/refactor, good abstraction and design, because that's what lets the AI rewrite a whole microservice without bringing down prod.

AI that lowers 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.
Engagement

How we start.

Every engagement is staged, so we both find out if we fit before anyone commits to much. Same progression whether you need a CTO, an advisor, or a second opinion.

Stage 01 — No commitment

A conversation

Free  ·  a LinkedIn message

Message me on LinkedIn — on purpose; it keeps the spam out and means I'll actually read it. A free call to see if we even like each other, and whether your problem is the kind I'm good at. (there's an email at the bottom of the page if you don't like LinkedIn)

Stage 02 — Low commitment

A short deep dive

Fixed fee  ·  about two weeks

I get into your code and your team and hand you a report you can use with or without me. You get something valuable no matter what, and we both find out if it's a fit for the long haul.

Stage 03 — If we both want to

An ongoing retainer

~$10k / month per day-a-week

We keep going at whatever cadence makes sense — a day a week, two days, or full time (about $40–50k/month). Simple C2C terms, and because you found me directly, no head hunters or agency fees.

The title — Fractional CTO, board advisor, due diligence, AI rescue — is just whatever fits your situation. Same person, same rate. See the rooms I work in →

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 want to be the first person the CEO calls for technical conversations. I like to end those conversations with realistic ideas and buildable solutions."

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 of building things, building teams, and 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.

In hindsight, most of my career has been fitting together things that don't naturally fit together: hardware and software, people and systems, engineering and the business. I've been through enough to have seen a lot of the ways to make those connections work, and I've also seen a lot of ways to make those connections not work. 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 love in person work. If we can get the team together, I will fly out for the week; there is something magical about spending time in the same room. For most day to day work, the tools from Google's global teams have served me well, most decisions are best worked out over email or slack or a 1:1 video call, and it's not hard to see who excels in this environment. I get more code and work done when I'm uninterrupted, and I get a much higher bandwidth connection with someone in person. It's a pragmatic balancing for me. In the beginning I've flown to remote sites twice a month, then a year later my relationships were strong enough that I only needed to fly once a quarter. For one major presentation I flew three weeks in a row, which is not ideal, but sometimes that's the best solution. It really depends on the people and the current events. Because I'm flying from Denver I can be in most US cities by tomorrow.
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 :)