Mindful Leadership in the Age of AI

Transcript

Introduction [00:37]

Thomas Betts: Hello, and welcome to The InfoQ Podcast. I’m Thomas Betts. Today, I’m speaking with Sam McAfee. Sam is a Silicon Valley veteran with over 25 years of experience leading technology organizations, working with everyone from global companies to startups. Sam is the author of Startup Patterns the book, and founder of Startup Patterns the company, a leadership and strategy firm helping founders and executives build resilient, high-performing organizations. He’s also the co-founder of Humanize, an AI-powered leadership platform. Sam’s expertise blends modern product development, mindful leadership, and organizational transformation.

Sam, welcome to The InfoQ Podcast.

Sam McAfee: Thanks for having me. Very excited.

Thomas Betts: Let’s start with that, that your bio covered a bunch of stuff, but what do you do, Sam? When are you typically brought in to work with an organization, and what are the goals?

Sam McAfee: Typically, I don’t get brought in on day one. I have a lot of experience with early stage startups and go-to-market strategy from the old days. But in more recent times, I usually get brought in after there’s been some success and things are growing, and that’s causing a lot of stuff to break, and so it’s when the stuff… You could call maybe day two. When the stuff that used to work, now, because of our success, is starting to crack in the foundation, for a variety of reasons, is usually when I get brought in.

Startup vs. Enterprise: Why Big Companies Struggle to Innovate [02:04]

Thomas Betts: Yes. The idea of what got us here isn’t going to get us there. It’s that pivot point that a lot of startups and even organizations that are working on an MVP, any new product, you go from, well, we had this project mindset, get this thing off the ground, get the MVP out there. A few customers start using it, and then you need to scale, and it’s a different process you need to go through from build the first to build the nth one of those. What are some of the barriers that you see in the industry during that transition, and is there anything new coming out in this age of AI?

Sam McAfee: I really appreciate that you pointed out it happens in bigger companies as well, when they’re trying to build something new. We, as an industry, know a lot about how startups should work these days. My book is about 10 years old, and it certainly wasn’t the first. There’s a lot of best practice out there, most of which orients around an experimental mindset that in the old days we built everything all at once and launched it during the dot-com boom, which is where I came up into technology. Those were the days of big design upfront and launches, and either it passed or failed. Usually, failed.

Of course, we’ve been using iterative development for a long time, and Agile reflects that in the Lean Startup, which basically forms the foundation of what we would think of as modern product management. Involves lots of experiments, lots of talking to customers, lots of building things that might not scale at first until you can validate that your idea has merit. That it’s something people want to buy. That it actually does the thing you think it does. That spirit is there, and I think a lot of startups these days, I’m finding, do it pretty well. I’ve definitely been part of a lot of initiatives where a large organization that has had some success in one market is trying to pursue a new product or a new revenue stream maybe in the same market, maybe in an adjacent market.

I definitely did a lot of consulting myself and with a lot of colleagues over the years, trying to teach those large organizations how to play startup again, how to form a team that can build something in the way that I just described for startups. And what we found in those days, and this is still largely true, is that the organization structures and processes and even culture that make it work really well at scale get in the way when they’re trying to build something new. There can be a lot of friction between the new and the old, and so companies have struggled to support and protect a new initiative. Whether it’s in an incubator or a lab or just a team that’s spun off, they have a hard time leading them in a way that would be effective for a startup project or product or service or revenue stream when they’re totally tooled to operate and keep the lights on, business as usual, which is a really different style of leadership, of process, all that sort of stuff. So yes, we see that a lot.

Thomas Betts: Yes. I talked about it as a go from day zero to day one to day two, like we have to get to that new thing. We have to scale up. You’re almost talking about cycling back and having that, we need to stop doing what we are now if we’re a big company that’s successful, and we’re doing all these things to support our legacy software. But to do something new, you can’t necessarily start from where you’re at right now. You have to think differently. And you’re saying that doesn’t always fit into a large organization mindset.

Sam McAfee: Absolutely. At so many different levels, too. In terms of investment, many large companies that are pushed to innovate, they don’t even think in economic terms that are small enough, right? You’ll sometimes see these portfolios where it’s like, hey, if it’s not a billion dollar project, we don’t even want to bother, right? I’ve worked with some of the larger organizations in the world, and when they think about funding things, it’s like these very large numbers, so it’s difficult for them to think in terms of small, early stage stuff.

