# Root Cause of a Healthy Team > Source: > Published: 2026-07-14 07:30:44+00:00 # Root Cause of a Healthy Team In this episode of Root Cause we sit down with Eric Lubow, a CTO who treats organizations like distributed systems, which means the root cause of a broken team is usually a design problem, not a people problem. Eric has spent more than 20 years building and repairing teams and platforms, from co-founding SimpleReach to running engineering through dozens of acquisitions at Thrasio, and he is now Chief Product and Technology Officer at Mapp. He is also a jiu-jitsu coach, and that shapes how he leads. We get to the root cause of what actually makes a team healthy, why becoming a manager means changing your definition of done, and why ceding control is the part nobody warns you about. We talk about leading AI agents the way you would lead a person, why silent heroes quietly turn into silent burnouts, and how to hire into a team instead of into a vacuum. Honest and specific, with none of the leadership-content platitudes, including the lonely parts of the job most people at the top never say out loud. đŸŽ„ YouTube: 🎧 Spotify: *Below you’ll find the text version of this episode, for those, who prefer reading :)* *Guest: Eric Lubow — CTO, jiu-jitsu coach, and military veteran who treats organizations like distributed systems* A combat veteran who led platoons before he led engineers, and host of his own podcast, *Beyond the Belt*, Eric gets with Nune to the root cause of something that, for once, isn’t broken: what actually makes a team healthy — and why the hardest parts of leadership are the ones nobody warns you about. ## A healthy ego, and why everything is maintenance **Nune:** When we first talked, you mentioned a few things you do besides all of this. Care to elaborate? **Eric Lubow:** I teach jiu-jitsu a couple of mornings a week before I start my workday. I also do **executive coaching** — I have a couple of C-level folks I coach. And somewhere in there I try to have a life and friends, practice language learning, and work on my own personal projects. I guess I do a lot of stuff. **Nune:** As I age — or enter midlife crisis — I keep thinking about this. You’ve accumulated a certain knowledge and you’re good at certain things. Do you enjoy doing new things that make you learn, or do you enjoy leaning into existing experience: “I spent ten years learning X, now I can just enjoy applying it”? **Eric Lubow:** It’s a very healthy mix, especially for me. I’m **terrible** at learning languages, but I still practice pretty much every day. It doesn’t come naturally, but you chip away at a problem and find a way that sits with you, and that’s interesting in itself. I’ll never be as elegant in multiple languages as the people I’ve seen — I’m awkward in every language I speak. But it’s a mix, because I’m also good at jiu-jitsu. I’m not *great* at it, but I’m good, and I enjoy learning new things. Sometimes I want to go deeper on something I already know well. Sometimes I want to go wider and learn something completely new. **I don’t really have an ego about being bad.** I don’t care when I make egregious mistakes that make me look stupid — I’ve accomplished what I’ve accomplished, and I’m okay with where I’m at. The same applies professionally. I don’t claim to be perfect, but I’ve made thousands of mistakes, and that’s helped me pattern-recognize. AI is brand new to almost all of us, and I still sat there and **learned it like a beginner** until I got to be bare-minimum mediocre at it — and then I could pattern-recognize where other people struggle, how I got through it, and what might work for them. I don’t really have an ego about being bad. I’ve made thousands of mistakes, and that’s helped me pattern-recognize. **Nune:** People need to hear this. I’m so tired of bucketing people into one way of thinking — you’re T-shaped or M-shaped or whatever-shaped. In reality we’re all messy human beings with different wants and different ways of getting things done. **Eric Lubow:** I agree, but it’s also healthy to have a **limited ego, or an ego in the right way**. I know I’m not good at languages, but that doesn’t stop me from trying, and it doesn’t stop me from making horrible mistakes. In German, *hĂ€sslich* and *hĂŒbsch* are very close to an English speaker — mess that up and you go from calling someone pretty to calling someone ugly. You laugh it off, you remember it, and you use it as a learning experience. **Nune:** Do your jiu-jitsu practice and your language learning complement your skills as a leader? Do they help each other? **Eric Lubow:** Absolutely, no question. There are many things I find beautiful about jiu-jitsu, but one of my favorites is that **no matter how good you think you are, you will get humbled.** You can be bigger, smarter, more skilled — and all you need is a little bit of an off day, and someone less skilled, smaller, and less talented will make you look stupid. That’s a very good straight line to a healthy ego: a gentle reminder that you still have something to learn. And that transfers to every other part of your life. The other thing I take off the mat is that in jiu-jitsu, **things have to work.** Someone can teach you a move, it can look flashy, and if it doesn’t work when you actually try it, then either you’re not good at it, it’s not the move for you, or it doesn’t really work. So you have to test things. If you’ve read what I’ve written, you can see I’ve tested a lot of things — I’ll try something, see it fails this way, and reason that this other thing will probably fail the same way, so I shouldn’t do that. You can see that arc of testing and failure and learning throughout almost everything I do, and much of it comes from forty-plus years of martial arts. No matter how good you think you are, you will get humbled. That’s a very good straight line to a healthy ego. **Nune:** I always thought you just learn a move and that’s it. But you have to put it through yourself, put it into practice. And there’s this other thing in sport — every day a little bit, and it adds up into something without you even feeling it. **Eric Lubow:** Like anything in life, there has to be a good balance. You enjoy it more if you’re good at it, and you nitpick yourself — in yoga you want the angle better, the stretch deeper, to hold the pose longer and breathe correctly. There are all these nuances you can fix and improve. **Learning becomes far easier when you’re motivated the right way and enjoy the journey.** I learned that deeply through martial arts, and I try to bring it to every part of my life, especially professionally. Some people show up to work for a paycheck and not because they love it. I’m fortunate to love most of what I get to do, which means I enjoy learning, enjoy making mistakes, enjoy cleaning them up and helping other people avoid them. **Nune:** I don’t think there’s a job where you enjoy every single factor of it. There will always be things that are boring, routine, people who frustrate you. But if you enjoy most of it, or you have a clear goal you want to reach, you have the motivation to ignore the rest. **Eric Lubow:** I agree, but I don’t even look at it as ignoring — I look at it as **maintenance tasks.** Very few people say “man, I love brushing my teeth.” They do it because it’s maintenance and you have to. Some managers say, “I hate doing one-on-ones.” But the one-on-one isn’t for you as the manager — it’s for your people. It’s where they hear where they’re at in your eyes, where your head is at on the team and their peers. **That’s maintenance work.** You don’t do it because you love it; you do it because it strengthens foundations. That’s how I view most things I don’t like doing. ## Teams as distributed systems **Nune:** Let’s talk about organizations as distributed systems. Is that Conway’s Law the other way around — not the infrastructure repeating the team structure, but the team structure repeating your infrastructure? And what does it mean in practice: do you build redundancy, do you think about vertical versus horizontal scaling, upskilling existing people versus adding new ones? **Eric Lubow:** There’s a level of nuance here that’s quite difficult to get through. That piece I wrote on **people as infrastructure** — or infrastructure as people, however you view it — I set out thinking it would be 1,500 words. I wrote 7,000, and had to cut it down to maybe 3,500 or 4,000, because it was such a dense set of ideas. And I still felt I left a lot out, because each thing starts at a high level and there’s depth every level down. I really tried to apply systems knowledge to the similarity of human interaction. To answer specifically: I didn’t learn about Conway’s Law until afterward, so I didn’t intentionally mimic it. But I do think the inverse is true. Conway’s Law asserts that infrastructure follows team structure; the inverse holds too. **It just matters how the leaders think, how they’re taught to think, and what biases and baggage they bring into the culture.** Culture is what you do repeatedly, and what people do when they’re not being watched — a similar definition to integrity. That’s why I like it: when you tell people “here’s what I expect,” they can be the judge of whether they’re meeting it when no one’s looking, and they can ask for help. You can say, “Hey, you’re not doing this, and here’s why I think so,” and they can say, “I was, and here’s why I think I was.” That communication helps you meet in the middle. Does infrastructure make people, or do people make infrastructure? At some point it meets in the middle. Culture is what you do repeatedly, and what people do when they’re not being watched. ## From IC to manager: ceding control **Nune:** Give me a practical example — like the one about setting goals and then letting people evaluate their own path to them. **Eric Lubow:** This was one of the more interesting transitions I had to make as a manager. Individual contributors hit a certain level and then become managers — a completely different job. I was guilty of thinking, “I know how to do this, I know how *I* would do it, and if this person isn’t doing it like that, they’re not doing it the best way.” **That’s a control problem.** As an IC, your job is to have as much control as possible over the outcome, because then you’re the responsible party when it goes right or wrong. But when you become a manager, you have to **cede control.** You go hands-off a little, and you shift toward being outcome-oriented: where are the outcomes I want you to reach? Then you guide people there — or, depending on their seniority, you let them get there themselves and you retro it together afterward. What went well, what could be improved, what decision did you make, what thinking did you apply? **The outcome-oriented approach is how people find their own way.** **Nune:** This is exactly what I struggle with — and Adrian and I discussed it in another episode; he called it an ego thing and a control thing. But for me it’s the reverse. If I ask someone to build a system, or a module, or a function, I can’t know every detail of how to get there, or even what the end result will look like. How can I ask someone to do something I’m not sure how it’ll look myself? It feels like I’m putting too much responsibility on them. I feel I have to know it really, really well before I can hand it off — but the moment I know it that well, I’ve usually already done the job. So: help me with delegation. **Eric Lubow:** That logic doesn’t apply beyond a certain level. There’s no way I, as a CTO, can be anywhere near as good at design as a designer — I can’t know that end-to-end. Because I grew up in DevOps, I can know DevOps really well, but even that’s hard given how much changes weekly and monthly. I can know it *well enough.* That “I have to know it perfectly” logic works at the manager level, maybe the director level, but beyond that you have different disciplines underneath you and you can’t know them all that well. Which means **people have to drive toward outcomes** — what does success look like? If this project were done successfully, here’s what the outcome would be. And the person might start and say, “Whoa, boss, something’s not right here, I don’t know how I’d possibly get to that.” Then you sit and rethink those assumptions together. You might be wrong. The goal is that you get a better feel for the right outcome the more experience and projects and building you do. Then you start handing those things off. At some point you have to cede control, and this is a really problematic transition. For me it took 12 to 18 months. I thought that getting something done — being able to check something off — meant *I* did it, and I’d feel like I hadn’t accomplished anything if all I did was guide people. I had to **change my definition of done** — to use the engineering parlance — for a task, a day, my job, so I could feel like, “Today was a good day,” even when all I did was make someone else effective. That was a very long transition, because nobody told me. Nobody said, “Hey, your ‘good’ is now somebody else being effective, not you having built the thing.” I had to change my definition of done — so that a good day was someone else being effective, not me having built the thing. **Nune:** It takes a more mindful, intentional approach to guide people, solve the difficult parts, and be present. You need to be in a healthy state of mind for that. If you code at 2 a.m., you can’t be in a healthy state the next day for people to approach you. **Eric Lubow:** Maintenance. Sleep is maintenance. **Nune:** What I’ve noticed is that the disciplines I’m *not* good at — front-end, UI, design — are actually my most successful delegation paths, because I don’t know how to do it, so I have to trust the person. The real hardship is letting go of the parts you *do* know, where you’ve built your own gut feeling of what “good” looks like. **Eric Lubow:** There’s a great essay — I’m going to mess up the name — called **“Give Away Your Legos.”** I think it was written by the folks at First Round. That essay teaches people a lot about becoming a manager — not the first-line manager, but being part of a scale-up where things change so fast that you keep getting responsibilities you’ve never thought about, and suddenly you have to give them away, someone reports to you, and you have to decide what “good” is for something you’ve never even considered. It talks about how to give those things away and still feel good about yourself. I don’t agree with 100% of it, but it’s information you can add to your toolbox about delegation and knowing it’s okay to give things up. **I still have every new manager read that essay.** **Nune:** Can you graduate straight into being a manager, or do you have to go through the hands-on path — developer, architect, DevOps? Can you just learn to be a manager without the practical experience? **Eric Lubow:** Absolutely. **It’s a skill, just like anything else.** One reason people struggle as managers is they often don’t make the transition from doing to leading. You have to become more of a communicator, and most people are never taught to communicate effectively — active listening, empathy, validating emotions, building relationships. Those are all skills, and I was awful at them early in my management career. I got away with it as a leader in the military because I cared about people, so I had empathy — but I didn’t know how to listen well, to reflect back, to say, “Let me repeat that back to you in my own words to make sure I understand.” These skills can absolutely be taught, but you have to know you’re lacking them — or have someone tell you. **And that’s a hit on your ego, because everyone thinks they can listen, everyone thinks they can communicate.** There are levels to it, and there’s probably room for improvement. **Nune:** You’ve also said a lot of people become the manager they *don’t* want to be — they become the opposite of their bad manager, and it’s not that healthy. It’s similar to not passing along generational trauma: either you become the extreme opposite of your parents, or you repeat the same thing. What’s the healthier way to become a manager when you have a vivid example of a *bad* one in your head? **Eric Lubow:** I actually don’t think it’s a bad thing to become the opposite of the manager you didn’t like — and I’m not throwing stones, I’ve phrased it that way too. It’s fine to do that *if* you know what you didn’t like, know what you’re fixing, and then **continue intentionally in the direction you want to go**, rather than just running away from what you don’t want to be. “I don’t want to be like that, so I’m going to go in this direction” is a good starting point. But the self-evaluation and self-reflection are what matter, to facilitate not just good behavior but *intentional* behavior. **Nune:** Maybe what I meant is not overdoing it. You can go the opposite direction; you just shouldn’t overdo it. **Eric Lubow:** One quote I keep in mind is **“everything in moderation, including moderation.”** Sometimes you need to go way overboard, and then you realize, “Okay, I’ve gone way overboard, I’m way in the opposite direction.” Cool — now stop, reassess, and decide whether to keep going or work on something else. ## Leading AI agents like you lead people **Nune:** Here’s a thought: people like you who are good at delegating and leading might have an easier time with AI agents, because you’ve already learned delegation. It’s about putting aside the developer ego — not writing that function yourself but delegating it — and building the infrastructure around the agents to make them effective. **Eric Lubow:** It’s funny — as soon as AI agents got popular, everyone started building governance frameworks: you have to do this, give them these guardrails. The first time I did agentic programming, I thought, **this is just like leading a person.** You tell them what you want, give them boundaries, give them enough context, don’t try to control them, then let them go do it. So I started talking to agents exactly the way I’d talk to a person I was assigning a task. I’d say — and I still do — “If you have any questions or need clarification, come back to me. And if you’re unsure whether something warrants more clarity, just ask.” That alone has given me really good interactions, and it’s the same when I go to multi-agent programming: “If you’re going to offload this to another agent, here are the boundaries I’d like you to set, and if you’re unsure, come back to me.” People tend to write very hard-line instructions for their agents — “do not ever do that.” Even when you ask Claude or ChatGPT to write a prompt for you, it gives you hard lines: do not do this, only do that. The problem is that **these agents are trained on the sum total of human knowledge.** If it’s representing a human, it’s representing communication — so if you’d talk to another human that way and get an effective response, go for it. But nobody really wants to be talked to like that. So I talk to agents the way I’d talk to humans, and it’s been incredibly successful. Most of the software I build, the agents do a very good job of coming back when they hit a problem, or suggesting another approach: “You started with this conclusion, and given the context you had — plus this other context I added — here’s what I think.” These agents are trained on the sum total of human knowledge. Nobody really wants to be talked to in hard lines — so I talk to agents the way I’d talk to humans. One more example. I often structure conversations with agents very specifically: “Do all your research, then come back to me, and every time you have a question or comment that warrants feedback, **enumerate it.**“ That way I can say, “Answer one, this; answer two, this; three and four, that,” and we create our own threads. It’s no different from how you’d have a conversation in Slack — if you want to break out an idea, you break it into a thread. So I do the same communication facilitation with agents that I do with humans, because it ends up reflecting my communication style back to me: theirs is depth when that’s what’s asked for, and mine is segmentation. **Nune:** Nobody cancelled user stories. We still have to define who needs to do something, the business background, what we want to achieve. It worked for years for people — why wouldn’t it work for agents who were trained by people to follow people’s instructions? Since you touched on the similarities: are there situations where you *prefer* talking to an agent over a person? And do you see people being replaced by agents? I know it sounds like it’s on everybody’s mind, but I think it needs to be addressed. **Eric Lubow:** It doesn’t sound stupid. The problem is the sheer amount of media we’re all being fed — boards want lower people costs, and agents can do that. There’s an easy path most people take. It’s the **Aldous Huxley** methodology: if you give people enough information, they won’t be able to sort fact from fiction. So if people keep hearing that agents will replace humans, they’ll keep acting like it’s already true, because they don’t have the headspace to think about it. There are certain things I prefer doing with agents. Sometimes I need a **thinking partner with more expertise than any human I have access to** — then I’ll go to an agent and say, “Help me think through this.” But at a certain point I much prefer input from humans, because I want humans to be able to do more. That’s one reason I love coaching: I enjoy helping humans get better at whatever they do. With executives, I want them to be better executives; with jiu-jitsu people, better at martial arts; with the people in my organization, more effective at their jobs. And sometimes doing your job more effectively means **using the right tool in the right way** — that’s often how I look at AI. Some people jump straight to “make these ten agents do this thing.” Maybe you’re right, maybe there’s something I don’t know. But I could also ask a person with a decade of engineering experience what they think. And if I want to understand the problem better before I ask them, I might say, “Give me a TL;DR — as a CTO, I want to understand how Kubernetes networking works in this scenario, with the pros and cons.” Not to “gotcha” the other person, but so we can have a baseline conversation informed from both sides. **I personally would not like to see AI replacing humans across the board** — though I know I’m not the only thinker in this space. **Nune:** Lately the people who said everyone would be replaced are dialing it back, saying humans are actually needed. It’s like how you’d first use a tool, then find a person and teach them to use it so you don’t have to. It’s the same here. **Eric Lubow:** I like to think of AI as a **force multiplier.** For as long as we’ve been doing this, one person could do one person’s job. If now one person can do 1.8 people’s worth of work, and I still have the same budget to pay the same number of people and get 1.8× the output, that’s wonderful. But I’m not personally looking to replace people with AI — I know that’s not the universal sentiment among technologists. I like to think of AI as a force multiplier. If one person can now do 1.8 people’s worth of work on the same headcount, that’s wonderful. And I make sure, at least in my organization, that we spend time teaching people how to use these tools. That doesn’t remove the fear — everyone hears the same media, that everyone’s going to be replaced. But if you can get people to use the tool, have fun with it, feel motivated and more effective, feel better about their job, and maybe give themselves a little time and headspace back in the day — **that’s a win.** ## What actually makes a team healthy **Nune:** As a team lead and manager, what would you call a *healthy* team? **Eric Lubow:** That varies greatly between managers and people. I’d say a healthy team first and foremost has the **psychological safety to call out what’s working and what’s not.** It’s productive, it can work together, take initiative, and fix problems. Those things don’t all happen at the same level on the same day — people have good days and bad days — but there’s give and take and the ability to operate in a unified way. That said, there are teams that work incredibly effectively without communicating much. They’re a bunch of individuals, and the manager facilitates a lone-wolf mindset across the whole team. **That can be a healthy team.** I personally wouldn’t want to work on it, but that doesn’t mean it isn’t healthy — it’s healthy because it’s authentically who the manager and the members are, and how they function together. A healthy team you’d lead and a healthy team I’d lead would look very different. Some people like more diversity of ideas; some like less. **Nune:** It’s like defining a healthy relationship — it’s individual to everyone. Of course there are obvious red flags, like a lack of psychological safety. Maybe the ability to absorb new tools and technologies, like AI, in a calm and successful way is another criterion for a healthy team? **Eric Lubow:** I don’t know about that. COBOL is still used in many banks and airlines. AI can probably write good COBOL, but most people will still have to check every line, because there’s not as much COBOL out there. So you don’t necessarily need people who adopt new things to be successful on that team. The need for adopting new tools and continuous learning is something *you* consider a healthy trait — and I do too — but it doesn’t mean everybody does. **There are good reasons for people to be “laggards” on the adoption curve.** Those people prefer stability and consistency. Just because your ambition is for the team to learn new stuff and drive forward, that doesn’t make the person who desires stability *wrong*. Their preference is, “I like what I’m doing, I’m good at it.” There are companies and teams that need those people. They’re just a different type of adoption-curve person, and there’s nothing wrong with that. There are good reasons for people to be “laggards” on the adoption curve. They prefer stability — and there are teams that need exactly those people. **Nune:** As a consequence, do you think the team mimics not only the infrastructure but also its leader? If I’m curious about new technologies and think it’s important, I’ll pass that to my team — so the team maps to my preferences and ways of thinking. **Eric Lubow:** I think the team mimics **leaders** — not just *the manager*. If your manager is inspirational, charismatic, deserving of merit, and people respect and want to be like them, then absolutely. But sometimes that person isn’t the team lead — it’s a team member who’s charismatic or respect-earning. Your job as the manager is to figure out who that person is. If it’s you, great, eyes on you as the role model. But sometimes it’s not you, and **that’s okay if your ego can handle it.** If it can’t, you’ve got other issues. If it can, you should be supporting and propping that person up, knowing everyone’s going to follow them, and guiding the team through them. So it’s not always “people follow the manager” — people follow leaders. Sometimes that’s you, sometimes someone else, sometimes you *and* someone else, or multiple people. ## Sharing, shadow IT, and the cheerleader trap **Nune:** In one of your posts you wrote about encouraging sharing — channels where you post what you built — to avoid shadow IT and shadow AI. Can you repeat that from your post, and then help me understand how to avoid it becoming theatrics? Some people genuinely love sharing — “hey team, let’s do X and Y together” — and others look at that and think, “That’s a poser, they’re just angling for the manager.” How do you navigate that? **Eric Lubow:** To start, I like to engender a **culture of sharing.** I want people as open and transparent as possible — that’s the kind of person I am professionally, giving people as much context as possible and letting them work through it at their pace. We have a couple of Slack channels for very public sharing. One is the **releases channel**: if you build something — on the roadmap, off the roadmap, for yourself, on company property — share it. We want people to feel inspired and motivated. And if you’re solving a problem, it’s probably not just *your* problem; someone else almost certainly has it too. You can get someone testing your tool, and it can save other people hours or weeks. There will always be people trying to catch the eye of leadership. I forget who said it — maybe Gergely, **The Pragmatic Engineer** — but there’s this idea of **“promotion-driven development.”** That’s always a possibility, but really it’s an enterprise problem: at larger companies, things need to be *seen* for people to get promoted. I personally think **cheerleaders are okay.** There’s a reason to sometimes say, “That’s really cool, I’m glad you did that.” And if someone is *overly* cheerleadery, it’s also okay to go to the background and say, “I’m really glad you’re doing this, but can you dial it down a little? We want to make sure other people don’t feel stifled.” It’s learning to deliver information as a leader in a way that facilitates good behavior **without tamping down enthusiasm.** That’s a hard line to walk — at some point you’ll crush someone’s enthusiasm accidentally and feel awful about it, maybe for the rest of your life — but you’ll learn that lesson. Getting this public-sharing thing right really matters. **Nune:** I didn’t expect you to aim for the cheerleader. I thought you’d aim for the person who *calls out* the cheerleader — because to me the cheerleaders are the ones who are more for sharing, and then there are people who don’t like that and intentionally stay silent: “That’s just a poser.” **Eric Lubow:** Let me give you an example of where cheerleaders aren’t a problem, but can accidentally *cause* one. Say you have a very forward-thinking engineer who’s deeply passionate about AI, constantly posting article after article. Even though it’s purely enthusiasm and excitement, people who aren’t as forward-thinking will think, “I don’t want to participate — I found something interesting, but they’re 20 steps ahead of me.” **Their enthusiasm sets the tone so far ahead that not everybody is willing to participate.** So you say, “I’m glad you’re doing this. Share those with me, or share them in this other group first, and let’s leave the more public group for people trying to catch up.” It’s the road to hell paved with good intentions: that person is excited and doing all the sharing you want, but they’re accidentally hurting other people’s motivation because they’re so far ahead. **Part of running an organization is taking care of people on both sides of the adoption curve.** Their enthusiasm sets the tone so far ahead that not everybody is willing to participate. You have to take care of people on both sides of the adoption curve. ## The hero problem **Nune:** Another article that hit a nerve for me was about heroics — heroes being the people who fix something in the middle of the night or on a weekend, which can also bring unintentional damage, as you put it. So what am I supposed to do? I’ve often *been* the hero who takes too much responsibility and fixes things. I understand the fix needs to be followed by a proper fix — but are these people supposed to just not fix it, or not care so much? **Eric Lubow:** Let’s separate this into two problems. First, **there will always be issues in production** — that’s just the nature of it — and sometimes you *do* want that person to go in and fix it. Sometimes you’re that person. But if that becomes what everybody relies on, you’ve got a problem — **especially if “everybody” includes you.** If you think, “I’ll just fix this in production when it breaks,” you’re setting yourself up for burnout. You’re saying, “This is going to have to be me until the end of time.” So yes, you solve the problem — and then you solve the *other* problem: what led to this being *you*? Either the only person who *can* do it, or the only one *willing* to. That means maybe you didn’t do knowledge sharing. Maybe you didn’t put the right documentation in place. Maybe the alerting only goes to you instead of to a group. Maybe you did the knowledge sharing but not the *teaching* that makes it useful. If you’re the only one who knows how to restart a service because it takes 20 steps — yes, document it, but then **explain why you got there** and have other people work on it, so the knowledge is shared and ownership can be shared. There are a lot of problems that led up to that production problem. Fix it, then fix all the subordinating problems that led you there. Silent heroes end up being silent burnouts. They get tired, they quit, they go find another job. Most people just go right back to developing — there are customer requirements, the next feature, sales pressure. But if you don’t do all this maintenance work, all this teaching and training, you’ll be right back expecting heroics, and having heroics expected of you — even if it’s only by yourself. **Nune:** I think I’m more comfortable solo for exactly this reason. It’s hard to put the brakes on yourself, and it’s easier to write yet another automation script than to explain 20 steps. But I acknowledge the other way is healthier — for the organization, the team, and yourself. **Eric Lubow:** You have to **trust that other people can do this work**, and you won’t build that trust just by handing it off. You have to make sure they know you have their best intentions at heart — that if you ask them to learn this, you’ll then trust them, and there’ll be fewer of those “get out of my way, let me do it” moments. Instead you sit next to them: “Okay, let’s work through this together. Yes, there’s an outage, but it’s a minor one, so we can allow this while we work through it.” Then you put a boundary on it: “We’ll spend ten minutes, and if we’re not making progress, I’ll go do it — and then we’ll sit down and figure out how to make *you* able to do this next time.” **Nune:** Is it the so-called hero’s responsibility to recognize and address this, or yours as the manager? **Eric Lubow:** Sometimes the hero *is* the manager. As senior leaders, you’ve been through the shit, so you know what it looks like and how to fix it — and you become the hero. But it’s incumbent upon leadership to recognize these problems. **Silent heroes end up being silent burnouts**, and then they go off into the sunset — they get tired, quit, find another job. It’s your job as a leader to recognize if *you’re* doing it, especially if there’s no one above you. If you’re the CTO pulling this crap, the CEO *could* recognize it, but really you have to ask: **why does this keep being me? What am I not doing right that I’m constantly the one doing this?** And if it’s your people, you do the retro and ask, “Why were you the only person able to fix this?” Do you ever stop, while you’re fixing something, and ask, “Hey, is this me?” **Nune:** I am that person, for sure — the one constantly burning out, doing too much. It’s a constant struggle to limit it. I wish we had indicators like in video games — a health bar, a hunger bar — that go yellow or red so I’d address it. But in reality you don’t see that, especially when your wants and desires are ahead of your capabilities, or just ahead of the hours in the day. For me it’s a path through mindfulness, through limiting, through pulling the brakes, through trusting people. **Eric Lubow:** It’s hard. Sometimes you just need to stop and ask: **am I having this defensive reaction because I’m hungry, or because I’m tired? Am I annoyed this person didn’t figure it out because I didn’t teach them, or because they’re really the problem?** These are hard questions, because they chip away at our insecurities. When it comes to machines, it’s easy to think of humans as distributed systems and abstract away the humanity — “where’s the pressure release valve, where can this team absorb more?” But those are *humans* doing that. So you have to check in with them and yourself: can you actually absorb more, and **what falls on the floor if you do?** Is it your health? Your mental health? A production system you can no longer maintain because there aren’t enough hours in the day? That’s the trade-off part of it. ## Hiring into a team, not a vacuum **Nune:** I really wanted to talk about hiring. People talk about it like it’s done in a vacuum — you go and hire a person — whereas in reality you hire a person *into a team*. When I was struggling with hiring as a first-time manager, a friend told me to treat it like dating: examine your team, understand what would fit, what the team needs. Maybe right now they need a fun person. I’m not saying ignore technical skills — but what do you think is more important: the outcome, or the team’s health? **Eric Lubow:** There’s no universally more important thing. One thing I’ve done over the years: when someone wants to hire for a role, I ask *them* to write the job description. The way I like to frame it is — **if you’d worked here the last 30 days, what would you have worked on? What skills would you have needed? And in the next 30 days, what would this person work on?** That’s the starting point. That’s how you get *actual* skills, not “this person has a bachelor’s degree and five years of Python.” You’d have needed real skill to do those tasks, and if you can talk about them — you don’t necessarily have to know how to do them, since they’re endemic to the system being worked on — you’ll have thought about elements of it: “This is a distributed-systems task, so I’d need to understand Zookeeper, or maybe Paxos.” That tells you the person has *thought about* these problems, versus “has this person been writing Java for 10 years?” The next part is the **team vibe.** Do you have a bunch of super-outgoing people with a busy Slack channel throwing memes all day? Or people who show up, talk very little, are introverts, do their job? There’s nothing wrong with either — but if you stick a strong introvert into a very extroverted team, they’re all going to be uncomfortable, because it’s hard for both groups to adapt. So knowing the culture of your team is really helpful. Sometimes you have an introverted team you want to pull out of its shell, so you want someone slightly more extroverted. Or you want an **ambivert** who can slide between both worlds. All of that is part of the dating-slash-hiring process. If you’d worked here the last 30 days, what would you have worked on? That’s how you get actual skills, not “five years of Python.” I also always do the **airport test**: if you were stuck with this person in an airport for 72 hours, could you have a conversation? Would you *want* to talk to them? For as long as I’ve been hiring — and I’ve hired literally thousands of people and done thousands of interviews, especially from my scale-up days — I always ask the same four or five questions at the tail of the interview. I’ve never published the piece I wrote about it, but for example: **“What advice would you give yourself five years ago?”** Some people say, “I’d have bought Bitcoin.” Okay — that’s information; it likely means they’re motivated by material things, which isn’t good or bad. Some say, “I’d have learned to become a better listener.” Cool — how’d you get there? Then I ask **what they do for fun**, because I want to see what they look like when they’re excited — if you do something for fun, you’ll talk about it excitedly, and I want that to come out. There’s nothing wrong with people who write code for fun *and* professionally, but if that’s *all* you do, your versatility is probably slightly less than someone with multiple interests. Another question: **“If you could tell me anything about yourself — ‘if Eric just understood this about me, our lives would be better’ — what would it be?”** Sometimes I get, “I’m such a perfectionist.” Okay, now I know I need to regularly ask this person, “Is this good enough? Have we progressed, or are we still aiming for perfection?” People will helpfully tell you these things. All of these get at the *person*, more than just the skill — **because if all you care about is skill, at some point their personality becomes a problem for you as a manager, because you never explored it**, and they never got to explore it with you. **Nune:** I’m glad you’re saying this. I hear horror stories of people going through eight, ten stages of interviews with coding assessments that take days to implement — whereas I’ve always approached hiring as getting to know the person and their motivation. For me it was always important that they’re curious, interested, that they want to share and help the team. The technical skills need to match, of course, but I believe everyone can learn whatever they want if they put their mind to it. **Eric Lubow:** Agreed. ## The loneliness of leadership **Nune:** You said something I want to quote back: anyone alone would likely fail. And you mentioned that when a CTO fails to recognize their heroics, a CEO might help them — but you’ve also said this is a lonely job. If anyone alone would fail, how do you, as a CTO who’s sort of alone, deal with that? Who are your peers? Is it your CEO, your co-founder, people from previous companies? Who do you share the burden with? **Eric Lubow:** There’s a mix of ideas in there. First, this is one of the reasons **executive coaches exist** — there’s the objectivity, and they usually have experience in these areas. An executive can turn to someone external and say, “I’m struggling here, this is what I need help with,” or “I’m struggling and I don’t even know what I need help with.” I also have people who were previous bosses, or who worked for me and climbed the ranks elsewhere, and I keep those relationships. Sometimes I’ll just message them: “I’m really stuck — here’s what I’m working with. How would *you* unpack this, especially knowing my strengths and weaknesses?” I keep that network. And I’ve had a running thing where almost anybody who has worked directly for me can reach out at any point — and many do. I have very regular conversations with former engineering leads, DevOps leads, product managers, data scientists. Some reach out on LinkedIn after two, three, five years of not talking: “Can you give me feedback on this PRD?” I’m happy to do it. Obviously I won’t drop everything, but those relationships are important. To bring it back inside the organization: it’s very difficult to have those kinds of relationships internally once you reach a certain level, because **you are the accountable party.** When something goes wrong *or* right, it’s you — you have to make sure it gets fixed if it went wrong, and if it went right, you often give the credit to someone else. That makes it feel lonely. Being C-suite is quite difficult because **you really only get the shit.** So I try to hand off all the positive, because I’m fortunate not to need recognition — and I feel lucky about that, because if I did, my job would be much harder. I can easily hand off recognition, and when something goes wrong I can easily accept blame, because my ego doesn’t survive on validation. But I know that’s not the norm. So, more specifically: I do have people in the organization I’ll go to — “I’m struggling with this, I need some kind of support, I’m not exactly sure what it looks like” — or, “Here’s exactly what I need; can you do this? If not, how do we get ourselves to that point?” Being C-suite is quite difficult, because you really only get the shit. When something goes right, you give the credit away. **Nune:** That’s exactly what I wanted to hear — whether it happens inside the organization or outside, and maybe it’s both. The follow-up: do you allow yourself to get vulnerable with your team, or does the figuring-out happen behind the scenes? Does it ever happen that you come to your team and say, “Look, guys, I don’t know”? **Eric Lubow:** It’s both. And I absolutely do. I would not have done that in my younger years, because I thought **“I don’t know” was a sign of weakness. It’s not — it’s a sign of strength.** It’s saying, “I don’t know what to do here, so let’s figure this out together.” We have the collective wisdom of five, six, seven people, decades of engineering, product, DevOps, and data-science experience. Let’s figure it out. If someone else can lead this and help me go in the right direction, let’s do that. I used to think “I don’t know” was a sign of weakness. It’s not — it’s a sign of strength. I’m fortunate to have a group of people now who accept that responsibility when I say, “Hey, I’m stuck,” and respond, “Okay, let’s work through this.” It’s not easy, because sometimes it’s “I’m the boss, I *should*“ — and that “should” is the enemy of progress when you’re stuck. It’s harder to actually do it, but the outcome is better. I won’t pretend I do it all the time. I’d love to say every time I’m stuck I ask for help, but no — sometimes I think, “I can power through this,” and sometimes I do, which is good for self-confidence and trusting myself. And sometimes I’m just not getting anywhere, and then I go to the team: “Here’s what I’m stuck on. How do we handle this?” ## Books, and the smallest win you’re proud of **Nune:** Thanks for the honesty — I feel like I got a free consultation in this one hour. I hope a lot of first-time managers, and seasoned managers handed a new team, get honest answers from this. Now, some final questions. I’m a big bookworm, so I always ask for recommendations — fiction, nonfiction, whatever feels right. **Eric Lubow:** The **Bobiverse** series — *We Are Legion (We Are Bob)* is the first book — is probably one of my favorite series of all time, by Dennis Taylor. It’s science fiction about an AI, and there are about five books now. I read 20 to 30 books a year, mostly fiction, mostly sci-fi space operas. **Becky Chambers** is a brilliant author too — my favorite of hers is either *A Psalm for the Wild-Built* or *The Long Way to a Small, Angry Planet*, also a four-book series. Otherwise, people can creep on my Goodreads and see everything I’ve read — probably the easiest way to get a recommendation. What would you recommend? **Nune:** First — one day when I retire, I’m going to have a podcast about sci-fi with IT people, because it’s so important for people to read sci-fi, to keep the spirit of an imaginative technological future alive. What I’d recommend: let’s be friends on Goodreads. **The Expanse** series I really liked. And the book before the one I’m reading now, **Children of Time** — I liked it a lot; it had elements of AI and how your consciousness gets mixed with the AI until they’re inseparable. The book I’m reading now is **Permutation City**, from 1994 — when you read it, you can actually trace why *The Matrix* happened when it did. It’s mind-bending and a hard read, but I recommend it. **Blindsight** by Peter Watts is also a hard read, all about cognition — if you sit through it to the end, the moment you close it your mind is blown, and you stay with that feeling for days. Honestly, I don’t really like technical IT nonfiction. I’ve always been embarrassed of that — I never read best practices, I try to figure them out myself. **Eric Lubow:** Same. There are only two books I’d recommend for management and leadership, both by **Patrick Lencioni.** One is *The Five Dysfunctions of a Team* — about 250 pages, very narrative, reads wonderfully, tons of incredible lessons; you can read it in an afternoon. The second is *The Advantage*, by the same author. It is one of the most *boring* reads — absolutely brutal to get through — but it’s one of the most dense, information-packed, valuable reads on maintaining healthy organizations. I’d be remiss not to recommend it, but it was a difficult, difficult read. **Nune:** We have this thing where each guest leaves a question for the next. Funny enough, this one is almost the question *you* ask in interviews: **what is the one thing you’d tell yourself at the beginning of your journey that you know now but didn’t then?** Treat it however you like — leadership, team-leading, or IT. **Eric Lubow:** I for sure did not spend enough time, when I was younger, **understanding myself through the lens of other people.** That’s been hugely problematic in my personal life and minorly problematic professionally. I really wish I’d been taught emotions, emotional communication, and self-awareness of emotions at a young age — I wish that were part of growing up. For me it wasn’t, and I’ve had to learn it the hard way, through many lost relationships I wish I hadn’t lost. I did not spend enough time, when I was younger, understanding myself through the lens of other people. **Nune:** How do you actually learn about yourself through the lens of others? I know how to learn about myself through reflection — which is maybe faulty, because you’re on your own, biased, thinking about you. So how do you do it through others? Do you just ask them? **Eric Lubow:** You ask, and **you listen.** “Here’s what I thought I heard — did I understand correctly? Here’s how I view what you said about me — did I get it right, or am I just being defensive?” It’s actually sitting with what you’re told, hearing it, internalizing it — and if you don’t understand it, asking, rather than assuming you’ll figure it out. But you have to do all the self-work first, and *then* you get to the point where you bring in other people’s input. **Nune:** And your question to the next guest? **Eric Lubow:** **What is the most benign thing that you’re proud of, and don’t get to talk about?** **Nune:** What is it for you? **Eric Lubow:** This is super benign. I helped friends move a couple of months ago. You’re in Berlin too, so you know parking is a nightmare. I was one of the people with a license, so I was the driver of the big Miles van. We drove, we unloaded, and then I went to put the van back — and on the first try, I **parallel parked it with about four centimeters on each side.** One move in, perfect. And I was so excited — but there was nobody around, nobody on the street saw it, my friends weren’t with me. I got back, and they were all exhausted from carrying stuff up and down the stairs, and I said, “Guys, I just parked the van.” And they said, “Yeah, we know.” And I said, “But you don’t understand — I *parallel* parked it, with that little space.” And they just didn’t have the energy, and they hadn’t seen it, so they couldn’t celebrate. They were just hearing it secondhand. But I managed to park that van on the first try, with so little space on each side. **Nune:** I’m actually learning for my driver’s license only now, at thirty-seven — so I can really share your excitement. Every successful trip in the practical exercise gives me so much energy. **Eric Lubow:** Yeah — you get used to it, but then those wins... I’ve been driving since I was seventeen, almost thirty-something years. But then something like that happens, and — right. ## References **Articles and ideas mentioned in this episode** Eric’s own writing that runs underneath this whole conversation: [Infrastructure by Adoption: An AI-Engineering First Principle](https://eric.lubow.org/2026/infrastructure-by-adoption-an-ai-engineering-first-principle/)(the “people as infrastructure” thread, organizations as distributed systems)[Systems Over Heroes](https://eric.lubow.org/2026/systems-over-heroes/)(the heroics piece: why silent heroes quietly become silent burnouts)[If You Want Compliance, Start with Celebration](https://eric.lubow.org/2026/if-you-want-compliance-start-with-celebration/)(sharing channels vs shadow IT and shadow AI) Other references that came up: [“Give Away Your Legos” and Other Commandments for Scaling Startups](https://review.firstround.com/give-away-your-legos-and-other-commandments-for-scaling-startups/)by Molly Graham (First Round Review). The essay Eric still has every new manager read.[Conway’s Law](https://en.wikipedia.org/wiki/Conway%27s_law)(and the inverse we kept circling: does the team shape the infrastructure, or the infrastructure the team?)“Promotion-driven development,” a phrase from [Gergely Orosz, The Pragmatic Engineer](https://x.com/gergelyorosz/status/1442162670753431559). **On the two dystopias.** Eric reached for 1984, then corrected himself to Aldous Huxley, and he was right to. The fear that you bury people in so much information they can no longer sort fact from fiction is Huxley’s *Brave New World*, not Orwell’s *1984*. Neil Postman drew the line cleanly in *Amusing Ourselves to Death*: Orwell feared the people who would ban books, Huxley feared there would be no reason to ban one, because no one would want to read it anyway. **Books mentioned** Eric’s picks: [We Are Legion (We Are Bob)](https://www.goodreads.com/book/show/32109569-we-are-legion-we-are-bob)by Dennis E. Taylor, first of the Bobiverse series[A Psalm for the Wild-Built](https://www.goodreads.com/book/show/40864002-a-psalm-for-the-wild-built)and[The Long Way to a Small, Angry Planet](https://www.goodreads.com/book/show/22733729-the-long-way-to-a-small-angry-planet)by Becky Chambers[The Five Dysfunctions of a Team](https://www.goodreads.com/book/show/21343.The_Five_Dysfunctions_of_a_Team)and[The Advantage](https://www.goodreads.com/book/show/12975375-the-advantage)by Patrick Lencioni (the only two leadership books he recommends, one a joy to read, one “absolutely brutal”) Nune’s picks: [The Expanse](https://www.goodreads.com/series/56399-the-expanse)series by James S. A. Corey[Children of Time](https://www.goodreads.com/book/show/25499718-children-of-time)by Adrian Tchaikovsky[Permutation City](https://www.goodreads.com/book/show/156784.Permutation_City)by Greg Egan[Blindsight](https://www.goodreads.com/book/show/48484.Blindsight)by Peter Watts Add each other on Goodreads: Eric is at [goodreads.com/elubow](https://www.goodreads.com/elubow) and Nune at [goodreads.com/nisabek](https://www.goodreads.com/nisabek).