Contribution Principles
Part of The PIRATE Way — Stories about scaling up engineering teams.
Acknowledge
Around a year ago, I penned my thoughts on a topic that’s currently being widely discussed, thanks to a recent article by McKinsey titled “Yes, you can measure engineering productivity”.
While I find myself gravitating toward the rebuttals presented by Kent Beck and Gergely Orosz (part 1 | part 2), I do concur with McKinsey’s overarching sentiment. However, I strongly diverge from the particulars they discuss. In my view, throughput or velocity can quickly become vanity metrics.
The sheer number of story points a team delivers doesn’t always convey meaningful insights, wildly when the definition of a story point varies between teams and is hard to standardize at a department level. The same goes for the number of pull requests. While velocity can guide a team’s operational improvements, it shouldn’t dictate leadership decisions.
Driving behavioral shifts within your team often requires leveraging metrics. However, leaning too heavily on superficial metrics might lead to the overjustification effect. This mirrors our prior discussions on motivation, where we observed how individuals tend to game systems when rewards are at stake.
The “Way of Working”
Joining a new organization necessitates deep diving into its processes, designated team, underlying architecture, infrastructure, and operational ethos.
Engineering salaries often represent a significant chunk of a startup’s expenses, so optimizing team performance is paramount.
My experience spans diverse organizations. At TravelPerk, the prevailing work ethos and engineering culture were commendable. Conversations with several product team members reinforced my impression of our swift delivery pace. Kudos to Sergio Berna and Dave Garcia for crafting such a culture and judiciously selecting team members.
When my time came, the robust foundation at TravelPerk allowed me to channel more energy into organizational fine-tuning rather than tech delivery. Nevertheless, ensuring that our growing team’s dynamics didn’t compromise our quality and pace was crucial.
As expressed before, we’ll dissect this journey into two phases: Building and Operating:
Building:
- Organizational Metrics: Analyzing seniority, domain expertise across teams, and the delegation of responsibilities.
- Software Development Metrics: Insights into team-member interactions with our codebase.
- Software Delivery Metrics: How optimized is the delivery process (or how Mature is the organization, DORA — DevOps Research and Assessment.)
- Other Efficiency Metrics: Manual tasks and operational work that hint at potential automation opportunities.
Operating:
- Quality Metrics: Delve deep into monitoring, from alarm frequencies to critical incident rates, ensuring what’s been built remains robust and reliable.
Final Notes:
- Compound Metrics: Metrics derived by combining multiple individual metrics, offering insights into the balance and trade-offs between different areas of performance, such as weighing deployment speed against post-release defects.
- Adoption of Service Level Agreement (SLA): Understanding the importance of SLAs in setting and meeting operational expectations.
To effectively measure and uphold these principles, you’ll need to equip your organization with specific tools. Dive deeper into this topic in our article, “Essential Tooling for Ensuring Quality and Effective Delivery”.
Stay tuned as I delve deeper into each of these facets in my upcoming posts.
Remember: This is a blog post from the series “The PIRATE Way”.
