Invention vs. Innovation: Lessons from VMware’s vMotion

Host: Lucas Hendrich, CTO at Forte Group
Guest: Kit Colbert, Platform CTO at Invisible Technologies

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group.

We have Kit Colbert with us today, Platform CTO at Invisible Technologies. It's great to have you here.

Kit Colbert: Thanks for having me.

The Story of Storage vMotion

What vMotion made possible

Lucas Hendrich: I sent you a bunch of questions before we scheduled this and got some great feedback, so I'm going to riff on one of them, out of order.

Anyone who's been in technology as long as we have takes things like virtualization for granted. VMware is part of that story, and you're part of the VMware story, having worked on vMotion. When I asked about something that was obvious to you at the time, you said there were things that in hindsight were very obvious but that you didn't see then. I'm curious about that journey and the lessons you learned. You also mentioned that innovation has both technical and non-technical components, in organizations and in developing new products. I'm curious about both.

Kit Colbert: Before Invisible Technologies — which is an AI company, of course; everything is an AI company now — I was at VMware for about 20 years, and I was a developer for the first half of that. As you said, I worked on a technology called vMotion.

For anyone who doesn't know: vMotion lets you take a running virtual machine and move it between two physical hosts while it's still running, without the application inside the VM, or any network clients talking to it, noticing anything happened. It's a completely transparent process migration.

Academics had tried to do this for decades before VMware. They always needed some special modification to the application or the underlying hardware to make it work. Because of the power of the virtualization abstraction, we did it without modifying any hardware or software.

Lucas Hendrich: And without rebooting, which was…

Kit Colbert: Without rebooting.

Lucas Hendrich: …the innovation of that time.

Kit Colbert: It was so powerful that even decades later, I'd meet VMware admins who had seen it for the first time when it was released, around 2002 or 2003, and nearly fell out of their chairs. It's something they'll never forget.

Moving the disk while the VM runs

Kit Colbert: I started full-time at the company around when that technology came out, in 2003, but didn't start working on it myself until 2005. While working on it, we hit on the idea for a complementary technology that became Storage vMotion.

Here's how vMotion worked. Because we're running a virtual machine, we can capture its full state, serialize it, send it over the network, and recreate it on the other side. One performance optimization was that we didn't copy the full disk image, which would be many gigabytes. Networks weren't that fast then, so it would take a long time.

Instead, we relied on a shared storage mechanism, like NFS or a storage area network (SAN). We essentially closed the disk file on the source host and opened it on the destination host, transferring it that way. It worked. But while the VM's compute could move between servers, its storage was locked to the storage device it lived on.

At the time, customers would swap out their back-end storage networks and arrays for something more modern every four or five years. That was a massive process: months of planning and effort, delicate execution, weekend windows to take things down and copy data over, and millions of dollars on top of the cost of the new arrays. Huge risk, too — all sorts of strange performance issues could come up.

We realized that, especially as networks got faster, we could copy the disk image and move a virtual machine's storage while it was still running. It wasn't that hard technically. In fact, I did most of it myself as an individual engineer — and this was before Claude Code and all the other coding tools. You wrote everything by hand, but it was still doable.

Obvious in hindsight

Kit Colbert: What surprised me, looking back, was that we built it without it being clear to me how useful it would be. I wasn't hands-on with customers doing storage migrations. I'd heard about them, but I'd never done one.

As we talked to more customers, the feedback was very clear: "Oh my God, if you have this capability, I want it yesterday." It took a while to get internal buy-in, but we eventually got it into the product and customers started using it.

It's funny, because the ROI is so obvious in retrospect. You could take a multi-month, maybe year-long project costing millions of dollars and dozens of people, with huge complexity, and turn it into essentially a drag-and-drop. The process might take a couple of hours, but it was all automated. That was the level of benefit customers got. Going in, I didn't see it, and it's shocking to me looking back, because now it seems so obvious.

Lucas Hendrich: It always does.

Kit Colbert: There's a lot of noise and a lot of competing priorities.

Lucas Hendrich: There's also the friction of process, the friction of big organizations, and the number of people involved in managing it all. Think of all the people who no longer had to lift and carry things between data centers — you put them out of work.

Kit Colbert: But not really, because it created all this new work.

Invention vs. Innovation

Trying to bypass the process

Kit Colbert: But your point about internal structure is absolutely spot on. I was a bit of a renegade when I was younger — maybe I still am — and I knew about a lot of our internal problems. We had something called the ECR process: engineering change requests. You used it when you wanted to add functionality to a release that hadn't been planned. Planning was still fairly waterfall-ish at the time.

I'd talked to customers, saw the value, and could do most of the work myself. Then I wanted to get it into the release, and I thought maybe I could circumvent the ECR process, because it involved a lot of red tape: talking to people, getting approvals, and so on.

So I went around and found some QA people to test it for me. I lined up several folks and planned to get it out renegade-style, under the table, so to speak. I'd been there a while, so I called in a lot of favors. But one person, on an end-to-end QA team, said, "Sorry, man, I can't help. I've got too much on my plate."

