The Learned Helplessness of Scrum Tech Leads
JIRA Jockey isn't a Job Anymore
Once upon a time—at least according to legend passed down from the mist-shrouded past—the Tech Lead was a builder.
They were architects of invisible empires—guiding, shaping, and scaling systems without needing to micromanage pixels or timelines. They held mental models of sprawling architectures and led engineers toward elegant solutions. Their job wasn’t to write every line of code, but to decide how the codebase should think. To model the right abstractions. To shape the invisible scaffolding behind the product.
That mythical Tech Lead is mostly gone (if they ever really existed).
Now, the Tech Lead is a glorified JIRA traffic cop, dragging half-digested user stories across the finish line in weekly sprint rituals. When a new feature lands, they don’t architect it. They coordinate. They schedule grooming meetings. They try to decode why the PM attached seven Loom videos for a dropdown menu. They micromanage subtasks in the backlog and chase down code reviews.
They no longer lead much of anything.
And the worst part? They’re fine with that. If anything, they’re comfortable.
How It Was Supposed to Work
The textbook version of product development goes something like this:
🔭Executives determine the markets the company should compete in, define the strategy, and understand the company's unique strengths.
🔎Product Managers uncover customer pain points and identify potential features or products to solve them. They test those assumptions and confirm what actually works.
🗺️Engineers and Designers figure out how to implement those solutions—and then build them.
Division of labor. Everyone playing to their strengths. Harmony.
Most companies don't look like that. Thanks to widespread Peter Principling, most managers are more comfortable doing a job one or two rungs below them.
📃Executives hand down lists of features, often based on what the last sales prospect complained about.
🗺️Product Managers, desperate to justify their role when the decision is already made, become shadow designers and architects. They micromanage the UX and write system designs masquerading as user stories.
🪚Tech Leads, seeing all this in place, shrug and stop trying to shape the product. Their job is reduced to pointing out that the PM’s fine-grained tickets forgot to mention empty states, and figuring who on the team is a flight risk.
The downward cascade of activity hurts companies on both ends. The leaders are unable to make decisive strategic moves, while tech leads on the ground become overpaid backlog gardeners. Meanwhile, PMs complain that things don’t “feel like Agile” without acknowledging that they’re not even doing Product.1
Learned Helplessness
Ceding control is easy in the short term. Product Managers are honestly not terrible at solution design, and Executives aren't wrong about strategic customers wanting features. It's hard to hold your ground against a charismatic and ambitious climber who likes doing parts of your job (that's why your PM is acting like this, themselves2).
But if every idea already comes half-built from the PM—with high-fidelity mockups, flow diagrams, and success criteria—your role isn’t to think deeply about the product. Your role is to implement it with minimal friction.
Honestly? It’s kind of nice. Someone else defines the structure. The tickets are pre-chewed. Your junior can take it from there. You negotiate what can be shipped, put up a symbolic resistance to the “nice-to-haves,” and get it to staging.
And it’s not that you can’t still think about systems (though honestly, you wonder about some of your peers)—it’s that you don’t anymore. You don’t get the reps, except for purely technical decisions. You forget how to hold big ideas in your head. You learn to think in half-screens and edge cases. Your strategic muscle atrophies.
Then, one day, you realize you haven't made a real architectural or domain model decision in years, but you're still collecting a pretty good paycheck. Unfortunately, this is a tragically bad time for complacency.
Why Engineers Get Paid So Much
For a long time, there were two good reasons engineers got paid like royalty:
They were the bridge between non-technical ideas and technical execution. If someone had a startup idea, it didn’t matter how good it was—they needed someone to build it. Engineers were the tollbooth.
They could go solo. Even if they didn’t really know how to sell or market or do customer discovery, engineers could build something fast, launch it cheaply, and eventually iterate their way to a business. Their iteration costs were near zero. Everyone else needed a partner and funding to play the game.
That’s why compensation ballooned (there were other reasons too). That’s why engineers got handed founder titles for writing Python in a garage. Both of those advantages are rapidly collapsing.
Refactored Right Out of a Job
Picking up those responsibilities again might help you stay relevant - for now. But the bar moves fast. In a world where AI is your junior dev, systems thinking was table stakes. While your PM is squeezing you from one side, AI tools are squeezing even harder from the other. Since the last time you checked on copilot, it's learned how to do most of your job.
A smart generalist—armed with a good idea and a few prompts—can now spin up entire applications using Lovable3. No engineering degree. No tech lead. No sprint. We’re going past co-pilots to complete team replacements—but 10x faster and nearly free. And their code is clean and well structured, because LLMs never get bored of building things the right way.
Even the Product Manager isn’t safe. AI can generate user stories, build Figma mocks, write onboarding copy, and simulate user flows. And it’s not "vibe coding." It’s structured, testable, and increasingly… good. A tweet can build a plausible MVP, and a good requirements document can build a plausible beta.
The new advantage comes from everything around the code: figuring out what to build, how to position it, how to talk to users, and how to incorporate it faster than anyone else.
What’s Left for Engineers
Engineers now face a fork in the road:
Be the 25% still running complex systems. Some software is still too messy, too chaotic, or too nuanced for GPT to handle. Mission-critical infra. Legacy monsters. Real-time data pipelines. These systems aren’t going away—but they’re not growing enough to replace CRUD work, either.
Go solo. Start your own business without giving up equity. Use AI tools to move fast. But now you’ll need the skills you never had to build:
Talking to customers
Identifying real pain points
Positioning and marketing
Iterating based on feedback
Building taste
Ostrich Mode. Convince yourself it's not happening. Six months ago, LLMs could only get 80% of the way there for nearly free, so why wouldn't someone pay you six figures to get 95% of the way there?
The Coming Founder Wave
If you're going solo, move fast. For decades, founders needed a team, a burn rate, an office. Just getting from idea to MVP might cost a million bucks. If engineers have been the tollbooth between idea and product, VCs have been the tollbooth between normal bank account balances and affording engineers.
For three decades, founders have had to either be technical or be socioeconomically adjacent to the Sand Hill Road crowd. This constrained the number of players while allowing funds to demand early equity at a steep discount. Not anymore, and the shift will hit the world economy like straight adrenaline.
Now, you can test an idea with $100 and a weekend. You can launch a product without ever opening VS Code. You can get revenue before you hire your first engineer. Implementation is democratized, and we might be looking at a three order of magnitude increase in the accessibility of starting a revenue-generating company with a tech stack. That’s huge for the quality of products. It’s probably huger for American and global social structures.
Coding Speed Is No Longer a Moat
With the shipping bottleneck automated, ideas do matter again—but Amdahl’s Law tells us the bottleneck will shift somewhere else. The people who thrive won’t be the ones who memorized the latest frontend framework. They’ll be the ones who know how to converge on product fit.
When everyone is fast, speed of shipping isn’t an edge. The new edge is knowing where to go, and how to iterate. In a world where anyone can build anything, the winners are the ones who quickly build the right thing—fast, cheap, and with no one to blame but themselves.
You don’t need permission to lead again. Just the nerve to ship without a ticket, and the willingness to learn what you do then.
Calling yourself a “mini CEO” with no direct reports or P&L is certainly a choice.
Sort of like how the Roman Empire accidentally collapsed because the Goths were fleeing the Huns, and it ended up easier to just sack Rome.
You’re probably already convinced it can’t do any of that. Try pasting in the last PRD you were handed.