I think in large measure, there’s probably more buying of innovation at that level. There are some orgs that I think still do try to innovate. We certainly saw a lot of it in the previous decade around everybody had an innovation lab. I mean, they all sort of still do, kind of. But I think it’s much more common for large orgs to admit the fact that they don’t know how to build like a startup, and they’ll usually go and do it through acquisition, through M&A is kind of the main way. But those practices we were describing, they are slowly getting absorbed into larger organizations as well, bit by bit, and I try to help that happen sometimes.

The AI Pressure Wave: Innovation or Mandate? [07:08]

Thomas Betts: I tacked on at the end there the, is anything changing with AI? I think where I see this, to your example, is the we need to add AI to our products so we look innovative, and they aren’t set up to do that. These companies haven’t been doing AI development. And if they think of it as just software, but they don’t recognize it’s different, it’s still only… Things won’t necessarily work the same way. Or they have new security policies they have to go through because you have to make sure these agents aren’t running amuck. What else do you see coming up as a barrier to adopting that innovation mindset?

Sam McAfee: There are two aspects in my mind to AI’s impact on our software development world. One is building AI capabilities into our offers, our products, our services, which has a whole bunch of implications. The other is how it actually affects our tooling and how we build those systems themselves. Those are two different, certainly overlapping topics. I think the first one is a little easier to cover, and we’ll probably spend a lot more time on the second aspect.

The first one is very much similar to every other trend that’s come along. I’ve been around long enough to remember Web 1.0, everyone needs a website, then everyone needed a mobile app, then everyone needed to be in the cloud, and then everyone needed to figure out this blockchain thing. Despite the shrill hysterics that this AI boom changes everything, there are ways in which those of us who’ve been in the game for a little while recognize these patterns. And so, when companies are rushing to offer something with AI in it… We’ve seen this. There’s a chatbot in every single application we use now, and there’s all sorts of generative capabilities. Some of which are very cool. Some of which are useful and have value. It’s great.

But it’s that same gold rush mentality. Or actually, not always really gold rush. But a good buddy and colleague of mine, Rich Mironov, an author of product management books and really smart guy, said to me recently that he coaches a lot of chief product officers. He said every chief product officer he’s spoken to in the last year is either desperately trying to launch something with AI in it because they were told to by the board or has been fired for not doing it, right? I mean, it’s clear that there’s a little bit of Wall Street, headline-driven, you must produce with AI. So, we know that’s happening.

I think that the simple answer is it’s like every other aspect of product development. You have to start with the customer and what value are they getting from the introduction of this technology. To this day, despite 25 or 30 years of Agile, however you calculate it, and at least 15 of Lean Startup, it’s still not that common and most organizations start with the customer, shockingly. But it’s true. And so, I think that people just are under a lot of pressure to compete in the market, naturally. That’s the world we live in right now. “Hey, we have to get ahead of this AI thing”, is a phrase that comes down from the board or from the CEO, and so there’s a lot of downward pressure from the organization to put AI into the product somehow or build a new AI product of some kind.

That’s where leaders in technology, heads of engineering, heads of product, people at the mid to senior level really need to be careful to push back a little bit or at least slow the process down because those products are still only going to be successful if they are meeting a real felt need by a customer that pays the bills, that will pay for a service. A lot of the AI explosion that we’ve seen, I would say some healthy amount of it does not yet do that or has not yet proven its value, right? Having a chat in everything. Or, “Oh, can I help you write that letter or that piece of copy?” everywhere you go might not necessarily be the most useful thing.

But of course there is a lot of value to it. Just it’s our job to validate with paying customers that this feature we want to build actually is something that they want. So, I think that first aspect is very much like every other technology shift where there’s pressure to ship something that satisfies it, and we have to think about the same best practices that many of us have been trying to follow still apply with AI in the product.

Experiments, Failure, and the Misunderstood Heart of Agile [12:03]

Thomas Betts: Yes. I think if we go back to when you said back in the early web days, build the whole product or get the whole thing shipped. It’s shrink-wrapped software. You get one shot, and it’s done, and it’s out the door. You had to do that somewhat because of delivery mechanisms, but now we can release hundreds of times a day, so we can constantly be updating our software. I think some companies, there was always that struggle like, “Oh, we need to be agile. We’re going to slap Agile on it. Get out the spray can, and now we’re Agile. We’re following Scrum, so we must be Agile”. But they didn’t embrace what you said as the experimental mindset, that it’s not just about follow these new procedures, and we’ll be better.

