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

Speaker A: The decisions you're making right now about AI adoption, architecture trade offs and how your team works together will shape your systems for years. Getting those calls right when the landscape is shifting this Fast is hard. QCON San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems. This November 16th through 2060 plus speakers across 12 tracks will share what's actually working in production and what isn't. No hidden product pictures, just senior practitioners helping senior practitioners learn more@qconsf.com. Good day, folks. This is Shane Hasty for the MCOQ Engine Engineering Culture podcast. Today I'm sitting down with Craig McLuckie. My normal starting point with these conversations is who's Craig?

Speaker B: All right, so my name is Craig McLuckie. I'm the founder and CEO of a startup called Stacklog. By way of background, I've spent most of my life in enterprise technology. I think I had most of the kind of early career impact when I moved to Google, where I got to work on what eventually became Google Compute Engine. Myself and Joe Beta 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 is obviously 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 M 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 stackclock.

Speaker A: What's different special about open source communities?

Speaker B: 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. Uh, it's a way that 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 the 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.

Speaker A: What's changing in the open source communities today with the advent of, uh, generative AI?

Speaker B: It's tough out there, I'll be completely honest. And I think what's happening in the open source community is a, uh, sort of echo of what we're seeing inside mainstream organizations. But it's been extremely challenging recently. 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, 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 those creative juices out and they can get access to very rich and sophisticated mentorship that exists outside of the 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, uh, you know, an example of something that, you know, I think this is a pretty common pattern, but we would historically really look 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, uh, 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 a lot of the open source communities that we are used to are built around relatively static, structured systems. The NPM ecosystem is something that a lot of developers use, and it is certainly people also 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? Uh, you know, 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.

Speaker A: That's on the open source space. Coming closer within organizations. This is the engineering culture podcast. What is the adoption of generative AI? Uh, what's the impact that having on organization culture?

Speaker B: It's all over the map and I think a lot of it depends on the organization's maturity. You could think of organizations as having maturity across a lot of different dimensions. 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, embrace, uh, an authentically diverse set of people and create an environment which 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 would 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 developer's day to day life cycle. 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 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 as effectively being a micromanager. And that's creating a certain fatigue, just uh, 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 is 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 3,000, 4,000 line PR, submit it to someone else and effectively put the onus on someone else in their team to do the work of actually micromanaging that agent. And uh, it creates a tremendous amount of tension 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. It can create a lot of friction and discontent. In the early Stages of adoption.

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

Speaker B: Yeah, something like that. I always joke that, uh, 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.

Speaker A: Yeah. 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 got this explosion.

Speaker B: 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, uh, the thing that people have been trained around is the kind of granularity of the implementation, 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're spending on something. Right. So there's almost this sort of subroutine that runs in people's mind around like, okay, I've got used to working in a quanta of some number of hours to days to get to a point where something is at a point. And now I have these tools that can just produce a lot more. So I think that's part of it. I think another part of it is just there's a lot of urgency that I'm seeing being introduced. Particularly, uh, 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 co 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.

Speaker A: How do we design a deliberate culture in today's environment? And what does a deliberate culture look like?

Speaker B: Yeah, I mean, it's something I obsess about.

Speaker A: Right.

Speaker B: 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. 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. I think there's some organizations that have create 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 resource available, et cetera. 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 um, 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. If you're in a security domain, operating with precision and care and thoughtfulness, being paranoid, there's a set of these markers that are necessary for where you are if you're in a startup urgency, bias to action, et cetera are really important. And so starting to identify those markers and then I like to do a distillation of those down to just a handful, four or five core elements that then become kind of what I think of as the sort of deliberate culture anchors. 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, you need to talk about it when you're Interviewing people. You need to make sure that the interview processes make allowances for this. Because basically what you're saying is our culture describes how we assess people as being good addition and accretive 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 kind of promotion activities will have a set of levels. This is what a suite one, this is what a suite two does. This is what a, uh, senior suite does, this is what a staff suite does, et cetera, and make sure that they are effective ties in to the culture. And then the final piece of it, and, uh, this is something I really like to do, is play back decisions that you have to make through the culture. 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. I think 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. You need to go back to the team and say, the culture demands that I do this, and you can't do this on a daily basis. You can't churn this. But 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. 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 cultural piece. It needs to evolve and the 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.

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

Speaker B: Yeah, 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. Uh, 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'm 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 incredible scaling apparatus. It's not personally a culture that I could live or manage in, but, uh, gosh, I can respect it. Right. And I'd admire it. And 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 are you 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. And so back to the thing like, boy, that requires a lot of work.

Speaker A: Yes, it does.

Speaker B: You know, as a CEO, I think of my job as being really grounded in three things. And, uh, 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, I'm repeating back something that stuck with me in my earlier, I don't know, 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 was actually set the strategy of the organization. I basically say this is the domain. This is how we can approach things. And three is, uh, I find leaders that can execute the strategy within the parameters of the culture that I find. 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, um, 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.

Speaker A: A lot of food for thought there. Second back, you touched briefly on um, promotion and career. What's happening with career journeys today.

Speaker B: 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 classic path that an engineer takes, where to be a great engineer. It's not like you just show up and you 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, uh, 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 API, with relationships so that you can do things like there's a path for someone to go from a, uh, 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 early 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, uh, of the system and building it at bigger scale. And I think what's really interesting, and this is something, I don't know where this goes because those early accrued 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, like making sure these things don't do anything stupid. The profile, the person who's going to be best at that is maybe not the people that we've trained in college. The education system we have may not support this. So the world is definitely in flux and uh, I don't have a good map for where it's going to end up, but I certainly think about it a lot.

Speaker A: 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 right now there's a

Speaker B: few things that I would kind of advise. You know, like 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, cloud code, what have you, and you're trying to think about 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 the situation where it's like, wow, I have access to Claude code. I get a set of four agents. I can come up with an idea, I can get something that's close enough to being hardened, and I can go harden myself. Uh, 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, uh, priority of 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. 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, right? Like, 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 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 assess 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. 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. 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, uh, I always think of agents are more like lawnmowers than anything else. You have to constantly push them to do work, and over time they may be converted to ride on lawnmower. If you build up enough expertise and competence in your space.

Speaker A: A lot of food for thought there's. If people want to continue the conversation, where can they find you?

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

Speaker A: Thanks so much for taking the time to talk to us today.

Speaker B: Thanks for having me on. It's been great.

Speaker A: Sam.