Craig McLuckie on Culture as a Team's Operating System in the AI Era

Transcript

Introductions [00:56]

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Craig McLuckie. My normal starting point with these conversations is, who's Craig?

Craig McLuckie: All right, so my name is Craig McLuckie, I'm the founder and CEO of a startup called Stacklok. By way of background, I've spent most of my life in enterprise technology. I think I had most of the early career impact when I moved to Google, where I got to work on what eventually became Google Compute Engine. Myself and Joe Beda were the product leads that brought that infrastructure as a service capability that Google brought to the market. And then we came up with this crazy idea along with this another engineer called Brendan Burns to build what became Kubernetes. You know, everyone was trying to fit the puzzle pieces together with Linux application containers, and we thought we had the puzzle box. And so we created that open-source project which has obviously been quite successful subsequently.

And I was also privileged enough to be able to participate in the bootstrapping and early leadership of the Cloud Native Computing Foundation as a way to bring together a community not only in support of Kubernetes, but to create innovation more broadly in the space. I started my first startup shortly after I left Google, which I ended up selling to VMware where I was responsible for the Tanzu portfolio, which is VMware's cloud native applications, and spent some time there and really enjoyed my time at VMware. And then I decided to do the crazy thing and have another attempt at building a startup, which is what I'm currently working on with Stacklok.

What Makes Open Source Communities Special [02:21]

Shane Hastie: What's different, special about open source communities?

Craig McLuckie: The thing that's wonderful about open source is that an open source community is a way for people to come together and work on a technology that they care about not for money but for love, right? It's a way that, you know, I think engineers in their souls like to create things and there's this wonderful characteristic that I think a lot of engineers share, which is they want to create something useful and they like to see it being used by other people. And open source communities are the most pure expression of that capability. A lot of people look at open source, you know, there's obviously business reasons to do open source, it's a wonderful way to create technology that is vendor agnostic, there's a lot of other attributes to open source. But I think the thing that I like the most about open source is that it really is a way for people to bring their creativity, their sort of engineering staples to work on something that they love and care about that's going to see tremendous use in a broad sense, and it is the purest expression of that kind of engineering joy as far as I'm concerned.

AI's Impact on Open Source Dynamics [03:27]

Shane Hastie: What's changing in the open source communities today with the advent of generative AI?

Craig McLuckie: It's tough out there, I'll be completely honest. And it's I think, you know, what's happening in the open source community is a sort of echo of what we're seeing inside, you know, mainstream organizations. But it's been extremely challenging recently. You know, when you think about open source community dynamics, it's effectively the collaboration of a community of the willing. A set of people that show up, do work, work together, you know, build relationship, have a connection, contribute. And it's a great environment in which young engineers that want to work on more interesting or complex things than they're necessarily being assigned to at work can really let their creative juices out. And they can get access to very rich and sophisticated mentorship that exists outside of their existing organizational structures. And I think that's been one of the most wonderful aspects of open source is that it's not just a side project, it's a way to access different people, different skills, different capabilities to work on problems that you think are enriching for you as an engineer and to actually progress your own journey as an engineer.

And one of the things that we're seeing that's become incredibly problematic for open source communities is the introduction of coding AI. You know, an example of something that, you know, I think this is a pretty common pattern, but we were historically really looked to welcome in additional engineers. And so we'd go through and carefully with thought triage the set of issues that the community is dealing with. We would deliberately not go and fix a lot of the low hanging fruit, we'd mark those as good first issues, and we'd leave them out there to tantalize early career developers or other people that might want to participate. You know, the set of things that would allow them to learn the project, cut their teeth on what's being developed.

And unfortunately, we are now just overwhelmed. You know, every time we do that, within a day there'll be dozens of submissions of these slop AI generated PRs that ostensibly fix the issue, but not in a way that's consistent with the community's work. And so it's created this tension where the maintainers of the project accept that a big part of being part of the community is reviewing other people's code. Now what they're finding is that they're just reviewing AI generated slop code that they're trying to harden. And it could be code that they've set up an agent to build for themselves, or it could be code that someone else has set up and hasn't necessarily gone through the process of optimizing their own prompts and building skills, and at least attempting to make the code consistent with the project.

