FY22-Q1 Development Division OKRs

Objective (ARR): Positively impact ARR through efficiency and SAS first goals => 62%

Objective (Product): Make GitLab more usable, secure, high-quality, and available => 59%

Objective (Team): live our DIB value, and address engagement survey items => 83%

Retrospective

Good

  • Framework - Great collaboration between PM and Eng on developing the framework to guide SaaS First thinking across all teams to focus on hard blockers to Enterprise adoption. Many people contributed ideas of where to start and what to consider.
  • SLOs - This OKR was really insightful and prompted us to look into our processes. The result of this OKR was a new process in place for the future. We also cleaned out a lot of issues since the quarter began, mostly through better triaging, proactive investigations (looking at the issues as they came in), and refinement of old issues (some issues were duplicates or already resolved).
  • SLOs - Our mean-time-to-close for S2's increased throughout the quarter (bad) while old issues got closed, but our number of closed issues and the percentage closed below SLO also increased (good). This tells me that if we continue on the same path with the new process, our mean-time-to-close will begin dropping.
  • CI
    • Introduced the practice of risk mapping and risk assessment to Development group teams
    • Increased cross-functional engagement on Quality concerns between development, product, and quality team members
    • Identified an experiment for introducing SRE stable counterparts into Product Groups.
  • DB Sharding
    • Landed on a POC prototyping plan (horizontal top-level namespace sharding) and a secondary backup plan (vertical application sharding).
    • Assembled a dedicated sharding group.
    • Kicked off the POC - spikes, researches, and prototyping.
    • Improved the WG meetings after receiving feedback.
  • CultureAMP - Everyone had a career development conversation.
  • CultureAMP - Tracking career conversations ensures this is happening at all levels; this is the first time we've tracked, so this is a great step in the right direction.
  • DIB - Overall the team was able to take the new DIB training and it was shorter than previous trainings.

Bad

  • Purchasing and Licensing - This OKR was (in hindsight) poorly written as it was not clear how to measure progress nor what was considered success.
  • Purchasing and Licensing - EMs were generally not working to update the status of OKRs every two weeks per our process
  • Framework - One project did not make as much progress (25%) as it wasn't staffed enough to make full progress and leaving in a half-finished state would have been a negative consequence.
  • SLOs - Even though we closed 15 issues that had missed their SLO's + worked on issues that had not yet missed their SLO, 10 new issues missed their SLO throughout the quarter. This almost cancelled out our progress with the OKR.
  • CI:
    • There is significant overlap between Quality and Reliability concerns which made framing of this KR challenging.
    • We did not determine a metric based way to measure progress.
  • DB sharding
    • The sharding approach proposals came together in April (later half of the quarter), due to the delayed WG kickoff because of other burning priorities of the DRI and the fact that sharding was not in scope initially when establishing the Database Scalability Working Group.
    • The WG meetings didn't go well in the first month from biased for actions and laying out ETA perspectives.
    • It was challenging to assemble the sharding group.
  • CultureAMP - For most people, we did these late in the quarter.
  • DIB - We didn't get to a 100%. This was do to some miscommunication on whether this was required in Q1 or optional based on function goals for the quarter vs. departments.

Try

  • Purchasing and Licensing - All future OKRS should be measurable
  • Purchasing and LIcensing - EMs should update OKR status every two weeks. We should put it in the weekly EM meeting and/or set up an automated reminder in slack.
  • Framework - Make sure projects are either staffed enough or provide feedback to change objectives.
  • SLOs - Avoid setting goals that are moving targets (new issues coming in) and use concrete numbers instead when applicable. The intent behind the goal, which was to reduce the open bug count to be more manageable, become more proactive, and decrease the age, got lost when we needed to account for the new issues coming in.
  • CI
    • Broaden definition of Quality to include scaling, reliability, and availability concerns.
    • Clarify ownership of Quality and Reliability centers of excellence (CoE) within product groups. Who owns these CoEs and how should product groups coordinate their quality and reliability efforts which are often intertwined in practice?
  • Sharding
    • More quantifiable information, such as confidence level, impact level (to codebase and functional domains), progress %, ETA etc., although the POC is nebulous in nature.
    • Always carry a sense of urgency and bias for actions.
    • Take actions timely when DRI becomes bottleneck.
  • CultureAMP - Tracking career conversations twice per year as opposed to once/year moving forward. Perhaps we track in Q1 and Q3 moving forward?
  • DIB - Get feedback and possibly commit to get everyone else trained by middle of June.

Cache buster (to get last status in issue URL tooltips): 2020-05-10c

Edited by Christopher Lefelhocz