Finding a sponsor

Kit Colbert: That forced me to go the official route. The code was done, but I spent the better part of three or four months trying to find someone who got the idea and could speak to a decision-maker.

Eventually I found a product manager on the storage team who understood it. I pitched it, and his eyes lit up. He went to the VP of product on my behalf, someone who could make the call: "Here's a lower-priority item competing for resources. Let's drop it and free up those resources for this." That's how Storage vMotion got into the release — around 2008, give or take.

What happened next was fascinating. Once it was in the release, people came to me from every direction. Marketing wanted to know what it was, how to position it, and how to describe it to customers. Tech support asked how it worked, what could go wrong, and what runbooks they needed for first- and second-line support. Sales came to work through pricing and packaging: which bundle it should go in, and how to pitch it. It ended up being a really powerful technology that many customers used.

Innovation is about impact

Kit Colbert: So what was the lesson? Not necessarily that being a renegade is bad. What I gained was real clarity on the distinction between invention and innovation. People tend to use the terms interchangeably, but this experience showed me they're fundamentally different.

Invention is about something new: a new idea, a new thing, or a new use for an existing thing. In my case, it was a new technology assembled from existing pieces.

Innovation isn't about newness at all. It's about impact — change, really. Some traditional economists, like Schumpeter, describe it as a change in the value of a system. I'm dating myself, but think about when the iPhone came out. Before it, your idea of a smartphone was very different and much more limited. The iPhone changed your conception of what a phone should be. That's innovation. It changes your value system — it changes human cognition.

So it's about impact. You might create the most world-changing technology, but if no one uses it — or, more concretely, gets value from it, personally or for their business — you haven't really innovated.

The company as an innovation machine

Kit Colbert: Here's how that applies to Storage vMotion. Say I'd gotten that last QA person to sign off and test it, and we shipped the code. No one would have known about it. There'd be no marketing, and sales wouldn't be pitching it. If some customer somehow found it and started using it, they'd probably mess something up. Who would they call? Tech support wouldn't know about it. Maybe they'd track me down, and I'd be up at 2 a.m. solving some problem.

In some ways, a software company is a machine that takes the technology you're building and turns it into value for the end user. There's a whole set of parts to that process — tech support, marketing, sales, all these functions working together. That's what creates innovation.

My mistake was this. Put time on one axis and effort on the other: I was trying to avoid the up-front effort of all the red tape. But that would have created far more effort for me later. I'd have had to pitch it to customers and support it myself.

The ECR process put some friction in front of a giant machine with thousands of people that cost many millions of dollars. And yes, you should have to put in a bit more effort to engage it. I put in a lot up front, but my personal effort dropped dramatically once I'd educated everyone and they took the ball and ran with it.

That's a very different way to think about release planning. As an individual engineer, I was looking at it very myopically — what it did for me, and how it held me back. In reality, it was a structure that enabled better innovation for the company.

Lucas Hendrich: Interesting. There are many cases of constraints doing that. You could argue the same for art: if you had a limited budget, or needed a certain amount of sponsorship to paint a portrait in the 1500s, would it have happened?

I think my comment about putting people out of work moving hardware between racks was on the nose, because it's analogous to where we are now. Innovation happens at that human interface — that's when it lights up.

It also reminded me of the Intel story. When Intel had to pivot its core business, the salespeople, whom you might expect to push back hardest — "Now we have to sell something new?" — were among the strongest sponsors: "No, that's exactly what the market wants."

Kit Colbert: Sometimes they have the best sense. Obviously they're focused on selling, but they also have a good sense of what customers want.

Lucas Hendrich: Absolutely.

Kit Colbert: Look at what's happening with AI today, as you mentioned. There was clearly an invention — something really powerful. The question on people's minds for a while has been: What will it be used for, and can it really deliver a return on investment, especially with the massive sums going into data centers and new models? My sense is we're starting to find out. Coding may be one of the first killer use cases. There's a "there" there, and there's certainly innovation happening.

AI and the Software Development Lifecycle

You're wrong two-thirds of the time

Lucas Hendrich: I think what we don't know yet is how AI will change our perception of effort and time. That's one of the biggest differences from a process change like moving from waterfall to Agile, which shortened the cycle of work and the feedback loop. Right now, in certain areas, it's ridiculously fast.

Kit Colbert: It is.

Lucas Hendrich: And the throughput of how knowledge — not just information — can be shared and transferred through LLMs is remarkable. But I'm on the optimist side. I'm thinking about all the new use cases that will grow out of this. Just as once you didn't have to worry about rebooting your VM, you unlocked all this potential productivity. That's the most interesting part, and we're still on this side of it.

Kit Colbert: I don't think we can really see it yet, but there's a lot happening. It's pretty fun to be back at a startup. When I joined VMware, it had about 300 people; when I left, 45,000. So it was very much a big-company vibe. Invisible has about 500 people, so it's much smaller, and startups can experiment more and be on the cutting edge of all this.

