Key Results/Outcomes

ENGAGEMENT:

• The people taking on the roles listed within the Engineering / Development domain, agree or strongly agree to the following statements:
  • I know how I’m being evaluated on these roles.
  • I receive actionable (meaning timely, frequent, specific, and observation-based) constructive feedback on my performance within the roles identified above.
  • I receive actionable (meaning timely, frequent, specific, and observation-based) recognition (public or private) on my performance within the roles identified above.
  • I believe I have the tools to meet or exceed the outcomes listed within the roles in question.
  • I believe I have the processes and environment to meet or exceed the outcomes listed within the roles in question.
  • I believe we are continuously improving in how we go about taking on these roles.
  • Note: This SHOULD have a direct impact on the NPS score of engineers (where they select 8+ on a 10-point scale to the question; “I’d recommend a friend come to work here”). However, given that full engagement is more inclusive than their primary roles, it doesn’t feel right to have that as a part of the measure of enablement leads.

QUALITY:

• As measured by staying below a 10:1 regrettable defect escapee to stories delivered ratio
  • I would love to make this ratio bigger, but let’s start here for now and establish a baseline before committing to something greater. One of the best measures of a great team is NOT the absence of issues, but how small the issue-to-resolution time. However, the spirit of this measure is that we are actively pushing quality to the left, meaning earlier in the process We will also measure the directed decrease in certain types of defect escapees that are targeted quarter over quarter.

SPEED:

• Points(or stories)/person over time doesn't necessarily mean we're delivering more value. However if points/person is decreasing then it'll very likely make it harder to deliver value continuously. Lean principles of single-piece-flow, collaboration principles that require heavy pairing at all parts of the process, and other strategies might appear to slow down the flow of work, but will help us deliver value more quickly. The idea here is that you as a software development enablement lead are paying attention to how the work is flowing and are making recommendations based on what you are seeing.

Glossary

• Timely
  • Within 48 hours of a remark-worthy event
• Frequent
  • A least once per quarter
• Immaculate Defections
  • Bugs caught by customers and are divorced from any specific project released in the last 90 days.
• Regrettable Defect Escapees
  • Bugs caught by someone outside of the squad and is tied to a specific project released in the last 90 days that are priority-1, priority-2, and some priority-3 bugs (we will have to use our discretion when saying if a priority-3 bug is regrettable or not)
• Non-Regrettable Defect Escapees
  • Bugs caught by someone outside of the squad and is tied to a specific project released in the last 90 days that are priority-4, priority-5, and some priority-3 bugs (we will have to use our discretion when saying if a priority-3 bug is regrettable or not)
• Regrettable Work Release Defects
  • For the squads that test every story, these show up as stories that make it to the remediations lane because they are bad enough that we've decided to not ship with the bug.
  • For squads implementing trunk-based/single-piece-flow/fix-forward, these show up as bugs found by testers that we decide to “hotfix” or cause us to pause cloud deployment propagation because they are bad enough that we've decided to not ship with the bug.
• Non-Regrettable Work Release Defects
  • Bugs caught by testers, but we've decided that they are low enough priority that we can ship/continue normal cloud deploy propagation with these known bugs
• Cloud Deploy Propagation
  • We have three nodes as I write this. US-1, US-2, and US-3. Our current process is to deploy to US-1, but we hold off for a while before we deploy to US-2 and US-3. Sometimes a bug will be caught in US-1, and we will pause the deploy to US-2 and US-3. The act of deploying to one and then another is cloud deploy propagation.
• Trunk-based/Single-piece-flow/Fix-forward:
  • As of writing this, the Skills Squad will be deploying every story individually to production (single piece flow). They will also not have any branches outside of the short-lived branches for their stories (trunk-based). Finally, when they encounter issues, instead of rolling back being the default action to restore service, the default action will be to deploy a fix/patch (fix-forward).

Things you might deliver/do

• Though you won't be exclusively responsible for engineers having the best tools and processes to do their best work, you will be heavily relied upon to ensure this is happening.
• You'll search for the “multiplicative effect”: impact multiplied by the number of people
• You'll be proactive by identifying and coordinate meeting common needs across the engineering team such as standards and conventions, documentation, etc.
• You'll be reactive by helping coordinate solutions to problems you hear about from the team, such as on-call support being frustrating, or waiting on reviews taking too long.
• You'll contribute to continually iterating on and improving the Engineer Growth Framework