492: Defining value within your team

What It Covers

Sally Hall and Adi Slater explore how to define and communicate value in software development beyond traditional metrics like lines of code or features shipped. They examine measuring success through problem-solving, working with non-technical stakeholders, identifying root causes versus symptoms, and the importance of user research in delivering meaningful solutions.

Key Questions Answered

• •Measuring Developer Value: Evaluate work through problems solved or prevented rather than lines of code, features shipped, or hours worked. A week spent on unimportant work delivers less value than quickly fixing a critical issue. Focus on whether users can complete tasks faster, with fewer errors, or have a more pleasant experience using the software.
• •Performance Optimization Impact: When revisiting code after two years, addressing n plus one queries and eliminating unnecessary operations like refreshing materialized views 10,000 times within transactions can yield 400 percent speed improvements. These concrete performance gains communicate value to stakeholders more effectively than technical explanations about query optimization or database architecture.
• •Stakeholder Communication Strategy: Non-technical stakeholders need metrics tied to their original motivation for hiring developers. Instead of explaining technical debt or architecture improvements, frame value in terms of reduced employee turnover, increased user retention, faster task completion, or revenue impact. Ask what problem they came to solve, not just what features they requested.
• •Building Versus Validating: Sometimes the most valuable work is not building features but preventing unnecessary development. Designers can test and validate concepts quickly through prototypes and user interviews, saving months of engineering time on features nobody wants. Ruthlessly delete unused code rather than commenting it out, since all code represents maintenance liability.
• •Root Cause Analysis: Users often request solutions to symptoms rather than underlying problems because they describe workarounds developed over years. Shadowing users and conducting deep interviews reveals the actual workflow needs versus adapted behaviors around software limitations. This investigation reduces complexity and eliminates unnecessary features that perpetuate inefficient processes.