And that tension is significant. It's definitely putting a lot of pressure on open source dynamics. And I think there's another tension here which is pretty obvious, which is, you know, a lot of the open source communities that we're used to are built around, you know, relatively static structured systems, you know, the NPM ecosystem is something that a lot of developers use. And it is certainly people are starting to ask questions like how relevant is this composable system when code is becoming increasingly cheap, and even good code is becoming increasingly cheap to generate. Like, are those existing structures going to hold in this new world where perhaps code becomes something like an intermediate language, and most of the IP creation happens in that sort of requirements gathering and defining and prompt generation sphere. So, it's a very new world out there and people are definitely struggling to adjust to the new realities of how these tools are changing the way they work.

AI Adoption and Organisational Culture [06:49]

Shane Hastie: That's on the open source space. Coming closer in, within organizations, this is the Engineering Culture podcast, what is the adoption of generative AI, what's the impact that having on organization culture?

Craig McLuckie: You know, it's all over the map. And I think a lot of it depends on the organization's maturity, right? Like you could think of organizations as having maturity across a lot of different dimensions. You know, there's the operational maturity of the organization, how much structure and rigor does the organization have, how well do they define and manage their internal practices and processes, and so that's one maturity dimension. There's a cultural maturity dimension that organizations have, around is the organization set up for success in terms of being able to engage and support people with a lot of different profiles, like embrace an authenticity, like an authentically diverse set of people and create an environment in which they can do their best work.

And what we're starting to see is this new dimension, which is the sort of AI maturity dimension. And what I've seen as a starting point, and I'd love to hear if this is something you're seeing as well as you talk to folks like myself, but there's this huge challenge that's emerging where these AI tools become a part of the developers' day-to-day lifecycle. They're fantastically productive, they behave effectively like an intern that's incredibly enthusiastic, but not necessarily very wise. And you can set them on any task and they'll produce something, and that something may or may not be good. And so I think every individual engineer is having to start to self-identify almost as a manager, right? Like they love writing code, but they realize that, you know, in some ways the most productive way for them to work is not to necessarily write the code themselves, it's to review the product that someone else has, and provide constant direction.

So they basically find themselves effectively being a micromanager, and that's creating a certain fatigue, you know, just an emotional fatigue on engineers. Like you want to create, you're trying to kind of scratch this itch to generate something that's wonderful. The thing that you've got used to historically is actually doing that with your own hands and actually being in there and understanding it and the joy of that. And now you're finding your day-to-day work being more about scrutinizing these systems, and that's what you're doing for yourself.

The Problem With Unfettered AI Tool Deployment [09:00]

The problem is, you know, in immature organizations where you don't have enough structure in terms of the operational maturity, particularly as it relates to AI, I see a lot of situations where there's not a lot of wisdom being demonstrated. So an engineer will vibe code up something which is a 3000, 4000 line PR, you know, submitted to someone else, and effectively put the onus on someone else in their team to do the work of actually micromanaging that agent. And it creates a tremendous amount of tension, you know, as a starting point. Unfettered deployment of these tools doesn't necessarily drive productivity, it certainly drives the amount of code that's being submitted as PRs. But when I actually start looking at the rate at which features are being burned down, unless you create a lot more structure and you up your maturity in terms of the process, if you can't reinforce your kind of core cultural anchors and start to drive awareness of how to use these tools, it can cause trouble for teams and it can create a lot of friction and discontent in the early stages of adoption.

More Code, More Bugs [09:57]

Shane Hastie: One of the numbers that I've seen was 300% more code being produced, 400% more bugs.

Craig McLuckie: Yes, something like that. I always joke that the only thing that we're seeing growing faster than AI code agent adoption is AI code agent introduced exploits in production environments. It is definitely a little, it's a little wild out there.

The Return of the Giant Pull Request [10:18]

Shane Hastie: You mentioned the 3,000 line pull request. We've been working for the last 20 years, 30, 40 years, to make our pull requests smaller and smaller and smaller, and suddenly we've got this explosion.

Craig McLuckie: I've thought about this a fair bit. Certainly a lot of the engineers that I've interacted with where it's like, why are you suddenly producing the 3000 line pull request? We like to think that the thing that people have been trained around is the kind of granularity of the implementation, right? Like the atomicity of a piece of work. But I actually think what people tend to think about more is the amount of time they spend on something. Right, so like, you know, there's almost this sort of subroutine that runs in people's minds around like, okay, I've got used to working in a quanta of, you know, some number of hours to days to get to a point where something is at a point. And now, you know, I have these tools that can just produce a lot more, so I think that's part of it.

