Part 3: Relatedness – Meaningful Work with People You Respect

Self-Determination Theory tells us that along with Autonomy and Competence, Relatedness is the third pillar that holds up intrinsic motivation.

It’s a fancy word, but think of it this way: Do I care about the people I work with and do I feel they care about me? Do I find meaning in the mission of my work, and a sense of belonging in this team or organization?

If the answer is yes, you’ve got an engaged employee. If it’s no, well… you get what I was in that first startup – a mercenary collecting a paycheck, half-eying the exit.

"Trench Trust" vs. Happy Hour

This is the third post in our series on Self-Determination Theory (SDT). We’ve covered Autonomy (control over your work) and Competence (getting better at your work). The third pillar is Relatedness.

In corporate speak, this usually gets translated as "Team Building." It manifests as forced fun—Zoom happy hours, pizza parties, or trust falls.

But in high-performance environments—whether it's a dev team, a trading floor, or a PE firm—Relatedness looks different. It relies on Professional Trust.

It answers two specific questions:

Do I trust the people to my left and right to do their jobs?

Is it safe to tell the truth here?

Psychological Safety is "Low-Latency Error Reporting"

Google’s famous "Project Aristotle" studied effective teams and found that the number one factor for success was psychological safety.

Engineers often dismiss this as "soft." So let’s reframe it: Psychological Safety is low-latency error reporting.

If your team fears looking weak or getting blamed, they will hide their mistakes. They will sit on a bug for three days hoping they can fix it before anyone notices. They won't ask for help until the deadline has already exploded.

In a "safe" team, an engineer says, "I messed up the estimates," or "I broke the build," immediately. This is a tactical maneuver. It signals to the team: We deal in facts here.

As a leader, you build this by modeling Intellectual Honesty. When I make a bad call, I state it clearly: "I was wrong about that architecture. That’s on me. Here is the fix." When the leader admits a tactical error without shame, the junior engineer can raise a flag on a critical bug without fear.

The "High-Performance Jerk" Paradox

Standard HR advice says you cannot have a high-performing team with "jerks." We all know that is false. Some of the most successful firms in the world—hedge funds, top-tier law firms, intense startups—run on aggression and fear. They work because the "Relatedness" there is based on Shared Elitism. The belonging comes from being part of the "best," even if the "best" are unpleasant.

But in Software Engineering, the "High-Performance Jerk" incurs a specific tax: Opacity.

Software is a highly coupled activity. If a developer is brilliant but toxic—sarcastic in code reviews, demeaning in meetings—their teammates stop interacting with them. They stop asking questions. They stop reviewing that person's code deeply. They route around the damage.

In a complex distributed system, this social friction turns into technical debt. You can tolerate the jerk, but you have to accept the cost: his code will eventually become a black box that no one else understands because no one wants to talk to him. In my experience, that tax is rarely worth the output.

How to Build Connection (The Graybeard Way)

You cannot force affection. You can, however, engineer respect.

The "Why." (Mission Connection) Engineers are cynical, but we are builders. We want to know our build is being used. I once had a team grinding on a boring refactor of a support ticket system. Morale was low. I brought in a customer service rep to talk to the devs for 15 minutes. She showed them how the old system forced her to click 12 times to reset a password, and how their new code dropped it to 2 clicks. She literally said, "You guys gave me an hour of my day back." The mood shifted instantly. The code didn't change, but the connection to the mission did. Connect the ticket to the human outcome.
Asynchronous Inclusion. "Culture" is often defined by the loudest extroverts in the room. This alienates your deep thinkers. I had a brilliant but introverted engineer who never spoke in brainstorming sessions. I switched our format. Before a big architecture decision, I started asking for written thoughts in a shared doc 24 hours before the meeting. Her written insights were devastatingly good. When I highlighted them in the meeting ("As Sarah pointed out in the doc..."), she became a central part of the dialogue. True inclusion designs channels where the quiet signal can be heard.
The Remote Reality. In 2025, organic connection requires engineering. My favorite trick is the "Human Check-in." I start 1:1s with "How are you doing?" and I actually wait for the answer. If a team member is burning out, or has a sick kid, I need to know so I can adjust the load. That is basic operational awareness.

The Multiplier Effect

Here is the math of SDT in the workplace: Relatedness is the multiplier.

You can give someone Autonomy (freedom). You can give them Competence (growth). But if they feel isolated—if they feel like a mercenary—they will take those skills you helped them build and walk across the street for a 10% raise.

When people feel connected—to the mission and to each other—they dig in. They stay for the hard parts. They fix the bug at 6 PM on a Friday because they don't want to let the team down.

This concludes our series on Self-Determination Theory.