Why OKRs and Agile Fail When People Are Treated Like Automation

There's a certain kind of workplace that turns every management tool into a weapon. OKRs become a stick to beat you with. Agile becomes a way to slice a waterfall into bite-sized chunks of misery. You've probably felt it—that low-grade dread when someone mentions a sprint review or a quarterly goal-setting session. It's not the tools themselves that are toxic. It's what people do with them.

I recently took a strategy and management course, and we studied these frameworks in a clean, academic way. They looked elegant on paper. OKRs were about setting direction. Agile was about adapting to change. But step into the real world, and you see the same tools used to grind people down. The gap between theory and practice is where the toxicity lives.

The 70% Trap

OKRs were designed to be uncomfortable. The original idea: you set ambitious objectives that you might only achieve 70% of. That stretch is supposed to push you beyond your comfort zone. But some managers decided that the 70% completion rate makes a perfect performance review metric. Suddenly, everyone is exhausted, because they're being graded on a system that literally expects them to fail a third of the time.

That's a clear misuse. OKRs are a goal-setting framework, not a performance appraisal. The objective is the direction. The key results are the milestones that show you're making progress. The whole point is to align the company around a shared vision. It's meant to drive change, not to monitor the health of existing operations.

KPI vs. OKR: Two Different Animals

KPIs are for monitoring the health of what you already have. You can have every KPI green—revenue up, churn down, servers humming—and still feel lost. That's when you need an OKR. It tells you, "Here's where we're heading next." You set a new direction, then define measurable key results to keep everyone moving together.

Most management textbooks will tell you: keep OKR self-assessments separate from KPI-based bonuses. Give people a sense of safety, and they'll actually take risks. But when you tie OKR completion to a bonus, the safety vanishes. People start protecting themselves. They set goals they know they can hit with 100% certainty. The tool that was supposed to encourage exploration becomes a stage for performing loyalty. The ambitious person sets a moonshot, hits 70%, and gets labeled a failure. The calculating person sets a low bar, clears it completely, and becomes a star. In the end, OKRs end up less effective than KPIs ever were.

And don't flip it either. You can't apply the "70% is fine" mindset to KPIs. Nobody accepts 70% uptime for a server. Some things are non-negotiable. That's the whole point of a KPI. When you mix the two, nobody knows what the standard actually is. Everyone starts guessing what the boss wants.

Agile's Broken Promise

Agile development was born from a simple observation: you can't know everything before you start. Instead of writing a perfect spec and executing it blindly, you build in small increments, show users, get feedback, and adjust. Each sprint ends with something usable. Then you pivot based on what you learned.

That's real agility. But in a toxic workplace, managers take a giant waterfall plan and chop it into sprints. It's still a fixed plan, just delivered in pieces. Each sprint becomes a progress report on a predetermined schedule. This fake agile only tries to solve the problem of execution efficiency. Real agile is about embracing uncertainty—the kind that comes from the outside world, from real users with real needs.

"Embracing Change" as a Weapon

The phrase "embracing change" gets thrown around a lot. It sounds noble. In reality, it's often used to justify a product manager changing their mind every other day because they had a new thought at lunch. That's not market feedback. That's just chaos.

The original intent of "embracing change" was to allow the product to evolve in response to genuine user feedback. But user feedback is not the same as a PM's shifting whims. Even in the strict Scrum playbook, change has a controlled mechanism. A sprint is locked for two to four weeks. During that time, the scope is frozen. Nobody can barge in and change the task mid-sprint. That lock protects the developer's ability to plan and focus. The product owner can update the backlog anytime, but new ideas wait until the next sprint. They don't crash into the work already in progress.

Refactoring Is Not a Luxury

Another casualty of fake agile is refactoring. In real agile, refactoring is a core activity. It's like breathing—you do it constantly. When you add a new feature and the code structure starts to creak, you refactor to make room for the future. A feature isn't "done" until it passes tests, meets quality standards, and is properly refactored. If you keep piling on features without refactoring, you rack up technical debt. The code becomes rigid. The next change costs twice as much. Over time, the system turns into spaghetti that everyone is afraid to touch.

But in a toxic environment, refactoring is seen as a waste of time. "We don't have budget for that." So the debt grows. The codebase becomes a minefield. And the developers get blamed for being slow.

The Real Target: Authoritarian Structure

Why do so many people in the Chinese-speaking tech world hate OKRs and agile? I think the hate isn't really aimed at the frameworks. It's aimed at the authoritarian structures that twist them into tools of oppression. OKRs and agile were supposed to bring a human touch to work—to give people autonomy, purpose, and a sense of control. But in a system that's already top-down and control-hungry, those humanistic ideals get warped. They become machines for squeezing every last drop of effort out of people.

Developers are human resources, but the emphasis too often lands on "resource." They're treated like automation—expected to produce predictable outputs at maximum speed, with no regard for the messy reality of human creativity and fatigue. And then, paradoxically, they're expected to act like humans when it comes to "passion" and "initiative." It's a double bind.

What Actually Works?

So what's the fix? It's not about abandoning OKRs or agile. It's about restoring the original intent. If you're a leader, ask yourself: Are you using OKRs to set direction, or to micromanage? Are your sprints truly iterative, or just a sliced-up waterfall? Are you giving people the psychological safety to aim high, or are you punishing them for falling short of an unrealistic target?

And if you're a developer stuck in a toxic workplace, know that you're not alone. The problem isn't you. It's the system. You can try to push back, document the misalignments, or look for a healthier culture. But don't internalize the failure. The tools aren't broken. The people wielding them might be.

In the end, the best management frameworks are the ones that respect the humans using them. That means tolerating uncertainty, allowing for failure, and understanding that people aren't machines. They're messy, unpredictable, and capable of amazing things—if you let them.