The reason behind that is so that we can do these little things, we can have those conversations, and I think that the experimental mindset gets lost in that a lot. I don’t see a whole lot of companies that are doing that. They may be following Agile processes. They might be following Scrum. They might have daily standups, and they might be communicating with their customers or a product owner. But they might not be thinking about it in terms of, did that work, and how do we do a little small experiment and roll it back if it doesn’t work and figure out the other thing? Because sometimes the experiments don’t work. It’s always the assumption that we have to do it, and it’s going to be successful.

Is that what you’re saying about with we’ve got to put AI in the product because the CPO asked for it, and the board asked for it, or the street asked for it? But there’s not really an experiment there. It’s like, thou shalt must do this.

Sam McAfee: Absolutely. I think it’s important for us to acknowledge that the experiments rarely work. It’s not 50/50. I mean, I think in most environments, where you’re experimenting the scientific method, most experiments should be expected to fail. The point isn’t to get all your experiments right or even get them to have a successful outcome. The idea is that having an experimental mindset and approach allows you to learn faster and to reduce uncertainty, right?

All of this is within business, and business is about uncertainty, right? And so, people whose responsibility is to fund efforts, they want to have as much certainty as possible. I think that one of the things that’s happened, certainly with Agile… I’m sure there’s been many discussions and debates about where Agile software development succeeded or wasn’t as successful and why. But I think my quick off the top of my head take on this has to do with the cultures that are in high-level executive management of large, standard Fortune 500 companies. There is a very different mindset in running an organization like that, where the culture and the incentives are about not failing.

Agile came up out of scrappy IT, tech startup folks, creatives and people who like to tinker. As Agile got more and more popular and as it got adopted by larger organizations… Of course, the management consultants played their role in popularizing it, for better or for worse. Mostly worse. I think we have a collision of cultures, where Agile was seen as a way for things to go faster and maybe to reduce a certain amount of uncertainty. But I think that the boardrooms miss the point that there has to be a certain flexibility, and that the reason why we push for shipping in smaller pieces is because we can ship faster and more continuously, but also because it allows us to be wrong more often, safely and more quickly, and recover faster.

We don’t bet the whole farm one season and then be wrong. We make lots of little bets every day. Every line of code that we push to production is in some respects an experiment, right? We don’t know for sure until users are using it if that was the right way to go. And so, I think that that culture of we’re going to try things and see how they work, it is not really in line… Our management and executive cultures came out of the industrial age, out of Taylor and Gantt, and a lot of large scale, we have to be sure, we have to be precise types of thinking, and a lot of punishment if you’re wrong, too.

I mean, you got to think about what the world of a senior exec is like in modern companies. It’s not that forgiving, right? That’s a different mentality from what it takes to do product development, to do service innovation. Innovation of any kind takes creativity. It takes flexibility. It takes the embrace of failure as a learning movement. And that’s not the environment on Wall Street or in the boardroom.

Finding Friction: Where Systems Break and Decisions Bottleneck [17:02]

Thomas Betts: I think when you’re talking about the… You’re trying to get into that innovation mindset, and I think this works both ways. Either you’re big, and you’re trying to add more innovation, or you’re small, and you’re trying to move into more stability. It’s that mindset shift. We talked about friction, and I think you brought it up. It can slow you down. How do you help identify what those friction points are in your software development process, whether it’s software development itself or the teams or the bureaucracy?

Sam McAfee: The way I think about it is where the system starts breaking down. If you’re putting in more and more effort and getting the same or less throughput, that’s usually a sign that something is structurally off. In an ideal environment, teams operate with a certain degree of autonomy. And autonomy isn’t free. It comes with the need for clarity and competence, quoting David Marquet a little bit there. But that idea of you got to have clear goals and then clear guidelines and constraints. If those two things are present, and if people have the skills and the training and the competence to do their jobs, they can operate with a very high degree of autonomy, and they can move very fast, and they can respond to an uncertain stochastic environment very quickly and get the job done.

Where we see breakdowns is typically because of usually a lack of clarity. In the beginning of our conversation, you asked about when I’m typically brought in, and I think one place that it really matters is around decision clarity. I really help with context around decisions. Who’s making them? Which ones do we need to make? At what level of the organization should they be made? Because decisions have a cost, right? And there’s usually a timing to them as well. One of my early product development heroes, Don Reinertsen, likes to talk about the costs of decisions.

