# Into the Arena: Lessons for Tech Leaders from 'Daring Greatly' > Brené Brown's 'Daring Greatly' predates her better-known leadership books, and it holds hard, practical lessons for anyone leading software engineers. This post reads nine quotes from the book through a technology-leadership lens: why a pattern of blame is really a problem with shame, why belonging beats fitting in, how trust is built one marble at a time, the gap between the values we practise and the expectations we set, and why your worth was never your output. It is the origin story behind the ideas I explored in my earlier posts on 'Dare to Lead' and 'Rising Strong', and a look at what it actually takes to step into the arena at work. *4 September 2026* · Jamie Taylor This post is part of an ongoing series on the books that I have read as part of my continual professional development (CPD). All of my CPD posts are available at the following link: [Continual Professional Development](/tags/continual-professional-development/) Picture two people in the same sprint review. One of them shipped the change that is currently misbehaving in production; she is watching the dashboards, answering questions, and explaining what she now knows that she did not know last week. The other has his arms folded at the back of the room, and when there is a pause he says, "Well, I'd never have built it that way." One of them is in the arena. The other is a spectator with opinions. That distinction is not mine. It comes from Theodore Roosevelt, in a speech he gave in Paris in 1910, and it is where Brené Brown took the title of the book I want to talk about today. > It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly. > > — Theodore Roosevelt, [The Man in the Arena](https://en.wikipedia.org/wiki/Man_in_the_Arena) [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) came out in 2012, which makes it the earliest of the three Brené Brown books I have covered in this series. If you have read my posts on "[Dare to Lead](/blog/continual-professional-development/leading-with-heart-and-mind-lessons-from-dare-to-lead-for-the-modern-workplace/)" and "[Rising Strong](/blog/continual-professional-development/finding-strength-in-vulnerability-lessons-for-tech-leaders-from-rising-strong/)", this is the book those two grew out of. It is the origin of the arena, and of the argument that vulnerability is the thing that makes brave work possible rather than the thing that gets in its way. I have spent almost twenty years in this industry, across more than fifty organisations, and I have interviewed engineers, architects and leaders across nearly 190 episodes of The Modern .NET Show. The single most reliable predictor of whether a team does good work, in my experience, has very little to do with the technology stack and almost everything to do with whether people feel safe enough to be seen getting it wrong. That is what this book is about. Here are nine quotes from it that I keep coming back to, read through the lens of leading software teams. ## When Blame Is a Pattern, Look for Shame Most of us can spot blame when it happens to us. It is harder to see it as a system, running quietly in the background of a team, shaping what people are willing to say out loud. Brown is blunt about what it costs. > There is nothing productive about blame, and it often involves shaming someone or just being mean. If blame is a pattern in your culture, then shame needs to be addressed as an issue. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) This is the sentence I wish more engineering leaders would sit with, because a great many of them will tell you, sincerely, that they run a blameless culture. Very few of them actually do. Blamelessness is easy to claim and expensive to live, and the gap between the two shows up most clearly in the moments right after something has gone wrong, when the instinct to find a person to hold responsible is at its strongest. I have written before about [what a blame culture looks like when the mask slips](/blog/building-psychological-safety-in-your-development-team/), and the story I tell there is the clearest example I have of Brown's point in practice. A junior developer, whose reasonable fix had passed three senior reviewers, internal testing and User Acceptance Testing (UAT) before an edge case reached production, was stood at the front of a room while her manager walked the whole team through what she had done wrong. She resigned that afternoon. The manager later told me the exercise had been "a great way of showing my power over the team." That is not a process failure being investigated; that is shame being used as a management tool, and the phrase "we don't have a blame culture here" had been said to me twice before I even started. The tell is in the language of your incident reviews. "Who introduced this regression?" and "what in our process let this through?" are both trying to prevent the next incident. Only one of them makes it safe to be honest about the last one. ## Belonging Is Not the Same as Fitting In Brown draws a distinction that sounds like wordplay until you have watched it play out in a team, at which point it becomes one of the most useful ideas she offers. > I get to be me if I belong. I have to be like you to fit in. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Fitting in is assimilation. It asks a person to sand off whatever makes them different so that the group stays comfortable. Belonging is the opposite; it lets someone bring the difference and stay. For a technology team, that difference is often the whole point. The engineer who keeps asking the awkward question about the data model, the tester who will not stop worrying about the failure mode nobody else wants to think about, the new joiner who says "at my last company we learned the hard way not to do this": these are the people who catch the expensive mistakes early, and they are exactly the people a fitting-in culture trains into silence. The quiet cost is that you end up with a team that agrees with itself. Consensus feels efficient, right up until the moment it turns out everyone was agreeing because disagreeing was uncomfortable. [Your team's silence is usually telling you something](/blog/your-teams-silence-is-telling-you-something-psychological-safety-in-development-teams/), and more often than not it is telling you that people have decided fitting in is safer than belonging. Leaders set that thermostat. If dissent is met with irritation, you are running a fitting-in culture whether you meant to or not. ## Trust Is a Marble Jar, Not a Grand Gesture There is a story in the book, told to Brown by her daughter's teacher, about a jar of marbles kept on a shelf. When the class does something that earns trust, a marble goes in. When trust is broken, a marble comes out. Trust, in that classroom, is not declared; it is accumulated and it is visible. > Trust is a product of vulnerability that grows over time and requires work, attention, and full engagement. Trust isn't a grand gesture—it's a growing marble collection. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) I like this because it corrects a mistake that ambitious leaders make constantly. They wait for the big trust-building moment: the off-site, the town hall, the heartfelt speech after a difficult quarter. Meanwhile the marbles are going in and coming out every single day, in units so small they are easy to miss. Turning up to the stand-up on time is a marble. Saying "that was my mistake, not yours" in front of other people is a marble. Following through on the code-review comment you promised to address, remembering that someone's parent was ill, not checking Slack while a colleague is talking: marbles, all of them, and each one tiny. The same is true in the other direction, which is why trust is so much easier to spend than to earn. This is the machinery underneath what Simon Sinek calls the Circle of Safety, an idea I have explored [in the context of "Leaders Eat Last"](/blog/continual-professional-development/leading-with-empathy-lessons-from-leaders-eat-last-for-the-modern-workplace/). You cannot install psychological safety in a workshop. You build it one marble at a time, and you keep building it, because the jar is never finished. ## Mind the Gap Between Values and Expectations This next one reads like a line from an organisational-design textbook, but it describes something I have watched hollow out more than one engineering team. > When our practised values are routinely in conflict with the expectations we set in our culture, disengagement is inevitable. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Every company has a values page. "We value quality." "We value learning." "We care about our people." The words are almost always fine. The damage is done in the space between those words and what the culture actually rewards. If the values page says quality, but the engineer who slows down to write the tests is quietly seen as the one who missed the deadline, your practised values and your stated expectations are at war, and your team knows it long before you admit it. People are very good at detecting this gap and very bad at ignoring it. What they do instead is disengage; not dramatically, but by degrees. They stop raising the risk nobody wants to hear about. They stop suggesting the better approach that takes an extra day. They deliver exactly what is expected and no more, because the culture has taught them that the stated value was decoration. This is why I think so much about [why a company does what it does](/our-why/), and not only what it says it believes. The stated value is cheap. The expectation you actually reward is the real one, and it is the one your best people will believe. ## Teach People to Sit With Discomfort Leadership writing loves to talk about growth. It is much quieter about the fact that growth and discomfort are the same experience described from two different moods. Brown does not let leaders off that hook. > The big challenge for leaders is getting our heads around the fact that we need to cultivate the courage to be uncomfortable and to teach the people around us how to accept discomfort as a part of growth. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) There has rarely been a better moment to take this seriously, because our entire industry is currently uncomfortable at once. Assistive tooling and agentic development are changing how the work gets done faster than most people can update their sense of what they are good at. That produces a very specific kind of discomfort: the fear that the skill you spent a decade sharpening is being quietly revalued. A leader who responds to that by performing certainty, insisting it is all fine and everyone should simply get on with it, teaches their team to hide the fear rather than work through it. The braver move is to name the discomfort and stay in it with people. I see this most clearly with the teams I work with who are learning new tools together, and with the students and apprentices I have taught since 2022, where the whole task is helping capable people tolerate the feeling of being a beginner again. A team that has been taught that discomfort is a normal part of getting better will walk towards the hard, unfamiliar problem. A team that has been taught discomfort is a sign something is wrong will find a way to avoid it, which is a real problem when the unfamiliar is arriving on a weekly basis. [The best teams treat "done learning" as a warning sign](/blog/when-your-team-thinks-theyre-done-learning/), not a destination. ## Neither Viking Nor Victim One of the sharper observations in the book is about a particular worldview Brown calls "Viking or Victim". It is the belief, often absorbed in high-pressure environments, that there are only two roles available to you: you are either the one doing the crushing or the one being crushed. Winner or loser. Predator or prey. There is no third option in which you are simply a person doing difficult work among other people. > When we lead, teach, or preach from a gospel of Viking or Victim, we crush faith, innovation, creativity, and adaptability to change. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Technology has its own dialect of this gospel. It is the culture of the "10x rockstar" set against the "replaceable resource"; the hero developer who saves the day against the team that is treated as interchangeable capacity on a spreadsheet. When that is the story a team is told about itself, everyone learns the only two available positions, and both of them are bad for the work. The would-be Vikings hoard knowledge and defend their territory, because in a winner-takes-all culture sharing what you know is a competitive risk. The people cast as Victims stop offering ideas, because in that same culture an idea is just a new surface to be attacked. Brown's list of what this crushes reads like a list of everything you actually need from an engineering organisation: faith, innovation, creativity, and adaptability to change. You cannot bully those qualities into existence, and a Viking-or-Victim culture is a very efficient way of destroying them. The alternative is not softness. It is refusing to accept that domination and defeat are the only two things on offer. ## Your Worth Is Not Your Output This is the quote I would tape to the monitor of every engineer I have ever met who ties their sense of themselves to their velocity. > It means cultivating the courage, compassion, and connection to wake up in the morning and think, "No matter what gets done and how much is left undone, I am enough." It's going to bed at night thinking, "Yes, I am imperfect and vulnerable and sometimes afraid, but that doesn't change the truth that I am also brave and worthy of love and belonging." > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Our industry is unusually good at teaching people that they are their throughput. The sprint burns down, the tickets close, the metrics tick up, and somewhere in the middle of all that measurement it becomes very easy to start believing that a slow week makes you a lesser engineer. It does not. "I am enough" is not a comforting slogan to be printed on a mug; it is a load-bearing belief, and its absence is one of the quiet engines of burnout. There is a hard-nosed reason for leaders to care about this, quite apart from the human one. A person who believes their worth is their output cannot rest properly, and cannot set a boundary or say "this is not sustainable" without feeling that they are confessing to a personal failure. That is a brittle way to run a human being, and brittle humans produce brittle systems. I have made this argument at length in my posts on why [looking busy is costing you real output](/blog/continual-professional-development/slow-productivity-why-looking-busy-is-costing-you-real-output/) and on [why rest is part of the work](/blog/continual-professional-development/rest-why-stepping-away-from-the-screen-is-part-of-the-work/). Brown gets to the root of it in a single sentence: the worth was never the output in the first place. ## Perfection Is the Enemy of Done Not every line in the book is delivered gently. This one, which Brown attributes to a straight-talking friend, is my favourite precisely because it is not. > Quick and dirty wins the race. Perfection is the enemy of done. Good enough is effin' good enough. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Perfectionism dresses itself up as high standards, which is how it gets away with so much. In engineering it wears the costume of quality: the endless refactor, the abstraction built for six use cases when there is one, the pull request that never quite ships because it could always be a little cleaner. It feels virtuous. It is often fear in a smarter outfit, specifically the fear of putting something imperfect in front of other people where it can be judged. The antidote is the willingness to ship the good-enough thing, learn from what happens, and improve it in the open. That is not an argument for carelessness; "good enough" still has to be genuinely good enough for its context, and knowing where that line sits is most of the skill. It is an argument against treating polish as a substitute for progress. This is the same instinct that underpins a healthy relationship with [failure as a source of learning rather than shame](/blog/continual-professional-development/embracing-failure-a-key-to-success-in-the-modern-workplace/). You cannot learn from the thing you never dared to ship, and perfectionism is very often the well-mannered excuse for never daring to ship it. ## The Courage to Show Up and Be Seen Which brings us back to the arena. Brown ends the argument where Roosevelt began it, and the passage is worth reading slowly. > Where scarcity and shame dominate and feeling afraid has become second nature, vulnerability is subversive, even uncomfortable. It's even a little dangerous at times. And, without question, putting ourselves out there means there's a far greater risk of feeling hurt. But as I look back on my own life and what daring greatly has meant to me, I can honestly say that nothing is as uncomfortable, dangerous, and hurtful as believing that I'm standing on the outside of my life looking in and wondering what it would be like if I had the courage to show up and let myself be seen. > > — Brené Brown, [Daring Greatly](https://app.thestorygraph.com/books/c2ea6d65-b7be-46cc-852b-195205397e31) Everything else in this post is downstream of this. Blameless incident reviews, belonging instead of fitting in, trust built marble by marble: none of it survives in a team where being seen is dangerous. The whole job of a technology leader, underneath the architecture reviews and the roadmaps and the standing meetings, is to lower the cost of showing up and being seen getting it wrong. That is what lets people step into the arena instead of watching from the stands. Being seen getting it wrong is the harder path for the leader too. When I assess the real state of a team and report it honestly rather than comfortably, I am choosing the arena over the stands, and it does not always make me popular. I have learned to be at peace with that, because the alternative is the version of my own work Brown describes: standing on the outside of it, looking in, wondering what it would have been like to have the courage to be honest. Daring Greatly is the book where all of this starts. If you have found the ideas in my posts on "[Dare to Lead](/blog/continual-professional-development/leading-with-heart-and-mind-lessons-from-dare-to-lead-for-the-modern-workplace/)" and "[Rising Strong](/blog/continual-professional-development/finding-strength-in-vulnerability-lessons-for-tech-leaders-from-rising-strong/)" useful, this is the ground they were built on, and it rewards going back to. And if you are weighing up how your own team builds the kind of culture where people will actually step into the arena rather than fold their arms at the back of the room, [a consultation might be a useful place to start](/schedule-consultation/).