In his book Ego is the Enemy, Ryan Holiday urges us to keep our own internal scorecard. He emphasizes that true excellence and meaningful achievements come not from external validation, but from internal standards rigorously upheld.
Software engineering and management often revolve around metrics: story points, sprint velocity, feature counts. Managers love measurable outputs. Executives delight in dashboards and charts.
But an uncomfortable truth often goes unnoticed: these external metrics frequently obscure rather than illuminate genuine value.
Metrics become targets, and targets inevitably distort the real work.
Great software engineers and exceptional managers operate differently.
They maintain an internal scorecard.
They hold themselves accountable to standards beyond what anyone explicitly requires. This practice transforms their work into a craft, not just a job.
External Scorecards Are Misleading
Management by numbers feels reassuringly objective. Yet it rarely captures genuine effectiveness. Story points are easily inflated. Velocity might surge temporarily, but at what cost? Deadlines, when set arbitrarily, lead teams to rush solutions that create more problems down the line. Teams chasing external metrics often find themselves trapped in a paradox of productivity.
Busy yet unproductive, active yet ineffective.
Worse, these external metrics create perverse incentives. Engineers might ship more frequently, but the quality of their solutions suffers. The resulting technical debt and brittle systems damage long-term product viability.
The metric has been met, but the business impact is negative.
Real business value stems not from the quantity of code or the speed of deployment, but from the quality, stability, and usefulness of the software delivered. High-quality software delights customers, builds trust, and drives sustainable growth. Ironically, none of these outcomes are fully captured by external metrics.
Internal Scorecards Define Excellence
The antidote to misleading external metrics is an internal scorecard, reflecting values engineers and managers uphold privately. An internal scorecard focuses on intrinsic measures:
quality,
maintainability,
readability,
pride in one’s work.
Software engineers committed to internal excellence proactively refactor messy code, write meaningful documentation, and thoroughly test their work. Even when no one explicitly demands it.
Their standards aren’t enforced externally; they arise from a deep professional identity.
Similarly, engineering managers who keep internal scorecards care deeply about mentoring, coaching, and team health. They prioritize developer experience and sustainable practices, even if these factors aren't immediately visible in productivity reports.
Internal standards reflect an ethos: doing what's right rather than what's easy or expedient.
Local Testing & Peer Reviews: A Personal Experience
I once managed a team working on a big, monolithic system that was absolutely critical to the company's operations. We shared the responsibility for this system with other teams. Our team made a conscious choice to enforce rigorous local testing and peer reviews for every pull request. This standard was self-imposed- no company-wide mandate required it. Peer reviewers didn’t merely glance at code, they tested the changes locally, challenged assumptions, and suggested meaningful improvements.
Other teams opted for lighter reviews and quicker merges. Initially, these teams seemed to outpace us in feature delivery. However, time revealed the true cost of their approach. Those teams faced incidents and customer-reported bugs. The velocity ultimately suffered, overshadowed by reliability issues and unhappy stakeholders.
In contrast, our team quietly built a reputation for stability and reliability. Our rigorous internal standards had a direct and measurable impact on reducing incidents. Over time, our team was recognized not merely for speed, but for sustainable business impact.
The key insight from this experience: externally enforced metrics rarely capture true effectiveness. Our internal scorecard- quality-driven, peer-enforced, privately maintained, consistently delivered greater long-term value.
Practical Steps for Keeping Your Own Scorecard
Developing an internal scorecard isn't abstract theory; it involves concrete, actionable steps:
Rigorous Code Reviews: Go beyond superficial reviews. Actively test code locally, question assumptions, and provide meaningful, constructive feedback.
Comprehensive Documentation: Write clear documentation not because someone explicitly demands it, but because you respect your future self and your colleagues.
Regular Refactoring: Proactively clean up technical debt, even if no immediate crisis demands it. Prevent future fires instead of merely reacting to them.
Blameless Incident Reviews: Treat incidents as valuable learning opportunities. Use incidents to refine your team's internal scorecard and processes continuously.
Developer Experience as a Key Metric
Developer Experience (DevEx) rarely appears explicitly in external metrics, yet it profoundly influences team productivity and morale. Teams operating with internal scorecards proactively identify and improve DevEx issues:
Regularly addressing slow builds and flaky tests.
Streamlining onboarding processes for new developers.
Investing in clear, well-designed internal APIs and tooling.
Improving DevEx creates a virtuous cycle. High-quality tools and processes empower teams to deliver better software faster, with less frustration.
Over time, this internal metric creates externally visible impacts
fewer defects,
faster delivery,
higher employee retention.
Leadership and the Internal Scorecard
Engineering managers and technical leaders carry significant responsibility for setting internal standards. Leaders who openly demonstrate and discuss their own internal scorecards shape their teams profoundly.
When leaders visibly prioritize quality, integrity, and long-term thinking, teams naturally follow.
Practically, leaders can reinforce internal standards by:
Celebrating thoughtful refactoring and high-quality code reviews openly.
Protecting team time dedicated to improving internal tooling and processes.
Providing context around business impact, connecting internal standards explicitly to long-term organizational success.
Driving Product Outcomes Through Internal Standards
Maintaining an internal scorecard also involves challenging product requirements and advocating for maximum customer value, even if such questioning isn't traditionally expected from engineers. Engineers and managers with strong internal standards are willing to ask hard questions, push back on unclear or ineffective requirements, and continuously align their efforts with genuine user needs.
Engineers who keep a strong internal scorecard don’t just implement features blindly. Instead, they actively seek clarity on
why specific features are being requested,
how success will be measured,
whether there's data or customer feedback supporting the requirements.
They challenge product managers by asking probing questions like: "What customer pain point does this solve?" or "How do we validate the necessity of this feature?" Such dialogue can significantly enhance the overall value delivered to customers.
Moreover, teams that adhere to internal excellence standards take ownership of product success, not just technical correctness. They proactively suggest simpler, more effective solutions that may reduce engineering effort while delivering greater customer value.
For example, rather than building complex customizations based on assumptions, an engineer might advocate for a minimal viable experiment to test the real customer demand first. This approach ensures resources are spent effectively and aligned with genuine market needs.
Ultimately, keeping an internal scorecard means engineers and managers step beyond their traditional roles, actively influencing product strategy and decision-making. This advocacy is crucial to creating meaningful, valuable products that genuinely meet customer needs and drive sustainable business outcomes.
Avoiding the Ego Trap
Keeping your own internal scorecard must not devolve into self-serving ego reinforcement. Maintaining high standards is about professional pride and integrity, not superiority.
The internal scorecard is quietly confident, never arrogant.
Yet, there's a subtle but critical balance between striving for excellence and slipping into harmful perfectionism.
Excellence drives value, encourages growth, and ensures robust solutions.
Perfectionism, however, can paralyze progress, create unnecessary friction, and stifle innovation.
Engineers and managers must remain vigilant to ensure their pursuit of quality does not become self-indulgent or counterproductive.
Signs of perfectionism include continuously polishing a feature long past diminishing returns, hesitating to ship due to fear of criticism, or stubbornly clinging to a specific solution rather than flexibly adapting based on feedback. To avoid these pitfalls, teams must regularly reflect on their motivations and the true impact of their efforts.
Practically, maintaining balance means setting clear criteria for what constitutes sufficient quality, defining when additional effort becomes wasteful rather than beneficial, and ensuring open dialogues within teams about when to stop refining and move forward. Examples of sufficient quality criteria might include:
The code meets the defined acceptance criteria and passes all relevant automated tests.
Documentation clearly describes the purpose, functionality, and usage of the code, ensuring future maintainability.
The solution aligns closely with the defined customer needs and business goals, validated by direct stakeholder feedback.
Refactoring and optimization efforts have removed obvious technical debt without becoming excessive or obsessive.
Peer reviews indicate clarity, readability, and adherence to agreed-upon coding standards and best practices.
Excellence is dynamic, not static. Internal standards evolve as the team's context and the organization's needs change. Rigidity and arrogance destroy the very flexibility that internal scorecards seek to foster.
Conclusion: Real Impact Comes from Within
External metrics like story points, throughput, velocity offer superficial reassurance. True business impact and customer delight arise from internally driven excellence. Keeping your own scorecard ensures that your work has integrity, longevity, and genuine value.
The teams and engineers who leave lasting impressions in their organizations and industries are those guided by internal standards. They pursue excellence for its own sake, confident that quality inherently creates business impact and customer satisfaction.
Reflect on your own internal scorecard. What values define your professional identity? Which internal standards guide your work? The answers to these questions define not only your current effectiveness but your lasting legacy.
Your internal scorecard, quietly maintained and rigorously upheld, becomes the silent engine driving your team's real, measurable business impact.
Keep your own scorecard; it will define your career.
You may also enjoy
Happy Engineers Ship. Miserable Engineers Interview Elsewhere.
Engineering teams do not fail because of bad technology choices. They do not fail because of outdated frameworks, slow CI pipelines, or lack of microservices. These are symptoms, not root causes. Teams fail because of demoralization—because the people writing the code stop caring. And when developers stop caring, everything grinds to a halt.
Your Team's Boundaries Are Terrible. Here Are 6 Ways to Fix Them.
Introduction: The Reality Check of Boundaries
Many of the core ideas and principles you mention here are applicable further afield, not just by software engineers and their managers. This has given me food for thought. Thanks for the insightful piece.