Scrum vs. Not-Scrum, A day in the life of "10x Developer" teams, Hard-work Myths

Issue #69 Bytes

Oct 26, 2025

🌱 Dive into Learning-Rich Sundays with groCTO ⤵️

Article of the Week ⭐

“Of course, in a frequent-release feedback-driven environment, there will be little or no backlog to manage because it will be changing continuously as we learn. There’s no point in a large backlog if we’re just going to throw away most of it.“

Scrum vs. Not-Scrum

Allen Holub’s latest essay lands on Scrum orthodoxy. He argues that the Product Owner role, as defined in the Scrum Guide, has become a hollow proxy for what real product leadership requires. The title promises ownership, but in practice, it often reduces to backlog management and ticket grooming, a far cry from the creative, market-facing, and strategic work that true product management demands.

The PO Is a Ticket Manager, Not a Product Leader

The Scrum Guide defines the Product Owner as someone responsible for ordering the backlog and setting product goals. On paper, that sounds strategic. In practice, Holub says, it turns people into “ticket monkeys.”

They spend their days writing, refining, and prioritizing stories, while the actual product vision is either assumed, outsourced, or lost entirely. In an environment built on continuous delivery and learning, the idea of maintaining a giant backlog doesn’t even make sense.

A healthy team needs 4 or 5 clear next steps based on what they’ve just learned. They doesn’t need 200 stories waiting in line. Yet POs, desperate to stay busy, invent work: expanding tickets with unnecessary detail, creating busywork that looks like progress but isn’t. This is what happens when you define ownership as maintenance instead of market-driven problem-solving.

Management Is Not Optional

A true Product Manager:

Understands the customer problem deeply
Shapes direction through insight, not backlog order
Measures success in business and user outcomes, not tickets completed

In contrast, the Scrum-defined PO rarely touches any of this. Seemingly a category error, mistaking coordination for leadership, often expressed from certified trainers:

“Our POs do learn product management. We teach all of that in our courses.”

Evident in many organizations beyond the 2000s, notably startups, there exists a hard line between Scrum-as-taught and Scrum-as-practiced. In the real world:

Most organizations apply Scrum mechanically
Cultural norms overpower whatever people learn in a course
Even good training gets buried under the weight of incentives, legacy thinking, and Jira dashboards.

The Scrum Guide itself is the official definition of “Scrum”. And it doesn’t mention any of the deeper product principles trainers have to smuggle in. That’s why so many teams believe they’re doing Scrum when they’re just performing ritualized project management with daily standups. Scrum-by-the-guide taken at its word and in isolation is pretty worthless.

Scrum was never a standalone Agile process. It started as a wrapper around Extreme Programming (XP). XP is one of the more pragmatic ways to make Agile methods more acceptable to traditional management. Scrum softened XP’s discipline and diluted its agility. Two decades later Scrum still functions the same way: a thin layer of process designed to make management feel safe, while teams underneath do the real work of product discovery, design, and delivery.

That’s why Scrum always needs to “wrap” something else like XP, Kanban, or Lean thinking to work at all. On its own, it doesn’t produce agility; it only produces ceremony.

If your Product Owner’s main contribution is moving tickets in Jira, you have an administrative bottleneck. What you need instead are Product Managers: people who combine market understanding, strategy, and delivery judgment to decide what should exist and why. Scrum doesn’t forbid that kind of leadership. It just doesn’t require it and that’s the problem.

Agility!

Other highlights 👇

Engineering velocity on steroids: What a 10x team looks like

In an interview with Hamming AI, their CEO helped Anton Zaides discover an answer to the question ‘what does a truly high-velocity engineering team look like day to day’?
At Hamming AI, a six-person team (plus two interns) ships faster than many fifty-person orgs. And it’s not what you think: not by working longer hours, but by compounding their learning rate.

The rate of learning dictates everything else

The faster you ship, the faster you learn what works. Every release is an experiment.

Two habits drive this:

Ship quickly. Shorten the cycle time from idea to customer feedback.
Talk to customers directly. Cut out the translation layers that dilute insight.

