Every software engineer has had that Wednesday.

You know the one. You open your calendar in the morning and it looks like a game of Tetris played by someone who has never seen an L-shaped block. Standup at 9:15. Refinement at 10. A “quick sync” at 11 that is never quick. Lunch, if you’re lucky. Then a sprint review, a cross-team alignment and a 1:1 squeezed into the last hour of the day.

Somewhere between all of that, you’re supposed to write code. Or think. Or heaven forbid, solve an actual problem.

Welcome to the meeting tax. It’s the silent killer of engineering productivity and almost nobody treats it with the seriousness it deserves.

Let’s get nerdy for a moment.

In computer science, there’s a well-known concept called context switching overhead. When an operating system switches between processes, it doesn’t happen for free. The CPU has to save the current process state, load the new one, flush parts of the cache and warm up again. The switch itself takes time and the performance cost is often larger than you’d expect because of all the cache misses that follow.

Human brains work the same way, except worse.

Research from the University of California found that it takes an average of 23 minutes and 15 seconds to fully return to a task after an interruption. Twenty-three minutes. Now think about that engineer with six meetings spread across the day. Each meeting isn’t just 30 or 60 minutes of time. It’s the meeting itself plus the context switch tax on both sides.

A 30-minute meeting in the middle of an afternoon doesn’t cost you 30 minutes. It costs you roughly 75 minutes once you account for the wind-down, the meeting itself and the ramp-up to get back into whatever you were doing before. That’s not a rounding error. That’s a 2.5x multiplier.

If your engineers have four meetings a day, you’re not losing four hours. You’re losing something closer to five or six hours of effective deep work. On an eight-hour day, that leaves maybe two hours of actual focused building time. And we wonder why estimates slip.

Here’s where it gets interesting.

Meetings aren’t inherently evil. I want to be clear about that. Some meetings are genuinely useful. A well-run design review can save weeks of wasted effort. A good retrospective can change how a team operates. A difficult conversation handled in person (or on a call) can resolve what would otherwise fester for months in Slack threads.

The problem isn’t meetings. The problem is that we’ve built a culture where scheduling a meeting is the default response to uncertainty.

Someone doesn’t know what’s happening? Meeting.

Two teams need to agree on something? Meeting.

A stakeholder wants visibility? Meeting.

Nobody read the document you shared? Believe it or not, also a meeting.

It’s like malloc() without free(). We keep allocating meetings but we never release them. The calendar fills up. The garbage collector never runs. Eventually the whole system starts thrashing.

In operating systems, thrashing is what happens when the system spends more time swapping between processes than actually executing them. If that metaphor doesn’t perfectly describe your average Tuesday, I don’t know what does.

I’ve worked in teams where people spent 60 to 70 percent of their week in meetings and then wondered why we weren’t shipping on time. The answer was staring at them from their own calendars.

Let me share a pattern I’ve seen play out multiple times. A team starts a new quarter with ambitious goals. Energy is high. Then meetings begin to accumulate. Alignment meetings. Status updates. Steering committees. Check-ins on the check-ins. By mid-quarter, engineers are coding in the margins of their day. Early mornings. Late evenings. Weekends. They’re putting in more hours but producing less.

Leadership sees the declining output and responds predictably: more meetings to figure out what’s wrong. The irony writes itself.

At some point someone bravely suggests “meeting-free Wednesdays” and for a week or two it works, until someone books a “critical” meeting on a Wednesday because it was the only slot that worked for everyone. The dam breaks. Wednesday returns to normal. The experiment is declared a failure.

The truth is, meeting-free days are a band-aid. They treat the symptom, not the disease. The disease is a culture that doesn’t value uninterrupted time. That treats calendar availability as a resource to be consumed rather than protected.

If you want to actually fix this, you need to start thinking about meetings the way you think about technical debt. Because that’s exactly what they are. Organizational debt.

Every recurring meeting that no longer serves its purpose is debt. Every “just in case” sync is debt. Every meeting that could have been a Loom video or a Confluence page or a well-written Slack message is debt. And like technical debt, it compounds. One unnecessary meeting becomes three because people start scheduling pre-meetings and follow-up meetings to compensate for the first meeting being unfocused.

Here are a few things I’ve seen work in practice.

First, make the cost visible. Most people have no idea how much their meetings actually cost. Do the math for them. If you have 8 engineers in a room for an hour, that’s 8 engineering hours. At a fully loaded cost of, say, $150 per hour, that’s a $1,200 meeting. Ask yourself: did we get $1,200 of value from that hour? If the answer is no, that’s not a meeting. That’s a slow bleed.

Second, apply a “two pizza” rule to meetings, not teams. Amazon’s two-pizza rule was about team size, but it applies beautifully to meetings. If the meeting has more than eight people, it’s almost certainly a broadcast, not a collaboration. Turn it into a slack message. Or a recorded video. Or a document with a comment thread.

Third, default to 25 minutes instead of 30 and 50 instead of 60. This isn’t just about giving people a bathroom break between calls (though that matters more than anyone admits). It’s about creating a forcing function for focus. When you know you only have 25 minutes, you skip the 7 minutes of small talk about the weather and get to the point. Parkinson’s Law is real: work expands to fill the time available for its completion. Give it less time.

Fourth, require an agenda. No agenda, no meeting. This single rule eliminates a surprising number of meetings because it forces the organizer to actually think about what they want to accomplish. If you can’t articulate the purpose of a meeting in three bullet points, you don’t need a meeting. You need to think more.

Fifth and this is the hardest one, protect your team’s maker schedule. Paul Graham wrote about this years ago: managers operate on a manager’s schedule where a meeting is just another block in the day, but makers (engineers, designers, writers) operate on a maker’s schedule where a single meeting can blow up an entire afternoon. If you’re a leader, your job is to be the shield. Take the meetings so your team doesn’t have to. Batch the necessary ones together. Fight for contiguous blocks of deep work time.

There’s a deeper philosophical point here too.

We’ve built an industry that confuses visibility with productivity. Being in meetings makes you look busy. Being available on Slack makes you look responsive. Having a packed calendar makes you look important. None of these things correlate with actually shipping software that works well and solves real problems.

The best engineering work I’ve ever seen happened when teams had space. Space to think. Space to experiment. Space to sit with a problem long enough to find an elegant solution instead of a quick hack. You can’t create that space when every hour is pre-allocated.

I sometimes think about the great works of computer science. Dijkstra didn’t discover his shortest path algorithm between a standup and a sprint review. Knuth didn’t write The Art of Computer Programming in 25-minute increments between syncs. These things required deep, sustained, uninterrupted thought. We don’t all need to be Dijkstra. But we do need to respect that the same principle applies at every level: good work requires focus and focus requires time.

Here’s my challenge to anyone reading this who supports a team or runs an organization.

Open your team’s calendars. Not yours. Theirs. Look at next week. Count the hours of meetings for each engineer. Multiply each meeting by 2.5 to get the true cost in focus time. Now look at what’s left. Is it enough? Is it enough to do the work you’re expecting them to do?

If the answer makes you uncomfortable, good. That discomfort is the beginning of change.

The meeting tax is real. It’s measurable. And unlike actual taxes, you can do something about it. You just have to decide that your team’s time is worth protecting.

Stop scheduling. Start cancelling.

Subscribe now

There is a famous story about the England football team in the 2000s. They had world class talent across the pitch. Lampard, Gerrard, Rooney, Beckham, Terry, Scholes. A lineup any manager should be thrilled to work with. Yet the team never delivered on its potential. They played like a collection of talented individuals who never fully became a unit. Everyone had ability. The problem was how they played together.

In tech and in many modern organizations we love to repeat the phrase “hire great people and get out of the way”. It is simple and attractive. It taps into the idea that autonomy fuels creativity and that smart people can figure things out on their own. There is truth in that, but it is not the whole story.

Getting out of the way works when the person you hired is doing work that depends heavily on individual contribution. A developer deep in a piece of logic. A designer working through a tricky flow. A researcher analyzing data patterns. These moments benefit from focus. You do not need a manager standing over someone’s shoulder telling them how to do their craft.

But once the work shifts from individual execution to team outcomes the equation changes. Building software, running a product organization or driving a strategic change is not an individual sport. It looks more like football. Complex interactions. Shared dependencies. Decisions that cross boundaries. People with different skills trying to solve one problem together.

This is the point where “get out of the way” stops being helpful. You can hire ten brilliant people, give them no direction and end up with ten different interpretations of the goal. You get duplicated effort, competing priorities, unclear ownership and frustration. Talent without alignment is noise.

Leaders have a real job here. Not to micromanage and not to control every detail. Their job is to create the structure that allows talented people to operate as a team. This sounds simple. It rarely is.

• It means getting clear on the purpose of the work.

• It means agreeing on what success looks like.

• It means setting constraints that focus the team rather than restrict them. Constraints like scope, priorities, time horizons, decision-making rules and how teams hand work over to each other.

This is the same lesson England learned the hard way. You can fill a pitch with stars and still struggle if the formation does not make sense. If the players do not understand how to work off each other. If the system does not support the way they naturally operate. Talent is only useful when the environment turns that talent into something coherent.

A leader’s job is to shape that environment. To design how the team works. To make sure people understand the strategy and the direction. To create interfaces between roles so that collaboration feels natural rather than forced. To remove blockers. To prevent thrash. To help the team make good decisions quickly instead of waiting for clarity that never comes.

There is another layer to this. Great people often carry strong opinions about how to work. In a team setting those opinions can collide. A leader needs to help the team navigate those disagreements. Not by picking sides, but by guiding the team toward shared principles. This is part of the formation. It is how you turn individual strengths into collective strength.

So yes, hire skilled people. Hire people who care about the craft. Hire people who bring ideas and energy and depth. Then put just as much care into helping them function as a real team. The magic is not in the résumés. It is in how the people connect. It is in how they move together. It is in the system around them.

High performance rarely appears just because you assemble high performers. It appears when leadership builds the conditions where collaboration becomes a force multiplier. That is the job. That is the impact. And that is when work starts to feel less like coordination and more like a team playing to its strengths.

Subscribe now

In every software company, there’s a moment when a team looks at a problem and says, we can fix this fast.

It’s a tempting phrase. Quick wins feel good. They create the illusion of momentum. They give stakeholders confidence that things are moving. They help teams prove they can deliver.