And I think another part of it is just there's a lot of urgency that I'm seeing being introduced, particularly, you know, this may not be true in all organizations, but there's a lot of urgency to demonstrate fluency in the use of these tools. There's a lot of almost counterintuitive incentive structures where people are being like, hey, I've seen organizations embrace heuristics around code generation as being almost a performance metric, and so it gets back to the Bill Gates quote around measuring productivity by lines of code is like measuring the value of an aircraft by its weight. These things are not equivalent. And so, I don't know the full answer, but I have to suspect that it's an interesting intersection of features, but also possibly an indicator that there's other maturity dimensions that the team needs to improve upon.

Designing a Deliberate Team Culture [11:52]

Shane Hastie: How do we design a deliberate culture in today's environment, and what does a deliberate culture look like?

Craig McLuckie: Yes, I mean it's something I obsess about, right? I tend to think of culture as the operating system of a team. And a lot of people are kind of dismissive of this nominal idea of culture as like the, it's the thing that HR writes on the sheet and there's five points on a poster and a bunch of people jumping with their hands in the air, and it's plastered all over the hallways, right? That's not culture. Culture is the operating system of a team. It defines how the team processes information, and it is intended to establish a set of commonalities. I truly believe the best teams have very high levels of diversity. I'm not a fan of trying to create this sort of self-replicating entity where every person in the organization is effectively bringing the same strengths and weaknesses to bear. Like a team should be a diverse entity. But culture effectively is the common core. It's a set of things that you can always revert to. It's effectively the core principles that should be tuned for the set of activities that the team is pursuing.

So I don't think it's a one-size-fits-all story, you know. I think there's some organizations that have created a culture that is able to span different domains. People like Amazon have a very interesting and novel culture. But I do think the culture needs to be tuned to what you're trying to accomplish, and it needs to be balanced for the set of constraints that the team has in terms of what resources are available, etc. And so for me, I think the starting point, especially with a new team, is I do an exercise where I start to kind of interview people, especially if it's a team that you're inheriting, and you want to kind of understand the culture. And try to distill out a set of kind of core ideals that they believe is significant and is important to them, but is also important to the mission at hand.

What I'll tend to do when I'm trying to kind of get to that point is just go and identify the things that people really care about, and that are objectively and intellectually important to the mission at hand. You know, if you're in a security domain, operating with precision and care and thoughtfulness, being paranoid, you know, there's a set of these markers that are necessary for where you are. If you're in a startup, urgency, bias to action, etc., are really important. And so starting to identify those markers and then I like to do a distillation of those down to just like a handful, four or five kind of core elements that then become kind of what I think of as the sort of deliberate culture anchors.

Reinforcing Culture Through Decisions and Promotions [14:17]

And once you've established that, there's a set of things that you as a leader need to do. You need to talk about it constantly, right? Like you need to talk about it when you're interviewing people, you need to make sure that the interview process makes allowances for this because basically what you're saying is "our culture describes how we assess people as being a good addition and a creative addition to the team". People can certainly learn culture, but the culture should reflect the nature of the team in some ways and a lot of that just can't be learned. So it becomes an anchor for describing who gets into the team. When you're looking at the promotion process, it should always tie back to the specifics of that culture, right? You know, a lot of organizations that are going through engineering promotion activities will have a set of levels. This is what an SWE1, this is what a SWE2 does, this is what a senior SWE does, this is what a staff SWE does, etc. And make sure that those are effectively tied into the culture.

And then the final piece of it, and this is something I really like to do, is play back decisions that you have to make through the culture. You know, when you have a hard decision that you have to make and it's not necessarily obvious, being able to relate that decision to the cultural markers or the cultural anchors that you've described for your organization is a way to constantly reinforce the culture. And then the final piece of it is reassess. You know, I always say this, but hypocrisy is the culture killer. If your team sees you behaving in a way that is incompatible with the culture, your culture is dead. And so when you encounter those situations, you have a hard choice to make. You either need to not do that, or you need to accept that your culture is not supporting the mission at hand, and you need to deliberately change that, and you need to go back to the team and say, the culture demands that I do this.

Evolving Culture Without Hypocrisy [15:55]

And you can't do this on a daily basis, you know, you can't churn this. But like, you know, when you get to a point where it's like, I have to do this, I had openness as a core cultural element, but we're just getting crucified, you know, for whatever reasons, we need to focus on a proprietary thing, there's these business justifications. We're going to go this way. We're not just going to go this way, but we're going to go back and update the culture and actually communicate that because the business imperatives have changed, we need to make sure that we reflect that in the sort of cultural piece. So it needs to evolve, and culture will have bugs. It has to be this weird intersection of intelligent design and evolutionary pressures, and you'll never get it right just out of the gate.

Implicit vs Explicit Culture [16:34]

