Most tech leaders are stuck using just one leadership style. They’re like carpenters who only own hammers – great at nailing things, but helpless when they need to cut wood or measure distance.

Research and observations across companies like Stripe, Uber, and several high-growth startups reveal that the most effective tech leaders master three distinct styles: conviction, policy, and consensus. Here’s why each matters and how to develop them.

The Leadership Style Trinity

Most leaders naturally gravitate toward one style. Some are the decisive type who love making bold calls (conviction). Others are process people who create scalable systems (policy). And then there are the coalition builders who excel at getting buy-in (consensus).

But here’s the uncomfortable truth: relying on just one style is leadership malpractice.

Let’s examine why.

Style 1: Leading with Conviction

Consider the last truly contentious technical decision a team might face. Perhaps choosing between monolith vs. microservices, adding a new programming language, or completely reorganizing the engineering department.

These situations share three characteristics:

• Extreme ambiguity
• High uncertainty
• Significant organizational inertia

This is where conviction leadership shines. It’s about making personal decisions on critical, contentious problems and seeing them through to execution.

Real Talk: When Conviction Works (And When It Doesn’t)

At Carta, the engineering leadership faced a major inflection point with their quality strategy. The existing processes weren’t scaling, and they had competing visions for the path forward. After deep analysis and stakeholder discussions, the leadership made a conviction call to implement a radical new approach.

Key lesson: The success wasn’t just in making the decision – it was in the follow-through. The team spent weeks communicating the vision, addressing concerns, and pushing through the inevitable friction.

But contrast this with a similar situation at Calm, where a conviction-based approach to quality strategy failed spectacularly. Why? Because the leadership missed crucial context and didn’t test the decision widely enough before pushing forward.

Style 2: Leading with Policy

Some decisions happen so frequently that making each one a special snowflake is organizational suicide. Consider:

• Quarterly planning
• Hiring and promotions
• Headcount allocation

This is where policy leadership becomes crucial. It’s about creating consistent frameworks that scale across the organization.

The Stripe Example

Stripe transformed their candidate review process from a haphazard exercise into a well-oiled machine. The key wasn’t in making better individual decisions – it was in creating a robust policy that:

1. Defined clear evaluation criteria
2. Established consistent decision-making processes
3. Built in feedback loops for continuous improvement

But here’s where it gets interesting: they tried the same policy-driven approach with Agile development practices, and it backfired. Why? Because they treated something that needed situational flexibility as a one-size-fits-all policy.

Style 3: Leading with Consensus

Sometimes decisions arise where:

• Context is scattered across multiple stakeholders
• There’s no clear decision-maker
• The impact is significant but infrequent

This is consensus territory. And make no mistake – it’s often the most challenging style to master.

The Uber Monolith Story

Uber faced the classic monolith decomposition challenge. No single person had complete context across all affected systems. The solution? They formed a decision-making group that:

• Represented all key stakeholders
• Established clear decision criteria
• Created a shared understanding of the problem space

The result was a successful decomposition strategy that had broad buy-in across the organization.

But contrast this with a reduction-in-force (RIF) situation at Calm. The leadership tried to build consensus around the approach, but the reality was that this type of decision needed conviction leadership instead. The lesson? Not every decision should be consensus-driven, even if it feels more comfortable.

Developing Your Leadership Style Portfolio

Here’s the good news: these styles are learnable skills, not innate traits. Here’s a practical approach to developing them:

1. Audit Your Current Style

• Track your next five meaningful decisions
• Note which style you naturally used
• Identify your comfort zone and blind spots

1. Force Style Diversity

• Once a month, intentionally pick a problem to solve using your least comfortable style
• Start with lower-stakes decisions to build confidence
• Gradually tackle more significant challenges

1. Create Learning Loops

• Document outcomes of decisions made with each style
• Analyze what worked and what didn’t
• Adjust your approach based on feedback

The Style Selection Framework

When faced with a decision, ask:

• Is this a highly ambiguous, contentious issue that needs decisive action? → Conviction
• Is this a frequent decision that would benefit from consistent handling? → Policy
• Is this an infrequent decision with distributed context and no clear owner? → Consensus

Moving Forward

The mark of a truly effective tech leader isn’t mastery of any single style – it’s the ability to fluently switch between styles based on the situation at hand.

Start by auditing your leadership style portfolio. Where are the gaps? Which style feels most uncomfortable? That’s probably where the biggest opportunity for growth lies.

Remember: The goal isn’t to become equally comfortable with all styles (that’s probably unrealistic), but to be competent enough in each to deploy them effectively when the situation demands it.

The challenge for every leader: For the next significant decision, pause and consciously choose a leadership style rather than defaulting to comfort zones. The results might be surprising.

The best tech leaders aren’t the ones who make the best decisions – they’re the ones who know how to make decisions in the best way for each situation.

The post was heavily inspired by this post by Will Larson.