We were talking earlier about every line of code potentially being an experiment. Something I used to say a lot in my consulting work is every single line of code is a business decision. You could think about a team or an organization building products and shipping them as a whole set of decisions that are being made at the individual level, at the team level, at the department level, at the organization level all the time. And where organizations tend to falter is when there’s a lack of clarity around, whose decision is this? What is the impact of this decision? If we have to escalate decisions to more senior management, that usually is a sign of breakdown.

When there is a lot of escalation… I mean, there are orgs where escalation’s seen as the norm. That’s a dysfunction. That’s an anti-pattern, right? If there’s an escalation, it’s because we didn’t actually plan for the logic of these decisions in advance. You can’t make all your decisions in advance, but you can actually think through the logic of different types of decisions. These are our goals. If this sort of thing happens, this is the kind of decision we want to make. If this thing happens, we want to go this other way. Then when there are outliers, the executives can say, “Okay, please come to me when these weird things happen. Those you should escalate. I’ll help to decide”. But most of the time, the team should be running on their own.

So, I think where you really see these breakdowns is when there’s a lot of escalation, there’s a lot of confusion, and there’s a huge amount of pressure and effort, but output, or outcomes, really, are not improving or moving fast enough, despite additional hires, additional resources, people working late, and it’s still not getting done. Not that I’m advocating for that. But more effort and it’s not happening means there’s a structural problem. By structure, I’m usually not talking about the concrete of the building. I’m talking about how the organization is put together, role definition, processes, that sort of thing.

Speaking Up For Psychological Safety [21:32]

Thomas Betts: Yes. You mentioned clarity and competence as being fundamental. I think those tie into the idea of psychological safety. The team and the individual team members feel like they have enough autonomy. They feel safe operating with that. They feel like they can have a little bit of open disagreement to actually challenge, like, “I need to help make this decision”. And you can go to a team member versus, “I’ve got to run it up the flagpole. We can’t decide anything ourselves”. So, what’s your definition of psychological safety, and how can you tell if it actually exists in the team or if there’s just a veneer that looks good?

Sam McAfee: You can tell psychological safety is present when people on a team, particularly ICs, individual contributors, are completely comfortable pushing back on bad ideas that come from their leaders. If the leader says, “Hey, I think we’re going to go this way”, and if someone in the meeting is able to say, “You know what? I think that’s actually a mistake, and here’s why”, and nobody gets fired or publicly shamed, or it becomes some sort of problem, like if you see that in an organization, it’s usually a good sign.

Psychological safety has been around as a concept for a while, and I’m really pleased to see it being taken more seriously in techie environments. Because I think in the beginning there was a little bit of a misunderstanding that, oh, this is a nice to have. It’s just squishy, happy, feely stuff. Actually, it’s not. Because in order for people to be able to make those decisions, they have to feel safe that they have the authority and the responsibility to make those decisions. Or if a decision needs to be made by discussion and collaboration, that all voices in the room are valid and that leaders will yield to better logic, better cases being made, are willing to listen, that’s when you see a lot of psychological safety.

I think the opposite is true. There’s certainly a lot of performative psychological safety that’s not really authentic, where leaders will have lots of platitudes and lots of words written on the office wall about how much they embrace ideas from anywhere. They say all the right words, but when you actually see teams operating, you go to a team meeting, and there’s 12 people in the room, and only two or three talk, right? Or a decision’s made, or a plan is put forward, and the most senior person in the room says, “Are there any questions?” and nobody has any questions. I mean, people should always have questions. I mean, it’s never that clear. If nobody asks any questions, it’s probably because they’re afraid that they’ll look stupid if they ask the wrong question. That’s a sure sign that there’s not psychological safety in that room.

Mindful Leadership: Creating Space Between Stimulus and Response [24:29]

Thomas Betts: I know one of the things you teach and talk about is mindful leadership. I feel like we’re getting there from here’s the team to here’s the leader on top of that team and supporting psychological safety and other aspects that it’s not just put the poster on the wall. So, what does mindfulness look like in a leadership contest? What is that day-to-day behavior and not just theoretical and a poster?

Sam McAfee: Mindful leadership is about being aware of the decisions that you’re making under pressure. It’s not about being calm. I mean, there are aspects of mindfulness that are a lot larger than the way that I talk about it. But in the context of leadership in an organization, we’re not talking about meditation. We’re not talking about silent retreats. We’re not talking about the level of calmness that you feel. It’s really more about being aware of your thoughts and feelings and those of the people around you in the moment when the pressure is on. It’s just about creating a tiny space between stimulus and response to slow down enough to make decisions with clarity. That’s what mindful leadership gets you.

