Why Developer Productivity Isn't About Your Tech Stack

Here's something that's going to sound wrong at first: the tools you use matter less for productivity than how you feel about your job.

I know, I know. We're talking about developers here—people who live and breathe tech stacks, who can argue for hours about which IDE is objectively superior. But Yanina Ledovaya, a cognitive psychologist who leads the developer experience research team at JetBrains, just presented data at GOTO Copenhagen that should make every engineering manager rethink their entire approach.

The problem is we're measuring the wrong things. Lines of code, pull requests, velocity—these are the "low-hanging fruit" metrics that Ledovaya says we chase because they're quantifiable and observable. Meanwhile, the actual drivers of productivity are invisible to our dashboards.

What Google and Microsoft Already Know

A 2021 Google study surveyed 622 developers across three companies about what predicts their productivity. The top factors weren't technical at all: job enthusiasm, peer support for new ideas, and receiving useful feedback about performance. Not a single mention of tooling.

Microsoft Research found similar patterns. When they asked developers to rate factors for perceived productivity, the winners were having a good manager, feeling productive (yes, it's circular), being fairly rewarded, and positive team culture. Technical factors didn't crack the top tier.

This keeps happening. Different companies, different methodologies, same result: social factors outweigh technical ones.

The Psychology Everyone's Accidentally Rediscovering

Ledovaya's argument is that all these studies are independently confirming something psychologists have known since the 1970s. It's called Self-Determination Theory, and it identifies three basic psychological needs that drive intrinsic motivation:

Autonomy — feeling like you have choice and control over your work, that you're the agent of your own behavior rather than "a pawn of external pressures."

Competence — feeling effective and capable, able to demonstrate and develop your skills.

Relatedness — feeling connected to and valued by others who share your goals and values.

"Productive humans are motivated humans," Ledovaya told the conference audience. "It's as simple as that."

The theory comes from Edward Deci and Richard Ryan, who've spent decades building an evidence base that makes Maslow's hierarchy look like a napkin sketch. (Ledovaya, delightfully blunt for an academic, admits Maslow's pyramid "has very little real-life evidence.")

What's interesting is that these three needs map cleanly onto the productivity factors companies keep rediscovering. Job enthusiasm? That's what happens when your autonomy and competence needs are met—you achieve results the way you think is best. Useful feedback? Hits both competence and relatedness. Peer support for ideas? All three at once.

The SPACE Framework, Decoded

The SPACE framework—one of the most respected models for assessing developer productivity—measures five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow.

Ledovaya's team analyzed how Self-Determination Theory shows up across all five dimensions. Satisfaction obviously depends on all three psychological needs being met. Performance outcomes improve when developers feel autonomous and competent in their tasks. Communication and collaboration are fundamentally about relatedness. Even flow states require a specific balance: enough autonomy to schedule uninterrupted focus time, enough competence to avoid constantly second-guessing yourself.

The framework already works, but understanding the psychological foundation explains why it works—and what to do when something's off.

The Measurement Problem

Here's the tension: intrinsic motivation is crucial for knowledge workers, but it's "far away from any kind of tool-related observability," as Ledovaya puts it. You can't instrument it. There's no dashboard.

Extrinsic motivation—salary, bonuses, promotions—is easy to manage because it's transactional. You do X, you get Y. Everyone understands the deal. But extrinsic rewards alone don't prevent burnout or disengagement.

Ledovaya's solution is surprisingly straightforward: just ask people. She provides example survey questions throughout her talk:

• Do you feel free to do your job the way you think it could best be done? (Autonomy)
• Do you feel that you have the skills and resources needed to perform your job effectively? (Competence)
• Do you receive feedback or recognition that you're doing a good job? (Relatedness)

These aren't magic. They're templates you can customize. But the act of asking signals something important: you're treating developers as humans with internal experiences, not just units of output.

What This Means for Teams

The implications are pretty direct. If you're optimizing for productivity, you should probably:

• Let developers choose how they accomplish their work, not just what they accomplish
• Create structures for meaningful feedback—not just performance reviews, but regular recognition and peer support
• Build team cultures where people feel genuinely connected to shared goals
• Stop assuming better tools automatically equal better productivity (though they don't hurt)

Ledovaya references a Picasso painting called "Accordionist" where the human figure is barely visible—obscured by the abstraction. That's what happens when we focus entirely on metrics and forget we're working with people.

The developer as human being goes missing.

Which raises an uncomfortable question: how many of our productivity initiatives are built around what's easy to measure rather than what actually matters? And if we started from the other direction—from human needs instead of observable outputs—what would we build differently?

Zara Chen is Buzzrag's Tech & Politics Correspondent