Leadership Lessons from BJJ

I’ve been building software products, mentoring teams, and stepping into interim CTO roles for over twenty years now. I’ve seen my share of complex systems and tight deadlines, where unknowns and obstacles pop up like surprise submissions in a Jiu Jitsu match. Recently, I began training at Gracie Barra to explore Brazilian Jiu Jitsu (BJJ). Within six months of rolling around on the mats (and oftentimes getting choked and in the beginning they came like a shot in the dark), I started seeing strong parallels between how we develop software and how we train in BJJ, particularly under the philosophy of Master Carlos Gracie Jr.

Below are some of the similarities I’ve spotted. If you’re into software, or just curious about martial arts, you might find these connections as enlightening as I did.

Starting from Scratch in a New Tech Environment

I’d trained in Taekwondo and Kickboxing before, but stepping onto the BJJ mats felt like a completely new world. I was back to a white belt, realizing none of my striking skills could get me out of an armbar or chokehold. This changed my perspectives on defense, where my previous skills would fail and encouraged me to unlearn old habits, embrace the unknown, and trust the process of learning ground-based techniques from scratch. Interestingly, this mirrors what happens in software engineering when you join a new team, start a project in an unfamiliar tech stack, or switch companies altogether. You may have years of experience in one language or framework, but find it doesn’t directly translate to the new environment. You have to let go of “the way things used to work” and learn fresh approaches—sometimes from the ground up. In both BJJ and software, that beginner’s mindset can be humbling, but it’s also the key to growth.

Embrace the Unknown and Assess Risks

In BJJ, you never fully know what your opponent’s next move will be. You can anticipate patterns such as an armbar setup or a triangle choke but at the end of the day, you’re often reacting in real time and constantly changing strategies. The same dynamic applies to software engineering. No matter how well we plan, unexpected bugs, changing requirements, or performance bottlenecks will surface. How do we deal with that uncertainty? By staying alert, reading the situation, and mitigating risk. On the mat, you keep your limbs safe and tucked in, check your opponent’s grips, and protect vulnerable positions. In software, you add safety nets like feature flags, logging, monitoring and thorough testing. You also break complex work into smaller, more manageable chunks to spot issues early. We don’t freeze just because things are uncertain, we adapt, look for signals, and keep moving.

Know When to Tap and Pivot

One of the biggest lessons in BJJ is learning when to tap. This is specially important as as white belt where you discover your limits and start being comfortable with being uncomfortable. If you resist a well-executed submission for too long, you risk a serious injury that takes you off the mats entirely. In software, we also need to recognize those moments when a project or feature is going nowhere, or is at risk of causing major setbacks. Maybe we’re overbuilding a solution, over architecting, building a wrong product for a user, or we’re missing product-market fit. If the signs are telling us to change direction, it’s usually better to tap and pivot rather than insist on forcing something that just doesn’t work. This doesn’t mean giving up easily. It means understanding the difference between pushing through natural obstacles (like normal code challenges) versus pushing into a dead end that could harm the overall product. By recognizing when to “tap” in software, we protect our time, budgets, and team morale.

Flexibility in Strategy

In BJJ, you learn a wide variety of moves, chokes, arm bars, sweeps, escapes, and so much more. And you don’t just stick to one move you’re comfortable with; you try different sequences so you can adapt on the fly. This flexibility is crucial because no two opponents, body types, or rolling scenarios are exactly the same. Similarly, in software, the more design patterns, tech stacks, and leadership approaches you understand, the better equipped you’ll be to handle diverse challenges. Maybe you need a microservices architecture in one scenario, or a simpler monolithic design in another. Maybe your team responds best to a certain style of daily stand-ups or pair programming, but you need to tweak the approach for a distributed team in a different timezone. The more options you have in your toolbox, the easier it is to pivot and choose strategies that fit the situation. Or maybe the Agile methodologies you have picked don’t make you agile, you need to create a new set of practices and make it work for your project and your team.

Discipline and Consistency

Discipline is one of the core philosophies Master Carlos emphasizes. In BJJ, that discipline means showing up regularly, even when you’re sore or busy, and drilling fundamentals until they’re second nature. You can’t learn that perfect kimura setup if you only train once in a while. For me, that means even when I travel for fun or work I find a close-by Gracie Barra and get to practice with a new team for the time I am traveling. In software, discipline shows up as consistent coding practices, continuous integration, and sticking to a predictable release cycle. When you commit to “training” your software team the same way you’d train your BJJ moves, you see improvements in code quality, collaboration, and overall velocity. You also instill an ethos where new challenges become opportunities for growth rather than reasons to panic.