Shane Hastie: Evolving cultures and being deliberate in that evolution, that takes a lot of awareness for the individual and the organization.

Craig McLuckie: Yes, it does. And it's interesting, and I like to think of myself as a pragmatist, right? I'm not going to try to fit everything that you're doing into these kind of cultural anchors, right? This cannot be procedural. The culture is the total operating system. Some companies have got closer to being able to describe culture as a procedural blueprint. Again, Amazon. I am so impressed with what Bezos did in terms of creating a culture that's self-replicating, creates value in a lot of different domains, has an incredible scaling apparatus. It's not personally a culture that I could live or manage in, but gosh, I can respect it, right? And I can admire it as a student of these things, it's something that you have to be respectful of. But it doesn't necessarily work for me or the kind of work that I do. So the way I tend to think about this just kind of making it real is that there's sort of implicit and explicit culture. There's the implicit culture, which is what the team is doing, and then there's the explicit culture, which is what you're saying the culture is. And it's very difficult to have total coverage of everything you're doing with your explicit culture. It's difficult to say that every decision down to which bug do I fix can kind of be tied back to culture. The thing that you can do is make sure that your explicit culture and your implicit culture are always compatible. Like there's nothing that's being done implicitly that is contrary to the explicit culture.

The CEO's Three Responsibilities [18:04]

And so back to the thing like, boy, that requires a lot of work. Yes, it does. You know, as a CEO, I think of my job as being really grounded in three things. And this is something I borrowed from another podcast I heard, so it's not original thought. I can't remember who it was, I'd love to attribute it, but I'm just repeating back something that stuck with me in my earlier journey. But I heard a CEO say this, and it was just like, holy shit, that's exactly right.

One, I set the culture of the organization. Two, I actually set the strategy of the organization. I basically say this is the domain, this is how we're going to approach things. And three is I find leaders that can execute the strategy within the parameters of the culture that I defined. And of the three things I do, culture is generally the most important and the least well understood, because it really is a top-down thing. And so I think to make it work, you have to make sure that the leadership of the organization understands that culture is critical to the success of an organization. The difference between a mediocre company and a great company is the strength of the culture. And that doesn't have to be one thing. There's a lot of great cultures out there. There's a lot of cultures that work really well. Even the ones I dislike, if it's a good culture to solve the problem at hand, you kind of have to respect it as a system. You may not just agree with it or want to embrace it for your own uses.

Career Journeys in the AI Era [19:18]

Shane Hastie: A lot of food for thought there. Circling back, you touched briefly on promotion and career. What's happening with career journeys today?

Craig McLuckie: You know, it's interesting, and it's a cause of sleepless nights for me, because there's two sides to this. There's a good side and a bad side, right? Like there's a light on the horizon and then there's a really complex thing. And I'm talking about this specifically for engineers, and I think it applies to other domains as well. AI is obviously changing the game. Providing access to this oracle that has access to the totality of human knowledge, synthesized down into embeddings that can then be accessed at a moment's notice is definitely changing things.

The thing that scares me the most is that that classic path that an engineer takes, where to be a great engineer, it's not like you just show up and write code. You have to take the time to write code, and in writing the code you start to understand the systems. In understanding the systems, you understand not just the distributed systems, but you also start to understand the processes. You understand how teams work. You understand how organizations fit together. You have opportunities to explore the boundaries between teams. You can start to see how APIs become necessary, but to work well in an organization you have to combine both the contract which is effectively the API with the relationship so that you can do things.

Like, there's a path for someone to go from a student to a distinguished engineer on this somewhat linear path of incremental ownership. And a lot of the challenge we face is obvious, which is a lot of the tasks that we would assign individuals earlier in their career are being displaced. They no longer have a lot of people earlier in their career writing unit tests, or fixing bugs, or doing some of the stuff that occupied their attention before they started getting into distributed systems design, and reasoning about the more complex parts of the system, and building at bigger scale.

And I think what's really interesting, and this is something I don't know where this goes, because those earlier career people, they have a lot of advantages in that they have access to this incredible corpus of human knowledge at a moment's notice. And also there's a set of new skills that are necessary to use that in its optimal way. But I don't know how you go from where people are starting right now to being experts in at-scale distributed systems design along this alternative career arc. And so I think it's definitely something that we need to think about.

And I wish I knew the answer, because I just don't. I think what I do know is that the engineering role is changing, value creation is happening at a different layer, code is moving more towards something that feels like an intermediate language, the way that engineering value creation is happening is more about assessment and almost risk mitigation, you know, making sure these things don't do anything stupid. The profile of person who's going to be best at that is maybe not the people that we've trained in college, the education system that we have may not support this. So the world is definitely in flux, and I don't have a good map for where it's going to end up, but I certainly think about it a lot.

