The Basics of Why Meritocracy Does Not Exist - The Power of Trust

Trust is our currency at work. Merit and job skill is only one aspect of building trust.

From a recent trip near Leavenworth.

Salvatore stomped into my office for his one-on-one meeting. He was clearly annoyed about something, and didn't waste any time letting me know what it was.

Salvatore huffed, "I just saw that Lamar got his promotion. How is it possible? I'm a better engineer, but I'm still not promoted."

"It can't end well to compare yourself to others," I replied, "but sure, we can talk about this. You remember that your promotion was held back because we couldn't find any senior peers to sign off on your promotion? You said you were going to work with Rene on that design document. What happened?"

He shrugged. "Rene is an idiot. I tried to review my plans with her, but she kept talking about things that don't matter."

The funny thing is that this isn't dramatized. I believe the word "idiot" was used in this case. It is shockingly common for employees, particularly engineers, to think that work is a meritocracy. More specifically, a meritocracy based on a specific skill or activity. For engineers, "I'm the best software engineer." For project managers it might be, "I'm the best at running projects."

While the job title for a software engineer might indicate that their job is to engineer software, that's not the whole story. Unless you're working at a startup of one, your job is to work with others to create value for a business. This includes your specialty (engineering, managing, project running, designing...) - but it also includes a variety of other skills. Most importantly, it includes working well with others.

Companies are not meritocracies. We are not valued based on our absolute skills or accomplishments. Employees regularly complain, saying that their company is filled with "politics." They're not being valued on their contributions, and instead they need to play the game.

While there are insider political games being played at times in companies, the majority of the time I've heard complaints, it is people railing against the need to build trust.

Trust vs Politics

If you understand the system, you call it building trust. If you dislike the need to build trust, you call it politics.

"I need co-workers to sign off on my promotion. I hate politics."

Co-workers are asked if they trust you and agree that you contribute value. That sounds like a good thing.

"The leaders of that group are all friends, and so they backed Erik's proposal over mine. Politics suck."

It sounds like a number of people who trust each other made a collaborative decision. It also sounds like they might trust Erik.

Trust is hard to quantify. You can objectively say that someone did or did not finish a task. It's harder to explain why one person is trusted more than another.

Why a Meritocracy can't exist

We would love to be objectively measured. I regularly hear that people want to take the bias out of the system, and measure people's contributions. While this might be possible if you're connecting bolts in an assembly line, in knowledge work I don't think it's possible.

Hitting dates: Meeting dates on tasks or projects is often used as a proxy for success. Yet some projects are more complex than others. People nervous about missing dates will set more conservative dates. Cutting features can let someone hit dates. Resource allocation and prioritization by those teams impacts dates.

Hours: Come in early and stay late. It's horrible when people use hours as a tool for meritocracy. Some people accomplish more per hour. Some people waste their time in an office. Some people do low value work.

Code volume or quality: For engineers, they often want to be measured on their speed of coding, or the quality of their code. Yet every single task is different. Some are more complex than others. Some require more innovation. Sometimes a single line of code adds more value than 10k lines of code. One person's brilliantly designed system is another team's nightmare for maintenance.

Business value: Particularly for product managers, I've seen them argue that the project they ran was worth $millions, or it beat expectations by some large percent. Yet often the same people launching the project set the expectations. Success of a project depends on dozens or hundreds of people. Some outsized success is a stroke of luck, and sometimes failure is the result despite genius.

For any knowledge based work, there isn't a way to "measure" value. Certainly not in an objective way.