How Your Leaders Can Capitalize on Humility
The leadership skill that compounds fastest isn't technical expertise or strategic vision — it's the willingness to say 'I don't know yet.' Here's how humility becomes a competitive advantage.
I was twenty-one years old when I became IFC President at UCLA — responsible for governing thirty-plus fraternity chapters, managing competing interests between organizations that didn’t always like each other, and representing the entire Greek system to university administration. I had no training for this. No leadership manual. No MBA framework.
What I had was the instinct to shut up and listen before I decided anything.
That instinct turned out to be worth more than every other skill combined.
The Wrong Model of Leadership
There’s a version of leadership that gets celebrated constantly — especially in tech. The visionary CEO who sees around corners. The decisive founder who trusts their gut. The technical leader who always has the answer.
This model produces leaders who are terrified of saying “I don’t know.” They equate uncertainty with weakness. They make premature decisions to project confidence. They hire people smarter than themselves and then override them because admitting someone else has a better answer feels like losing status.
I’ve watched this pattern destroy teams. Not dramatically — slowly. The engineer who stops raising concerns because they’ve been overruled too many times. The analyst whose insights get repackaged by their manager without attribution. The new hire who has the best idea in the room but hasn’t earned the political capital to say it yet.
The leader in this model isn’t leading. They’re performing.
Humility as an Information Advantage
Here’s the reframe that changed how I think about this: humility isn’t a personality trait. It’s an information-gathering strategy.
When I took over as IFC President, the previous administration had a tense relationship with several chapters. My instinct — probably influenced by my cognitive science studies — was to understand the system before trying to change it. So I spent my first three weeks doing nothing but listening. I met with every chapter president individually. I asked the same three questions: What’s working? What’s broken? What would you do if you had my job?
Three things happened:
I got better information than any predecessor. People tell you what they actually think when they believe you’re genuinely listening, not just collecting ammunition for a predetermined decision. By week three, I had a clearer map of the political landscape than the outgoing president had after a full term.
I built trust before I needed it. Every relationship I formed during those listening sessions became a line of credit I could draw on later. When I eventually had to make unpopular decisions — and I did — people gave me the benefit of the doubt because they’d experienced me taking their perspective seriously.
I made better decisions. This is the obvious one, but it’s worth saying explicitly: decisions informed by diverse input are simply better than decisions made in isolation. I’m not smarter than thirty chapter presidents combined. I don’t have their context. Humility isn’t just nice — it’s empirically superior as a decision-making strategy.
How This Translates to Technical Leadership
I’m an AI engineer now, not a fraternity president. But the pattern is identical.
In technical architecture decisions: The best technical leaders I’ve worked with don’t prescribe solutions — they define constraints and let the team find the path. When I’m designing a system, I present the problem and the constraints to the people who will build it, and I ask: “What am I missing?” The number of times someone has pointed out a failure mode I hadn’t considered is humbling. That’s the point.
In stakeholder management: AI projects fail when technical leaders can’t translate between engineering and business. The translation skill isn’t about dumbing things down — it’s about having enough humility to understand that the business stakeholder’s concerns are real and valid, even when they’re not technical. “The model accuracy is 94%” means nothing to a VP who wants to know if their team can trust the system. Meeting them where they are requires admitting that your framing isn’t the only valid one.
In mentoring: The most impactful thing a senior engineer can do for a junior engineer isn’t teaching them the answer. It’s showing them that not knowing the answer is a normal, productive state. When I mentor junior team members, I deliberately think out loud — including the dead ends, the uncertainties, and the moments where I change my mind. This does more for their development than any code review.
The Compound Effect
Humility compounds in ways that confidence doesn’t.
A leader who admits what they don’t know attracts people who are willing to fill those gaps. Over time, they accumulate a network of collaborators who trust them, contribute voluntarily, and stay loyal through difficulty — because they’ve experienced being genuinely valued for their perspective.
A leader who projects certainty attracts people who are comfortable being directed. Over time, they accumulate a team of executors who do what they’re told but don’t volunteer insight, don’t flag risks, and leave when a better-paying directive appears.
The first leader has an information advantage that grows every year. The second has an information deficit that grows every year. By year five, they’re operating in completely different realities.
The Practical Application
If you’re a leader — or aspiring to be one — here’s what capitalizing on humility actually looks like in practice:
Start every new role, project, or team by listening. Not for a day. For weeks. Ask the people closest to the work what they see. Take notes. Resist the urge to “add value” immediately. Your value in the first thirty days is your fresh perspective — which you can only offer if you’ve actually gathered information first.
Say “I don’t know” out loud, regularly. Follow it with “but here’s how I’d find out” or “who on this team would know?” This models intellectual honesty for everyone around you and gives permission for others to admit uncertainty too. Teams where uncertainty is safe are teams that catch problems early.
Give credit with specificity. Not “great work, team.” Instead: “Sarah’s insight about the caching layer changed our architecture for the better.” Specific attribution builds trust and incentivizes people to keep contributing their best thinking.
Make decisions transparently. When you do decide — and leaders must decide — show your reasoning. “Here’s what I heard, here’s the tradeoff I’m making, and here’s what would change my mind.” This isn’t weakness. It’s an invitation for ongoing feedback from people who might see something you don’t.
Treat every person’s context as valid. The intern sees things the VP doesn’t. The customer support agent knows failure modes the engineer hasn’t imagined. The junior analyst noticed a data quality issue that invalidates the dashboard the C-suite is reviewing. Humility means believing that insight can come from anywhere — and building systems that capture it.
The Paradox
The paradox of humble leadership is that it looks like weakness to people who don’t understand it and looks like a superpower to people who’ve experienced it.
I’ve been on both sides. I’ve watched confident leaders make fast decisions that felt good and turned out to be catastrophically wrong. I’ve watched humble leaders take an extra day to listen, make a better decision, and build a team that trusted them enough to execute it with conviction.
The leaders I want to work for — and the leader I’m working to become — are the ones who understand that certainty is expensive and humility is free. In a field that changes as fast as AI, the only sustainable advantage is the willingness to keep learning.
That starts with admitting what you don’t know yet.
This is part of my ongoing writing about leadership in technical organizations. My perspective comes from leading the UCLA Interfraternity Council (30+ chapters, multi-stakeholder governance), building AI systems at CGI, and studying how humans process information through my cognitive science background. More at natewhiteman.com.