Advice for New Team Leads [22:19]

Shane Hastie: What's your advice for the reasonably new team lead, technical lead looking at how do they support their teams and looking to the future?

Craig McLuckie: Right now, there's a few things that I would kind of advise. Let's say you're a relatively early career team lead, and you now have a team of engineers, and I assume you have access to tools, Copilot, Cursor, Claude Code, you know, what have you. And you're trying to think about, you know, where you want to go. I think the starting point is recognizing that if you yourself are not an expert in understanding these systems, you're not going to be able to serve your team. And the temptation to start to rely more on these tools to do the work is going to be constantly there. I think one of the biggest challenges every new lead faces is that they always think that they could just do the work themselves. At the end of the day, stuff gets weird, generally the people that make it into that early lead role are some of the best engineers, the best line engineers, they've still got those muscles.

And they are now in this interesting situation where they have to balance two things. They have to balance understanding these tools and where value creation happens without displacing and alienating their team. That's a very important balancing act to maintain. You can't be in a situation where it's like, wow, I have access to Claude Code, I can set up four agents, I can come up with an idea, I can get something that's, you know, close enough to being hardened, I can go harden it myself. What am I doing with these people? I don't know, they're probably doing something. That's a failure mode. Because what you really need to be doing is supporting them through that process, and so I think the first thing you have to do is hold on to the notion that your role is to drive the productivity of other people, and not fall into just doing a lot more work, and treating your AI teammate as being a priority over your other teammates because they're more responsive and they do good work. At the end of the day, you have to balance actually spending time with the tools to understand them, and understand how they work, so that you can mentor your team, and actually be an AI maximalist yourself in your own approach. With maintaining that identity that your job is not to produce the work yourself, it's to support your team in producing the work product and scaling that.

Ownership, Guardrails, and Letting Go [24:33]

The other thing that's really important is to start to maintain the culture of the team. To sort of emphasize that while we have new tools, our responsibilities are largely the same. It's not okay to produce something, and then push it up the chain to me to turn your AI coded slop into quality code. Everyone has to own everything they do. Doesn't matter whether it's a coding agent that produced it or something else, at the end of the day, you need to feel full ownership of that before you put it on to someone else.

So you don't generate that kind of fatigue I talked about earlier around having to spend your life coding and then assessing the output of coding agents and then assessing the output of someone else's coding agent because they're too lazy to do it themselves. I think that sort of constant reinforcement is good. And then the final thing I think, which is harder, is there's this letting go that has to happen. There is an incredible opportunity here. Like the rules are different. The unit economics of work are different. The set of challenges your team can face are different. Like once you cross the threshold of being able to actually use these tools in a certain way, set up the appropriate guardrails, you constantly have to challenge yourself like, hey, maybe we can do a lot more. Maybe the things that we've learned in terms of our operating cadence are not there. Maybe we can actually produce something in a lot more efficient way if we let go of some of those assumptions.

Building Agentic Systems — Lawn Mowers, Not Autopilots [25:52]

But I think probably the biggest assumption and the most significant assumption that people have to let go is when you're actually building agents themselves, when you're trying to create these things, the existing rules of traditional systems and imperative systems that everyone is used to are different. You're dealing with stochastic systems, and you have to spend enough time with them, you have to learn what works, what doesn't, before you can start to actually generate value. And that generally comes on the back of a lot of experimentation.

People are not going to work into this and just say, oh, it's three lines and boxes, a database, we'll stitch them together, make it work, and then we'll figure out how to make it scale, we'll kind of make it functionally complete. That's not how agentic systems work. And you have to learn that the hard way by doing, and make sure that you're not assuming that, hey, I could just design it and it will work. You've actually got to go through the hands-on. I always think of agents as more like lawn mowers than anything else. Like you have to constantly push them to do work, and over time they may be converted to a ride-on lawnmower if you build up enough expertise and competence in your space.

Where to Find Craig [26:52]

Shane Hastie: Great, a lot of food for thought there. If people want to continue the conversation, where can they find you?

Craig McLuckie: Oh, you can find me on LinkedIn, under Craig McLuckie. I don't know how many there are, but I'll probably be the top one that comes up.

Shane Hastie: Thanks so much for taking the time to talk to us today.

Craig McLuckie: Thanks for having me on. It's been great.

Mentioned:

• Craig McLuckie on LinkedIn