Teamwork: Organized Like a Team, Fighting Like a Family

One of the things I love about BJJ is how you and your training partners genuinely want each other to improve. Sure, you roll against each other, but you exchange tips, correct each other’s mistakes, and offer feedback. You want your training partner to be better because the next time you roll, you roll with a stronger and more aware opponent that helps you get better. Consequently, you take every measurement to ensure you are not hurting your partner. Even after an intense match, when both are laying on the ground gasping, eventually one gets up and holds the other person’s hand, gives them a high-fives and smiles. In software, we do our best work when we treat each other as allies rather than competitors. Pair programming, code reviews, and constructive retrospectives all help us collaborate. When one person on the team grows, the whole team levels up. Encouraging that culture of shared success strengthens both morale and technical expertise.

Switching Training Partners

One of the great things in BJJ class is how you switch partners multiple times per session. Sometimes you choose a partner you’re comfortable with, other times the professor pairs you up with someone who’ll either challenge you or teach you a new technique. You learn from a variety of people with different styles, body types, and skill levels. In some rounds, you’re the one dishing out tips; in others, you’re learning something completely new. The goal is not to win all the time, it is to be better than when you first walked in the door. In software teams, a similar dynamic happens when you rotate pairing partners or code-review buddies. Pairing with different teammates means you’re exposed to new perspectives, coding styles, and problem-solving approaches. Ask for feedback from your colleagues and the stakeholder will give you direction or might spark a new idea that helps you improve your skills or the product you are engineering. Even after two decades in engineering, I still learn daily from fresh engineers, whether it’s a new tool they’re using, a different way of thinking about architecture, or a shortcut I never considered. Switching partners (or pairing buddies) keeps the knowledge flow active and ensures everyone continues to grow.

Mentorship and Respect for Others’ Growth

BJJ is structured around ranks and belts, but higher belts don’t just show off; they guide beginners and share insights. There’s a mutual respect where everyone knows that at some point, we’ve all been the newbie who didn’t know how to tie the belt or execute a simple guard pass. In software, it’s similar. Principal engineers and senior devs should be mentors, not gatekeepers. When you share your knowledge with junior teammates by explaining design patterns, code reviews, or architectural principles, you create a culture of learning and trust. Being a mentor doesn’t mean forcing your solutions on others; it means guiding them to figure out their own paths, just as a higher belt encourages a white belt to adapt techniques to their style and body type. The Responsibility of Power and Knowledge A fundamental rule in martial arts is that you don’t use your skills to hurt others. You defend yourself and those you need, compete on the mat, and respect the boundaries of training partners. That responsibility matters off the mats too. The more skilled you are, the more careful you should be about the potential impact of your actions. As a software engineer, especially in today’s world of AI and data-driven products, the power of your work can affect millions of users. We need to be mindful of ethical considerations, data privacy, and security. Being “strong” in a technical sense isn’t enough; we must also ensure we’re using our knowledge for good and not putting users or communities at risk. That means thinking deeply about how a feature can be misused or how data might be leaked, rather than rushing to build something without considering the consequences.

Non-Quiting Spirit: Keep Showing Up

After half a year of training BJJ five to six times a week, I’ve learned that the secret sauce is simply showing up. Whether you’re battling an injury, traveling for work, or feeling overwhelmed by the daily grind, just put on the rash-guards! You adapt your training, maybe work on technique instead of hard sparring, but you stay in the game. One important thing to remember is to always make your partner know if you’re not feeling 100% or you are injured, they will understand and go at your pace. Within the first 3 months of my training, I popped my ribs 3 times. Some of you might know the pain that comes with every breath! But I showed up, I let my partner know and we rolled light, or just practiced techniques. The same perseverance sees software projects through tough times: from blocked tasks to budget cuts to shifting client demands. Adapting doesn’t mean quitting. Sometimes you switch gears, scale back scope, or refactor part of the system instead of building new features. You keep iterating until you find a path forward.

Putting It All Together

The lessons from Master Carlos’s Gracie Barra BJJ, discipline, teamwork, flexibility, respect, and responsible use of power, map almost one-to-one to the best practices I’ve seen in software engineering. Both pursuits require you to deal with unknowns, learn when to pivot, stay open to new techniques, and never forget the potential impact your decisions have on others. Whether you’re shipping code or refining your kimura, success boils down to practice, awareness, and a willingness to help those around you grow. So next time you’re on the fence about trying a martial art, or you’re looking for new ways to think about software leadership, consider giving BJJ a shot. You might discover that what makes you a better grappler can also make you a better engineer—and a better human being, too.