Stubbornness

For most people, “Stubbornness” conjures images of a frustrating coworker digging in their heels on the smallest of compromises. They probably hated the experience.

But if we flip perspectives, I doubt their coworker thought they were being stubborn. Instead, they likely viewed it as being persistent in a cause they have conviction in. It’s just perception.

This especially matters for startups where high level of stubbornness is practically a base requirement. Navigating the idea maze requires running into dozens of dead ends. Launches will flop, customers will churn, teammates will leave. Being successful requires getting through that gauntlet while still holding this crazy belief that the company can live up to your ambitions. It requires the right kind of stubbornness.

As I’ve developed in my career, I’ve found that the difference between productive and unproductive stubbornness is largely in what you choose to be stubborn about. Stubbornness itself (or persistence or discipline or …) is usually just a signal that someone gives a shit.

At its best, stubbornness:

1. Focuses on an end goal that matters to the organization. At some companies, this might look like being stubborn about giving a specific edge-case customer a great experience. At others, it might look like maintaining code quality across a scaled engineering organization. At almost all, it will not be standardizing on tabs vs. spaces.
2. Is flexible about the how, but fixated on the what. If you have a specific feature that’s confusing customers, you might try updating documentation, building a robust playbook for your customer support team, or overhauling the design. The goal is to solve the customer’s pain, not to just make the site prettier.

As an example: At AngelList, I was incredibly stubborn about fully automating the accounting for all of our venture funds. Sometimes that aligned perfectly with the company’s overall vision and we’d staff whole teams of engineers on building out these systems. In other quarters it felt like I was the only one who even cared about this issue. But because I was flexible on the route to this goal, I was able to disagree and commit in lean quarters while still keeping the idea alive.

Beyond myself, I try to manage stubbornness in my team by:

• Encouraging people to be stubborn about the right things. Reward good stubbornness and give feedback on the bad.
• Finding and sharing wins. Say your team is getting demotivated after a product launch a few months ago that hasn’t seen much growth. Yet you’re just starting to see signals that things are trending positively. Sharing those positive customer anecdotes or leading-indicators can help the team keep pushing until the win is obvious.
• Developing a balanced team that can be stubborn in different ways. I want to put the engineer who cares about readability on the infrastructure rewrite project and the product obsessive engineer on the customer-facing project. Coaching one into the other is likely going to yield worse results while also devouring time.
• Keeping the team focused on a small number of things that matter. You can only be stubborn about a few things at once without edging into asshole territory.
  • This includes redirecting people if they’re stubborn about something that doesn’t matter. This is a critical moment— doing it poorly can quickly demotivate the team, while doing it well can produce a superteam.
• Personally staying at the company for longer. The best way to encourage stubbornness is to model it yourself by staying long enough to build conviction and lead by example.

Ultimately, managing and directing stubbornness is a big part of my job as a leader. That doesn’t mean avoiding stubborn people, but finding them and channeling their energy into the things that matter.