When engineers joined customer calls, they shipped same-day fixes because they felt the pain directly. The waste wasn’t meetings as they initially thought, but rather the CEO playing telephone.

The New PR Process

As velocity increased, code review became the bottleneck. They overhauled it:

Architecture reviews first. Human review before any code is written as it’s the cheapest time to catch errors.
AI-assisted code reviews. Multiple LLMs (Greptile, Graphite, Cubic) run in parallel for coverage.
Human review last. After AI triage, engineers focus on what truly matters.

Average PR merge time: under two hours.

Testing and Quality

Speed exposed fragility. The team responded by doubling down on tests: 10,000 unit tests and a dedicated QA engineer building evals to prevent regressions. The next challenge: keeping their speed and improving reliability.

The CEO Still Ships

To fix bottlenecks, you have to be inside the system. Sumanyu codes daily, following what he calls the “Elon algorithm”:

“Find the most painful problem, simplify it, and fix it.”

It’s the only way to see where friction actually lives.

Hiring for Learning Rate

Instead of chasing seniority, they hire interns and fast learners. People who adapt quickly and think experimentally. In an AI-driven world, learning rate beats experience. Each week, the team audits where time goes, finds the biggest drag on progress, and fixes that one bottleneck at a time. No grand frameworks, no cargo-cult “10x” slogans. Pure systematic elimination of waste and relentless curiosity.

Manager.dev

Nobody Cares How Hard You Work

Companies don’t hire skills; they hire solutions to painful problems their customers are experiencing. If you want your work to matter, find the pain your team or manager actually cares about.

Steve once joined an engineering team at Amazon that had a reputation for poor code and slow delivery. The diagnosis was “low skill.” But after watching for a week, he discovered a broken release process that made every deployment painfully slow. Fixing that system, not teaching new coding tricks, changed everything.

Start with the Pain

Next time you talk with your manager, ask questions that reveal real friction:

“What’s the most frustrating part of your week?”
“What keeps the team from moving faster?”
“If you could fix one thing instantly, what would it be?”

The answers tell you where your effort will actually be seen.

Your Skills Are the Product

Once you’ve found the pain, look at what skill, if mastered, will remove that type of pain entirely. That’s the product you’re developing in your career.

When Steve worked with that struggling team, his impact was in translating technical issues into business terms leaders could understand. Instead of saying “our pipeline is complex,” he taught the team to say “we’re losing two developer weeks every month.” That small shift unlocked resources and visibility.

Your most valuable skills are often the ones that feel natural — the things you do without noticing. To uncover them, ask:

What problems do I always gravitate toward?
What do I enjoy that others avoid?
What compliments do I downplay because it feels easy?

Those answers point to your authentic strengths: the ones that form your true product.

A Life Engineered

Where’s All the Engineering Effort Going?

Last week in New York, Typo AI’s CEO, Kshitij Mohan, held up a placard that said “Where does your engineering effort really go?” It’s a simple question, but one that keeps coming up in almost every conversation I have with CTOs.

Everyone wants to move faster. But the real question is “what are we moving fast on?”

Across teams, I keep seeing the same pattern. We measure velocity, commits, and releases, but we rarely see how that effort is distributed. Studies from McKinsey show that around 35–45% of developer time still goes into maintenance, bugs, or unplanned work. On dashboards, it all looks like progress, but a big part of that motion is just keeping things from breaking.

That’s why visibility into effort allocation matters. Knowing how much time goes into roadmap, debt, or firefighting isn’t about tracking productivity. It’s about knowing where your capacity is really going. When 40% of the team’s week disappears into maintenance, it’s not a delivery issue. It’s a signal about architecture, priorities, or process maturity.

And now with AI changing how engineers spend time, this visibility becomes even more important. Coding assistants and automation tools are speeding up some parts of work, but also shifting what “effort” even means. Some teams will just move faster. Others will use that saved time to go deeper into design, reliability, and innovation. The difference will come from knowing where the effort actually goes.

So when you look at your team’s sprint or delivery charts this week, ask yourself — do you really know where your engineering time is going?

No alternative text description for this image

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