And you’re right, it’s directly related to psychological safety in many ways. I think it’s worth our listeners to consider that when there is not psychological safety, or when there are leaders that are creating an environment where psychological safety is relatively low, it’s not usually intentional, right? I have a great deal of empathy for senior leaders, given their position and the amount of pressure that they’re under. I mean, I’ve done a lot of writing. Some folks have followed my blog or read my books, and I can really lambast the CEO pretty fiercely from my blog soapbox, but I think a lot of it is playful tone to make a point. The reality is I have a lot of sympathy for people in leadership positions because it is not easy.

A good buddy of mine who used to be a coaching client that I coached for many years, who’s a good friend now, we were just on a call the other day, and he said, “Sam, if you told me 20 years ago that most of senior leadership is talking people off the ledge, I’m not sure I would’ve believed you. It’s like this whole job is going around making sure everyone’s okay”. I think that senior leaders have a lot of pressure on them from above, from the market, from the board, from other peers, and so when there’s low psychological safety, it’s not typically conscious of a leader that’s creating that situation. They are reacting to their environment. It may be that they aren’t comfortable allowing other people to speak or allowing to be pushed back on their ideas, not in a conscious way, but because they’re not really aware of what they’re doing, right?

Mindfulness, in a way, is one of the tools that you can use to build more psychological safety in an organization because it allows a leader to look at their own behavior and to think in a measured way about whether that behavior is creating the kind of environment that’s going to allow their teams to perform at the level they want them to perform and to produce the business outcomes that they want to see. Most of the time, it’s the leader’s own behavior that things they say offhandedly, not thinking things through, being tired and overworked and grouchy, whatever it is, saying that their door is open, but never being available. Not recognizing that their words have an enormous amount of power. So, it’s really important to not flippantly say things without thinking them through, because they have a huge impact on the rest of the team.

When leaders start to become more mindful of these things, it allows them to shape the culture and the environment in their organization in a way that’s very intentional and that will produce the kinds of outcomes that they’re looking for, often in an indirect way. But hey, leadership is an indirect job, right? You can’t just control everything. You have to create conditions. It’s more like a gardener. You plant the seeds. You water. You don’t make the plants grow. Those plants will grow according to the conditions that they’re in. Mindful leadership really embraces those principles.

Thomas Betts: Yes. Yes. Smile more is a line from Hamilton. Talk less, but listen more is really what you’re getting to is sit down. When someone comes to you, listen to them before you just respond. Definitely always good advice. Just take a beat before you just jump into your default, because sometimes that is your gut reaction. You’re going off emotion, not okay, here’s what’s actually best for the situation. Here’s what that person’s considering.

It almost works in hindsight. If someone’s raising an issue to their manager, it may be the, this is the environment you put us in. Here’s the garden that you’re creating. You need to spend a little bit more time on it. Find those opportunities to say, “Yes, I may have done something wrong”. It might be both of us need to take this opportunity to grow.

Sam McAfee: Yes. Usually, one breath is enough. It doesn’t take that long. A couple of seconds is enough time biologically, cognitively for your brain to catch up with what’s going on in the moment and to think. If you look at Thinking, Fast and Slow by Daniel Kahneman or other… Sorry, I’ve been nerding out on neuroscience books for a long time.

One of the things that’s really interesting is the parts of the brain that are very automatic are super fast, right? If we were in the same room, and I tossed you a baseball, you would catch it before your brain even had a chance to catch up and tell your arm what to do. We have a part of our brain that’s very reactive that has kept us alive. It’s there for evolutionary reasons. That’s not the part of the brain that should be running the meeting, right? The slower, more methodical, thoughtful part of the brain is the one that we want in charge of the organization.

Thomas Betts: Yes. The runaway from the animal chasing me.

Sam McAfee: Yes, exactly. Yes. We’re not like-

Thomas Betts: Very important to run away, but not in this situation.

Sam McAfee: Right. We’re not being chased by actual tigers, most of the time.

Humanize: AI‑Supported Leadership and the Human‑in‑the‑Loop Future [31:13]

Thomas Betts: That’s not my experience writing software at least. I want to wrap it up going into where we’re at now and where we’re headed. Tell us a little bit about what Humanize is–the AI-powered leadership platform. Where do you see AI as a tool that can help leaders, and where should people be cautious about the AI snake oil that’s being sold out there?