But most of the time, quick wins aren’t really wins. They’re shortcuts dressed up as progress.

In the short term, they make people feel productive. In the long term, they quietly erode trust, stability and focus. The debt they create isn’t just technical. It’s organizational. It builds slowly, disguised as speed, until one day everything slows down and no one knows why.

I’ve seen this pattern play out in every kind of team; from scrappy startups to scaled engineering organizations. The impulse comes from a good place. Someone wants to show impact fast. A customer needs something urgently. A new leader wants to prove value. So the team skips one layer of design, compromises on testing or defers integration with the main system until later.

Later never comes.

That’s the thing about quick wins. They multiply. Once a company gets used to chasing them, they become the default operating mode. The team stops asking whether the work aligns with strategy. They just ask how fast it can be done.

Leadership starts rewarding firefighting instead of focus. Engineers learn that fixing what’s visible matters more than building what’s right.

It feels great at first.

Number of things done goes up. Releases become more frequent. Dashboards show movement. But under the surface, something starts to rot. The codebase becomes harder to change. Teams spend more time debugging than developing. Every new project needs another workaround for the last one. Eventually, the company reaches a point where progress looks busy but feels heavy.

One of my favorite examples came from a company where we shipped “quick wins” for almost a year straight. Every sprint, something new went out. Sales loved it. The board loved it. Customers thought we were unstoppable. Then we hit a wall.

A simple change request from a key customer took six weeks to deliver. Every part of the system was entangled with temporary fixes and “short-term” logic that had never been rewritten. We hadn’t built a product. We had built a collection of patches held together by optimism and duct tape.

When you peel it back, the core problem is that most organizations confuse urgency with importance. A quick win feels urgent because it’s visible. A scalable solution feels important but abstract. It’s hard to show progress when the work is mostly invisible i.e. refactoring, architecture decisions, infrastructure improvements etc.

Those things take time, yet they’re the only foundation for lasting speed.

Quick wins don’t just accumulate in code. They seep into culture.

Teams learn that short-term wins get celebrated and long-term work gets questioned. Product managers start optimizing for the next demo instead of the next quarter. Leadership reviews become a showcase of small wins instead of a reflection on outcomes. People start to believe that shipping something is always better than waiting.

The result is a culture addicted to motion without meaning.

There’s a simple test for whether a quick win is worth doing. Ask yourself if it moves the system forward or just hides the problem.

Sometimes, a quick win genuinely helps. For example, adding a short-term manual process to validate an idea before automating it can be smart. It tests assumptions before investing heavily. But shipping an unscalable feature because “we’ll fix it later” isn’t a win. It’s a delay of pain.

Good leaders know that momentum is not the same as progress. They protect their teams from the illusion of speed. They push for clarity on what actually matters. They slow down when things start moving too fast. They help everyone remember that the goal isn’t to look productive; it’s to be effective.

Actual progress in software feels almost boring. It’s when teams quietly strengthen the foundations. It’s when engineers delete code instead of adding it. It’s when the organization says no to things that don’t align with strategy, even when those things could be done quickly.

It takes discipline to say no to quick wins. It takes even more discipline to build systems that make quick wins unnecessary.

If you find yourself chasing short-term deliverables over long-term direction, take a step back. Look at your roadmap. Look at how much of it is reactive. Look at what you’ve postponed in the name of speed. That’s your real backlog.

Quick wins feel satisfying, but sustainable success comes from the unglamorous work of making better decisions, not faster ones.

In the end, the best teams don’t chase quick wins. They build durable systems that keep winning, long after the rush has worn off.

Subscribe now

If there’s one thing I’ve learned leading software delivery teams, it’s that time tracking is the easiest metric to measure and the least meaningful one.
We’ve built entire dashboards around hours logged, sprint velocity and burn-down charts. Yet none of them tell us if we actually moved the needle for the business or the user.

Somewhere along the way, measuring time became a substitute for measuring value.

We love numbers because they make us feel in control. When teams are behind, we measure harder. When they’re overworked, we add more tracking. But in all honesty, time is a poor proxy for progress. In high-performing teams, impact replaces effort as the primary unit of measurement.

I’ve seen teams spend months delivering exactly on schedule, only to realize that what they built didn’t solve the problem it was meant to. They hit every milestone, every sprint goal and every release date. The product just didn’t matter.

When you measure time, you optimize for busyness. You reward people for being available, not for making decisions that improve outcomes. You build systems that look efficient on paper but are disconnected from customer value.

A team working ten focused hours in the right direction achieves more than a team working fifty hours in the wrong one. Yet we continue to celebrate utilization instead of effectiveness.

If you want to understand whether your teams are truly delivering, shift your attention to outcomes that matter.

1. Cycle time to customer impact
How quickly does an idea become something a user can experience?

2. Adoption and retention metrics
Are people using what we built, and does it actually make their job easier or faster?

3. Learning rate
How fast can the team validate assumptions and adapt based on feedback?

4. Operational resilience
How often does something break and how long does it take to recover?

5. Team health and predictability
Are people proud of what they ship and can they consistently deliver value without burning out?

These are not softer KPIs. They’re leading indicators of organizational health. When teams obsess over outcomes instead of hours, accountability shifts from “did you do the work” to “did the work make a difference”

Time-based metrics often appear in cultures that don’t yet trust their teams to own results. The assumption is that if people aren’t closely monitored, they won’t perform.
But high-trust environments work in reverse: autonomy breeds accountability.

If you can’t measure trust directly, look for its shadow; psychological safety, ownership and clarity of purpose. When teams know why they’re building something, they don’t need a timer to tell them how long to work on it.

Every meeting, every sprint, every project should start with a single question:
What will be different when this is done?

If you can answer that clearly, time becomes a byproduct, not the target.

The best teams I’ve worked with treat time as a constraint, not a goal. They focus on making the biggest possible impact within that constraint.
They optimize for clarity, flow and value; not man-hours or velocity.

The Takeaway

Software is not an assembly line. You don’t win by clocking more hours; you win by making better decisions.

If your dashboards are full of time metrics, you’re measuring effort, not effectiveness.
Start tracking what actually matters; outcomes that solve problems for customers and reflect value for your business.

Stop asking “how long did this take?”
Start asking “was it worth it?”

In tech, we often wear busyness as a badge of honor. Slack notifications flood our screens and calendars fill up with back-to-back operational meetings. But there’s an uncomfortable truth: if you're a leader consistently caught up in day-to-day operations, you're NOT leading. You're managing. And there's a crucial difference.

True leadership requires space. Space to think deeply, to connect dots, to identify trends and to envision future states. Without it, leaders risk becoming bottlenecks rather than catalysts, losing sight of the strategic direction (aka the North Star), that their teams rely upon.

Consider this common scenario: a scaling tech startup has a senior director who is incredibly talented, ambitious and driven. In the early days, being hands-on made sense. But as the team expanded, her involvement in routine operational tasks, like reviewing minor product tweaks, attending every sprint event or responding to every customer complaint, began consuming all her available time.

Initially, the hands-on approach felt supportive and reassuring to her team. But gradually, a problem emerged. Her engineers, product managers and designers began feeling directionless. Questions like, “What are we ultimately trying to achieve here?” or “What’s our broader strategic objective?” became frequent. Her constant operational presence ironically created confusion rather than clarity.

This scenario isn't unusual. In tech, especially within high-growth startups, leaders often mistakenly equate activity with effectiveness. Operational involvement gives an immediate sense of productivity and achievement but it's deceptively short-lived. Without dedicated strategic thinking, the team soon hits an inevitable wall: lack of clarity, stalled progress and decreased morale. The short-term gains of micro-involvement evaporate quickly, replaced by a long-term loss of momentum.

Contrast this with a different scenario - a leader who consciously creates boundaries around operational engagement, prioritizing strategic time. Instead of being omnipresent, this leader trusts her teams to handle daily tasks, intervening only when truly necessary. She dedicates specific time each week for strategic contemplation, market & data analysis and deep dives into industry trends. Her conversations shift from day-to-day troubleshooting to future-oriented strategic dialogues. She asks questions like, “Where will our industry be in three years?” and “How do we position ourselves uniquely in a competitive landscape?” Her team feels empowered because they have clarity on their North Star and a clear understanding of their role in reaching it.

If you're a leader feeling trapped in operational quicksand, it’s essential to start reclaiming your calendar. Begin with delegation - genuinely trusting your team with execution. Remember, delegation isn’t just about offloading work; it’s an act of trust and empowerment that boosts your team's confidence and ownership.

Next, create dedicated "thinking time" blocks. These are non-negotiable hours on your calendar strictly reserved for reflection and strategic planning. Protect these fiercely; treat them as the most critical meetings of your week, because in reality, they are. During these times, disconnect from immediate tasks, reflect on your organization’s long-term vision and realign your strategic priorities.

Lastly, openly communicate the rationale behind your shift in approach. Make it clear to your team that your stepping back from daily operations isn’t about disengagement but about giving them the space and clarity to excel while you focus on steering the ship toward success.

Ultimately, being busy isn't the hallmark of great leadership. Strategic clarity and the ability to guide effectively toward a shared vision are. It’s time we stop glorifying busyness and start celebrating purposeful leadership.

Subscribe now

There's a certain beauty in well-written code. I don't mean the superficial kind; the glossy, polished veneer of neatly arranged functions or the sleek uniformity of carefully placed comments. No, I'm talking about a deeper elegance. It's the quiet harmony that happens when code perfectly solves a customer's pain, addresses a business need or delights a user.

And yet, sometimes we lose sight of that harmony.

I've seen developers get caught up in the allure of writing the shiniest, most impressive solution. Something that would make peers whistle in admiration. I am sure I’ve done it myself. It's human nature to chase after perfection, especially in tech, where the new and exciting forever beckons us onward. But shiny, perfect code that doesn't actually solve the user's problem is about as useful as a beautifully built boat that never touches water.

This isn't to diminish the importance of technical excellence. Far from it. Caring deeply about technology means making intentional decisions - when to scale up, when to simplify, how complex a solution should really be etc. It means respecting your craft enough to know when a quick and dirty fix isn't enough, and when it’s exactly what's needed.

Though the truth is a bit bitter - code isn’t written for the coder. It’s written for the user. A feature that doesn't solve a real-world problem, no matter how cleverly coded, is ultimately hollow.

