Joe Beda and Craig McLuckie co-created Kubernetes, the infrastructure standard that became the default for cloud native computing. Now running Stacklok, they’re watching enterprises hit the same identity, permissions, and security problems with AI agents that took the container ecosystem years to resolve, and they’re building tools to compress that timeline.
In this episode of Founded & Funded, Madrona’s Tim Porter sits down with Craig and Joe to talk through what AI adoption actually requires from the organizations building and deploying it right now. They cover why the governance frameworks most enterprises have today weren’t built for agents, how MCP provides the controlled access layer that makes autonomous agent work possible without slowing everything down, and why the architecture decisions being made right now are significantly harder to undo than they appear. They get specific about sequencing, including why developer posture has to come before knowledge worker deployment, what the FDE model looks like when it’s working, and what consistently goes wrong when a platform gets deployed without staying to close the loop. And they go inside Stacklok to talk about what’s changed about building software, what makes someone valuable on a team when agents are doing an increasing share of the work, and why the lock-in risk everyone is focused on is the wrong one.
For founders making infrastructure and talent decisions, and for the CIOs and CTOs responsible for making AI adoption stick at scale, this conversation is one of the more practically useful things you’ll watch this year.
Listen on Spotify, Apple, and Amazon | Watch on YouTube.
This transcript was automatically generated and edited for clarity.
What Are the Lessons from Cloud Native That Apply to AI Agent Adoption?
Tim: I mean, putting it lightly, you’ve both been at the forefront of two different infrastructure eras now, the cloud-native era, we’ll just call it that, and now the AI era, the LLM era. Most founders today are making foundational decisions without having that historical perspective and having lived through it before. What are some of the big lessons learned from the first time around that now you’re applying to helping founders who are building in this fastest-moving era that I’ve ever seen in my 30 years in technology?
Joe: I like to say that don’t underestimate what can be done when the people doing it don’t know what they’re doing is impossible. I think the spirit of a startup is that you have to ignore conventional wisdom in the lessons of the past to some degree, and that’s the only way to move forward and really, truly innovate. But that being said, I think that there are some lessons that we are taking away. I think open source is an enormous enabler of communities is one of those things, and it’s something that we’re investing in with Stacklok. Things both move faster and slower than you think they do, especially when dealing with enterprises.
One of the things that I did before Heptio was start this open-source project called SPIFFE around identity. That was about 10 years ago, and only now are we starting to see it come into its own with the AI era. And it’s also one of the things that we’re looking at building into Stacklok products there. So it sometimes takes a lot longer for these things to fully mature, and the old adage of it happens slow, and then it happens fast definitely comes into play here.
Tim: I think it’s a great point that thinking with a blank sheet of paper in some ways helps solve problems the right way, but having some first-principle historical perspective always helps as you solve those things. So I think getting that balance is absolutely right. Craig, what would you say are the lessons you learned from helping to build cloud-native to now helping companies address this AI moment?
Craig: Well, I think it’s definitely a moment of chaos. When you start to see a new pattern emerge, like the Kubernetes and container opportunity, it’s very difficult for enterprises to know what’s real. I think that, as we saw the evolution of the cloud-native ecosystem, there are some amazing new technologies that emerge, but there’s also a lot of flash-in-the-pan moments, and it’s very difficult for an enterprise to have that kind of discernment. I think the thing that we really focused on in the past was effectively being the field guide or the jungle guide that would help an organization bring a real authenticity to the table and help folks not just reason about the technology that you’re working on, but also reason about the broader ecosystem, understand the state of the art and really deal with the impedance mismatch that exists between a very fast-moving innovative community and the relatively slow-moving but incredibly significant enterprise tech space.
So I always think of this moment and opportunity to slip the clutch to be able to engage with an organization and bring change at a pace that they can absorb is really important. And I think trust is key. I think having that awareness of what it takes to actually make change happen in an enterprise environment is really important.
Why Did Joe Beda Rejoin Craig McLuckie at Stacklok?
Tim: Joe, you rejoined Craig to help build Stacklok. Say more about this moment. You touched on it a bit about why this problem right now working again with Craig is the biggest and best thing to go spend your time.
Joe: Well, I think there are two factors that made me decide to jump in. First of all, it was just being ready, I think. Doing a startup and being part of a startup as a full-contact sport, you’ve got to be ready to be in it, and being able to take some time off and recharge was really important, and it means I can bring my all to this. But beyond that, I self-identify as an engineer after all this time, and the world has changed so much that if I want to continue to consider myself an engineer, I have to really learn how to use these new tools and be effective with them. And the only way to do that is to jump in and get your hands dirty.
How Is the Developer Workflow a Preview of Knowledge Worker AI Adoption?
Tim: Enterprises are developing and deploying AI in a lot of different ways. Coding is at the forefront. Everybody in the organization, from information workers to developers, wants to use agents. The number of agents are multiplying by orders of magnitude, and that creates a lot of security concerns, a lot of compliance concerns, a lot of trust and safety concerns, and other governance-type things. And so you guys at Stacklok are trying to make that manageable, but say more about what you are hearing from customers that problem and how you think about the framework to go best address it.
Craig: I think there’s a lot to unpack there, but I mean, the way I’d start with it is I think we’re starting to see a hint of what the future looks like for knowledge workers through the lens of developers. What I mean by that is if you look at the way that a modern development team operates right now, you look at the way that the Stacklok development team operates, we are generating tremendous value through the use of agents. And the way that we work has changed. There’s no longer a single developer operating in an IDE. It’s a single developer taking responsibility for the work product of a pretty broad cross-section of agents that are all specialized to perform certain tasks. And the developers are really becoming the center of orchestration for these agentic systems, curating them, making sure that they can understand the work product that’s being produced, being accountable for their behavior, and ultimately making sure that they’re productively engaged in a direction that the company cares about.
And so when we think about where this is going over the next few years, I think what we’re seeing in the development space will naturally start to cascade into the knowledge worker space, but there’s going to be a lot of challenges for knowledge workers to be able to embrace that pattern of engagement. Developers are pretty flexible in their thinking. They have a relatively high-paying threshold when dealing with the configuration of their local environment. They can be educated in certain patterns, and their very nature leads them to this kind of curiosity with the tools that may or may not exist in the space with knowledge workers. And I think when we look to the patterns and practices, the most important thing is being able to trust that agent to do work for some amount of time to create value.
And for a developer, that might mean setting up an isolated environment and standing up a whole bunch of tools, and then making sure that the right controls are in place, and they’re willing to actually make those investments for themselves. You cannot ask a knowledge worker to do that in a realistic way. And so I think the starting point for us is really like, “Let’s figure out how to enable AI to be a natural part of a knowledge worker’s work. Let’s make sure that they have access to the set of systems that they need to be able to actually generate value. Let’s enable them to start providing tools that these AI systems that can actually start to do work. And then, over time, it increases the richness of those capabilities so they get to that experience where agents are a natural part of the workforce.” And it really starts with how do we borrow from some of the ideas that are coming out of the development organization and make that accessible and democratize it for knowledge workers?
What Is MCP and Why Does It Matter for Enterprise AI Security?
Tim: So that’s the big picture. Let’s zoom in. One of the places that is an important standard that enables this knowledge worker and developer experience is this MCP. So people want to use these LLMs, they want to connect to their data, they want to connect to other tools, and they want to connect other services. Enterprises aren’t going to let either their knowledge workers or their developers just to download random code off the internet or connect to it. Talk about MCP as a standard, where that’s going, and why that’s an important initial attach point to help address this broader challenge.
Craig: I often draw analogy, and I think back on the first time I saw Docker. And, I mean, Joe, I don’t know if you remember this, but I remember just kicking myself because when I looked at Docker, I could see two things almost coexisting in the same space. One was a technology that unlocked containers in a new use case, enabling productivity for developers, creating portability for their applications. But you could also squint at Docker, and you could see Kubernetes on the other side of it. And I think I had a very similar experience when I looked at MCP when the specification was introduced. It was kind of like, “Oh, wow, why didn’t I think of this?”, because it really promised two things. It suggested what the future of AI native applications might look at. If you have the LLM being the presentation layer and the view model for modern app, what’s that middleware?
What’s that middle tier that enables you to actually start accessing data? And MCP is suggesting that. And I think that’s where people start to think about these experiences, but it also represents this opportunity to control the aperture whereby agents start to access systems. And having a formalized protocol means you can now have the selectively permeable membrane that you can wrap around your existing systems and make sure that value flows in both directions, but harm does not. And I think that starting point of MCP as a gateway that enables controlled access to resources is incredibly important. And for organizations, when you’re starting to think about these workflows, people are very poor at scrutinizing the work of an agent.
“Having a formalized protocol means you can now have the selectively permeable membrane that you can wrap around your existing systems and make sure that value flows in both directions, but harm does not.” — Craig McLuckie
You think about the YOLO mode, or you think about developers being asked to reason about every access request to a resource. Humans don’t work that way. And so the gateway to productivity is having the right guardrails in place so that you can set that tool or that agent off to go and do work, knowing that it can’t get up to any harm and that it can’t egress data that you don’t want it to egress. And so I think that is the gateway to productivity. It’s not just about asserting control and slowing things down, but by actually creating those guardrails, you enable a lot more velocity and productivity in organizations. It works well for developers. And then, as we see knowledge workers starting to have to asking the same questions, it will work just as well for them.
Tim: People listening that might not know, we mentioned that Craig and Joe co-created Kubernetes. I mean, maybe after Linux, the most successful open-source project in history. Maybe that’s debatable, but it’s just become an absolute standard across enterprises. You all saw this problem around orchestrating cloud workloads. You just mentioned you saw Docker and containers, and looked ahead to what’s next. Joe, talk about that a little bit. There became lots of different pieces to Kubernetes, and I don’t want to overextend the analogy. Maybe MCP is one piece here of this broader puzzle to get to Enterprise’s ultimate goal.
Joe: Yeah, definitely. I think what we’re seeing is MCP is a great starting point. It’s both a great place to control risk, as Craig was talking about, but also when we talk to enterprises, you can give your knowledge workers a chatbot, and that’s great, but a chatbot that’s connected to your internal systems, that’s even better. As we talk to customers and they try and make this stuff work, I think they start off with just rubbing some AI on and hoping for the best, and it turns out that’s not good enough. You really do need to connect it to your external systems.
What Is an LLM Gateway and What Is “Left of the LLM”?
We’re seeing three overlapping concerns here that are driving the ecosystem of tools. The first is safety, this idea of governance and making sure that bad things don’t happen because you’re essentially coupling these stochastic systems that have built-in randomness. That’s one of the ways they work with things that are critical to your business. And so you have to be careful there.
The second thing is that you need to make them actually work. They have to actually deliver on what they’re promising. And then, as we see more and more of this, cost control ends up being a piece of the puzzle, also. And so, just like we’re seeing MCP as being one lens and one place where you can exert control both around safety and ability, I think the next piece of the puzzle is the LLM gateway. Essentially, having something standing between your workloads, your agents, whatever an agent means in that context, and the upstream LLM providers, that’s a place where definitely cost control can come into play. But there are also safety concerns there around egressing sensitive data, and also maintaining the level of flexibility so that as we see new models come out as self-hosting of some of the open-weight models becomes more tenable and more realistic, depending on the use case, that LLM gateway becomes a very strategic choke point across all three of those factors that people are worried about.
But then, if you zoom out and look at the larger picture, I think when Chat GPT first hit the scene, so much of the focus was on the LLM itself and everything that’s happening there. But if you draw a diagram of what happens between a user’s intent, let’s take a knowledge worker using a chatbot, for example, and that LLM, there’s a bunch of stuff in the middle there, and it’s that stuff in the middle that we’re seeing a ton of innovation. We’re actually seeing a ton of advancement in terms of the capabilities. When you look at something like the coding agent, something like Claude Code, the LLM is a big part of it, but also what’s happening as part of Claude Code itself is a significant piece of the puzzle. It’s going to be a similar thing as we start seeing knowledge workers start using these systems in a more in-depth way.
It’s not just a direct line to the LLM. There’s a bunch of stuff happening in the middle there, around context management, memory management, being able to upload and organize documents, and share those. How do you actually build skills and share those skills with your teammates? That peer-to-peer enablement, defining what the agent is. All of those things are happening left of the LLM in that diagram, in my mind at least, of that journey from the user to the LLM. And that’s a place where there’s enormous appetite, I think, to create something that is both open and aimed at enterprises for them to run behind their firewall. And I’m really excited about exploring that and partnering with users around figuring out what it makes to really enable them to provide those Claude code-like moments, but for the rest of the company.
The Mainframe vs. Open Platform Question That Will Define the AI Infrastructure Era
Tim: That’s really helpful, and it mirrors in security broadly this notion of shift left, get closer to the developer, designed for security and safety earlier in that process. You mentioned LLM gateways, maybe just in terms that another founder can appreciate. Everybody agrees on, “Hey, I want my team to use more of the LMs. Hey, I want them to use agents. Hey, we’re going to get more sophisticated around harnesses around these things.” But I also hear, “Does an LLM Gateway solve the security and safety? Do I need to have an observability and monitoring solution and just look at what happens either on the network or around the workstation? Is this an identity problem? Is it a registry?
There’s a white list like, “Hey, these are known good tools or other data sources, we’re okay.'” But I think to your point, there’s a lot of “stuff” that happens there. Maybe how should a founder or even an enterprise think about is it the right set of these things that works for you? Or is there some other framework to think about it, Or debate that’s even the right set of things.
Joe: No, no, I think the answer to all of that stuff is that we need all of that stuff. And I think there are parallels here with the Kubernetes cloud-native world. So if you look at the CNCF landscape, it’s this eye chart with a gazillion logos. And it’s intimidating for enterprises to figure out, “How do I even get started with that?” And I think we’re seeing a similar thing in the AI space where there’s so many choices and all of them have these impacts in terms of security and cost and the ability to get stuff done. And I think a lot of companies are looking for a starting point and a guide to help them navigate this territory.
Craig: I mean, I think about what Kubernetes offered and why the CNCF landscape map became such an eye chart is it really represented a principled interface so that someone could specialize on one thing that’s relevant to every Kubernetes environment like observability or some facet of security around eBPF or novel ways to actually drive isolation. And it created efficiencies so that organizations could start to specialize and actually deliver value across the world. I think the big question that we have to ask ourselves as an ecosystem, as enterprise organizations, as startups, is are we moving back into the mainframe era, where the world is highly vertically integrated? Or are we going to be in a world where a platform starts to emerge that enables organizations to create specialized value and enables optionality so that you’re not necessarily tied into one system?
“Are we moving back into the mainframe era, where the world is highly vertically integrated? Or are we going to be in a world where a platform starts to emerge that enables organizations to create specialized value and enables optionality so that you’re not necessarily tied into one system?” — Craig McLuckie
And it could be around inferencing. Obviously, the frontier models are running at the absolute forefront. There’s incredible innovation happening there, but open-weight models are maybe a generation or two behind and they offer incredible price performance advantages for some organizations. So being able to hold option value on that is important, but that’s not going to work if so much of the value is coupled in what Joe describes as being left at the LLM. And so I think we do need to see this platform architecture emerge in the open source. I think MCP is a seed crystal that offers an opportunity to grow this ecosystem around it, but it’s obviously insufficient.
And I actually think if you look at it, Kubernetes offers a lot of the hints, not just in terms of how to build around a community, but literally just Kubernetes. It actually is a pretty principled control pane. It has some really nice properties in terms of reconciliation-driven action. And I think we will naturally start to see this community emerge around Kubernetes itself where we start to introduce first-class primitives that unlock this class of use case and value.
Why Is LLM Lock-In the Wrong Risk? Where Does AI Lock-In Actually Live?
Tim: So Joe, you mentioned shifting left of the LLM. We talked about how a big driver of the whole cloud-native wave was allow interoperability and to make enterprises feel like they’re not getting locked into a certain cloud or a certain technology. There’s a bunch of lock-in potential considerations here, either in like a technology stack choice or even the LLM that you want to use. My goodness, every week there’s a new model that comes out that leapfrogs the other one. And I would imagine that customers want to stay very nimble about, “Hey, whatever’s the best fit for me, that’s the model I want to be able to use within a framework that’s safe and reliable, et cetera.” Is that something that you think is an important consideration here as well?
Joe: Yeah, exactly. I think as this world unfolded, I think there was a certain level of relief that it was actually so easy to switch between LLM providers, and people felt like they had that optionality there, but the stuff that is sort of to the left of the LLM, that ends up being much more tied to your day-to-day existence. Now, when we talk about developers, they’re really good at switching tools. They do it all the time. And we’ve seen like, oh, folks move between different coding agents and different IDEs to be able to do that. But I think when you’re looking at this through the lens of an enterprise delivering tools to knowledge workers, they’re not going to be as nimble as developers. And so if you train all of your sales team on how to use Claude or how to use OpenAI, you’re not just tying yourself to that LLM provider, you’re tying yourself to the entire experience delivered through the set of front-end tools provided by that.
“If you train all of your sales team on how to use Claude or how to use OpenAI, you’re not just tying yourself to that LLM provider, you’re tying yourself to the entire experience delivered through the set of front-end tools provided by that.” — Joe Beda
So really, we’re seeing in that much more knowledge worker-facing or consumer-facing space, much more vertical integration that can lead to lock-in. And we think that doesn’t really serve the enterprise as well. We think that they want to own the destiny of how they train and how they inform and how they build tools for their knowledge workers beyond the developers, and they want to make sure that that is insulated from the actual upstream LM provider that they’re using. And so that’s an evolution that I’m going to be looking forward to and something that we’re very interested in at Stacklok.
Tim: A great point. And I think Stacklok enables, “Okay, whatever’s the best model for you, plug it in.” But also if, “Hey, today MCP is a great way to,” but that might be a different standard down the road, and you’re also abstracting away from that as well. It’s like, “Let’s take whatever the best interoperability standard, the best model, and make sure that enterprises can access that as the best-of-breed in that scenario.”
Joe: Yeah, exactly. I think MCP is a great starting point, but this world’s moving fast, and we want to make sure that we have all the right touchpoints so that we can enable our customers to stay abreast of the latest and get the best out of it. So one of the things that we see is that, let’s say, you have an enterprise that’s doing the AI-enhanced banker. So it’s a human, and they want to give that human a tool so they can do stuff faster, more effectively, access data, and join all that information together. That’s really powerful. And traditionally, oftentimes we’ll have corporate controls, but there’s an overlay of your company handbook says, “Don’t do X. And if you do this other thing, we can actually maybe arrest you, and you go to jail.” There are all these sorts of human-level constructs that keep people from doing things.
Well, those don’t apply to AI, really. An AI can move faster than a human. It can access a lot more information before you understand what’s happening. Also, you can tell it to follow the handbook, but it doesn’t always follow the handbook. It is a stochastic system, and it’s not afraid of going to jail, so the set of controls that we have in AI that we need to advance those things. So, for example, if you have this AI-empowered banker and they’re on a call or in an interaction with a customer, you want to make sure that as they enable tools to act, say, sensitive customer data, they have some sort of proof that there’s a live customer on the other end and that they’re accessing this on behalf of a customer. So that’s another piece of information that there’s a transaction with a customer that you have to carry from the agent interacting through whatever interface that they’re using, through maybe an agent calling an agent calling an agent calling an MCP server calling a database.
“An AI can move faster than a human. It can access a lot more information before you understand what’s happening. Also, you can tell it to follow the handbook, but it doesn’t always follow the handbook. It is a stochastic system, and it’s not afraid of going to jail.” — Joe Beda
And then, as you get to that database, you may want to restrict to say, “Oh, only return information for this single customer.” And so that entire chain, you have to carry that information through, and we don’t do that typically today. There are a few places where enterprises can do that type of transaction token, but it’s pretty rare. And being able to plumb that through that entire stack is what we think a key thing to be able to really build trust that you can give knowledge workers access to sensitive information, which they already have, but through agents in a way where they can trust that things aren’t going to go wild and do something that is unsafe.
Where Should Enterprises Actually Start With AI Agent Adoption?
Tim: You’ve started with banks, different customers have different priorities, and where you start. And that’s maybe what I’d like to talk about next is to try… It’s all complicated, it’s going to evolve, but where to start? So, from just a user adoption standpoint, do you see patterns within your customers about where they’re most focused initially?
Craig: Just talking about us as a company, we see the developer space as being highly contested and notoriously hard to monetize. This is true of developer technologies universally, but it also is the place where an organization can understand and learn the full value of the system, but also create leverage for themselves. So one of the patterns we see is during the days of Kubernetes, we would come into an organization, and we would like to partner what’s now known as FDEs. We used to call them field engineers back then. Now, they’re called forward deployed engineers with a platform, and they would help an organization get over the learning curve. Our FDEs are now outperforming our expectations massively because they’re not showing up and just doing work. They’re showing up and bringing skills. They’re showing up and helping to educate the team around how to actually operate their own agents.
And so getting the development posture for an organization right from the get-go is really important because it also accelerates the use of the technology itself. It accelerates the operationalization of all these platform pieces and it accelerates an organization’s path to value. And so I think for most organizations it is about getting the engineering flow right first, making that transition so that you’re starting to use agents to generate asynchronous value, getting into that world where the engineers feel like they’re flying. And once you’ve there, you’ve now established a set of patterns and you can start to extrapolate that for knowledge workers. And you can also start asking questions around what’s working for developers that just won’t work for knowledge workers. If you start looking at technologies like Claude, which is really amazing, so much of the work is being done locally like the developer’s desktop is the anchor point for integration.
It’s where memory management and session management happen. That’s probably not going to work for your knowledge workers who need to create experiences on phones. So you can start to extrapolate what good looks like, but you can also ask the question, what needs to change and what needs to be built to create those outcomes for knowledge workers? And then, I think it has to be grounded in a very specific, concrete use case. I think that where enterprises fall down, and some of the things we’ve seen, is that it is kind of by modality. If we get a chance to work with an enterprise, not just around a platform deployment, but identifying the first cohort of users, the first agent, getting them to the point where they have the sophistication to actually create the outcomes, great things happen.
But if we just deliver a platform and walk away and expect that enterprises are going to be able to turn the corner on agentic development and understand the mechanics that are actually building something that’s precision-oriented to create value in the space, things don’t necessarily go as well. And so I think you really do need to close out the arc and be patient with identifying, first getting the development team that you’re working with to a point where they’re operating excellently so that you can bring in the skills so they can actually start to feed themselves, and then identifying those initial use cases and working those to completion before expanding the program up.
How Should Enterprises Configure AI Agents? MCP First, LLM Gateway Second
Tim: Within a use case, now this is sort of a technology lens on it, is the place you advise customers or other founders you talk to around securing this whole process within use cases, start with this notion of LLM gateway or start with this notion of like, “If you’re really sure that everything you’re connecting to over MCP is secure, you’re in good shape.” So from a product technology standpoint, what’s the analogous here, where you get started down this journey?
Craig: I mean, I think the MCP section is an important starting point. And then, the way I think about it is like, what are you trying to optimize around? And I think the thing that you need to optimize around specifically, when you’re working with development teams, is how long can an agent do useful work before I have to go back and intervene?
Joe: And the factor is trust there.
Craig: And the factor is trust. So the first thing you have to do is get to the point where the agent is able to run for some amount of time without you having to constantly watch it and approve every tool access and integration. And so starting with some very coarse-grained controls around, “I’m going to configure this thing to run in a relatively isolated environment, I’m going to be judicious around the tools it has access to, knowing that they have read-only access and the ability for the system to start egressing sensitive data, et cetera, is limited,” is the logical starting point. Because once you’re at that point, you are now creating efficiencies for yourself.
“The gateway to that outcome is MCP. It is a natural starting point because it gives you the guardrails that enable you to go fast.” — Craig McLuckie
And so I think you always start there, and the gateway to that outcome is MCP. It is a natural starting point because it gives you the guardrails that enable you to go fast. Once you’ve got to that point, you can start asking questions around, well, LLM Gateway would be another is the immediate next question. A lot of organizations that make that first transition start to experience a little bit of sticker shock with token consumption. They want to be able to start doing intelligent routing and say, “Hey, these types of requests, you probably shouldn’t be using Opus 4.7. Maybe a cheaper model makes more sense.” And then, you start to work into creating the more complete system over time.
How Is Stacklok Building Software Now? What Has Changed About Engineering Teams?
Tim: Another topic is you referenced how forward deployed engineers from field engineers, how that has evolved, and just using AI in everything you’re doing internally. Maybe just talk about that. How is Stacklok building software? Are you in the “Hey, it’s basically the same number of developers,” and everyone is doing 10 or 50 times more? Is it a mix where your team is mostly directing other agents to do things? How are you driving efficiency and productivity using AI within Stacklok?
Craig: It’s wildly different. It’s unrecognizable. The profile of what constitutes a successful developer is unrecognizable. You always maintain as a startup fund, you always have in your head your life raft exercise of who your most valuable engineers are. That’s become completely Freaky Friday’d up. Everything is different. And I think the starting point is recognizing that we treat engineering now as a performance sport. You don’t need a hundred football players to win the Super Bowl. I mean, I’m not a sportsball guy, so I don’t know how many you actually do need. I’m pretty sure it’s not a hundred. So you’re able to actually be far more effective with the resources you have. I think there’s almost this Ballmer Peak. We used to joke about how much your code performance improves with drinking. But I think there are performance elements to having smaller teams, smaller, more senior teams that are able to reason about not just the code. Joe describes it as product engineering.
“The profile of what constitutes a successful developer is unrecognizable. You always have in your head your life raft exercise of who your most valuable engineers are. That’s become completely Freaky Friday’d.” — Craig McLuckie
The wisdom to be able to balance understanding of the customer with what you’re driving is very different. PM’s role is very different. Their ability to scale is disproportional. We have systems where we’re obviously very careful about what conversations are transcribed as we are interacting with larger organizations, but we will make sure that we take great notes and then put that into a channel, and then make that available to all the engineers so they don’t have to speculate. They can ask questions about which of the 60, 70 customers you’ve talked to over the last month want X, Y, Z. That is immediately available to the engineers when they’re doing research on features.
And so everything has changed. The scale of management has changed. The tools that engineering management use are fundamentally different. The way that we handle planning and the set of skills we’ve built around planning and design are completely changed. The way that our designers work is just foundationally different. We no longer work in Figma. Our designers produce working systems. And then, they take those working systems to the engineers and then they throw them away. Or they’ll take subsets of it, but our designers-
Joe: Code is not nearly as precious as it used to be.
Craig: It’s not precious, and free code is free. And it’s so much more evocative to just have a working system that your designers produced than to try to extrapolate on Figma. We just don’t do that anymore. We’re able to… The FTEs themselves are contributing significantly. They’re taking these skills that the product team is producing, and they’re now able to expand the product surface as they’re working with customers, because they’re just using the same tools and practices, and they’re fitting in. I mean, it’s incredibly exciting. It’s wonderful. It’s scary as well. It’s just a whole new world.
Tim: Joe, you said code is less precious. Say more about that because, obviously, you can generate a lot more code. Sometimes with companies, I hear, “Well, that just creates a different bottleneck, which is code review and code quality.” And then, I hear others say, “Code review? I don’t look at the code. You say AI reviews it, we just test it with AI.” Now, of course, it depends on what you’re building. If you’re building for pacemakers versus a consumer website, then the stakes of if it goes down are differently. But how do you balance that?
Joe: Well, I think the job has just fundamentally changed. One of the things that I joked about in the pre-AI era is that the job of somebody who’s a high-level principal engineer, architect level is that oftentimes you’ll draw a bunch of boxes on a whiteboard and then you’ll have teams go off and compile the whiteboard. And these days, you still have to actually know the structure of what you’re building. You still have to have your pulse on what’s happening, but you’re operating at that compile-the-whiteboard level. Instead of having engineers do it, you have agents that can go off and compile the virtual whiteboard for you.
But one of the lessons that you learn as you’re managing these large teams is that you can’t read all the code that’s being produced, similar to how you can’t read all the code that’s being produced by agents, but you build an intuition around what are the key places where I do want to keep an eye on things, schemas for your databases, API contracts, level of test coverage? You get this sense of like, “If I pay attention to these things and something looks off, then I go ahead, and I dig deeper.” And so I think part of engineering now is building those more senior skills of how to actually manage a lot of work and find the real inflection points that you want to watch. And that’s not something that a typical entry-level engineer knows how to do.
There’s another interesting aspect here in that if engineers now have like six coding sessions talking to an agent all going at once. I started at Google 20-some years ago now or not even, well, not quite that long ago, but like maybe 15 years ago, and there was this idea of 20% time there, this idea that if you give engineers room to play, they can do amazing things and you want to give them that freedom. Now, the idea at the time was like one day a week the engineer goes off and actually does a personal project that’s related to the company, but also is more exploratory. Well, now if you’re running five or six agents, you can take one of those agents and have them do something more exploratory. So there’s still room to bring that human element and that intuition of exploring new spaces, but we just have a much expanded tool set to be able to do it with.
Tim: You know, every successful company in my experience was good at bringing together a diverse set of people, a diverse set of perspectives, and together you can do great things. And if there’s a monoculture, you mentioned like the job of a senior engineer architect used to be put it on a whiteboard and then a team goes and compiles it. Okay, so today you can have your-
Joe: I’m being tongue-in-cheek there.
What Two Traits Separate Elite AI Teams From Everyone Else?
Tim: For sure. But I mean, just to extend that analogy, today you could define it and have a team of agents go do that. There’s an argument like, “Okay, so that means you just need more senior people who know how to do that.” But then, we also hear like, “Well, no, we don’t just need these ‘later-in-career people’ with all this experience.'” That’s great. You do need that. But sometimes the earlier-in-career people who were born in AI. They know how to do this, and we need more of that, just like, “This is a new world, and it’s completely my first language.”
So that’s maybe another form of diversity on the engineering team is like people that were really AI-native and maybe don’t have that experience, but really know how to use these tools. And then, there’s, of course, the, “Hey, I know how to build software and manage a team and now that team is part people and part agents.” How do you think about that and getting the right mix on the team, Craig?
Craig: It’s really interesting because it’s like I look across and I won’t constrain my attention here to just engineering, right?
Tim: Yeah, thank you. Yes, absolutely.
Craig: I look at my recruiter at Stacklok and the work he does. I used to think he was just a great recruiter. He would go and source fantastic candidates, build relationships, and do a lot of things. He is now able to do that job. He was massively outperforming in the recruiting context. And so he has taken his curiosity and has led him to other areas. He is now very effective in operating in our sales organization because a lot of the work that he did translates over. He has access to new tools, so he’s constantly able to build agents and run them. And he started to self-identify almost as a developer himself. He’s not writing code, but he is building agents, and those agents are creating value in a lot of different domains.
“You absolutely have to have the depth of talent to have taste … The thing that’s really valuable is the ontology that is constructed, the views that are used to generate the code, because the code can always be regenerated from the ontology. You’ve got to know what good looks like.” — Craig McLuckie
I think you absolutely have to have the depth of talent to have taste. When you’re thinking about like, “Where is the IP, where’s the value?” It is obviously encapsulated or expressed in the code, but the thing that’s really valuable is the ontology that is constructed, the views that are used to generate the code, because the code can always be regenerated from the ontology.
Joe: You’ve got to know what good looks like.
Craig: You’ve got to know what good looks like. That taste, that sensibilities, the instincts that these agentic systems don’t necessarily demonstrate now, they may over time, but they don’t have it now. So you really need that depth in your engineering organization, and you are able to start scaling that out relatively quickly. And I think the other piece you need is this kind of curiosity that comes with that generalist mindset, this willingness to be unfettered in terms of how to think about value creation, being willing to challenge the boundaries of your role, the boundaries of conventional wisdom.
And so I think you do need to bring those two capabilities together, and you need great teams are going to have the right mix of both taste and sophistication, but also that exuberant curiosity and willingness to challenge, that innovative flair. And it doesn’t have to be constrained to any one function. I think the thing that’s surprising me the most is just how versatile some people are when they have access to this class of tools.
Tim: Well, thank you both so much. This has been such a great conversation. I mean, from where I sit, this challenge of whether it’s Madrona, whether it’s an enterprise, whether it’s startups we talk about, we want our teams and our people to deploy AI agents to use it, to lean into AI every way they can use to make their job more efficient, more productive or even more enjoyable, but how do you do it safely? How do you do it securely? You two are a dream team. It’s fun to see you working together again, addressing this really critical problem, and also just these lessons learned and things you accomplished in the past, how there are some good things there, but also now it’s different in how we are adopting, just like the rest of the world is, to move super quickly to build a great business by helping customers. So thank you both very much.
Craig: Hey, thanks for having us.
Joe: Thank you, and thanks for being part of the journey, Tim. It’s always great to work with you.
Related Insights
