Why 52 work items are a recipe for disaster

Just because you put them in a sprint does not mean they will get done. If you use velocity as a metric then respect the velocity. What is in the sprint should have priority on each item and all of items in a Sprint hopefully align to a sprint goal, that might be a bit more tricky but some expression of "what matters for this sprint".

That’s beside the point. The real problem that’s represented by planing 52 items at once is the assumption that none of the 52 items would yield new information or discover new unknowns. And what does that mean? It means the expectation of no new discoveries, no new learnings and no growth. And no growth means dying. Also prioritization at the execution level is overrated, prioritization should should be done on the planning level after alignment is reached. At the execution level, it’s a simple topographical sort. Nothing beats a simple topological sort. If you find contentions of priorities in execution, it’s not a priority issue, it’s a planning issue.

1. Pick something. 2. Focus on it. 3. Complete it. (MVP) That's iterative agile development in a nutshell. Picking multiple things preventing focus or changing what's picked or focussed on before completion is not agile - it's not anything aside from chaos and a waste of resource.

This really resonated with me! Especially pointing out “A good leader doesn’t measure success how much work is listed. They measure it by whether the right work gets done.” In this fast paced; results focused environment, we need to ensure the ‘right’ work gets done. As well, leaders need to allow time for the lower management teams to get some traction moving forward on the priorities and stop asking the team to pivot to new priorities too soon, and still expecting the previous priority is still going to get done.

I’m sharing my approach to team leadership and reflections on the traits of a high‑performing development team; feedback and suggestions are more than welcome. I believe a development team can excel when a few fundamentals come together: clarity of purpose, technical ownership, and care for people. Clear objectives and alignment on measurable outcomes make prioritization simple and give technical decisions real purpose, shifting focus from tasks to tangible impact. Genuine ownership of responsibility areas, supported by obstacle removal and shared decision processes, builds trust and velocity while preserving quality and safety. Lightweight, repeatable processes—reliable CI/CD pipelines, rigorous code reviews, and shared definitions of “done” reduce risk and increase predictability. Automation and observability are priorities to maintain a sustainable pace and respond quickly to incidents. People’s growth is sustained through coaching, regular feedback, and concrete career paths; providing challenges, support, and visibility on progress is key to retaining and motivating talent. Cross‑functional collaboration from the earliest stages, including Product, Design, and Security, reduces risk, anticipates architectural choices, and maximizes product impact. It’s important to measure with core SLOs/SLIs, delivery metrics, and team well‑being indicators to make informed decisions and drive continuous improvement. In short: clarity, ownership, growth, strong technical foundations, and collaboration are the building blocks for sustainable, meaningful team outcomes. What are your thoughts?

Simple is the goal. But simple is hard. It’s easy to throw code at a problem. It’s much harder to understand the problem deeply enough to solve it simply. Simple requires clarity. It requires tradeoffs. It requires the kind of thinking most teams skip when they’re racing toward “done.” Simple isn’t lazy. Simple isn’t basic. •Simple is earned. And it almost never happens by accident. 📗 Product Driven is about building teams that think this way—before they build anything at all. https://lnkd.in/g-AbjXF5

When you care about everything, you care about nothing. I’ve seen it happen to some of the best engineers I’ve known. I’ve done it myself. You step into leadership, you see a dozen things that could be better: code style, sprint planning, metrics, release notes. You want to fix them all. Over time, the team slows down. Reviews pile up. Every small decision needs approval. The lead feels overworked and underappreciated, and the team feels watched instead of trusted. Things are not improving and trust is eroding on both sides. The real problem? Lack of focus. Leadership isn’t about doing more. It’s about choosing what matters most and letting the rest go. Start by fixing one high-impact thing. Something that, if improved, creates a flywheel - a virtuous cycle that builds momentum. Over time, that’s how teams scale. What should you fix first? That depends. Tech debt. Architecture. Team culture. Communication. Every team has a different friction point. But whatever it is - start there.

I thought I was moving my team faster by cutting straight to feedback. I was actually slowing us down. One simple change doubled our sprint velocity. Here's what happened: Our team works incredibly hard building voice agents that have to think and talk at the same time. It’s tough work. I'd jump into a review, skip the recognition, and go straight to what was missing. My intent was speed but what landed was criticism… I noticed the pattern when the energy shifted. People heard "not good enough" when I meant "let's move faster together." So I changed how I entered the conversation. → Now I start by naming what actually shipped. → Not a generic "great job" but the concrete thing that moved us forward. → Then I restate the shared goal in plain language so everyone knows why it matters. → After that, I make one clear ask with a next step and who owns it. Why it works for us: • People hear intent because I show I see the effort first  • They know where we're going because the goal is restated every time  • We don't lose tempo arguing about tone or second-guessing direction The work is intense when you're building something this hard. The feedback has to reduce friction instead of adding to it. If you lead a product or engineering team, try this on your next review: Name one real win. Tie it to the goal. Make one ask. Protect the next block of builder time. Then watch what happens to velocity. Recognition first, one clear ask second. Not softer. Faster. How do you give feedback under pressure?

✨ A team moving fast isn’t always a team moving forward. Speed without direction only takes you in circles. 🚀 Velocity vs. Alignment Teams often start by chasing velocity. How fast can we deliver? How many story points can we close? How quickly can we ship the MVP? But here’s the truth — ⚡ Speed means nothing if everyone isn’t moving in the same direction. Many teams sprint hard, release fast, yet miss business goals. Why? Because each one runs toward its own metric instead of a shared outcome. 🎯 True alignment isn’t a kickoff deck or an OKR slide. It’s when: ✅ Engineering, Product, and Business share the same north star metrics ✅ Priorities stay consistent across pods ✅ Dependencies are mapped early ✅ Everyone understands not just the what, but the why Alignment isn’t a milestone. It’s a living process — something that needs constant care and clarity. 💡 The Bottom Line: Velocity without alignment creates noise. Alignment without velocity creates stagnation. The magic happens when both coexist — but alignment always comes first. Because when everyone moves together, speed becomes a byproduct, not a struggle.

Every team member should know why they’re doing what they’re doing — and how success is measured. That’s how strategy becomes real. Not through presentations or big ideas, but through systems that make clarity repeatable. In operations, we see it every day — the difference between a team that’s busy and a team that’s effective often comes down to structure. Because when strategy isn’t backed by systems, it stays stuck at the top. But when it is, it flows — through every role, task, and decision. ✨ The real bridge between strategy and execution is built through: • Clear workflows — so everyone knows what success looks like. • Defined metrics — so performance can be measured, not assumed. • Feedback loops — so actions continuously improve toward the goal. When these systems are in place, accountability becomes natural, and alignment becomes culture. You stop chasing results — and start engineering them. Strategy may set the direction, but operations make it visible, measurable, and sustainable. So, before you create your next plan, ask yourself: Do we have the systems that make this strategy come alive?