Look at how the SDLC has evolved. You mentioned waterfall to Agile. Why did that make things faster? It turns out software engineers — and people in general — are more often wrong than right about what will actually make an impact for customers, which ties back to the idea of innovation.

Microsoft Research had some good papers on this, maybe a decade or more ago. They measured software changes intended to move a KPI positively and found that about two-thirds made no measurable difference or a negative one. Effectively, two-thirds of the time you're wrong — and that may be better than average; I don't know. The general idea is that if you believe you'll be wrong a lot, it doesn't mean you shouldn't do things. It means you should limit the effort you put into each one and validate quickly.

Lucas Hendrich: And close the loop as quickly as possible.

Kit Colbert: That's the beauty of Agile: a much tighter loop and cycle. Add everything that came with SaaS — frequent updates in production, A/B testing — and you get a lot of feedback and can iterate much faster. That was the thesis, and it's very much been borne out. You don't spend a waterfall-length nine months on something that's probably wrong. That makes no sense.

Developers who cost twice as much

Kit Colbert: Now we're in the AI age, and within my engineering org I'm seeing massive uptake. We're trying to put more structure and best practices around it. Generally, I don't want to limit developers' token consumption per se. I want them to be smart about it. But if someone spends six grand a month on Claude Code and is 10x more productive, that's great.

Lucas Hendrich: Six grand isn't bad. Until it gets to a junior engineer's salary.

Kit Colbert: That's exactly what I've been discussing with our CFO: the expectation that engineers will be more expensive now, because you have to add token costs on top of salary. There have always been some expenses, like cloud costs, but these are growing so fast that you're right. I could see us, by the end of 2026, assuming a developer costs twice their salary, because they're spending a salary's worth of tokens a year on LLMs for coding.

We're not there yet, and it'll take a while. But having developers run five, eight, or however many agents in parallel changes your whole process and makes it dramatically more productive.

The half-pizza team

Kit Colbert: I also think it will change how we organize. The two-pizza team, which has been the gold standard for a while, will go away. You may not even have a one-pizza team. Maybe it's a half-pizza team: two or three people. When those two or three people have 20 or 30 agents between them, how do you manage all the code being created?

Lucas Hendrich: It puts a huge amount of pressure on the art of product management — deciding and orchestrating tasks. Now there's a deadweight loss: at the end of the day, I have to spin up a couple of agents to work overnight. Even if they're low latency and just churn and trickle on the token gauge, if I'm not doing that, I'm constantly losing opportunity.

That's a whole new kind of pressure. The only comparable pressures in running teams have been things like time zones and communication friction — and all of that goes away. There's huge pressure to minimize that deadweight loss.

Kit Colbert: I agree. You want to set agents a task so you can go have dinner or go to sleep while they work, then come back and check their work, of course — without spending the whole day checking it.

Lucas Hendrich: Right.

Kit Colbert: We'll have to scale out systems for that too. I've heard that some foundation model companies use LLMs almost exclusively to validate other LLMs' work. So waterfall to Agile was one step, SaaS best practices were another, and this will be the next iteration.

It feels like we're right on the precipice. Over the last couple of months is really when I've felt the shift. I'm reading a lot more organizational thinking — like the half-pizza team — about the best practices developers can use to embrace these new patterns, what skill sets they need, and how that differs from a traditional computer science degree.

From Licenses to Subscriptions to Tokens

Lucas Hendrich: I read today that Marc Andreessen posted on X — I'll get it wrong — that computer science has gone from a craft to something like physics: you learn the principles, but you don't actually sit down and write it out.

That's the evolution underway. You also mentioned SaaS, and when I think SaaS, I think subscription. That's another question I had. We've both lived through the shift from purchasing to renting. It's very interesting in economic terms: from "this is yours forever and maybe I'll maintain it" to paying a much smaller monthly fee for ongoing access. That let you ship code and features faster.

The push to move people from licenses to SaaS had repercussions throughout development organizations and how they improved their processes. Now there's a new economic reality we're not sure about yet. Tokens are one unit of economics, energy is another, and at some point that has to be reflected in pricing. I don't think the market has figured that out.

Kit Colbert: Not yet. It's certainly not obvious to us.

Fewer hires, more startups

Kit Colbert: There are some really interesting things happening. You saw the Citrini report a month or so back, and a bunch of rebuttals to it, some really good. One — I forget who wrote it — took the exact same format and just changed some of the wording to make it much more positive.

I think a couple of things will happen. First, there will definitely be an inflection in the labor market. We're already seeing it — Block supposedly laying off about half its people. I think it's reality. If you spend a developer's salary worth of tokens per developer, you now have 2x the cost. With the same cost envelope, you can't hire as many people. But if they're 10x more productive, maybe that's OK. That's point one.

Point two: I think many people who might not have gotten a job will start companies. You'll see many more startups. They won't necessarily be blitzscaling. You can get a lot done with one person now. You can literally have a one-person startup that scales quite a bit, because agents can handle marketing or whatever you're not an expert in.

