Every month we do a roundup of interesting and thought-provoking stories from the Software.com community.
Building on his previous introduction to Accelerate, Jon dives into some of the key metrics for measuring delivery performance (lead time, deployment frequency, mean time to restore, and change fail percentage) and how they relate to each other.
This chart shows, undeniably and unequivocally, that it's possible to reach high performance and high quality, at the same time. There is no tradeoff between speed and quality. Time and time again I hear the argument to move fast even if it costs in quality, but the data shows this is a false dichotomy. It's a "pissing our pants to keep warm"-argument (or in more polite company: "go running without tying your shoes"-argument), that might feel good in the moment but is ultimately not a strategy for success. Performance and quality go together. Do not sacrifice one over the other.
Paul, Director Of Engineering and Co-Founder at JetThoughts, describes how he optimizes team structure when dealing with the uncertainty and complexity of building MVPs. Importantly, fast feedback loops help avoid waste and prioritize consistent communication.
In structuring a team for MVP, we should consider the following: there are a massive number of uncertainties. We have to work with assumptions and bets.
The goal for the business is to find a good enough solution for a reasonable budget: ROI. It's vital to have the fastest feedback loop to prevent dramatic waste.
Aditya, Software Engineer at Probo, describes the importance of platform teams in crafting a high-end developer experience. It's all about striking the right balance of extensibility, configurability, delight, and simplicity.
As developers we like the flexibility and power to configure systems according to our needs. So naturally when end-users are 'developers' it feels okay to ship products with an assumption that developers will be able to navigate through technical challenges. This often ends up with multiple layers of configuration, difficult integration/testing & inefficient documentation.
Csaba, Software Engineering Manager at Personio, lays out a framework for measuring burnout. There are three scorecards to help evaluate burnout: occupational exhaustion, depersonalization and loss of empathy, and personal accomplishment assessment.
The problem with burnout is that we don't know how to recognize it. Christina Maslach, a US social psychologist came up with this simple scorecard called the Maslach Burnout Inventory to assess how burned out you might actually be. We should all probably, periodically, take a look.
Domenico, Senior Software Engineer at VMware, summarizes some of the lessons he learned in an incident management workshop led by ThoughtWorks. When planning for incidents, it's important to consider the different roles and responsibilities, as well as how to do post-incident reviews.
In general, there are three main roles during an incident:
Incident Commander: It's an authoritative role, responsible for leading the efforts to mitigate the incident.
Communication Manager: It's a secondary role, often merged with the IC; responsible for handling communications with stakeholder and executives.
Incident Responder: It's a member of the technical staff with clearly defined responsibilities over a specific service or groups of services, during an incident.
Software.com is a community and space for engineering leaders to share their ideas, advice, and resources on building effective engineering teams. Learn how to start contributing.