Solving the Accountability Puzzle in Software Organizations

Software development teams often find themselves caught in a frustrating bind. Business leaders expect clear results, like revenue or customer retention, while engineers are judged on meeting deadlines for specific features. This disconnect creates tension, as coding isn't a predictable assembly line. It's a creative process full of discovery, where pinning down exact outcomes feels like trying to predict the weather months in advance. The result? Teams end up chasing arbitrary deadlines instead of delivering real value, leaving everyone dissatisfied.

This issue isn't new. Since the 1968 NATO Software Engineering Conference highlighted the 'software crisis' caused by late and over-budget projects, the industry has grappled with how to measure success in a field where uncertainty is the norm. Unlike sales teams, which commit to revenue targets without specifying every deal, engineering teams are often held to rigid feature-and-date promises. This misalignment fuels frustration, as developers feel micromanaged while executives wonder why their investments aren't paying off.

A big part of the problem lies in who makes decisions. Product managers, tasked with shaping strategy and prioritizing features, often face scrutiny for lacking deep technical or financial expertise. Some engineers argue these roles create unnecessary layers, slowing down decisions and adding bureaucracy. For example, discussions on platforms like Hacker News in 2025 highlighted concerns about product managers lacking technical, financial, or sales expertise while retaining decision-making power, leading to unrealistic plans.

Yet, product managers aren't the sole issue. Engineers, while skilled in building systems, may lack the market or customer insight needed to prioritize effectively. The tension boils down to a power struggle over who should steer the ship. Airbnb's 2023 restructuring, which transformed traditional product management into Apple-style product marketing functions, sparked debates about whether these positions are essential or just organizational bloat. The answer isn't clear-cut, but it's evident that unclear roles and overlapping authority create bottlenecks.

One promising solution comes from James Shore, VP of Engineering at OpenSesame, who introduced the Product Bets framework at Agile Cambridge on October 2, 2025. Instead of tying success to specific features or deadlines, Product Bets focus on estimated business value. Each bet outlines a business outcome, like boosting retention or cutting costs, with a financial estimate based on discounted cash flow analysis. Teams commit to delivering a dollar amount of value annually, much like sales teams target revenue without predicting every deal.

This approach flips the script. It treats software development as an iterative discovery process, not a homework assignment with a due date. At OpenSesame, Shore's team spent nearly two years refining this model, gaining traction by shifting conversations away from feature checklists toward strategic outcomes. While no bets were fully completed by the presentation date, early results showed less pushback on deadlines and more focus on what truly matters.

OpenSesame's journey offers one case study, but PostHog provides another compelling example. This analytics platform embraces an engineering-led approach, where product engineers set quarterly goals based on user needs rather than rigid metrics like OKRs. By giving developers autonomy to decide what to build, PostHog avoids wasteful processes and focuses on delivering features users actually want. Feedback loops ensure accountability without heavy-handed oversight, proving that engineers can prioritize effectively when given clear context.

Contrast this with Microsoft's 2000s-era misstep with test-driven development (TDD). The company tried to impose TDD as a prescribed, up-front process, missing its iterative essence. This led to guidelines that clashed with the discovery-driven nature of software, showing how rigid frameworks can backfire. The lesson? Accountability systems must embrace flexibility, not force predictability where it doesn't belong.

For accountability to work, organizations need clear roles and consequences. Product Bets require strong executive buy-in, as leaders must sponsor bets and accept that estimates, not hard numbers, drive decisions. This can be tough for data-driven cultures craving precise ROI. Shore's own CFO noted that their financial model was a starting point, needing more rigor over time. However, the framework's strength lies in its honesty about uncertainty, letting teams pivot without being locked into bad plans.

Critics argue that estimated value feels too abstract, potentially letting teams dodge real accountability. There's also the risk of leadership resisting personal responsibility while demanding it from others. The solution lies in fostering a meritocratic system where competent decision-makers gain influence through results, and those who falter step aside. This requires psychological safety, so teams can admit failures without fear of blame.

The push for better accountability comes at a pivotal time. With 92 percent of product teams testing AI tools in 2024-2025, the pressure to deliver meaningful outcomes is higher than ever. AI introduces new complexities, like security risks and novel failure modes, which demand accountability systems that prioritize user value and compliance over feature quotas. Meanwhile, the rise of product-led growth, seen in companies like Slack and Zoom, shows that focusing on user behavior changes can drive success without heavy sales reliance.

The road ahead isn't easy. Cultural resistance, especially from leaders used to predictable project plans, remains a hurdle. Yet, frameworks like Product Bets and engineering-led models like PostHog's offer a path forward. By aligning teams around outcomes, not outputs, and clarifying decision-making roles, software organizations can break free from the accountability trap and build products that truly deliver.