The threat of "we'll build it ourselves"

Kit Colbert: As hiring at larger companies softens and those people move to smaller companies, innovating on more niche things, there will be a reciprocal effect on the bigger companies: a lot of downward pressure on pricing.

You've seen it. Some SaaS companies charge high prices, and it frustrates you as an engineering leader: "I could build this myself. But it'll cost so much, it's a lot of effort, and I have to support it." You run the numbers, it's not worth it, so you suck it up and pay them. That won't be true anymore, because it'll be much cheaper to rebuild at least the parts you need. So either you do it yourself, or you go to niche players who can charge much less because they're one-person shops just spending on tokens. I think you'll see a lot of dynamic change across the industry.

Lucas Hendrich: It creates new markets and new economies. In some ways that's no different from the shift from Windows to the internet, though I think the dynamics are a bit different now. And there's huge uncertainty around the amount invested in a specific chip architecture, which could change in a couple of years. How much of that spend will be rationalized? Things are getting more efficient.

That's too much for me to keep in my head while running a company or a software development team. The way it translates for me is: How much should I invest in scaffolding, tooling, architecture, and structure? Those decisions are really hard right now, for the reasons you described. Can you build it yourself and scale it? Will some last-mile problem actually cause trouble? There's still some rattle in the spaceship, and you don't know what it is.

Kit Colbert: You're right. My sense is that what matters isn't so much whether people actually do it. Some will, but to your point, many probably won't, for exactly the reasons you mention. The more important point is that the threat that you might do it is now very real, more than before.

In negotiations, your procurement team can now say, "I can just have my team build this, so you need to lower your prices." That pressure is very real and probably already being felt.

I won't name names, but there are definitely a few vendors we're looking at internally and saying, "Maybe we'll renew for one more year, but probably next year — maybe in six months — we'll build an alternative." That's especially true for companies in the open source space, where there's a core piece of software you can build on, and all the extra glue work — operations, integration — is now pretty easy to do with AI agents.

Lucas Hendrich: Absolutely. And rather than eliminating engineering jobs, I think it will create new kinds of jobs, skill sets, and ways of thinking. You're still following the laws of physics; you're just at a different layer of abstraction.

AI Is a Normal Technology

Amplifying talented people

Kit Colbert: I think AI is a very normal technology. It's disruptive, no doubt, just like the internet or anything before it. When cars came along, many of the people working with horses went out of business, because horses weren't used much for transportation anymore. But life moves forward, people find new work, and I think there's no shortage of it.

In general, AI amplifies the abilities of talented individuals. I had coffee this morning with a film producer, and we talked about AI's impact on his industry. I'm no expert, but he thinks it could dramatically lower the cost of making movies.

Take storyboarding, which has traditionally been 2D — sets of images. Now you can create a whole 3D world and even place camera shots, making it much more real before anyone is on set doing the physical recording. That dramatically cuts costs, because you don't need five or ten different shots; you know the shot you want and do just a few takes. So I think it will be very empowering. Some roles won't be as useful anymore, but there will be plenty of new ones.

One last point: for people coming out of school or new to the industry, I think there's plenty of opportunity, because we want people who are more AI-native — who've grown up used to having a bunch of agents doing work for them. That will be a critical skill set, and younger people will naturally gravitate toward it.

Orchestrators and guardrails

Lucas Hendrich: I agree 100%. To set up an argument that can cause anxiety: AI enables people to create startups. But part of the population doesn't want the hassle of a startup and isn't dying to bring their ideas into the world. They want to live their lives and be productive. For people who are good managers, executors, project managers, or orchestrators, there's a huge opportunity to become experts at creating the right guardrails for all of this. Those guardrails will need to be firm yet very malleable, adapting quickly to change.

What counts as intelligence keeps moving

Kit Colbert: It's interesting to look at the history of computing and how we've thought about what intelligence means, and whether computers — or AI — have it. Computers used to be humans: people who did a lot of math and equations. They computed. Now a computer is a device, and early computers did basic arithmetic that was hard for us but easy for them. Before computers, people thought that someone who could do that was a computer.

Alan Turing, with the Turing test, thought that if a computer could converse so well you couldn't tell the difference, it had achieved intelligence. And then we said, "Well, not really. Something else is missing." Look at modern AI. It's good, but there's always something elusive off in the distance. Maybe it's taste, maybe something else.

So the idea that AI will take over or do things to me seems misplaced. It's not about what AI does. It's about what a human does with AI.

Lucas Hendrich: Precisely.

Kit Colbert: It's always that pairing that matters. Modern LLMs contain the world's human knowledge, but they have no individual perspective, desire, or drive. It's the human — like a filmmaker with a vision of what they want to create — who uses AI as a tool to realize it. It's no different for programmers or anyone else. Maybe in a Skynet future AI does its own thing, but for now it's very much a tool.

