- Leadership in Tech
- Posts
- Improvement Sprints
Improvement Sprints
#23 – February 08, 2021
sponsor
WTF is SRE? It’s about delivering what you promised while incrementally improving your service with new features. SLIs, SLOs and Error Budgets exist to balance and help guide decision-making. A main principle of SRE, these budgets give teams more autonomy and allow them to make calculated decisions based on estimated impact. Join Nathen Harvey from Google on another WTFinar brought to you by Container Solutions. 9th February, 15:00 CET
this week's favorite
Nothing worth doing is easy and anything worth doing is worth doing well … or so the sayings go. My personal experience certainly proves to me that these are more than simple soundbites and I am fairly confident in those sayings having more than a ring of truth to most IT professionals. So then why do we so often see innovation and professional development limited to the occasional day or Friday afternoon?
We framed our work to make CI “better” as an experiment with defined questions and metrics from the beginning. Could we use metrics to improve the experienced quality of CI? Once we knew that we were meeting some threshold of quality, could we use these metrics to prioritize future work? We gave ourselves a month to answer the first question and hoped that we’d have a while to test the second.
From each of our two experiences starting out as introductory-level engineers at Box, to becoming first-time managers overseeing five-person teams, then directors overseeing 30-50, and ultimately VPs managing hundreds, we've experienced software engineering from every angle.
As an engineering leader, I value trust and believe that individual contributors should be involved in architectural and high level technical decision making. I consider every line of code to be a decision made on behalf of someone else (including your future self) and having a fast-growing distributed team makes technical decision making particularly difficult to manage.
All software teams have technical debt — parts of the code that weren’t created with today’s challenges in mind, or were written poorly, or were expedient hacks that are now problematic. Having tech debt isn’t necessarily a bad thing; if people spent all their time making code perfect, nothing would ever get done. But too much accumulated debt makes it slower to deliver new features and is a source of bugs and quality issues.