I recall a team wrestling with a tricky problem: an elegant microservice architecture was on the table, but the business needed a feature yesterday. After hours of debate, it became clear that though the microservice was the better technical solution, a simpler, monolithic feature release would get the job done fast and effectively. They chose the latter, shipped quickly and solved an immediate user problem. Technical purity lost the battle that day, but user satisfaction and business value won the war.

Does that mean sacrificing quality or technical excellence? Of course not. It means prioritizing carefully, intentionally. It's about knowing when good enough is genuinely good enough and when you truly need the perfect solution.

Context, as always, is king. There are no easy answers here. Anyone selling you a simple formula isn't telling the full truth. The art of building great software lies in navigating these trade-offs thoughtfully. It's a dance; delicate and sometimes frustrating but always worthwhile.

And let’s clear something up: there is no "us vs them". There’s no "business team" against "product team" against "engineering team". We're all on the same side, working toward the same goals and solving the same problems. The moment we forget that, we've already lost the plot.

So let's continue to write beautiful code. Let’s keep pushing the envelope technically, but let’s never lose sight of the reason we're here in the first place: to solve problems, make things better and build something that truly matters.

Subscribe now

In the mythical land of Agiletopia, an enchanting place frequently celebrated in corporate fairytales, we encounter a curious beast: Pressure Driven Development, what the townsfolk whisper in hushed tones, PDD. Unlike its nobler cousin Test-Driven Development or its elusive sibling Behavior-Driven Development; PDD thrives in shadows cast by Gantt charts and arbitrary executive deadlines. It emerges when leadership speaks agile but breathes waterfall.

Picture this: The CEO proclaims himself Chief Product Visionary, decreeing from atop Mount Gantt that all products shall be developed with agility, flexibility and innovation. As long as they precisely match the roadmap etched in stone during an executive retreat six months prior. This visionary, much like Tolkien's stubborn dwarven kings, hoards timelines and scope like precious gems, oblivious to the army of hobbits. Sorry, engineers - scurrying about trying to deliver.

Engineers, the tireless minions of this tale, find themselves caught between epic quests ("Build me an MVP, but with every feature imaginable!") and side missions ("We must demo something to the customer tomorrow - so just, you know, hack it together!"). Meanwhile, everyone outside of engineering eagerly dons the pretend title of Project Manager, wielding their precious Roadmaps as if the salvation of Middle-earth depended on them.

And iteration? That whimsical creature, agile's very spirit animal, is banished to the dark forest, replaced by rigid plans and impossible timelines. “Deliver on time, on scope, quickly—but please don’t waste precious time iterating. Iteration is for those who fail the first time,” bellows the self-appointed head of product.

Here's a spoiler: this isn't my first adventure in the land of PDD. Over the years, I've journeyed through many corporate kingdoms where leaders swear allegiance to agile principles at the surface, yet quietly conspire with traditionalist villains beneath. The tales are always eerily similar; buzzwords thrown around campfires, stand-ups turned status updates, retrospectives reduced to polite grumbling sessions.

The path out of this enchanted forest of dysfunction is simple, yet as daunting as Frodo's journey to Mordor. Shifting power, control and mindset. True agility requires the courage to embrace uncertainty, accepting iterative learning over rigid predictions.

Engineers and RnD must step out of their cozy Shire-like comfort zones to guide, educate and influence those clutching their beloved Gantt charts. We must teach them that iterative development is not a shortcut or failure but a strategic embrace of reality itself.

For those brave enough to embark on this transformation, remember this, real agility isn't declared from the ivory towers of leadership. It's forged in the trenches, shaped by engineers empowered to build iteratively, honestly and courageously.

So, here's my parting advice to leaders lost in the labyrinth of PDD: put down your precious charts. Stop hoarding control like it's your last lembas bread and trust your fellowship. It’s not magic, it’s simply good sense.

After all, Agiletopia, much like Harper Lee's Maycomb, has no room for pretension; it demands authenticity and most of the time a pinch of rebellious humor definitely helps.

Subscribe now

Introduction

When I first joined the team as a Technical Program Manager (TPM), my now-collaborator, Jono, wasn’t convinced that my role was necessary. Like many engineering leaders, he saw TPMs as a necessary evil - another layer of process, meetings and overhead.

Fast forward a year and we built an incredible partnership, one that’s helped our teams and the company deliver better, faster and with more clarity. Today, we’re sitting down for an honest conversation about how our collaboration evolved, the initial skepticism and what we’ve learned about making TPM-Engineering partnerships work.

Here’s our conversation.

The Evolution of an Engineering-TPM Partnership

Pranshu: Let’s start at the beginning. When I first joined as a TPM, you were skeptical about the role. Can you share what your initial concerns were?

Jono: Before we worked together, my perception of the TPM role was quite limited. I saw TPMs primarily as facilitators of reports and status updates, occasionally stepping in to coordinate dependencies across teams. They often seemed to enforce processes without providing clear rationale, which made their role feel more administrative than strategic. At best, I viewed TPMs as responsible for running standup meetings and ensuring teams stayed on track to meet deadlines. At worst, I saw them as an additional layer of management that added overhead, requiring extra explanations about the project's status rather than actively contributing to its success.

Pranshu: That makes sense. At what point did your perception start to shift?

Jono: The turning point for me came when we were down a product manager. As the Engineering Manager, I had to work closely with you as the TPM to determine not just what we were going to build, but also how and when. The real shift in my perception happened when I saw you thinking beyond just the features and timelines, focusing on how we could break down deliverables to validate assumptions earlier. That was my AHA! moment. I realized that having someone who not only understands the technical side but also thinks strategically about delivery can be incredibly valuable.

Pranshu: That’s a huge shift! What do you think makes a TPM valuable to an engineering team?

Jono: The best TPMs aren’t just workload managers. They act as force multipliers for engineering teams. I think about it in a few ways:

• They reduce cognitive load - so engineers can focus on solving technical problems rather than chasing down dependencies or aligning stakeholders.

• They bring structure to chaos - especially in cross-team projects where things can get messy fast.

• They help engineers communicate their needs better - whether it’s with leadership, product or other teams.

Pranshu: We’ve worked together on some challenging projects. What’s been one of the biggest wins from our collaboration?

Jono: One that stands out when we had to align multiple RnD teams to work against an external deadline. That was a tough one - high visibility, shifting requirements and a ton of dependencies. I remember thinking there was no way we’d hit the deadline. But you helped cut through the noise, keep stakeholders aligned and make sure we focused on the right things. I don’t think we would have delivered it before time without that level of coordination.

Pranshu: On the flip side, what’s the biggest lesson you’ve learned about working with TPMs?

Jono: That it’s a partnership, not a handoff. Early on, I thought of TPMs as just project trackers, but now I see the best results come when we’re aligned as a leadership team. That means including TPMs in technical discussions, strategy, and decision-making, not just status updates. When we treat TPMs as true partners, everything runs smoother.

Pranshu: For other engineering leaders who are skeptical about TPMs, what advice would you give?

Jono: Give it a chance. But also, be clear about what you need from a TPM. If you’ve had bad experiences in the past, don’t assume all TPMs operate the same way. And on the other end, if you’re a TPM, focus on delivering value early - help with something tangible, unblock something, make a decision easier. That’s how you earn trust.

Closing Thoughts

When we started working together, we were on opposite ends of the TPM debate - one skeptical but open minded, the other eager to prove value. Today, we’re a stronger team because we learned how to collaborate effectively. This experience has taught me that great engineering and program management partnerships don’t just happen, they are built.

To all the engineering leaders who still see TPMs as a necessary evil: The right TPM won’t slow you down - they’ll help you move faster. And to TPMs trying to gain trust: Don’t just track work—help teams win.

Have you ever felt overwhelmed by the sheer amount of work your software team takes on? What if embracing less could actually produce more? In the fast-paced world of software development, where planning is both an art and a science, finding the right balance between productivity and creativity is crucial. The strategic 70/30 rule provides a framework that enhances both performance and innovation, fostering a work environment that thrives on flexibility and adaptability.

Why Embrace the 70/30 Rule?

This approach suggests that teams should plan to utilize only 70% of their total capacity for core projects and deliverables each quarter. The remaining 30% is reserved for the unexpected; be it surprises, cross-team assistance, experimentation or continued learning. But why allocate such a significant portion to seemingly unproductive time? The answer lies in the unpredictable nature of software development and the immense benefits of preparedness and creativity.

Benefits of the 70/30 Rule

Implementing the 70/30 rule not only facilitates better project management but also nurtures a healthy work environment. Here are the key benefits, presented as compelling reasons to consider this approach:

• Enhanced Team Morale and Reduced Burnout: By not overloading the team with excessive commitments, you foster a less stressful atmosphere. This can lead to higher job satisfaction, lower turnover, and more committed employees.

• Increased Flexibility to Address Urgent Issues: The reserved 30% acts as a buffer, allowing teams to handle unexpected challenges without disrupting the planned workflow. This flexibility is crucial for maintaining continuous delivery in a dynamic work environment.

• Fosters a Culture of Innovation: By allocating time for experimentation, teams can explore new technologies and methodologies that could lead to significant breakthroughs in projects. This kind of environment encourages creativity and out-of-the-box thinking.

• Continuous Skill Development: Setting aside time for learning ensures that your team stays updated with the latest industry standards and technologies, which can enhance their efficiency and the quality of their work.

• Improved Project Outcomes: With more focus on manageable workloads, teams can produce higher quality work. Detailed attention to fewer projects tends to result in better outcomes and fewer errors, leading to greater client satisfaction.

  ---

  Implementing 70/30 in Sprint Planning

  To effectively implement this model, break down your quarterly goals into shorter, achievable targets. Here’s how you can structure this:

  • Quarterly Planning: At the start of each quarter, outline the main objectives and key results you aim to achieve. Ensure these account for only 70% of your team's total capacity.

  • Sprint (or Iteration) Goals: Divide these quarterly objectives into smaller, incremental goals. Each sprint should have its goal that align with the broader quarterly targets.

  • Weekly Check-ins: Use these meetings to track progress, adjust plans, and redistribute tasks as needed to deal with the unexpected. This keeps the team flexible and responsive.

  • Reflection and Adaptation: At the end of each quarter (not limited to), review what was accomplished, what wasn’t and why. This reflection will inform the next quarter’s planning, allowing for adjustments based on what works and what doesn’t.

    ---

    Conclusion

    As software teams, our capacity for work is not just about the quantity but also the quality and impact of what we deliver. By planning for only 70% of our capacity, we open up space for growth, support and flexibility (key ingredients to thriving in the tech industry). In the journey of software development, remember, flexibility is as important as efficiency. Let the 70/30 rule be your guide to a more balanced and innovative approach to planning.

    ---

    Thanks for reading. Subscribe for free to receive new posts and support my work.