Teaching AI: Human Data Labeling

Invisible's two businesses

Lucas Hendrich: Or maybe at Invisible, where you've named components after axons and neurons.

Kit Colbert: Yes, we've got the brain theme going. But again, it's a tool. Some background: Invisible has two main businesses. One is human data labeling — teaching AI about things. It started with basic stuff, like "Is this a hot dog or not a hot dog?" Really simple. Now it's gotten much more advanced, but I think there will always be a need for it.

Lucas Hendrich: Expand on that for a minute, because I don't think our audience realizes what an honor it is to have someone here who knows the inner workings. I'm speaking more to the business audience: it seems like this thing appeared and suddenly changed everything, but it's been a long evolution.

From the Transformer to human feedback

Kit Colbert: Yes. The background on LLMs is that a research paper came out of Google proposing the Transformer model. One challenge with this kind of generative AI is keeping track of attention. Think about a long sentence, or a paragraph or more: you have to remember different things that were said, or what a pronoun like "he" refers to, especially in a complex sentence. Part of the Transformer's beauty is that it helps focus the model's attention on the right things so it can figure out the next word.

To train these models, they gathered huge amounts of data from the internet, books, anything. The model essentially taught itself from that data, getting a sense of how grammar works and how concepts relate to each other. But there are a lot of gaps.

You might want the model to be better at something specific, like language translation. For that, you need human input to make sure it's doing what it should. When it gets things wrong, it can use direction from humans to improve. That's one of Invisible's businesses: helping label that data.

A few years ago it started very basic, mostly grammatical. You'd see a prompt and two or three possible model responses. As a human, you'd read them and say, "Based on what was said and the context I have, this response is best, here's why, and here are the specific problems with the others." You give it that context, and it learns and does better. It's only gotten more advanced. Now we have doctors, lawyers, astrophysicists — really specialized work. It's pretty wild.

Lucas Hendrich: Gen Zers too — trying to understand "six seven."

Kit Colbert: I know, the TikTok memes. I don't know.

Lucas Hendrich: By the time this comes out, that'll be old.

The need for humans keeps evolving

Kit Colbert: It's been funny, because there's always been a question of whether, at some point, humans will have taught AI everything and human data labeling won't be needed. That's just not what we're seeing. We keep seeing new needs.

As I said, our notion of intelligence keeps shifting. It's a very human instinct to say there's something special about us. Computation? Fine. Interactive dialogue? Well, a computer can do that, so there must be something else. As that keeps evolving, we'll always need humans guiding models and giving them feedback. That's the foundation of a lot of what these foundation model companies do: the learning.

Lucas Hendrich: It's exciting that your company has been part of that process.

Kit Colbert: It still very much is. That's one part of the business.

Enterprise AI and forward-deployed engineers

Kit Colbert: The other side is enterprise AI solutions. Many companies want to do things with AI and experiment with it, but can't take it the last mile — back to the innovation point. You may have built something and proven it works, but how do you get it to your own customers, show there's value, and realize business benefit?

Lucas Hendrich: And on that side, you have forward-deployed engineers.

Kit Colbert: Yes. If you're familiar with Palantir, it's a similar model. My job as platform CTO is to build many of the components. We don't want a consulting gig where everything is built uniquely; we want reuse. So we build core components that the forward-deployed engineers take, customize, or build on to solve each client's pain point.

The Path to CTO

Falling in love with operating systems

Lucas Hendrich: One central theme of this podcast is how the CTO role varies across companies, and how people end up as CTOs. Most of the time, they didn't plan their careers that way. They went to law school or studied molecular biology or astrophysics. You're a case of someone who started as an engineer — a staff engineer — did the work, and moved up that path.

So a couple of questions. First, anything you want to share about that journey, starting with the choice of whether you want to do more than write code — which people are now being forced to adapt to.

Kit Colbert: Everyone's becoming a manager of sorts.

Lucas Hendrich: Right. Second, what do you think the skill set or typical makeup will be for someone in a similar executive role five or ten years from now? It's always been multidisciplinary. At some point you need enough financial intelligence to understand what people are talking about and connect the dots: how your and your team's productivity shows up in revenue, margin, and so on.

Successful technologists have always needed some product mindset, because you're not just building something. When you talked about invention versus innovation, I briefly thought of those cheesy "As Seen on TV" ads. Those are inventions; nobody buys them, and they live on late-night shopping channels. Versus things like the iPhone that change the world. So, your journey to CTO, and where you think it's heading, since we'll be molding the clay a bit differently.

Kit Colbert: I've always been a techie. Growing up, I remember learning programming languages, and it was so cool to see what a computer could do. Being on the internet in the early days was awesome. In college I definitely wanted to do computer science, but didn't know exactly what.

It was an operating systems class that made me think, "Wow, this is cool." I really liked the low-level OS pieces. Writing a kernel, which you do in the more advanced, coding-heavy class, was eye-opening: seeing how basic concepts work, like a thread. Hyper-threading aside, generally speaking a processor has no concept of threads. You have page tables and processor state registers, but no thread. The operating system creates the concept of threads. Seeing how that worked, looking under the covers at how things actually function, was really cool. That kind of exploration, insight, and deeper knowledge always attracted me.

