
About this episode
Get every episode summarized
Each time The InfoQ Podcast publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
Transcript ready
178 searchable segments. Every word is indexed and playable.
Full transcript
The InfoQ Podcast — Mindful Leadership in the Age of AI. Machine-transcribed; use the interactive transcript above to jump the player to any line.
If your team has AI running in a proof-of-concept, but you're still figuring out how to run it reliably in production, you're not alone. That's the gap most engineering teams are navigating right now. Cucon AI Boston, this June 1st and 2nd, brings together senior engineers, software architects, and technical leaders who've already made that shift. They'll share the patterns it scaled, the mistakes that didn't make the blog post, and what they'd actually do differently. No hidden product pictures, just senior practitioners, hoping senior practitioners. Learn more at Boston.qcon.ai Hello, and welcome to the InfoQ podcast. I'm Thomas Betz, today I'm speaking at 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. Thanks for having me, very excited. So 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? 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 we call maybe day two, you know, when the stuff that used to work now because of our success is starting to crack in the foundation for a variety of reasons, as usually when I get brought in.
Yeah, 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, you know, 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 end of 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? I really appreciate that you pointed out it happens in bigger companies as well when they're trying to build something new. You know, we as an industry know a lot about how startups should work these days, you know, my book is about 10 years old, and it certainly wasn't the first. So there's a lot of best practice out there, most of which orient around an experimental mindset that, you know, the old days we built everything all at once and launched it, you know, during the dot com boom, which is where I came up into technology.
Those are the days of big design up front and launches and either it passed or failed, usually failed. And of course, we've been using iterative development for a long time when agile reflects that and kind of the lean startup, which basically forms the foundation of what we would think of as modern product management. It 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. So 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 in maybe in the same market, maybe an adjacent market. And 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. And so 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, you know, 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. So when they're totally tooled to operate and sort of keep the lights on business as usual, just a really different style of leadership, a process, all that sort of stuff. So yeah, we see that a lot. Yeah, I talked about it as a go from day zero to what day one to day two, like we have to get to that new thing, we have to scale out, 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 that you're saying that doesn't always fit into a large organization mindset. Absolutely, and it's 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? Like you'll sometimes see, you know, these portfolios where it's like, hey, if it's not a billion dollar project, we don't even want to bother with, right? Like, you know, I 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. And 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 the large organizations as well bit by bit. You know what, try to help that happen sometimes. And I kind of tacked on at the end there, the is anything changing with AI? Like I think where I see this to your example is the, we need to add AI to our products that we look innovative and they aren't set up to do that. Like 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 in the 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?
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. And the other is how it actually affects our tooling and how we build the 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, you know, I've been around long enough to remember Web 1.0, you know, everyone needs a website, then everyone needed a mobile app, then everyone needed to be in the cloud. And then everyone needed to sort of figure out this blockchain thing. There are ways in which 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 and we've all, you know, we've seen this, there's like a chatbot in every single application we use now. And there's all sorts of generative capabilities, some of which are very cool, you know, some of which are useful and value, it's great. But it's not seen, you know, gold rush mentality or actually not always really gold rush, but a good buddy and colleague of mine, Rich Miranov, an author of product management books and really smart guy said to me recently that he coaches a lot of chief product officers and 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 buy the board or has been fired for not doing it. I mean, it's clear that like, you know, there's a little bit of Wall Street headline driven you must produce with AI.
So we know that's happening. And 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. And to this day, despite 25 or 30 years of agile however you calculated and at least 15 of lean startup, it's still not that common in 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. And so, 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. And that's where leaders and technology heads of engineering as a product like people it's sort of like the mid to senior level really need to be careful, you know, to push back a little bit or at least like slow the process down because those products are still only going to be successful.
If they're meeting a real felt need by a customer that pays the bills or you know that will pay for a service. And so 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 like 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 there's a lot of value to it just it's our job to validate with paying customers that this feature we want to build actually 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 same best practices that many of us have been trying to follow still apply with AI in the product. Yeah, 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 its shrink wrap software like 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. And I think some companies there was always that struggle like oh, we need to be agile. We're going to slap agile on it like 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 is the experimental mindset that it's not just about follow these new procedures and will be better. Like 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. A lot of companies that are doing that they may be following agile processes. They might be following scrum. They might have daily stand-ups and they might be communicating with our customers or a product owner. But they might not be thinking about it in terms of did that work and how do you 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. And 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, no, shalt must do this. Absolutely. And I think it's important for us to acknowledge that the experiments rarely work. It's not 50, 50. You know, I mean, I think in most environments where you're experimenting in the scientific method, you know, most experiments should be expected to fail. And it 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 an approach allows you to learn faster and to reduce uncertainty. So, you know, all this is within business and business is about uncertainty, right? And so people whose responsibility is to fund efforts, you know, they want to have as much certainty as possible. And 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 sort of fortune 500 companies. There is a very different mindset and running an organization like that where the culture and the incentives are about not failing. Agile came up out of the sort 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. And of course, the management consultants played their role in popularizing it for better 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 and smaller pieces and 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. So we don't bet the whole farm one season and then be wrong we make lots of little bets every day like every line of code that we push to production is in some respects and experiment right like 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 like our management and executive cultures came out of the industrial age out of Taylor and Gantt and a lot of you know large scale. We have to be sure we have to be precise types of thinking and a lot of punishment if you're wrong to you're going to think about like what the world of a senior exec is like in modern companies is not that forgiving right so that's a different mentality from what it takes to do product development to do service innovation and innovation of any kind takes creativity it takes flexibility it takes the embrace of failure.
As a learning movement that's not the environment on on Wall Street or in the board. I think when you're talking about the you're trying to get into that innovation mindset and I think this works both ways you're big and you're trying to add more innovation or you're small and you're trying to move into more stability mindset shift we talked about friction and you brought it up that 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 the way I think about it is where the system starts breaking down so if you're putting in more and more effort and getting the same or less throughput that's usually assigned that something is structurally off. So 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 according David Marquet a little bit there but that idea of you know you've got to have clear goals and then clear guidelines and constraints and if those two things are presently
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. So in the beginning of our conversation you asked about when I'm typically brought in I think one place that 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 the organization should they be made because decisions have a cost right and there's usually a timing to them as well drawing a lot one of my sort of early. Product to the human heroes don't write it in you know likes to talk about the costs of decisions you know we're talking earlier about every line of code potentially being an experiment something I used to say a lot in my consulting work it's like every single line of code is a business decision and so 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's a lot of escalation I mean there are orgs where escalations kind of 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 so you can't make all your decisions in advance but you can actually think through the logic of different types of decision 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. And 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 you know people working late and it's still not getting done not that I'm advocating for that but you know more effort and it's not happening means there's a structural problem and by structure usually not talking about the concrete of the building i'm talking about how the organization is put together roll definition processes that sort of yeah you mentioned clarity and competence being fundamental I think those kind of tie in to the idea of psychological safety like 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. 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.
So 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 or publicly shamed or you know 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 like oh this is sort of a nice to have it's like squishy happy. The feeling stuff and 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 rumor valid in 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 and 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 lots of words written on the office wall about how much they embrace ideas from anywhere and they say all the right words but when you actually see teams operating. You had a team meeting and you know there's 12 people in the room and only two or three talk right or you know a decisions 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 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 if there's not psychological safety in that room. So I know one of the things you teach and talk about is mindful leadership and I feel like we're kind of getting there from here's the team to here's the leader on top of that team and supporting psychological safety and other aspects it's not just put the poster on the wall so what does mindfulness look like in a leadership contest was that day-to-day behavior and not just theoretical poster.
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 there 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 and so 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.
I have a great deal of empathy for senior leaders given their position in the amount of pressure that they're under earlier my career I mean I've done a lot of writing some folks have followed my blog or in my books and I can really lambast the CEO pretty fiercely you know from my blog soap box but I think like a lot of it is playful tone to make a point the reality is I have a lot of sympathy for people in in leadership position. Because it is not easy while good buddy of mine who used to be a coaching client that I coached for many years who's a good friend now who just don't call the other day and he said you know Sam if you told me 20 years ago that most of senior leadership is talking people off the ledge. I'm not sure what I believe you know like this whole job is going around making sure everyone's okay right so 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 a situation like they're 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 so 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 kind of not thinking things through being tired and overworked and grouchy whatever it is you know 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 a kinds of outcomes that they're looking for often an indirect way but a leadership is an indirect job right like you can't just control everything you have to create conditions it's more like a gardener you know 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. So mindful leadership really embraces those principles. Yeah yeah smile more is a line for mail and talk less but listen more is really what you're getting to is like sit down 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 considered. It almost works in hindsight like 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 know you need to spend a little bit more time on it find those opportunities say yeah I may have done something wrong it might be both of us need to take this opportunity to grow.
Yeah 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 common or other to have been nerdy 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 like if I we're in the same room and I tossed you a baseball. You would catch it before your brain even had a chance to catch up until your arm what to do we have a part of our brain that's very reactive that is kept us alive you know it's there for evolutionary reasons that's not the part of the brain that should be running the meeting right like the slower more methodical thoughtful part of the brain is the one that we want in charge of the organization. Yeah they run away from the animal chasing name.
Yes exactly yes we're not like very important to one way but not in the situation not being chased by actual tigers most of the time. That's not my experience for brain software at least so I want to wrap it up going into we're at now and we're headed so tell us a little bit about what humanizes the AI power leadership platform where do you see. AI is a tool that can help leaders and where should people be cautious about like the AI snake oil that's being sold out there. Well human eyes 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 you know 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 you know one needs to look only at the Phoenix project you know Jean Kim's work or a 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. So we built human eyes 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 so we have 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 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 and we've been very careful to balance. And you know this is early days so we're still figuring 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 so the robots can help us a lot but they can't help with everything and so we're trying to figure out where it's appropriate. For someone to raise their hand and ask for a human to intervene and me provide some coaching or some feedback or listening ear whatever it is so humanizes 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 you know we don't wave the AI flag around that much on the website but like yeah there is AI in the brain it is built on an AI platform.
And then we're building the platform with AI right so we're like generating code you know we're using tools like you know cursor and things like that which is really interesting because this is different than the last startup I worked on right like 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 so it's a lot of meta for me it's a lot of interesting like how are we you know embracing the values that were 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 right like communication.
Between humans but then also sometimes you need to hand things off to an agent and so you know how all that fits together I think we don't really know you 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 and I would say what I see right now at the beginning of 2026 is it's still pretty wild west like there are lots of patterns. There are some patterns that are emerging that aren't super clear but there are some patterns but like the speed of changes so fast I mean even just in terms of the tools we're using to build our platform you know we've swapped out some components or some ideas or some systems from six months ago where we're 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 like we don't know exactly what's going to work.
And so it's really important for us is our organization grows that we my favorite phrase but eat our own dog food as they say eat in our own restaurant that's a better way for you so yeah I think that 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're joking about earlier you know the early websites early mobile there's a lot of ways in which AI is just like that. It's not completely different to everything I've 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 so 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.
Yeah and that's that's one of the goals of InfoQ is you know information Robinhoods 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 the show but unfortunately we're not a 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're going to be able to talk to you. It's a fantastic discussion I'm sure we could have kept going for hours. Thanks so much for having me this is really fun. And listeners we hope you'll join us again soon from another episode of the InfoQ podcast. You
More episodes
More from The InfoQ Podcast

How SBOMs and Engineering Discipline Can Help You Avoid Trivy’s Compromise
The InfoQ Podcast

Context Engineering with Adi Polak
The InfoQ Podcast

Failure As a Means to Build Resilient Software Systems: A Conversation with Lori...
The InfoQ Podcast

Agentic Systems Without Chaos: Early Operating Models for Autonomous Agents
The InfoQ Podcast