Sam McAfee: Well, Humanize came out of a lot of work. It’s a relatively new product. We’re only about a year old, a little bit less at this recording, but coming along fast. But it came out of many years of collaboration. My colleagues and I have been trying to help organizations improve their leadership, improve their business outcomes to lead in a more mindful and humane and psychologically safe way. We’re definitely coming at this with a point of view. There’s a lot of research showing that these more humane ways of leading also produce better outcomes as well. One needs to look only at the Phoenix Project, or Gene Kim’s work, or Radical Enterprise by Matt Parker. There’s a lot of work being done by thoughtful people to show that these better, more modern ways of leadership are actually effective. They’re not just nice to have.

We built Humanize to help leaders with difficult decisions. A little bit like what I do manually, this tool is a platform to enable leaders to go and discuss challenges that they’re having, and it will help them reframe the problem and point them to tools and resources that they can use to tackle those problems. We’ve collected knowledge from a cohort of thought leaders and colleagues across a range of disciplines. Some very technical or product development, others, leadership, culture, business, organization, communication skills, all of those things. We’ve poured it all into the system, and then the system is able to interact with you and help you with your goals as a leader.

We’ve been very careful to balance… This is early days, so we’re still figuring it out. I encourage people to try it out and give us feedback. We also need to be experimenting and learning from our users. But basically, we are calibrating the point of human intervention. The robots can help us a lot, but they can’t help with everything, and so we are trying to figure out where it’s appropriate for someone to raise their hand and ask for a human to intervene and maybe provide some coaching or some feedback, a listening ear, whatever it is. Humanize is built around that principle. It’s not removing the human from the loop, but trying to figure out where the human goes in the loop, right?

It’s interesting for us that we’re building a tool that… We don’t wave the AI flag around that much on the website, but yes, there is AI in the brain. It is built on an AI platform, and then we’re building the platform with AI, right? We’re generating code. We’re using tools like Cursor and things like that. Which is really interesting because this is different than the last startup I worked on, just in terms of how we write code and push it to production. A lot has changed in terms of our own workflows. We’re still a small, scrappy team of three. But the great thing for me is the speed and fluidity that we can communicate and deploy new features when you’re a team of three in the proverbial garage, shipping multiple features a day. That’s a really exciting place.

It’s a lot of meta for me. It’s a lot of interesting, how are we embracing the values that we’re espousing to our customers and our clients in how we’re building the tool itself, right? We put a lot of thought into how the design needs to enhance human interoperability, like communication between humans, but then also sometimes you need to hand things off to an agent. How all that fits together, I think we don’t really know. I mean, I’ve had the pleasure of talking to a lot of tech leaders in the last few months for a separate project, actually, around how AI is changing their workflows. I would say what I see right now at the beginning of 2026 is it’s still pretty Wild West. There are lots of patterns that are emerging that aren’t super clear, but there are some patterns. But the speed of change is so fast.

I mean, even just in terms of the tools we’re using to build our platform, we’ve swapped out some components, or some ideas, or some systems from six months ago where we were using something different, and then now there’s a better way. That’s all the more reason why we have to have a flexible experimental mindset in doing this. We don’t know exactly what’s going to work, and so it’s really important for us as our organization grows that we, not my favorite phrase, but eat our own dog food, as they say. Or eat in our own restaurant. Maybe that’s a better way of putting it.

Yes, I think it’s really hard to say. We’re really at an interesting point technologically where there are patterns from previous phases or rounds of technological innovation. We were joking about earlier, the early websites, the early mobile. There’s a lot of ways in which AI is just like that. It’s not completely different to everything that’s come before. But then there are also ways where it is pretty different, and we have to work carefully as a community to figure out what’s different and what’s the same. I think being thoughtful, having conversations like this, it’s really important for us to share knowledge with each other, open source. All of those things are really crucial at a time like this where, frankly, nobody really knows exactly how it’s going to work out two, three, five years from now. It’s an exciting time.

Thomas Betts: Yes. That’s one of the goals of InfoQ is information Robin Hoods. We like to have these conversations. We like to get that information out there, start more discussions. There’s so many opportunities for people to learn. Like you said, your product is a way for leaders to use AI to help them learn. I hope they’re looking for those opportunities, including listening to this show. But unfortunately, we’re out of time. We need to wrap it up, so Sam McAfee, thanks again for joining me today. This is a fantastic discussion. I’m sure we could have kept going for hours.

Sam McAfee: Thanks so much for having me. This was really fun.

Thomas Betts: Listeners, we hope you’ll join us again soon for another episode of The InfoQ Podcast.