A poor man's MBA

Kit Colbert: At VMware, I was an individual-contributor developer for the first ten years or so and climbed the ranks. Because it was a small company and I was close to many different things, I started picking up basic business acumen. It was like a poor man's MBA: seeing things work, or not, in real life.

Lucas Hendrich: Do you have an MBA? I don't — for exactly that reason.

Kit Colbert: I don't, but I learned so much. I'd talk to friends who were getting MBAs, and we could actually debate the material. I had some of the vocabulary and concepts. I also developed a product sense by connecting with customers. I've always been drawn to the enterprise side, talking individually with customers and understanding their unique needs.

About ten years in, I'd been a tech lead, but as an IC, not in formal management. I moved to a different team, and an opportunity opened when the CTO of that team left. The GM offered me the role. I didn't know what I was doing, but I said yes. It involved technical architecture, technical vision and strategy, and evangelism, with a small set of engineers reporting directly to me. I did that for a year or two.

The containers moment

Kit Colbert: Around then, I saw containers coming. This was the 2015 timeframe: Docker was emerging, and Red Hat was making a lot of noise about it.

Lucas Hendrich: That was huge in that evolution. It changed everyone's game.

Kit Colbert: It was massive. I saw it coming and was very worried for VMware, because Red Hat was obviously going to be negative on VMs. It's funny: containers still predominantly run on VMs today. They're complementary; containers never replaced VMs. But at the time it seemed like an existential threat that could wipe VMware off the map.

So I talked to our CEO a lot about it and eventually took a leadership role in a new business unit focused on what we called cloud-native apps. I temporarily became a GM, which I had no idea how to do, and I totally messed it up, obviously.

Lucas Hendrich: I wouldn't say obviously. But it's a recurring theme: getting into roles and figuring them out.

Kit Colbert: I don't know if you'd call it failing upward, or maybe I'm too dumb to know my own limits, so I just keep pushing.

The lazy engineer's paradox

Lucas Hendrich: Something you said earlier really resonated: it's a rare skill to make the leap from doing something with technology to improving someone else's quality of life. Maybe I fall somewhere in the middle. I love automating things because I'm ultimately lazy and want to do other things.

Kit Colbert: I want to save my cognition. That's the engineer mindset: we're very lazy.

Lucas Hendrich: It's a kind of paradox, right?

Kit Colbert: It is. You spend a lot of time automating something that doesn't take long to do manually.

Lucas Hendrich: Exactly. But I think that will also be the skill of the future: knowing enough of the laws of physics to ask the right questions and create things that improve human quality of life.

Learning from failure

Kit Colbert: Absolutely, and it's an exploration. I didn't know what I was doing. I saw a problem I thought was existential for VMware and was willing to jump in and try. I didn't know what to expect. I had some ideas, and I learned a ton — that was the key. In what I'd consider a failure in that role, I learned more than in any other role. And it set me up for what came next.

I spent about two years slogging through that. It was awful and very stressful. Then I went back to being a proper CTO of one of our business units, and a few years later became CTO for the whole company, with a very large engineering organization of up to 2,400 people.

I didn't progress gradually from slightly bigger team to slightly bigger team. As GM for cloud native, I had 150 people; then I went back to about 15; then to 2,400. A strange leap. But the things I didn't do well with cloud-native apps, which I reflected on afterward, prepared me better for that bigger role.

So I don't see failure as bad per se. I'm very hard on myself and self-critical. But what matters more is whether you're learning and getting better, and that experience taught me a lot.

Leading through influence and making the call

Kit Colbert: As an IC, I was used to leading through influence. And in every role — even running a 2,400-person team — you still lead through influence. You can't put a gun to someone's head and make them do things. People will do what they're going to do. You can use a bit of carrot and a bit of stick, but…

Lucas Hendrich: And it's harder the further separated you are. You're taking a lot of complex interests, tastes, preferences, and worldviews and trying to shape those vectors into something that moves in one direction.

Kit Colbert: Exactly. I think I was good at setting the vision. Where I struggled was being firm and making decisions. Sometimes people would say, "We've talked it through; we need a call." I wasn't used to that. As an IC, someone else made the call. So it was, "Oh no, I have to make the decision."

It took me a while to realize that, which seems obvious in hindsight, and it wasn't my natural strength. But I had the chance to reflect and strengthen those weaker areas as a leader, so I could do better managing a much larger team.

One of the hard things is letting go of some decisions. Yes, you need to make decisions sometimes, but most aren't technical. They're about organization, strategy, or priorities, which then have downstream effects on the technical work. As a leader, you have to take yourself out of the technical details a bit, because there's so much going on that you don't have time for it all.