Empowerment - The golden word of modern tech leadership. The dream of every well-intentioned leader. The promise of autonomy, decision-making power and the ability to “own” one’s work.

And yet, when leaders actually try to empower their teams, something odd happens.

• Engineers suddenly look… uneasy.

• Product managers nervously ask, "So... what's the catch?"

• Designers stare at their Figma files like they're waiting for an executive to swoop in with "final feedback."

• Everyone starts cautiously asking "Who approved this?" before making any decisions.

Because let’s be honest, most software teams have been burned before. They’ve heard the “you are empowered” speech before and it usually comes with strings attached, hidden expectations, or an unspoken "but."

So today, let’s talk about why software development teams are secretly terrified of empowerment and more importantly, how leaders can actually help them embrace it.

Why Teams Are Scared of Empowerment (And Rightfully So)

1. They’ve Been ‘Empowered’ Before… And It Was a Trap

In many organizations, "empowerment" is just a sugar-coated way of saying "you're on your own now."

• "You're empowered to make decisions!" (Translation: We're offloading responsibility, but still expect you to hit all targets with no additional support)

• "You don’t need to ask for approval anymore!" (Translation: We’re still going to judge your decisions retroactively and wonder why you didn’t do it differently)

• "We trust you!" (Translation: But if anything goes wrong, you’ll still need 17 approvals to fix it)

No wonder teams hesitate when leaders suddenly want to “empower” them.

2. They’ve Been Taught to Follow Orders, Not Make Decisions

Many software teams operate in command-and-control environments, even when leadership swears they don’t.

• Product makes the roadmap.

• Engineering executes the backlog.

• Leadership sets the direction.

• Teams are "consulted" but rarely get to make the final call.

And suddenly, after years of this structure, leadership declares:
"We want YOU to decide what to build next!"

That’s like telling someone who’s only ever followed GPS directions to suddenly drive without a map. Sure, it sounds nice but where the hell do they even start?

3. They Know ‘Empowerment’ Still Has Unwritten Rules

Teams have seen what happens when someone truly takes empowerment at face value.

• An engineer refactors a critical component because it was a mess. Leadership: “Why wasn’t this on the roadmap?”

• A designer takes creative risks. Leadership: “Can we make it look more like [insert competitor]?”

• A product manager makes a bold call to cut scope. Leadership: "Why didn't you consult more stakeholders?"

Teams know that empowerment only goes as far as leadership’s tolerance for surprise.

How to Actually Help Teams Embrace Empowerment

Alright, so teams are understandably hesitant. But how do leaders actually create an environment where empowerment isn’t just a scary buzzword?

1. Define Empowerment in Plain English (or your local language)

Empowerment isn’t just a warm feeling, it needs clear boundaries.

• What are they actually empowered to do? (E.g., “You own tech debt prioritization within your sprint”)

• What guardrails exist? (E.g., “You can change architecture decisions, but let’s do a design review first”)

• Who has final say on what? (E.g., “You own feature scope, but let’s align on quarterly priorities”)

If empowerment means everything, it actually means nothing.

2. Show, Don’t Just Tell

Leaders need to demonstrate that empowerment isn’t a trap.

• When a team makes a decision - back them up.

• When an experiment fails - celebrate the learning, not the mistake.

• When someone takes initiative - don’t micromanage or override them.

Empowerment isn’t just about saying "You can make decisions now." It’s about proving that those decisions will be respected.

3. Reduce the Fear of Failure

Most teams aren’t scared of empowerment itself. They’re scared of what happens if they get it wrong.

So, leaders need to normalize smart risks by:
✅ Encouraging small bets (A/B test an idea instead of launching a massive feature)
✅ Framing failures as learning ("That didn’t work, what did we learn?")
✅ Modeling vulnerability ("I’ve made bad calls too, but we adjusted. That’s how we grow")

4. Make Decisions WITH the Team, Not FOR the Team

Teams will only trust empowerment if they are part of the decision-making process from the start.

• Instead of handing down a roadmap, co-create it.

• Instead of setting goals in a vacuum, define success together.

• Instead of waiting for teams to speak up, actively ask: “What do you think?”

Nothing makes people feel more empowered than actually having a say in the direction.

Final Thoughts: If You Want Teams to Feel Empowered, Make It Safe to Be Empowered

Software teams don’t fear empowerment itself. They fear the consequences of taking it seriously.

So if you’re a leader who wants your team to truly own their work, ask yourself:

• Do I reward initiative, or punish deviation?

• Do I support their decisions, or quietly override them?

• Do I create a space where failure is part of learning, or something to be avoided at all costs?

Because at the end of the day, teams don’t need permission to be empowered.

They need proof that it’s real.

So, you want to be a Product Manager. But not just any product manager, You want to be a solidly, unapologetically mediocre product manager. Not great, not terrible, just comfortably wedged in the middle of the competency bell curve. The kind of PM that people tolerate, but no one would actively recommend.

Well, good news! I’ve put together the perfect guide to underwhelming product leadership. Follow these steps and you’ll blend into the corporate scenery so seamlessly that no one will ever think to promote (or fire) you.

1. Have No Clear Vision, Just Vibes

A great product manager has a compelling vision. But you? You don't need that kind of pressure. Instead, make vague, inspirational statements that sound deep but mean nothing.

Example:

• "We need to leverage AI to disrupt our space!" (Leverage AI how? For what? Who cares! It’s AI!)

• "We should be more customer-centric" (Groundbreaking insight, really. Now let’s all sit quietly and let the engineers figure it out.)

Pro tip: When someone asks for specifics, just say, "It depends" Then move to another meeting before anyone can follow up.

2. Master the Art of the Buzzword Bingo

Great PMs articulate real problems. You, however, should focus on sounding like a product visionary without actually saying anything.

Here’s a handy template for any situation:
"We need to align our roadmap to drive synergies across scalable, data-driven, AI-powered ecosystems while ensuring a seamless, customer-centric experience."

Bonus points if you say "north star" at least twice per meeting.

3. Don’t Prioritize, Just Say Yes to Everything

Real prioritization is hard. It requires saying "no" sometimes and that might make someone mildly unhappy. Instead, commit to everything, all the time and let engineering deal with the consequences.

When your team gets overwhelmed, remind them: "We’re an agile company! Just be more agile!"

And when leadership asks why nothing is shipping, blame "cross-team dependencies"

4. Hold as Many Meetings as Humanly Possible

You may not be great at building products, but you can be great at filling people’s calendars with pointless meetings.

• Status update? Meeting.

• Review the roadmap that’s already in Confluence? Meeting.

• Alignment meeting to discuss the alignment of future meetings? Yes.

If someone asks, “Could this have been a slack message?” just say: "We need real-time collaboration", Then schedule a retrospective on meeting efficiency.

5. Delegate All the Hard Work, Take Credit for Success

Why get your hands dirty when there are engineers, designers and data analysts for that? Your real skill should be delegating everything, then swooping in at the last moment to present the results as if you personally built the product with your own two hands.

And if the project fails? Just say: "We lacked executive buy-in"

6. Feature Factory? Yes, Please!

Forget about solving customer problems, just focus on shipping as many features as possible. More features mean more impact, right? Right?!

• Don’t bother validating ideas.

• Don't define success metrics.

• Just launch things and hope for the best.

When leadership asks about the adoption rate of your last five features, distract them by saying "We need to revisit our OKRs"

7. Ignore Engineering Constraints. They’ll Figure It Out

The best way to be a true mediocre PM is to treat engineers like vending machines. You put in a vague requirement and poof, software comes out.

• If an engineer pushes back on feasibility, say "Let’s be solutions-oriented"

• If they ask for trade-offs, respond with "Can't we just make it an MVP?"

• And if all else fails, "What would Amazon do?"

Bonus: Write "Just a small tweak" in JIRA tickets that requires three months of backend refactoring.

8. User Research? Nah, Just Assume

Why waste time talking to users when you can just assume what they want?

• Never test hypotheses.

• Never check analytics.

• Just follow your gut, or better yet, ask the HiPPO (highest-paid person) in the room.

When someone suggests a usability study, roll your eyes and say: "Steve Jobs never did user research"

9. Be the Master of Roadmap Chaos

Your roadmap should be a work of art, constantly shifting and changing so no one ever really knows what’s happening.

• Shift priorities every other week.

• Always be in “exploration mode”

• When leadership asks what’s actually launching this quarter, say "We’re taking an iterative approach"

If all else fails, just send a beautifully formatted PowerPoint deck. People love decks.

10. Have No Opinion, But Insist on Consensus

Your job isn’t to drive decisions - it’s to make sure no one is unhappy.

• Instead of making tough calls, endlessly gather more "alignment"

• Instead of defining trade-offs, ask "What does everyone think?" until people stop showing up to meetings.

• When leadership asks for your recommendation, just say, "It’s a complex problem"

Congratulations! You’ve officially created decision paralysis and delayed every roadmap item by six months.

Final Thoughts: Embrace the Mediocrity

If you follow these steps, you won’t be known as a great PM but you also won’t be known as a terrible one. You’ll exist in that comfortable middle space where expectations are low, meetings are plenty and you always have a new PRD to share.

And isn’t that what corporate success is all about?

Now, if you’ll excuse me, I need to send a Slack message asking if we should schedule a meeting about the roadmap.

In the world of software development, decision paralysis is the bogeyman we talk about often but rarely address head-on. Among its many repercussions, one stands out as the most insidious: opportunity cost aka the cost of delay. While the cost of making the wrong decision is often visible and tangible, the cost of waiting (the cost of not deciding) is a silent killer that can erode the foundation of an organization, a product, or a team.

When I think about the most successful organizations I’ve worked with or observed, one principle unites them: speed beats perfection. These organizations are not reckless; they don’t act without thought. But they deeply understand that every second spent deliberating is a second not spent building, learning, or serving their customers. They act decisively, embrace the unknown and prioritize momentum over inertia.

Let’s unpack why the cost of waiting is the ultimate competitive disadvantage and how addressing it can transform the way your organization operates.

The Real Cost of Doing Nothing

Inaction feels deceptively safe. It gives teams the illusion of risk avoidance. “We’re waiting until we’re sure” becomes the mantra. But every delay comes with hidden costs that compound over time:

1. Falling Behind the Competition

In software, time isn’t just money, it’s market share. While your team is debating edge cases, your competitors are shipping updates, winning customers and setting new expectations. The window of opportunity narrows every time you hesitate.

2. Stalling Innovation

The pace of innovation thrives on experimentation and iteration. When teams delay decisions, they lose the ability to learn from the market. Products stagnate, ideas go stale and the opportunity to evolve slips through the cracks.

3. Declining Team Morale

Prolonged indecision frustrates teams. Developers lose enthusiasm when they’re left waiting for clarity. Designers feel disconnected when their work is deprioritized. Over time, a culture of hesitation can erode team morale and motivation, leaving people disengaged and disconnected from their work.

4. Eroding Customer Trust

Customers notice delays. They may not know the internal bottlenecks, but they feel the absence of progress - features that haven’t launched, bugs that haven’t been fixed, promises that haven’t been fulfilled. In the age of instant gratification, customers don’t wait; they leave.

Why Opportunity Cost Is the Most Critical Metric

Every decision has a cost, but waiting has the highest cost of all because it robs you of time, the one resource you can’t replenish. Here's why understanding and acting on opportunity cost is the key to success for any organization, product, or team:

1. Opportunity Cost Forces Prioritization

When you acknowledge that waiting has a cost, it forces you to prioritize ruthlessly. Suddenly, the question shifts from “What’s the perfect solution?” to “What’s the most impactful thing we can do right now?” This shift in mindset is transformational.

2. Opportunity Cost Drives Experimentation

Acknowledging the cost of waiting encourages a culture of experimentation. Instead of striving for perfection, teams test hypotheses, ship MVPs and collect feedback. Every experiment yields data and every iteration brings you closer to the right answer.

3. Opportunity Cost Aligns Stakeholders

When leaders articulate the cost of delay, it aligns teams and stakeholders around a shared sense of urgency. It eliminates the “let’s wait and see” mentality and replaces it with a collective commitment to action.

How to Avoid the Cost of Waiting

1. Build a Culture of Action

Leaders must encourage teams to make decisions with the information they have. Emphasize that mistakes are learning opportunities, not failures. Celebrate momentum, not just results.

2. Create Clear Decision Frameworks

Define criteria for when decisions should be made. For example:

• Low-risk, low-impact decisions: Take a call, move quickly and validate.

• High-risk, high-impact decisions: Involve stakeholders, but set a deadline for action.

3. Measure Opportunity Cost

Ask your team:

• What’s the cost of not making this decision?

• What would we learn if we acted now?

• How does waiting impact our customers, competitors and morale?

4. Communicate with Transparency

When a decision is delayed, communicate why and set clear timelines. Transparency builds trust and keeps everyone aligned.

Leadership’s Role in Fighting Decision Paralysis

Great leaders don’t wait for perfect conditions - they create conditions for progress. They empower teams to act, support them when things go wrong and remind everyone that momentum is the lifeblood of success.

One of the best leaders I’ve worked with used to say, “The riskiest decision is the one we didn’t make” She understood that hesitation wasn’t just a delay, it was a lost opportunity. And in the fast-paced world of software, lost opportunities compound faster than we realize.

The Bottom Line

The cost of waiting isn’t just about lost time, it’s about lost opportunities, lost learning and lost momentum. In software development, progress beats perfection every time. The most successful organizations, products and teams are those that embrace uncertainty, act with confidence and iterate their way to success.

So, the next time you’re tempted to wait for perfect clarity, ask yourself: What is the cost of waiting? Chances are, it’s higher than you think.

A Personal Announcement

If you've enjoyed exploring the themes of patience and timing in today’s article, you might find my book,

Wisdom of Middle-earth: 50 Lessons Inspired by The Lord of the Rings, particularly enlightening.

It delves into timeless wisdom drawn from the depths of Tolkien’s world, offering unique insights that resonate with our lives today.

Don’t wait to check it out. It’s available on Kindle now for those who are ready to embark on a journey of discovery and inspiration!

Agile once held the promise of flexibility, collaboration, and actual working software delivered frequently. But that was before we got our hands on it. We’ve twisted it, stretched it, and buried its original values so deep that all that’s left is the skeleton of a “framework” that we awkwardly nod at during meetings.

Today, I’ll show you the 7 surefire ways we’ve made agile utterly unrecognizable, with a little extra credit to leadership for adding their own flavor of chaos.

1. Sprints That Never End

Sprints are meant to be short, iterative cycles, but where’s the fun in that? Stretch your sprint goals like rubber bands. Spill unfinished work into the next sprint. Who cares if the backlog is growing faster than weeds in a garden? Deadlines are a social construct anyway.

Pro Tip:
Aim for a sprint backlog that looks like a family-size buffet; ambitious, chaotic, and far too much for anyone to digest.

Real-Life Example:
We had a 2-week sprint that turned into a 5-week crawl. By the time we finished, no one remembered what the original goal was. True agile spirit, right?

2. Daily Stand-Ups That Last Longer Than Your Lunch Break

Stand-ups are supposed to be quick syncs. But why stop at 15 minutes when you can turn it into a full-blown strategy session, therapy hour, or debate club? There’s nothing like someone giving a 10-minute monologue about “this one blocker” to derail the entire team.

Pro Tip:
The golden phrase is: “While we’re on this topic...” If no one’s actively checking the clock, you’re winning.

Real-Life Example:
With one team, our 15-minute stand-up always turned into an hour-long rant on implementation details, code reviews etc. Did we resolve anything? No. But we did thoroughly explore the concept of inefficiency.

3. Agile by Name, Waterfall by Nature

Sure, we call ourselves “agile,” but let’s keep operating like it’s the 1990s. Long roadmaps, unmovable deadlines, and milestone charts that look like they were drawn with a ruler. Flexibility? Please.

Pro Tip:
Use agile buzzwords like “iteration” while demanding multi-month plans signed in blood. Nothing screams agile like rigid, top-down processes.

Real-Life Example:
I once watched a team spend 2 weeks crafting the world’s most colorful Gantt chart to “plan” a 3-month roadmap. The chart was a thing of beauty. So many colors, so many milestones, and zero reality. By the time we actually started work, the plans were outdated, half the dependencies were non-negotiated or broken, and our will to live had officially expired. But hey, at least we had a stunning visual of what could have been.

4. Leadership That Refuses to Give Teams Autonomy

Agile thrives on empowered teams making decisions. But why trust the experts you hired when leadership can swoop in, second-guess every choice, and micromanage the backlog? Decisions aren’t for the team, they’re for the people above the team.

Pro Tip:
Make sure every decision needs leadership approval, no matter how small. Bonus points if you say things like, “I just want to make sure we’re aligned” while ensuring alignment never happens.

Real-Life Example:
A team I knew couldn’t even choose what tool to use without a VP weighing in. Autonomy? Never heard of it. Agile? Mostly just in name.

5. Jumping on Fancy Frameworks Like SAFe

SAFe - the perfect framework for leadership that wants the illusion of agile while maintaining their love for top-down control. Why stick to simple, flexible agile principles when you can add layers of bureaucracy, redundant ceremonies, and so many acronyms that no one knows what’s happening?

Pro Tip:
Talk about “alignment” and “scaled agility” while introducing unnecessary overhead. Nothing kills team flexibility faster than rigid frameworks disguised as solutions.

Real-Life Example:
I once attended a SAFe “PI Planning” session that spanned two full days. Did we align? Nope. But we did create 100 sticky notes that no one ever looked at again.

6. Letting Jira Run the Show

Jira - the tool that turns agile teams into ticket-checking zombies. Forget collaboration and creativity. Your only job is to click “In Progress,” “Blocked,” and “Done” while praying you don’t forget a subtask.

Pro Tip:
If anyone asks how the project is going, just send them a link to the 37,000-ticket backlog. Real progress happens in Jira, not in code.

Real-Life Example:
A development team I worked with spent more time managing tickets than actually coding. By the end of their sprints, we didn’t have working software, but our board sure looked immaculate.

7. Retrospectives That Change Absolutely Nothing

Retros, where we bravely admit everything that’s wrong, knowing full well it won’t matter. Write it all down on colorful (miro) sticky notes, nod enthusiastically at “action items,” and then promptly ignore them until next sprint’s retro.

Pro Tip:
If someone asks about last sprint’s action items, look confused and mumble something about “bandwidth.” Retros are about venting, not improving.

Real-Life Example:
Our team once spent an hour identifying “communication issues” as a recurring problem. Solution? Another meeting to discuss communication strategies. Did it work? Take a guess.

Agile Is Dead, Long Live Agile

If you’ve followed these steps, congratulations! You’ve successfully killed agile while maintaining the illusion of progress. Your sprints are chaotic, your retros are pointless, and your teams are drowning in Jira tickets. But hey, at least you can still throw around buzzwords like “velocity” and “incremental delivery” in leadership meetings.

The true spirit of agile isn’t about collaboration or delivering value. It’s about looking agile while doing the exact opposite.

So go forth and kill agile, one sprint at a time.

Subscribe now

Leadership is a tricky business. You want to stay involved, remain informed and appear helpful. So what’s the solution? Hovering over your team, reviewing every pull request and questioning every decision. After all, the closer you are to the code, the better the product… right?

Wrong.

Welcome to Leadership by Proximity, where leaders can’t let go of their developer glory days and insist on being “hands-on”, not because it helps but because trusting your team is apparently too risky. If you’ve ever wondered how to completely kill team morale, stifle growth and slow down delivery while believing you’re being an “involved leader,” buckle up.

Let’s explore why being “close to the code” doesn’t make you a great leader and what you’re missing out on while micromanaging everyone to oblivion.

1. Your Team Doesn’t Need a ‘Backseat Developer’

Here’s the truth: You were probably a great developer back in the day. Maybe you optimized queries, built clean abstractions, or wrote code so beautiful it deserved to hang in the Louvre. But now? Your job isn’t to code. It’s to lead.

Hovering over your team like a backseat driver (“Why’d you use that approach? Have you thought about doing X?”) doesn’t help. It just frustrates. Your team didn’t sign up for two code reviews: one from the relevant team members and one from you, the self-appointed “Chief Code Commenter”.

Pro Tip:
Ask yourself, “Does this really need my input?” If the answer is no, step back. Micromanagement doesn’t improve quality, it just slows everyone down.

Real-Life Example:
I once worked with a leader who spent hours reviewing his team’s (perfectly functional) code because it didn’t “feel” right. In the end, the team spent more time explaining their work than actually delivering. Progress? Nonexistent.

2. Micromanagement Is a Morale Killer

Nothing screams “I don’t trust you” like nitpicking every decision. The irony? You probably hired this team because they’re skilled, experienced and capable. So why treat them like interns?

Micromanagement isn’t just annoying, it’s demotivating. Teams that feel constantly watched stop thinking creatively, lose confidence and eventually give up. Why bother making decisions when the boss is going to override everything anyway?

Pro Tip:
If you can’t stop micromanaging, take up a hobby. Try woodworking, gardening, or writing the next Lord of the Rings, anything that keeps your hands off the code.

Real-Life Example:
A former colleague had a manager who would “shadow deploy” every release. After the team delivered, he’d secretly push his own changes live, like some kind of coding vigilante. Did it improve things? No. Did it destroy team morale? Absolutely.

3. Proximity Isn’t Productivity

The “close to the code” leadership style comes from a good place: the desire to stay informed. But being close to every commit, meeting and Slack message doesn’t make you productive; it makes you a bottleneck.

Instead of empowering the team to work autonomously, you’ve inserted yourself into every process. Now, nothing moves forward without your blessing and everyone’s just waiting for you to “review when you have time.” Congrats, you’ve become the single point of failure.

Pro Tip:
Great leaders unblock their teams. If you’re holding things up because you need to “check in” on everything, you’re not leading, you’re stalling.

Real-Life Example:
A manager once joined every single stand-up and asked individual developers for updates on Jira tickets. By the time we finished explaining things to him, the team had lost half the morning. “Productivity” was achieved only in his weekly report.

4. Autonomy Builds Better Teams (and Leaders)

Here’s a radical idea: trust your team. Empowering your people to make decisions doesn’t mean you’re disconnected; it means you’re building a team that doesn’t depend on you for every tiny thing.

When leaders back off and give teams the freedom to solve problems their way, amazing things happen. People take ownership, build confidence and start delivering better results. And here’s the kicker, you finally get to focus on actual leadership instead of micromanaging GitHub commits.

Pro Tip:
Set clear goals, align on priorities and then get out of the way. If something goes wrong, great leaders coach teams through the problem instead of saying, “I knew we should’ve done it my way.”

Real-Life Example:
One of the good leaders I ever had trusted us to experiment, learn and fail fast. The team delivered faster, collaborated better and felt like we actually owned the work. Weird how trust works, huh?

5. Fancy Frameworks Won’t Save You

When leaders realize micromanagement doesn’t scale, they often turn to fancy frameworks like SAFe, hoping for the illusion of control. Spoiler alert: SAFe doesn’t mean safe. It just means you’ve added more layers of process and bureaucracy to slow everyone down.

Instead of empowering teams, these frameworks introduce redundant rituals, endless planning sessions and enough acronyms to make your head spin. Flexibility? Gone. Innovation? Stifled. But hey, at least the Gantt chart looks good.

Pro Tip:
If your solution to chaos is “more process,” you’re probably solving the wrong problem. Focus on trust, transparency and clear goals, not over-engineering your team’s workflow.

Real-Life Example:
I once sat in a 2-day SAFe PI Planning session. By the end, we’d spent more time debating alignment than actually building anything. Did we scale agility? Nope. Did we scale confusion? Absolutely.

6. Leadership Is About Outcomes, Not Outputs

Great leaders focus on results, not micromanaging the “how.” If the product gets delivered, customers are happy and the team is thriving, does it really matter if someone didn’t follow your exact coding style?

When you fixate on outputs (individual lines of code or exact processes) you lose sight of what matters: delivering value. Let your team own the how and you focus on the why and what next.

Pro Tip:
Measure success in outcomes (user value, business impact), not in code reviews, velocity and Jira ticket updates.

Real-Life Example:
A leader once spent an hour critiquing a function name. That hour could’ve been spent shipping the feature or aligning on strategy. Instead, we got a lecture on “naming conventions.” Priorities.

7. Good Leaders Scale Themselves Out of the Day-to-Day

Good leaders don’t need to be “close to the code” because they’ve built teams they can trust. By empowering your people, you scale yourself. You’re no longer the bottleneck, you’re the enabler.

Your focus shifts from micromanaging to creating an environment where teams thrive. That’s real leadership, not hovering over pull requests.

Pro Tip:
If you’ve built a team that can function without you, you haven’t made yourself obsolete - you’ve made yourself a great leader.

Real-Life Example:
The best leader I knew spent more time coaching, mentoring and removing obstacles than scrutinizing technical decisions. The result? A team that delivered, grew and trusted each other.

Conclusion: Step Back to Lead Better

Being “close to the code” might make you feel helpful, but it doesn’t make you a good leader. Real leadership is about trust, autonomy and enabling teams to do their best work without you watching their every move.

So, take a step back, let your team own their decisions and focus on the bigger picture. After all, nobody’s looking to follow a backseat developer. They’re looking for a leader.

Subscribe now

As a software team, how often do you find yourself stuck in decision paralysis, waiting for perfect clarity before moving forward? Spoiler alert: perfection rarely arrives. Yet, the hesitation to act without "all the answers" can stall progress, kill momentum, and frustrate teams into oblivion. Here's a reality check: making decisions with incomplete information isn’t just okay, it’s often the only way forward.

The Unattainable Myth of Perfection

Let’s start with a truth most of us know but don’t always accept: we will never have all the data. Requirements will change. Stakeholders will add new conditions. Unknown dependencies will rear their ugly heads. If we wait until we feel completely certain, we’re not avoiding mistakes; we’re just creating a new kind of failure - failure to act.

This doesn’t mean we should act recklessly, but it does mean we should embrace a mindset that values progress over perfection. After all, software development is inherently iterative. You build, you learn, you adjust. Waiting for certainty robs us of the chance to learn faster.

Why Teams Hesitate

Several factors fuel this hesitation:

• Fear of Being Wrong: No one wants to be the one who made the “wrong” decision. But here’s the thing: sometimes the wrong decision teaches us what the right one should have been.

• Overvaluation of Data: Teams can fall into the trap of believing they need a mountain of data to validate every choice. Ironically, by the time you’ve gathered all that data, the problem may have evolved.

• Stakeholder Expectations: Teams feel the pressure to present foolproof plans to stakeholders, which often leads to analysis paralysis.

  ---

Acting with Confidence, Not Perfection

The key is to make decisions with confidence, even when the information is incomplete. Confidence doesn’t mean arrogance; it means trusting your team’s expertise, using available data, and knowing when to move forward.

Example: Shipping Features with Iterative Releases

Imagine a team debating whether to release a new feature. They’re stuck on edge cases - what if this fails under XYZ scenario? While those concerns are valid, the endless back-and-forth halts progress. Instead, they could:

• Roll out the feature to a small user segment.

• Collect real-world feedback.

• Address any issues in subsequent sprints.

By shipping iteratively, the team learns faster and adapts sooner, instead of wasting weeks debating hypothetical scenarios.

Practical Steps for Decision-Making with Limited Information

1. Define Your Risk Tolerance

Not every decision needs exhaustive scrutiny. Evaluate the potential blast radius:

• High impact, high risk? Slow down and involve more voices.

• Low impact, low risk? Make the call and move on.

Example: Refactoring a Legacy Feature

Instead of waiting for a complete understanding of dependencies, a team could focus on one small module at a time. If something breaks, the impact is isolated, and they’ve still made progress.

2. Use Data Strategically

Leverage the data you have, but don’t obsess over what’s missing. Often, 60-70% certainty is enough to act. Use the remaining 30% as an opportunity to learn and refine.

3. Create Feedback Loops

Build mechanisms to quickly validate or invalidate decisions:

• Roll out changes in A/B tests.

• Use feature flags to control visibility.

• Rely on metrics like user behavior, error rates, and engagement to guide iterations.

  ---

4. Communicate Transparently

Make sure your team and stakeholders understand that not all decisions are final. Position them as steps in a broader learning journey.

Example: Prioritizing a Sprint Goal

A team chooses to focus on enhancing performance for one feature, knowing there might be trade-offs with others. They communicate this decision and align on metrics to evaluate its success after deployment.

The Role of Leadership: Creating a Safe Space

Leaders play a critical role in fostering a culture where decisions can be made confidently without the fear of failure. This includes:

• Encouraging teams to experiment and iterate.

• Backing the team when things don’t go as planned.

• Shifting the focus from "getting it right" to "getting it moving."

One of the good leaders I worked with often said, "The worst decision is no decision." And they meant it. Waiting for perfect information wasn’t an option because they understood the opportunity cost of stagnation.

The Cost of Waiting

The biggest risk of decision paralysis is the opportunity cost. While you wait for all the answers, competitors move ahead, user needs evolve, and your team’s morale suffers. Remember, no amount of analysis can guarantee a flawless outcome. But no action guarantees no outcome.

What Progress Really Looks Like

True progress isn’t about getting every decision right the first time. It’s about maintaining momentum, learning from mistakes, and iterating toward success. The magic of software development lies in its agility. The ability to adapt, refine, and improve. Don’t let the fear of imperfection rob your team of that magic.

So, the next time you’re stuck in the endless loop of “Do we know enough to act?” remind yourself: decisions made with half the information are often better than no decisions at all. Move forward, embrace uncertainty, and let your team’s expertise guide the way.

Subscribe now

Happy New Year Folks! Let’s get into it.

Giving feedback is not an easy task. You’re essentially telling someone, “Hey, you could do and/or be better,” without making them want to pack up their desk or mute you forever on Slack. The secret? Delivering constructive criticism that sparks growth without leaving a trail of shattered confidence.

Spoiler alert: It’s not about sugar-coating the truth or drowning it in compliments. It’s about being clear, actionable, and, dare I say it, a little human. Let’s dive into how to master the art of feedback without turning your one-on-ones into therapy sessions.

1: Be Blunt, but Not Brutal

Honesty is the foundation of good feedback, but there’s a difference between being direct and being a jerk. Skip the fluff and get to the point. Your team doesn’t need a Shakespearean monologue about their work ethic; they need clarity.

Example:

• Instead of: “This project isn’t meeting expectations, but you tried really hard, and that counts for something.”

• Say: “This project isn’t meeting expectations. Let’s break down why and figure out a way forward.”

It’s not about being “nice”. It’s about being constructive while still being human.

2: Focus on the Work, Not the Person

The quickest way to destroy morale is to make feedback personal. Critique the task or the decisions, not the individual. Remember, you’re here to fix the output, not their personality.

Example:

• Instead of: “You’re disorganized and it’s affecting the team.”

• Say: “The project tracking isn’t as clear as it could be. Let’s look at tools or approaches to improve it.”

See? Same message, less drama.

3: Make It Specific and Actionable

Vague feedback is about as useful as a GPS that says “Turn somewhere soon.” Your team needs actionable advice, not riddles.

Example:

• Instead of: “You need to improve your communication.”

• Say: “In our last meeting, the action items weren’t clear. Let’s try ending with a summary next time.”

Specific feedback gives people something to work with. Ambiguity just makes them frustrated or worse, defensive.

4: Timing Is Everything

There’s a fine line between providing timely feedback and blindsiding someone. Feedback works best when it’s given promptly and when emotions aren’t running high, think right after a sprint retro, not mid-crisis.

Pro Tip:
Deliver feedback as soon as it’s relevant, ideally when it can still make a difference, like after an incomplete deliverable but before the next deadline.

What Not to Do:
Don’t wait until the next big project to say, “By the way, your last report was confusing.” Nothing screams “I’ve been holding a grudge” quite like late feedback.

5: Ask Questions Instead of Dictating

Instead of barking out orders or handing down judgments from your managerial throne, try turning feedback into a conversation. Questions help the other person think critically and feel like they’re part of the solution.

Example:

• Instead of: “You need to stop overcomplicating designs.”

• Say: “What’s the core problem you’re trying to solve with this design? Is there a simpler way to achieve it?”

Questions encourage dialogue, not defensiveness. Plus, it subtly implies, “Hey, I trust your brain to figure this out.”

6: Don’t Forget the Bigger Picture

Feedback is more effective when it’s tied to goals and outcomes, not just nitpicking for the sake of it. Frame your critique in terms of how it contributes to the team’s or company’s success.

Example:

• Instead of: “Your code review comments aren’t helpful.”

• Say: “By providing more detailed and actionable comments in code reviews, we can help the team improve quality faster and reduce rework during the sprint.”

When people see how their improvement aligns with the bigger picture, they’re more likely to take it seriously and less likely to roll their eyes when you’re not looking.

7: Follow Up Without Hovering

Feedback isn’t a one-and-done deal. Following up shows that you care about progress without micromanaging. Think of it like watering a plant, too much attention, and you drown it; too little, and it withers.

Example:

• “Hey, I noticed some improvements in how you’ve been organizing tasks. Great work! Let me know if you need support to keep building on that.”

Follow-ups show that you’re invested in their growth, not just ticking a box for HR.

8: Know When to Keep Your Mouth Shut

Not all feedback is worth sharing. Sometimes, the best feedback is letting people learn from their own mistakes. If the error isn’t critical or doesn’t impact the team’s success, consider giving them the space to figure it out.

Pro Tip:
Before you give feedback, ask yourself: “Is this worth bringing up, or am I just nitpicking to feel important?” (Spoiler: It’s probably the latter.)

9: Feedback Isn’t Just for the Bad Stuff

When we hear "feedback," we often assume it’s code for “Here’s everything you did wrong.” But feedback is a two-way street. It’s just as important to highlight what’s working well as it is to point out what needs improvement.

Celebrating wins and reinforcing positive behavior isn’t just about making people feel good (though that’s nice too), it encourages the team to double down on what they’re already doing well and builds a culture of trust and recognition.

Pro Tip:
Positive feedback is most impactful when it’s specific. Don’t just say “Good job”; explain why it was good and how it made a difference.

Example:

• Don’t just say: “Your problem solving approach was innovative.”

• Add: “Your approach saved us significant time during implementation, and I think we should apply it to future projects as a best practice.”

Be Direct, Be Kind, Be Useful

Good feedback doesn’t need to be sugar-coated, but it does need to be helpful. It’s about showing your team where they can grow while giving them the tools and confidence to actually do it.

So, ditch the compliment sandwiches and focus on being clear, constructive, and maybe just a little bit human. Who knows? You might just foster growth without anyone sobbing into their coffee.

Now go forth, feedback warriors, and make the workplace a better (and slightly less awkward) place. One honest conversation at a time.

Subscribe now

As the year winds down, I wanted to take a moment to pause, reflect, and thank all of you for being part of this journey.

I started Team Dynamics 101 just a few months ago, driven by my passion for sharing my experience around what makes software teams tick. It’s been a wild and rewarding ride, and seeing so many of you join, read, and share these articles has been the greatest gift I could ask for.

From exploring the quirks of ineffective meetings to poking fun at the pitfalls of agile, this space has become something I’m genuinely excited about each week. Your support, whether it’s through subscriptions, feedback, or just the occasional “Hey, I needed that laugh today”, means the world to me.

What’s Next?

I’ll be taking a short New Year’s break to recharge (and maybe plot a few more sarcastic rants). The next article will drop on January 7th, and trust me, there’s plenty more cool stuff coming your way in 2025.

Until then, I hope you all get some well-deserved rest, time with loved ones, and maybe even a meeting-free week (imagine that!).

Wishing you a Merry Christmas, Happy Holidays, and a New Year full of great ideas, productive teams, and slightly fewer “quick syncs.”

See you in January! 🎉

- Pranshu

Let’s get one thing straight: technical debt isn’t the secret playground of engineers. It doesn’t quietly sit in the background while teams merrily ship features. It’s a ticking time bomb, and when it goes off, the blast radius impacts everyone; Product Managers, stakeholders, users, and yes, even the engineers who warned about it in the first place.

Yet, technical debt is often brushed aside as “engineering problem,” something to be dealt with later when there’s “time”. Spoiler alert: there’s never time. And by the time you do get around to addressing it, the costs have ballooned, timelines have slipped, and user trust has eroded.

So let’s talk about why technical debt is everyone’s problem and, more importantly, how we can tackle it together.

What Is Technical Debt?

Technical debt is like cutting corners to meet a deadline. It’s the code you know isn’t optimal but works for now. It’s the shortcuts, the hacks, the “we’ll refactor this later”, decisions that pile up over time. But just like financial debt, it accrues interest. The more you ignore it, the harder it becomes to move quickly and effectively.

Example:

Imagine you’re building a house. You decide to skip insulation to save time and money. The house looks fine, but when winter arrives, heating costs skyrocket. Fixing it later means tearing down walls; a much bigger (and costlier) problem than doing it right the first time.

In software, technical debt manifests as slower (future) development cycles, more bugs, and increased maintenance costs. The real kicker? It eventually blocks your ability to innovate and deliver value.

Why Should Everyone Care?

1. It Slows Down Feature Delivery

The same codebase that shipped your MVP quickly becomes a drag when debt piles up. Every new feature takes longer to implement because the foundation is shaky. Engineers spend more time untangling old decisions than building new solutions.

2. It Affects User Experience

Technical debt isn’t just an internal issue. Users notice when systems crash, when performance lags, or when features are half-baked because the underlying code is duct-taped together.

Example:

A team rushed to ship a feature for a major customer demo, skipping proper testing and ignoring warnings about scalability. The feature worked during the demo but crashed under real-world user load. The fallout? Lost revenue and a strained customer relationship.

3. It Increases Costs

Bugs caused by technical debt lead to rework, firefighting, and longer development cycles. These costs are rarely factored into project budgets, but they’re very real and they grow exponentially over time.

Addressing Technical Debt: A Team Sport

The good news? Addressing technical debt doesn’t have to be a blame game. It’s about collaboration, alignment, and shared responsibility.

1. Acknowledge It Openly

The first step is to admit that technical debt exists and affects everyone. Avoid framing it as an “engineering issue”. Instead, discuss it as a barrier to delivering business value.

2. Make It Visible

Use metrics to quantify technical debt and its impact. Highlight things like bug resolution time, developer productivity, and user feedback. When stakeholders see the data, it’s easier to prioritize debt alongside features.

Example Metrics:

• Cycle Time: How long does it take to complete a task?

• Error Rates: Bugs caused by rushed solutions.

• Downtime: How often are users affected by system failures?

• MTTR: How long does it take us to restore service?

• Deployment Frequency: How often can we deploy? How painful is each deployment?

3. Prioritize It Like Any Other Work

Technical debt shouldn’t live in the shadows. Bring it into the backlog. Make it part of the conversation during refinements and planning.

4. Build It Into the Roadmap

Just like features, technical debt has a place on the roadmap. Use initiatives like “tech sprints” to get this going and then dedicate a percentage of each sprint to tackling it. Product Managers, this is where you shine; connect the debt to business outcomes, like faster delivery or improved user satisfaction.

5. Set the Right Culture

Leaders need to create an environment where engineers feel empowered to call out technical debt without fear of being labeled blockers. Teams should celebrate proactive maintenance, not just shiny new features.

Balancing Debt and Delivery

Here’s the tricky part: You can’t eliminate all technical debt, nor should you try. Some debt is necessary to move quickly, especially in the early stages of a project. The key is knowing when to take on debt and when to pay it off.

Example:

A startup rushes to release a feature critical for landing funding. They knowingly accrue debt but have a plan to address it in the next quarter. That’s smart debt. Compare this to a team that accrues debt without a strategy. This is where things spiral out of control.

Final Thoughts

Technical debt is everyone’s problem because it affects what we all care about: delivering value to users, staying competitive, and maintaining a healthy team culture. It’s not about pointing fingers; it’s about working together to build something sustainable.

So, the next time someone asks why we’re spending time “cleaning up code,” remind them: It’s not just cleanup. It’s an investment in your team’s ability to innovate, deliver, and thrive. Let’s stop treating technical debt like a dirty secret and start treating it like the strategic priority it is.

Subscribe now

Ah, velocity. The cherished metric of software teams everywhere; or at least by the managers who love charts and graphs with upward trajectories. For those unfamiliar, velocity is the measure of how many story points a team delivers in a Sprint. And while it sounds useful, in my experience, it’s one of the most misunderstood and misused concepts.

So, let’s dig in. Is velocity the holy grail of team productivity, or is it the illusion of control dressed up as a metric? Spoiler: it’s the latter.

The Story Points Illusion

At its core, story points are a relative measure of effort, complexity and risk. They make sense within a team. Emphasis on within. Team A’s story points are not comparable to Team B’s, and even within Team A, story points are just a tool to facilitate discussions. Yet somehow, people outside the team love to treat them like absolute truths.

Enter the dreaded question: “Why is our velocity lower this Sprint?”

Here’s the thing - story points are not deadlines. They’re not commitments. They’re not progress indicators. They’re simply a way for a team to collectively understand the complexity of their work. However, when managers start equating velocity with productivity, it quickly devolves into nonsense metrics that drive unhealthy behaviors.

When Velocity Becomes a Problem

1. The Illusion of Control

Velocity gives some managers the illusion that they’re in control. By tracking the “number” of story points delivered, they think they’re driving efficiency. But here’s the truth: asking “Why is velocity down?” doesn’t magically solve user problems. It just pressures the team to inflate numbers or sacrifice quality to hit an arbitrary target.

2. Unhealthy Comparisons

“Team B is delivering 100 story points per Sprint; why are we only doing 60?”
This question is the equivalent of comparing apples to oranges. Different teams, different contexts, different baselines. It’s not only unproductive; it undermines team morale.

3. Missing the Bigger Picture

Focusing on velocity distracts teams from what actually matters: solving user problems and delivering outcomes. The goal isn’t to deliver the most story points. It’s to deliver the most value.

What Story Points Are Actually Good For

Let’s be fair: story points aren’t inherently bad. They serve one valuable purpose - building a shared understanding.

When a team estimates a story, it forces them to discuss complexities, dependencies, and potential risks. That’s the real value. It’s not about whether a task is a “3” or a “5.” It’s about the conversation that happens when someone says, “Wait, why do you think this is a 13? Did we miss something?”

Story points drive collaboration. They help teams align on what needs to be done and how difficult it will be. But beyond that? The actual number doesn’t matter.

Stop Obsessing over Velocity and Start Measuring Outcomes

The most productive teams don’t obsess over how many story points they’ve delivered. Instead, they focus on the outcomes they’re driving.

Here’s what that looks like:

• Instead of asking: “What’s our velocity this Sprint?”

• Ask: “Did we achieve our Sprint Goal? Did we move closer to solving our user’s problem?”

The best metrics aren’t about how many tasks you’ve completed. They’re about the value you’ve delivered. For example:

• Did we reduce user churn by X%?

• Did we speed up onboarding by Y minutes?

• Did we address a critical user pain point?

Velocity is about output. Outcomes are about impact. Choose wisely.

The Role of Leadership in Fixing This

If you’re in a leadership role and you’re still using velocity as your north star, it’s time to rethink. Your job isn’t to push the team to deliver more points, it’s to create an environment where the team can deliver meaningful results. That means:

• Trusting your team’s expertise. They’re closest to the ground. Let them define how to get there.

• Setting clear goals. Help the team focus on outcomes, not tasks.

• Removing obstacles. Whether it’s endless meetings or unclear priorities, your role is to clear the path for your team to thrive.

And most importantly, stop asking why velocity is low. Start asking how you can help the team achieve their goals.

A Real-World Example

Eons ago, I worked with a team that consistently delivered “low velocity” compared to others in the organization. On paper, it looked bad. But here’s the thing: they were solving big, hairy problems that had gone unaddressed for years. Their work directly reduced customer churn, improved retention metrics, and created new revenue streams.

Meanwhile, another team with “high velocity” was churning out low-impact features no one asked for. Guess which team added more value to the company?

Where Do We Go From Here?

If we want to build better teams and better software, we need to stop obsessing over how many story points we can cram into a Sprint. Instead, we need to:

• Focus on meaningful goals. Set Sprint Goals that solve real problems.

• Measure what matters. Define metrics that reflect user impact, not task completion.

• Use story points for alignment. Not as a scoreboard.

Velocity isn’t inherently evil, but it’s not a measure of success either. If we keep treating it like one, we’ll miss the forest for the trees. So let’s stop caring about how fast we’re moving and start caring about where we’re going.

Because in the end, the goal isn’t just to move fast. It’s to move forward in the right direction.

Subscribe now

In software development, there’s nothing quite as frustrating as the word “done.” It sounds definitive, but without a clear Definition of Done (DoD), it’s anything but.

“Done” can mean different things to different people; developers, testers, Product Owners, and stakeholders. And when those definitions clash, chaos isn’t far behind.

Why Do You Need a Definition of Done?

A strong DoD is more than a box-ticking exercise. It’s the backbone of a team’s workflow, ensuring that what gets shipped is valuable, reliable, and ready for users. Here’s what it accomplishes:

• Creates a Common Understanding of Quality
  The DoD establishes a baseline for what “done” looks like. Without it, teams often assume wildly different standards. One person might think a PBI is done when the code is written; another might expect full integration testing.

• Reduces Rework
  By preventing PBIs that don’t meet the DoD from moving forward, you avoid the costly cycle of revisiting incomplete or broken work.

• Builds Stakeholder Confidence
  When teams follow a clear DoD, stakeholders know they’re getting features that meet agreed-upon standards, not half-baked code rushed to production.

• Prevents Unfinished Work from Reaching Users
  A poorly implemented feature can damage your product, reputation, and user experience. The DoD ensures only high-quality work makes it out the door.

  ---

Why Poor DoD Is a Recipe for Disaster

• Misaligned Expectations
  Imagine this: A developer marks a feature as done because the code works locally. The tester assumes it's incomplete because it hasn’t been integrated. Meanwhile, the Product Manager expected it live in production yesterday. This kind of misalignment is the hallmark of a poorly defined DoD.

• Endless Rework
  I once worked with a team that shipped a “done” feature, only to spend three more sprints fixing bugs, scaling it for production, and updating documentation. Why? Their DoD didn’t include performance benchmarks or documentation updates.

• Stakeholder Frustration
  When features are marked as “done” but don’t work as expected, stakeholders lose trust in the team. Worse, they might start micromanaging future sprints, undermining the team’s autonomy.

DoD vs Acceptance Criteria

• Definition of Done: Focuses on technical completeness and team-defined quality standards that apply to all PBIs.

• Acceptance Criteria: Focuses on user needs, specific to each PBI, ensuring the feature delivers the intended value.

• DoD vs. Acceptance Criteria

  Here’s a simple metaphor to understand the distinction. Imagine you’re building a car.

  • Definition of Done (DoD): The car passes all official technical inspections and is roadworthy.

  • Acceptance Criteria: The car has a red exterior, a trunk size above X liters, and built-in Bluetooth.

  Both are critical, but they serve different purposes. Without meeting the DoD, the car isn’t safe to drive. Without meeting the Acceptance Criteria, the customer won’t buy it.

How to Build a Strong DoD

Creating an effective DoD doesn’t happen overnight, but here’s a roadmap:

• Collaborate to Define It
  Involve developers, testers, Product Managers and even stakeholders. The DoD should reflect the needs of everyone involved.

• Start Simple
  Begin with a basic checklist: code reviews, unit tests, and integration tests. Add more layers over time, like performance testing and scalability benchmarks.

• Document It Clearly
  Post your DoD where it’s easily accessible. Ambiguity is the enemy of productivity.

• Revisit Regularly
  As your team grows and the product evolves, your DoD should too. Periodically review it to ensure it remains relevant and effective.

What’s in a Good Definition of Done?

A strong Definition of Done (DoD) ensures that work is complete, high-quality, and ready to deliver value. A robust DoD evolves over time and can be categorized into levels of maturity; Good-Enough, Good and Mature.

Regardless of the maturity level, a good DoD focuses on Quality Standards and Non-Functional Requirements.

1. Quality Standards

These are the technical checks and balances that ensure your code and features meet the team’s defined expectations. Here's an example of how they evolve:

Initial DoD: Foundational Quality

• Unit Test Coverage: At least 85% to ensure critical parts of the codebase are tested.

• Functional Testing: All functional tests pass without issues.

• No Known Defects: Any bugs identified during testing are resolved before release.

• Peer Code Reviews: Every piece of code is reviewed and approved by teammates.

• Documentation: Completed and updated to reflect changes.

Mature DoD: Improving Quality Assurance

• Maintainability Index: Ensuring code maintainability with a score of 90 or higher.

• Functional Test Automation: Over 75% of functional tests are automated to improve efficiency.

• No Coding Standard Errors: Adherence to best practices and agreed coding standards.

• Technical Debt: Addressed promptly and kept under 5 days (subjective).

Stringent DoD: Advanced Quality Standards

• Regression Testing: All regression tests are completed and pass.

• Performance and Load Testing: Benchmarked to ensure the feature meets performance standards under expected loads.

• PEN Testing: Ensuring security vulnerabilities are addressed.

• Regulatory and Compliance Updates: Meets industry regulations and standards.

• UAT Approved: User Acceptance Testing is completed and approved by relevant people.

2. Non-Functional Requirements

These often-overlooked aspects ensure the software remains reliable, scalable, and user-friendly over time:

• Availability: The system meets uptime requirements.

• Scalability: The feature or application can handle future growth and increasing user demand.

• Performance: Features meet predefined benchmarks, ensuring speed and efficiency.

• Security: Complies with legal, regulatory, and organizational standards to protect data and systems.

• Maintainability: Code is well-structured, easy to understand, and simple to update.

• Usability: Features meet user experience guidelines, ensuring they are intuitive and functional.

  ---

The True Meaning of Done

Here’s the bottom line: “Done” isn’t just about shipping a feature. It’s about delivering value. Without a strong Definition of Done, you’re not building software. You’re building confusion.

The next time someone says a PBI is done, don’t just take their word for it. Ask them:

• Has it passed all the tests?

• Is it ready for production?

• Does it meet user needs and expectations?

• Does the customer know about this? Can they use it? (credits: )

Because if it doesn’t check all the boxes, it isn’t done.

And remember: Done is more than a checkbox. It’s a commitment to quality, alignment, and user satisfaction.

Subscribe now