Jeff Gothelf
Sense & Respond Learning
Jeff Gothelf has spent over two decades building product teams and consulting leaders on how to ship value instead of features. In this conversation, he breaks down his 20-year rule: measure behavior, not output. That applies to everything, including hiring. You can teach craft. You can’t teach humility or curiosity. Jeff explains why those two traits beat technical skill every time, and how to spot them in an interview.
Jeff made this mistake early in his management career. He hired designers with strong portfolios who delivered great work. But they wanted to be the designer. They didn’t collaborate. They didn’t share. The friction dragged the entire team down.
After repeating this mistake a few times, Jeff reversed his criteria. He started prioritizing candidates who fit the team over candidates with the best technical output. The shift changed everything. You can teach someone to design. You can teach someone to code. You cannot teach someone to be curious about how their teammates work or humble enough to take critique.
You can teach craft. It’s really difficult to teach curiosity. It’s really difficult to teach humility.
Jeff Gothelf, author of Lean UX and Sense & Respond
This applies across roles. Jeff now looks for people who want to understand the system they’re building in, not just execute their portion of it. That means designers who ask engineers about technical constraints before finalizing a concept. Engineers who care about the user experience they’re shipping, not just whether the code compiles. Product managers who want to hear how the rest of the team works instead of just handing down requirements.
When you hire for collaboration over individual brilliance, conversations shift from “no” to “what if we tried this instead.” The team moves faster because fewer decisions die in handoffs.
Jeff uses a single behavioral question to screen for humility. He asks candidates to tell him about a time something they proposed didn’t meet expectations or didn’t work the way they hoped. Then he listens.
The answer reveals everything. How did they feel when it failed? What did they do next? What did they learn, and how did they apply that learning? Strong candidates own the failure without deflecting blame. They describe what they changed and why. Weak candidates blame the client, the timeline, or the brief.
This question works because it forces the candidate to demonstrate self-awareness in real time. You’re not asking them to describe their greatest strength or walk through a portfolio piece. You’re asking them to admit they were wrong and explain what they did about it. If they can’t do that in an interview, they won’t do it on your team.
Jeff pairs this question with close attention to how the candidate describes their role in past projects. Do they use “I” or “we”? Do they credit their team or take all the recognition? Do they show interest in how the rest of the product got built, or do they only talk about their slice of it? These small signals add up.
Most organizations treat employee thought leadership as a threat. Jeff sees it as a recruiting advantage. When you let your team publish, speak, and share what they’re learning, you make your company visible to the talent you want to attract.
Jeff experienced this firsthand at the Ladders, a high-growth startup in New York. The company gave him room to experiment with how design could work inside agile development. He wrote about what the team learned. People kept hearing the Ladders mentioned in those conversations. The company’s hiring brand skyrocketed because candidates associated the org with the problem space Jeff was exploring.
Everybody kept hearing about the Ladders because this is the organization where this idea was born.
Jeff Gothelf, author of Lean UX and Sense & Respond
This works because thought leadership signals that your company supports learning in public. That attracts people who want to grow, not just collect a paycheck. It also filters out candidates who want to keep their heads down and avoid scrutiny. If you want a team that shares knowledge and iterates in the open, you need to model that behavior before you hire.
Jeff recommends being explicit about this opportunity during the hiring process. Tell candidates you’ll give them time to write, speak, or contribute to the community. Clarify what they can talk about and where the red lines are. Then see who steps up. The people who maintain that effort over time are the ones who will push your product forward, not just execute a backlog.
If you’re looking to build a remote team that values this kind of transparency and autonomy, explore how Latin American talent can scale your hiring strategy.
Jeff’s brother sat on a sports betting idea for 20 years. In April, Jeff grabbed his laptop and prompted the idea into existence using an AI code tool. An hour later, they had a clickable prototype across four or five screens. His brother looked at it and said, “Now what?”
That “now what” is the work. AI can generate the idea. It can scaffold the interface. It can write the first draft of the code. But taking that prototype and turning it into a product people use, pay for, and tell their friends about requires humans. You need someone to identify the customer need. Someone to refine the experience. Someone to make sure it’s secure, scalable, and compliant.
Jeff attributes this insight to Teresa Torres and Petra Wille, who said on their podcast that AI can get you 70% of the way there, but the last 30% is what makes a product successful. That last 30% is where craft lives. It’s where you turn output into outcome.
This applies to hiring too. You can use AI to screen resumes, draft job descriptions, or generate interview questions. But you cannot automate the judgment required to assess whether someone will thrive on your team. You cannot prompt curiosity into existence or train humility through a chatbot. The decisions that matter still require humans who understand the context, the culture, and the strategy behind the role.
For more on how AI is reshaping hiring without replacing it, see why companies laying people off for AI will regret it in 18 months.
Jeff has been anchored to this principle for 20 years. Early in his design career, he found himself negotiating what percentage of his design requirements documents would actually ship. That’s not why he became a designer. He didn’t sign up to make documents. He signed up to create user experiences.
The opposite of making stuff is observing what people do with the stuff you make. Every output you ship is designed to generate a behavior change in someone else. That could be a customer using your product, a colleague consuming a budget you prepared, or a candidate moving through your hiring process. The only way to know if you built something valuable is to measure whether the behavior you intended actually happened.
This shifts how you think about success. Shipping a feature is easy to measure. It’s binary. Did you ship it? Yes or no. But that doesn’t tell you if anyone used it, if it solved a problem, or if it drove revenue. Behavior is harder to measure, but it’s the only metric that matters.
It’s super easy to stop and measure success when the thing is done and you’ve shipped it to market. But what is using it?
Jeff Gothelf, author of Lean UX and Sense & Respond
Jeff applies this to hiring too. It’s one thing to write a great job description. It’s another to see if candidates drop out at step one of your interview process. If no one makes it to step two, your process is broken. If your 90-day retention rate is 3%, your hiring decisions are broken. You can’t fix either problem by shipping more job descriptions. You fix it by measuring what candidates do and adjusting based on what you learn.
When Jeff coaches executives, he pushes them to shift the conversation from feature velocity to customer behavior. He tells boards that outcomes are the leading indicators of revenue. The fewer features you ship, the better, as long as each one drives the behavior you need. For a deeper look at how to structure teams around outcomes instead of output, explore how other leaders are making this shift.
Jeff says the scariest phrase in software development is “You know what would be cool?” That phrase is scope creep knocking on your door. In the past, scope was expensive, time-consuming, and difficult to expand. That constraint forced teams to say no. Today, AI makes it trivial to prompt a new feature into existence. Tokens are cheap. The temptation to build is irresistible.
But every feature you build is something you have to maintain forever. Jeff’s friend owns three restaurants and built his own point-of-sale system because he could. Jeff texted him: “You are now in the software maintenance business.” That system will require updates, bug fixes, security patches, and compliance work indefinitely. The friend doesn’t have a software engineering team. He’s the team.
This is the hidden cost of AI-generated code. Getting the idea to exist is trivial. Productizing it, operationalizing it, scaling it, and maintaining it is the work. That work still requires humans. It requires a product person to refine the customer need and build the go-to-market plan. A designer to create a compelling interface. An engineer to make sure the system is secure, scalable, and maintainable.
Jeff would still start with that trio: product, design, engineering. Those three roles working together can identify what actually needs to be built, not just what would be cool to build. AI amplifies their productivity, but it doesn’t replace the judgment required to decide what not to ship.
If you’re building a team to scale product development without expanding headcount, consider how nearshore talent can give you senior-level capacity at a sustainable cost.
Humility and curiosity are the two most important skills in hiring somebody. You can teach craft. You can teach talent to some extent, maybe not fully, but it's really difficult to teach curiosity. It's really difficult to teach humility.
That was always the question, right?
Tell me about a time where something you proposed didn't meet the client's expectations or didn't work out the way that you'd hoped. How did you handle that situation? And then just kind of listen to what the person shares, how they felt about it, what it motivated them to do, and what they took from that action, and how they implemented that.
What's one of the biggest hiring mistakes that you see leaders make when they're staffing a product or a design organization?
You end up hiring somebody who's
I'm Luiz Cent. This is Who We Hire. Our guest today is Jeff Gothelf, the author behind Lean UX, Sense & Respond, and Forever Employable. For over two decades, Jeff's helped companies build better product teams and smarter ways of working. He coaches leaders on org design agility storytelling and proper AI transformation, along with what it takes to hire and grow talent. Jeff, welcome to Who We Hire.
I'm thrilled to be here, Luiz. Thanks for having me.
The players are So, Jeff, let's dive in. You've built and reshaped a lot of different teams uh through through your decades of experience. And well, what's one of the biggest mistakes hiring mistakes that you see leaders make when they're staffing a product or a design organization?
I've made this mistake myself um in in hiring in the past, particularly in my in my early management roles. Um is you you end up hiring somebody whose craft skills are strong, but the the rest of what they bring to the team ends up being toxic or challenging, at least. I've hired folks in the past, for example, for design teams who were really strong designers. And they wanted to be the designer and we were a team, you know, and so there was there was some friction there that ended up dragging everybody down even though the the output of their work was high. You know, and that happened a few times until until we learned the hard way enough that we would rather take somebody who's maybe not as strong as a craftsperson if that's the right thing to say, but they fit really well with the organization, they collaborated, they shared, they were they were humble about their work, they were willing to take critique, they were willing to grow with us and I think that that was that was a big lesson for us. A couple of for me a couple of times over my career.
And so you were able to implement that in interview process to bring in candidates who were were humble, who were curious, who what were what were going to share the knowledge rather than hoard the knowledge.
So look, I mean to me those two words actually humility and curiosity are the two most important skills in hiring somebody. The two most important things you're looking for when hiring somebody. And to me those are the biggest the best skills you can hire in anybody because ultimately you can teach craft, right? You can teach talent to some extent, maybe not fully, right? But I think you it's really difficult to teach curiosity, it's really difficult to teach humility. And so yes, if you build that into the hiring conversation then we get a sense of what people do when they're faced with a challenge. And that's that was always the question, right? Tell me about a time where something you proposed didn't meet the client's expectations or didn't work out the way that you'd hoped. What how did you handle that situation? And then just kind of listen to what the what that person shares, what they how they felt about it, what they what it motivated them to do, what they took from that action, what they took from that action and how they implemented that. And so that that was always a and eventually once we learned that was a a winning strategy moving forward.
Love it. So jumping to Forever Employable, you flipped the usual career advice script and like on a company angle though, so not thinking about the the the branding that we would do to ourselves to be forever employable, but from a company, how does that change how companies should hire, who they hire, and how they evaluate candidates?
This is something really interesting. I think there's there's a tremendous opportunity here for organizations to take advantage of people who want to be thought leaders in a space. We'll just use that. I want to want to improve their personal branding. I think a lot of organizations see that as a threat, and I think that's the wrong reaction to this. I think that the organizations that embrace this, embrace the people, and support them, some some organizations have these roles like product evangelist or tech evangelist, which is essentially a thought leadership role, right? You go around the world, you write content, you give speeches, you talk to people, and you build excitement for the products and services that the company offers. But, I think that generally speaking, if you I'll give you an example, there's there's a few folks in my space who are thought leaders, and and have full-time jobs, right? They're not consultants, they're not trainers, they're not speakers professionally or or in a in a full-time capacity, but they full-time jobs. And to me, what that says is that the organizations that hire these folks have have a a good sense of how to connect with a a a recruiting audience that is highly valuable, right? So, if you've got if if you've got a smart person who's visible, part of the conversation, and you allow them to do that under the umbrella of your brand, it sharpens the hiring brand. It makes it super you know, super more interesting when it comes to who you're going to attract when it comes to hiring the next person or with more open roles. Um and I I think that's a tremendously valuable thing. I was lucky enough to work in an organization in New York City. It was a high-growth startup uh called the Ladders. This was a long time ago where they really did let me do this because it brought a lot of really positive attention to the organization. You know, we were working on solving a a ways of working problem that we had and it turned out that pretty much every other software development organization in the world had, which was how do you get design to work nicely with agile software development. All right, nobody had a good answer for that. Neither did we, but I was in a position where we got the opportunity to experiment. And along with a lot of other folks, we figured out an answer. And in simply writing about that answer, everybody kept hearing about the Ladders, the Ladders, the Ladders, right? Because this is this is the organization that that not only allowed us to allowed us to figure this out, but this is the organization where this idea was was born. And so all of a sudden, the the hiring brand of that organization skyrocketed because of that. And that was because they embraced this.
Wow. Love it. Love it. So, what are some tips for a company that may maybe they're bigger um they're they're scared, they're nervous that somebody's going to post something that you know, could could be off of their brand like but they do want to take advantage of this and they do want to start empowering teams. Go ahead.
I suppose there's always a risk that someone's going to say something uh that is uh perceived poorly. I think if you're hiring somebody like this or you've met somebody in the organization who wants to do this, there are probably some ground rules you want to set in place, some things that they can talk about, some things that they probably should not talk about, and certainly where the red lines are. They should know where those red lines are because ultimately that's going to reflect poorly on the organization and that could end up costing them their job, right? In that situation. I think that's that's really uh it's really important. But I think that if you're uh if you're interested as an organization in creating this opportunity within your company, I think being explicit about it is the best way to start, right? It's to let people know that we've got some people to step up to have some public conversations. We're willing to give you time to do this. We're willing to give you support to do this. We're willing to amplify it in a variety of different ways. We're We're going to pay for your travel to go speak at conferences, that type of thing. And then see who steps up right?
And then who And then who maintains it?
But there has to be there has to be some some indication from the from the organization that this is that this is welcome.
Love it. Love it. Thank you. So, uh another book, I mean we could just go and ask questions about all the books. Lean UX, um it's all about uh small cross-functional teams. So, when you're hiring for cross-functional team, what are you looking for that like may maybe a resume misses? Um you you talked about a couple things earlier. Um humility, curiosity, uh but now in the world of AI, right? It's it's even crazier than when you wrote this book. Uh so, talk to me about that.
Yeah, look again, I I don't want to rehash the humility and curiosity things. I do think those are those are super important, right? Because I've met for example, we'll talk about software engineers, right? I've met software engineers who had no interest at all in any kind of cross-functional collaboration or variability in their work process or anything at all. Like their job was Anyway, that's how you know that.
Or you would recognize that. Like they would say like I don't want to do anything but ship code.
Yeah, yeah, basically the way the way they recognize it is they would say, "Tell me what to build." And then they put their headphones on and then they would see you tomorrow, right? That that type of thing. I think there's a time and place for that kind of work, for sure. But if you're trying to build a cross-functional collaborative team, you've got to start hiring folks who are not only good at what they're doing, but are interested in how the rest of the work gets done, right? When I started my career, everything was waterfall, right? So, every everyone had their own phase, and we all worked in silos, right? Within our own phases, and then we would hand off uh for example, I was a designer, I would hand off the output of the design phase to the engineers, right? And the first words out of the engineer's mouth at that at that time was always no. No. No, we're not building this. No. No. No. No. No, we can't. No, we can't, right? And that was my impression of engineers. Engineers are the people who said no to all the good design work that we did, or to 50% of it at least, right? On a good day. And when we began to collapse those silos into work in a much more cross-functional way, in a more agile way of working, in a more where we were having regular daily conversations across product design and engineering, um all of the sudden, right? It wasn't that they were saying no because they didn't like me, or they didn't like the work. It was they said no because it had some kind of technical constraint or technical limitation that I wasn't aware of. Because I was only finding out at the end of my particular phase, right? And so, I think if you can find folks who are good at their work, but curious about how other people get their work done. Again, and and I and we you know, AI is blurring the lines here a little bit. It's not really teaching people how to code or how to design, it's just enabling them to do it. Uh but at the very least, if there's if there's interest, then when you present something to uh to your team, and they come back and they say, "Look, here is uh here's some of the challenges in implementing this particular design." You can say, "Well, look, I've looked into this, and I think if we used maybe this approach, that might work." All of the sudden, right? You've shown interest, you clearly understand my pain points as an engineer or as a designer, and you're meeting me halfway. And to me, those those were the most successful people that I've ever hired in my life. And I've hired those folks multiple times in in life because I would again, kind of you know, we talked about this a little bit at the beginning, right? You you can hire the rock stars and they're going to do great work, but they're going to want to be treated like rock stars and you're going to have to kind of let them do their own thing without getting in their way. And if you've got the the bandwidth and the capacity and and the freedom to kind of let them run and do that, that's terrific. But most of us don't. Most of us right? Have teams to build and so I would much rather get somebody who's maybe not as strong a coder or as a designer, but actually knows how to how to talk to an engineer, knows how to talk to a product manager, knows how to communicate their needs against what they believe to be the the challenges or the needs of the engineer or the product manager because that makes for a much more honest and realistic conversation and then the knows that they don't the knows don't come as as frequently and instead it's more like well what if we did this instead, right? Or how about we try this? It becomes a becomes a much more productive conversation with people who show a little bit of curiosity. Again, there's that word, right? In how an engineer does their work or what challenges they're facing. And it just comes from understanding the systems that you're building and and the kind of the technical architecture that you're sitting on top of and I think that it's negligent, honestly, if regardless of what you do if you work in tech to not understand the basics of the tech stack that you're building on.
Love it and dropped a lot of good knowledge bombs there and what I took away is like you need to be working toward a solution rather than saying oh it can't be done, can't be right, right? So if you're working together with a solution, but you also mentioned that it sounds like you're not as bullish on AI replacing roles as as some of the other guests that may have been on here. So you don't think Claude code is is replacing developers and Claude design is replacing designers and do you and and Claude copy replacing copywriting? I heard you say that it's never going to really get it in your voice, right? And I mean, you've written five books from scratch before before AI, you know, I want to hear your contrarian take on this.
There are two folks, two sort of peers of mine in the product management and product discovery space thought leadership space named Petra Wille and Teresa Torres. And they have a podcast together. And on a recent episode of their podcast, I think it was Teresa who said something like AI can get you 70% of the way there, but it's that last 30% that actually makes for a successful product. And I tend to buy that, right? I'll tell you why. I'll tell you a story, right? My my brother is not a tech guy, he's not a startup guy. Actually, he did work at a startup briefly to be fair, but he's a lobbyist for real estate development in New York City. He's a good guy.
We need that. Thanks, yeah. No, we need that.
Yeah, but he's on the good side of things like hospitals and and affordable housing and and that that side of the conversation, not like more luxury skyscrapers. I just want to give him his credit. Right? But he's not a tech guy. And but he's been sitting on an idea for 20 years. Just he's a sports guy and he's had this idea for some kind of a sports exchange betting thing that he's he's 20 years been sitting on this idea. And I saw him in April and we were sitting on the couch and he's like, man, I goes, I'm still sitting on this. We're watching a sports a basketball game or something. And he's like, man, I'm still sitting on this idea that I've had for 20 years. And I was like, hang on a sec. I grab my laptop. Right? We got Quad Code or Lovable or whatever. I can't remember what it was, right? I was like, tell me your idea, right? Just prompting prompting prompting prompting. An hour later, we've got like a four or five screen clickable user experience, right? We've modified a few things and we look at it and he's like, wow, that's really cool. And then he looks at me and he goes now what, right? That now what, that's the work, right? That's the 30% that Teresa I talking about. That's where the craft is. That's where human beings are to at the moment are not being replaced. That's where to you know, you you can get an idea to exist very very very quickly. But taking that existing idea and turning it into a successful human experience that can be consumed in a meaningful way, in a lucrative way, whatever it is, is the work and it's that last 30% and that's where really where the humans come in. Uh and so I think there's absolutely going to be uh some uh blurring of the lines, reduction in roles. We're seeing it to some extent. But the good work, the work that actually delivers value from humans, will still require humans in my opinion for a long time to get it to that point. I think the conversations that we're hearing are skewed towards highly entrepreneurial people who are motivated to build their own businesses, right? And that is far from the majority of the of the humans in the world.
Damn. You think most people So we had a guest uh Sam Alavi who was our in um he was at HubSpot for a long time. Now he's a a VP at Pearl, which is a um a marketplace um for like skilled You can give an example or like uh he needed to call a vet in the middle of the night and his wife was able to get on the the marketplace and really uh find somebody fast and and and get help. But he thinks that more and more businesses are going to be built and enabled because of AI. Um and there's going to be a lot more solopreneurs and single-person companies be because of AI and it But you think motivation is a factor. You think most people don't want to go and and have to go and and build rather go and and find a mission and a purpose and go and and and join that.
Yeah, look, I think as my daughter likes to say, stuff can be two things. And uh and so it's a it's a family expression we like around here. Um
I love it.
But yes, I I think the answer to your question is yes, right? Will there be more solopreneurs and entrepreneurs entrepreneurs? Absolutely. Absolutely there will be solopreneurs more that and people I look, even we like I'm I'm not a developer, right? But recently you know, I run a training business. I run a training company and we've been looking for a a way to scale our training to multiple cohorts at the same time at an efficient cost that preserves the way that we like to teach our material. And there isn't a product on the market that delivers that right now. And so my business partner and I started mocking things up in cloud code. And and built clickable experiences and we're we're temporarily seriously considering going into the software business.
Uh yeah, we've we've we've since backed off a little bit, but right? But the but the ability was there, right? And and the the and the fact that you can create something tangible in in in minutes or hours, you know, or over a weekend is irresistible in some cases. However, however, all of the stuff all of the crap that comes with then running that business is on that person, right? I I I'll tell you another story. I have a good friend here who lives here near me who owns three restaurants. And he's an he's entrepreneurial by nature, right? He's always been entrepreneurial. He loves AI. He's all in on it, right? He built his own point of sale system for his three restaurants. Why? I guess because he could. I guess maybe he didn't want to pay for a for an existing system. And I not jokingly I texted him the other day and I said, you are now in the software maintenance business. For Right? You have to you have to maintain this software forever by yourself. Right? Because you don't have a software engineering team. And so there, you know, I again, the the temptation to build businesses with these new tools is irresistible. I think about it every day. What could I build today? Right? But then you get to that now what? Right? Now I got to be sock socks compliant or whatever. Right? Now I've got I've got to you know, be GDPR compliant. Now I've got to maintain this. Oh crap, I've got to build a separate instance for a customer who wants this installed on a different type of server. It's trivial to get the idea to visualize the idea. It is not trivial to take that idea and productize and operationalize it and grow it successfully. That's That's where the work is. And that's that's human work.
You don't think AI will get there?
Look, it's getting better, right? And it's taking on a lot a lot of those things, but I I think ultimately the the successful products, given that everybody everybody can can create the same things, I guess at this point, are the ones that are going to be opinionated and can tell a compelling story, right? And that ultimately deliver lengthy relationships with those customers. Right? And I think that that those things come from humans.
Yes, 100%. I'm glad you went to customers as well. I know you do a lot of customer work and I was listening to you where you talk about let's start let's stop measuring features and start measuring the impact that the work that we do have on customers and their behavior. How did you come up with that?
I mean, look, this this has been the anchor of our work 20 years at this point, which is when I started doing design work, the the the impetus for the first book for Lean UX and all that was I found myself in you know, creating design deliverables and then negotiating what percentage of those deliverables as design requirements documents were was actually going to get implemented and shipped to customer? And that's not what it's not what I signed up for this. I didn't sign up to make documents. I signed up to create user experiences. And so, the the opposite of of making the this stuff is what what do we want people to do with this stuff? And for us, that's always been the the fundamental mindset shift from output to outcome. And it doesn't matter what you do, right? All of us go to work every day, whether whether we're entrepreneurs or solopreneurs, or we work in a large organization, and we make stuff. And that stuff gets consumed by other humans. It could be humans inside the organization, or it could be humans outside your customers of the organization. The only way to determine whether we've actually made something valuable is to observe what people do with the thing that we give them, right? It's super easy to stop and measure success and and, you know, applaud for yourself and pat yourself on the back, right? When the thing is done and you've shipped it to market, right? Hey, I made a Sharpie. There's the Sharpie. Right? Incredible.
Now, what is using it?
Yeah. Well, what was I just made it. No one's used it, right? All I did was All I did was make was make it. But that's really easy to measure. It's binary. Right? Did you make the Sharpie? Yeah, here it is. I made the Sharpie. Did you not make it? No, I didn't make it. And because it's easy to to measure, it's easy to manage, right? But was anybody ever looking for a Sharpie? Right? What problem was the Sharpie solving? How do you know that Sharpie was the solution to solve that problem? Right? The only way that you know that to know that something was actually valuable is to see if anybody's looking for it, if anybody finds it, if anybody tries it, if anybody tries it again, uses it regularly, pays you for it, tells their friends, etc., etc., etc., right? Like their behavior actually changes to indicate that you've given them something that has meaningfully made their life better. And that that could be true for a consumer-facing product, customer-facing product, or it could be for um you know, anything that you make inside your organization. I made a budget. Right? Well, are you getting a thousand questions every time you deliver your budget? Well, guess what? Then the budget you made isn't isn't clear. The delivery process isn't clear, right? You can make it better, right? There there there's an infinite number of things, but everything that we make, right, is is an output and it's designed to generate some kind of behavior change in somebody else. And that that's always been the crux of the work from beginning to end, and it's it's broadly applicable, right? Think about it from a hiring perspective, okay? Um because we talk about this with HR folks all the time, right? It's one thing to to put out an excellent job description, right? It's another to have, you know, I came up with the interview process. Okay, but everyone drops out at step one. We never get anybody to go to step two. And why don't any the candidates make it to step two? Right? Or maybe, right? We we've really refined our job our job descriptions. Awesome. Interview process, people get through it, we make we we we make really clear decisions, and then our our 90-day retention rate for new hires is abysmal. It's like 3% whatever. Right? I Again, just because you came up with a process or a way of working or an idea, and just because you love it,
doesn't mean that it's a good idea, right? The only way to know that it's a good idea is if the people who have to use it are actually doing so and continue to do so in in a meaningful way.
So, what What are some ways and then I heard you talk a little bit about this before. It's like psychological safety at work. So, you know, if I'm the boss, I'm the CEO, and I have this bad idea, and my my team is scared to go and tell me, um how do I go and create that environment for them for them to be able to go and shut down my ideas?
You have to model the behavior for them. The most powerful thing that you can do for your team is to show them how you want them to behave. And when it comes from the top, it's super powerful. Right? Um I'll say I'll share another story cuz I think stories and and and case studies are always the best way to illustrate this stuff.
So you don't have to believe this.
Just my words, but actual things that have happened to me cuz these are my stories. But we were working this was about 10 years ago. We were working with one of the big banks in the US doing some executive coaching. Basically teaching their their leadership team of this bank how to think about their organization as a software company because these were all bankers who had decades of of experience running banks, but banks are software companies these days. Right? They're regulated highly regulated software companies. And so we were working with them and we were introducing the principles of Agile. Right? Not Agile capital A the religion, but like the principles of agility and uh And you know, sensing and responding, small batch size, continuous learning, continuous improvement, all of these various ideas. And these were fascinating new concepts for these folks. They'd never work this way. They'd work in a very top-down, I tell you what to do, I have the experience, you do what I say, and that's it. And then after about 3 4 months of this type of coaching with this leadership team, after one of our coaching sessions, the CEO had a had a an all-hands meeting with all of his direct reports and their direct it was about 150 EVPs and SVPs or so in the room. And he got up in front of all these folks and he said three words. He said, "Agile is hard." And man, our our phones started lighting up. Right our emails started to blow up from all these people who knew what we were doing in the organization. Like, "Oh my god, he gets it. He understands. He knows." Right? So you show a little bit of humility. You show a little bit of of oh my god, I learned something new and it's changed the way that I worked. Um I'm I you know, I'm not always 100% right and that's okay. Right? And as soon as you start to model that behavior, you know, I six months ago we had our all hands and I stood up in front of you and I confidently said that our strategic direction is west and we've been going west for six months and guess what? It's the desert
there's nothing here. Right? And so what I've learned is that west is the wrong direction and now I'm standing in front of you and I'm saying that we need to go north. And here's why I think north, right? Here's the justification. And so we're shifting direction 90° and we're going north. Right? What you've just done there is you've proven to the organization that it's okay to be wrong. It's okay to learn from your mistakes. It's okay to have a new hypothesis as long as it's based on evidence. And and that cascades down. It doesn't have to cascade down at the at the organizational strategy level. It can cascade down to the daily product decisions. Right? I thought we were going to do single sign-on or whatever. We're going to implement this implement this AI chatbot but it doesn't seem like this is the right place for it and based on the feedback that we've gotten from customers, we're going to try it in a different location. Right? Model that behavior and you'll watch people do it.
How often are you coaching leaders to do this?
We you know, honestly not often enough. That's the truth. I think over kind of a an average year we'll do two to three executive engagements. We spend a lot of time with product development teams. And so middle management and the the leadership teams of product managers and designers and developers and that type of thing but two to three times a year we get in the room with executives. In fact, I was I was making a pitch for that today with a with a new client in the UK and hoping that we get that gig because there's a lot of potential there.
I'm sure you can help them and when when you go and coach somebody to go and let's say a CEO to go get up in front of their company and say, "Hey, we've been heading to the desert for 6 months. We need to change direction." Why are they hesitant? Are they scared that they're going to appear weak? Do they get pushed back? Have some of them just simply not done it? What
Yeah.
What have been your experience?
The short answer is yes. Yeah. Because why? Because we all believe that leaders need should know what they're what they're doing and where they're headed. They should have all the answers and they should be able to make decisions about what what work we should be doing moving forward. And if they come across as not confident or hesitant, then that sort of cascades down through the organization. That's the belief. And I think, you know, I think a lot of leaders feel that way. But as you start to head down the path that you've prescribed, if the evidence comes back and contradicts what you expected to happen as you went down that particular path, you have the capacity to stand up in front of the organization and say, "This didn't work out. I really thought it would, but for these reasons and these reasons and these reasons, we're not making the kind of progress that I thought we would. So, we're pivoting. And here's why we're pivoting and why we're going in this new direction and how we hope and what we hope to see in this new direction." And what's nice about that last bit is that it means the definition of success. Right? So, we've been headed what we've been heading west. It's nothing but desert. We're going to head north. How do we know north was the right direction? Well, when we see X and we see Y and we see Z. And typically these are customer behaviors that we're talking about, right? That's how we know and that's allows us to then pause periodically and assess, are we making progress towards those goals? If we are, terrific. Let's keep going. But if not, let's figure out if we have to pivot again or change what we're doing.
Love it. So, you you mentioned you were toying around with some software ideas. If you can share them, what would be the first three hires you make? What roles would you fill strictly with AI? Which ones would you do with a human and and why?
Yeah, look, to me I think I think like as I mentioned before, you know, one of the things that we've been looking for from from you know, we're we're we're a training and education company. And so for us it's and our clients are huge, right? We typically work with with large organizations. Um and so we're looking for a cost-effective way to scale training in a format that these teams will actually consume, which is a really difficult challenge, kind of difficult needle to thread in there, right? And so, you know, for me if if I was if I was staffing a team to build this product idea that we've been toying around with for the last couple of months that we've prototyped a couple of times now, for me it's it's a it's a product person, a designer, and an engineer. Uh that's that's why I would I would there.
Like to me that those three people and and those three people working together to identify because look, it's You you know what the scariest phrase is in uh software development?
Yeah.
Let me let me teach you the scariest phrase in software development. The scariest phrase in software development is "You know what would be cool?"
Yes.
Like literally, that's like the the most ter like if you hear that
It's the expensive frame.
Exactly. Shut that conversation down. Immediately. Immediately, right? Because that's that's scope creep knocking on your door. And and look, there was a point in time where scope was was expensive and difficult and time-consuming. And so that was an easy way to shut it down. And today it's like, "Oh, I'll just prompt it into existence." Right? Um to me
I mean, tokens are cheap.
No, it's exactly and they're getting more expensive, right? So, look, to me you need a product person to identify the identify and refine and continuously refine the the customer needs, the business needs, the go-to-market plan, the the the the product marketing side of it, the the features that were that we definitely need, the unique value proposition, that type of thing. You need a designer to make to help build and and create a compelling user interface. And you need an engineer to make sure that this is, you know, scalable high-performance secure etc., right? All of three of these folks can work with AI tools to do this. There's nothing stopping them. I think their productivity together would be exponentially increased. But to me, it's that that trio that we've talked about for decades at this point as the the crux of any successful software development team. That's where I would start. Again, like for example, right? For for our company, there's myself and Josh, my business partners. Both of us have the exact same backgrounds. We were designers, product managers, and then and then entrepreneurs, right? And you wrote the books together. And we wrote the books together, right? So, we're authors, we're speakers, but we're not engineers. We could do the product work, for sure. I would still want to hire a better designer than me to do the design work. Um and and again, they they want to use whatever tool to to to to help with the design, terrific, right? But it's it's it's the their experience and expertise that will create a great user experience.
Love it. So, that's the the first three you would for building a company or or, you know, one of your ideas uh an incubator within the company. What about on the side, so let's say I have a I'm a founder, see, you know, first-time CEO, I have 150 people. I want to keep growing and providing a better experience to our customers, but I'm having a board that and an investor that are pushing me to increase my revenue per employee to make sure that I'm I'm matching some of these higher-growth AI companies in in in revenue um per person there. How how would you approach that?
to me this is a really interesting conversation because it comes back to this the irresistible nature of uh of AI productivity amplification. Right? Everyone's like, "Oh my god, we can 10x our productivity." And you can. Uh which means that you're going to 10x the production of garbage. And the and and the kind of garbage that you have to live with forever until you sunset it because it's software. These conversations, right? The the revenue per employee, the the velocity of production, they look at at at two they look at two things kind of at opposite ends of the story. They look at features at kind of the bottom end of things and revenue at the high end of things. And in between, no no one not no one, but very rarely do we actually talk about what has to happen in between to to go from features to revenue. And what what has to happen is customer behavior. It's it's outcomes. It's people have to change their behavior. And so for me, if I have a board that's pressuring me to to drive up revenue per employee, my directive to the team isn't, "Hey, make more stuff." It's, "Hey, let's identify the behaviors that drive revenue or the ones that are most likely to drive our revenue in the next year and let's come up with ways to encourage that behavior in our target audience." Right? We don't have to come up with a thousand ways. We just have to come up with the best ways and then refine those ways. And that's the beauty. AI will allow us to to generate a bunch of ideas, to test a bunch of those ideas much more quickly than before, and then to implement only the ones that actually drive the behavior change that we're looking for. So in my if it was me in that role, I would try to continuously shift that conversation back to outcomes. Outcomes of the leading indicators of revenue. Right? And honestly, the fewer features that we have to ship, the better. The more value we get for each bit of code that we release, the better. The less stuff we have to maintain indefinitely. And so to me that that would be that would always be the shift to say, "Okay, great. What are the leading drivers of revenue right now? What do you want to fo- Where do we want to focus as an organization strategically for the next 6 to 12 months?" Okay, great. Now, let's figure out how to drive those behaviors.
I love it. I I love that you keep touching on like the maintenance part of of software cuz I think it's so important. And you said this before in some of your uh another show you were on where it like sometimes you wish they wouldn't add AI feature and just make sure it's reliable and make sure it works. And then it's uh it's such an understated value. Like when I log in, does it does it actually do it? Can I can I use it? Uh So, when you you you touched on it a little bit um earlier, you you mentioned culture but you didn't dig deeper in in in there. Um you kind of threaded away from it which I which I want to I I I want to dig deeper into into why but in terms of mission, values, culture, how important is that in brain brain in folks into your organization? Do you really need to have your values written and posted on a wall or is that like what what what how do you think about that?
It's a great question. Um Look, I I've I've started a a few small companies um and in the high-growth startups that I've worked in, you know, the mission was always clear. Right? This is this is what we do. This is who we do it for. This is why we do it and what we hope to achieve. Right? Something along those lines. Um the you know, the values Look, of course they're important. Right? I think it's it's, you know, if you can build those values in early in the organization, then they just kind of become part of the DNA of the organizations. I I'll give an example again, like I ran I ran this consultant I I helped run this consulting company in New York for 4 years. You know, and and we had we the founders had talked about our values. And for example, we would turn down work from defense companies. Right? Weapons manufacturers, things like that. Like we didn't want to be in the business of helping other people kill more people efficiently more efficiently.
They don't want to be a war doc.
Didn't want to be a war doc. It's okay, right? There's a lot a lot of money there, but we don't want to we don't want to be there, right? And and so it was important for us to articulate those things. And then when whenever the some something came up that that kind of teetered on the edge of of one of these values, we would have a conversation about it. And and the way that we I particularly I'll I'll just tell you I'll share how we did it at the consulting company. The way the way that we did it at the at the services company was we we said, "Look, there there were, you know, four or five principles in in in every office. And the question was does anybody want to take this on? If it was on the fence, right? Is there anybody here who actually wants to take this client on? Because you you you own it. Right? If it's if it's if it's your client. Um and if nobody if nobody stood up to take the client, we passed, right? There there were things that were definitely sort of no, and if if if they were on the fence, that was always the test. And and generally speaking, if it was on the fence, nobody ever stood up to take it. So.
I've never seen that before, and I love how all your advice comes from action. It's not Oh, yeah, we wrote this. No, this is the behavior we we did. This is actually a decision we made, and that that's how our values got created.
Yeah. We did it. We did the work.
Amazing. So, Jeff, as we're wrapping up here, where can folks go and find you? Who should be reading your books? And who I know you're working with mostly larger companies. Um what kind of company should should be finding your consulting services?
So, we're we're super easy to find, right? You can find me at Our company's called Sense Respond Learning. You can find us at senseandrespond.co. Uh you can find me at jeffgothelf.com. And of course LinkedIn is is I'm very active on LinkedIn all the time, so feel free to connect there as well. But we work with typically mid-size to large organizations who are upskilling their product management teams, their design teams to to do product development work in modern ways with AI, etc. with a customer-centric, a human-centric lens on all of it. And so, if that's interesting to you, we'd we'd love to hear from you.
Fantastic. Jeff Gothelf, thank you so much for being on Who We Hire.
My pleasure. Thanks for having me, Luiz.
Ooh.