You can have veto power, but if you're going to micromanage everyone, there's not much point in having all these other people. It's just you. So you learn that your value to the organization is different than before, that what got you here won't keep making you successful, and that you need to focus on other things. That was another big eye-opener I learned the hard way.

AI: Overrated and Underrated

The future is here, unevenly distributed

Lucas Hendrich: That's interesting. What's something about the current AI landscape — its use or how it's conceived — that you feel is overrated, and something underrated?

Kit Colbert: Great question. I'm not sure about overrated versus underrated, but one thing I'll say is that the future is here, it's just not evenly distributed.

Lucas Hendrich: OK.

Kit Colbert: As I mentioned, one thing I love about being at a startup is that we can move so fast and experiment. Startups have fewer guardrails and less structure, so people are just trying random things. People do that at big companies too, but it gets shut down much faster because the structure is there to say, "No, you can't do this."

We have people using all sorts of AI tools. It's a bit of the Wild West, so we've had to say, "Let's be careful with corporate data," and so on. But there's a lot of experimentation and envelope-pushing. The ways we're using AI at Invisible, and at many other startups, and how we're rethinking team structure around it — maybe that's happening abstractly at larger companies, but there's no way they can roll out anything like it.

Lucas Hendrich: Yes.

Kit Colbert: Or even have access to these tools yet.

Lucas Hendrich: So the underrated aspect isn't technical. It's the impact on organizations, processes, and ways of working.

Kit Colbert: And it's here now. People have been talking about it as coming, and you hear bits and pieces, but I see it again and again, especially in the San Francisco startup scene, at panel discussions and incubator events.

Lucas Hendrich: It feels like you breathe it in the air there.

Kit Colbert: One reason the city is back the way it is, is that so many AI companies are based in San Francisco. That's the nexus. People are trying everything and sharing best practices. It really is the future being here: you look around and think, "This is incredible," given the productivity we're seeing. It's been discussed theoretically, and it will absolutely reach much larger companies, but it takes time. We have to prove it out in this part of the industry first.

Knowledge shared at the speed of an LLM

Lucas Hendrich: I totally agree. Have you read Guns, Germs, and Steel?

Kit Colbert: Of course.

Lucas Hendrich: Part of its thesis is that innovation happens because of human proximity. When you're not worried about hunting on the Great Plains and you're concentrated enough, ideas spread quickly. To me, that's also the underrated part of AI. We used to be able to rent-seek on expertise, but our hardware isn't built for long-term retention and retrieval of data, and our cognitive powers don't have the same calculating muscle.

Kit Colbert: So having that knowledge shared quickly through an LLM — being able to summarize all the slop out there and get to the signal in the noise. Or with expert material: "Explain this to me in simple terms."

Lucas Hendrich: Yes, and you broaden yourself. An early version of that, maybe, is YouTube — I'm a YouTube junkie. I want to learn about something, find a video, and that's how I learn. I learn by listening; just reading doesn't help me as much. It provides the experiential part of learning. That's definitely underrated.

Overrated: throwing tools at people

Lucas Hendrich: What I think is overrated — and it's always been the case — is the idea that you can just introduce technology and get results. Give a bunch of students laptops; that first wave of injecting technology everywhere and expecting some result.

Kit Colbert: I have another underrated one, but on the overrated side, I completely agree. It's not just students; it's developers too. As I said, I view AI as a normal technology, like any other tool. Whenever you give a developer, or anyone, a new tool, they'll be less productive at first, because it takes time to learn the tool, incorporate it into your workflow, and really get value from it. Over time, the more they use it, the more productive they become. But it's not magic. Like anything else, it needs best practices and structure, just like Agile development, and the industry is now forming ideas about those best practices.

Lucas Hendrich: And the common misconception has always been that you can change overnight. You can't. You need military precision in your operations.

Kit Colbert: So the idea that you can just throw it at people and they'll naturally figure it out — they should definitely play with it. But when you want to industrialize and scale it, especially when you're spending a lot on tokens, you want to be really thoughtful about doing it effectively.

Overrated: AI taking over, and AGI

Kit Colbert: Another overrated idea, which we discussed earlier, is that AI is going to take over everything. It's not AI; it's people doing things with AI. I keep coming back to that. AI isn't some sentient thing acting on its own. People will use it like any other tool.

Lucas Hendrich: AGI is overrated.

Kit Colbert: I believe it, because I already have enough AGI, in a sense. It depends how you define it. In some ways, superintelligence is here. Look how amazing these things are. They're amazing. Do they also suck at a lot of things? Yes.

We can clearly build machines that are very smart in certain ways, but their intelligence will be jagged. I think that's really important. The idea that some AGI will be better than the aggregate of all humans in every possible way doesn't make sense to me.

Humans aren't smarter than every other animal species in every way, either. I was reading the other day that chimps are apparently better at game theory than humans. They have better working memory, and in some of these scenarios — maybe the prisoner's dilemma, I'm not sure — they perform close to the Nash equilibrium. Generally we're smarter than chimps, but not in that way. I think AGI will be the same: really great in some ways, probably not in others, and never better than us in every way.

Lucas Hendrich: It'll be the combination of these things. Quantum computing, for example, is amazingly good at cryptography.

Kit Colbert: Exactly. But you have to rewrite the algorithms for quantum to be useful. People thought you could take the same algorithm, but no — it takes a completely different algorithm to take advantage of quantum.

Underrated: agents that run for a week

Kit Colbert: I'll end on a positive note, on the underrated side. I think it's currently underrated how long AI agents will be able to run on their own on a fairly complex task by the end of 2026.

Today, METR's measure — I think it's 10 to 12 hours. That alone should shock people. These things can do a full workday on their own. You can set one going in the morning or overnight and check on it 12 hours later. It's pretty amazing.

Lucas Hendrich: It is.

Kit Colbert: Given how quickly capabilities are increasing and new models are coming out, it wouldn't surprise me if by the end of the year they could run for a week. Today it's half a day, give or take. It wouldn't surprise me at all if you could give one a fairly complex project plan, say "Have at it," and check back the next week.

Think about how we manage people. Many people on my team I only need to meet weekly, because they're very capable. If something comes up, they can ping me anytime, but weekly we check progress, deal with issues, and work through them. You can imagine AI agents being the same by the end of the year: checking on them weekly, reviewing their progress, and validating what they're doing.

I think that's extraordinarily underrated, and back to our earlier discussion, it will change how we operate. You're an engineer, but you're effectively managing all these agents…

Lucas Hendrich: Yes.

Kit Colbert: …much as you would people.

Rewriting everything

Lucas Hendrich: It makes you wonder whether we'll eventually rewrite everything that's ever been written — and I mean that seriously.

Kit Colbert: Think about it.

Lucas Hendrich: I think it took a week to rewrite Firefox.

Kit Colbert: Especially any kind of modernization. Mainframes running COBOL still handle a lot of core transactions for financial institutions. It's very delicate, and you don't want to break it, because trillions of dollars are at risk. But, to your point, it becomes much more tractable now that you can have all these AI agents work on it, generate a ton of tests, and validate it.

Lucas Hendrich: Version two, ready next week.

Technology on Screen

Her

Lucas Hendrich: Last curveball question — a really easy one. What's your favorite, or the best, representation of computers or technology in a film or fictional series? The one closest to reality — which is hard, because reality would be boring.

Kit Colbert: I know it became a thing with Sam Altman a year or so ago, but the movie Her always stuck with me.

Lucas Hendrich: Good prediction.

Kit Colbert: What I liked was that it showed such a different user experience from what you typically see. Usually it's very visual. This was purely vocal, which I found so interesting. It wasn't what you'd expect, but you could see it. If you played it out, you could imagine computers being that way. I loved that it was such a departure from the usual very visual, keyboard-heavy representation.

Lucas Hendrich: That's a good one. Or Ex Machina — it has to be embodied somehow.

Kit Colbert: Yes. Her was the first that came to mind, and it really jumped out at me at the time.

Fit for purpose

Kit Colbert: Here's an interesting thing, though: I don't actually want to interact with a computer solely by voice. It's useful for some things, but if I have a spreadsheet or I'm looking at code, I need a screen. Things have to be fit for purpose.

But as LLMs evolve, you'll be able to move some things you used to do on a screen to voice. Take code: once I have a model I trust enough, I could just ask it verbally to check something and report back, like I would with someone who works for me. I'm not going to look over your shoulder while you read the code; I trust you to look and give me an accurate report. So I think there will always be a need for a screen, but it will shift and evolve.

Lucas Hendrich: The form factor question is really interesting. From the very beginning, I loved the command line. It's always felt like the most intuitive way to interact with the machine, with a lot of caveats.

Kit Colbert: Yes.

Lucas Hendrich: And chat, or a CLI like Claude Code, has moved in that direction and kind of parked there. You can click a button to dictate, and it transcribes and executes.

Hackers vs. reality

Lucas Hendrich: I have an answer to my own question. I hope it doesn't reveal too much about me. The worst example is literally the movie Hackers, where typing fast somehow equals doing something. But the movie Blackhat, with Chris Hemsworth, which kind of came and went, showed hacking as a very slow, arduous process. Or Mr. Robot, which I've always liked.

Kit Colbert: The other problem with Hackers is that those guys were really cool. Come on — I was a nerd. We're nerds. Of course I watched the movie, because you have to, but it didn't feel real. To your point, it misses that the real thing looks very boring from the outside, because you're scouring really detailed stuff.

Lucas Hendrich: You're checking logs, picking apart traffic.

Kit Colbert: There's nothing sexy on screen — just a lot of command-line stuff. It doesn't make for a good movie, so I get why they went the direction they did.

Closing

Lucas Hendrich: Kit, it's been a pleasure.

Kit Colbert: Lucas, thank you so much. Wonderful talking to you. I appreciate it.

Lucas Hendrich: Thank you. That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.

‍