Example Slide - HackMD

## *Overview* We can improve our support to other engineering teams while also make documenting our stuff easier. Maturity evaluation has been around for ages and might still be very useful to us. We can use maturity levels to help other teams and serve as guideline to our documentation effort. --- ## *Health check assesment* ### Measure outcomes - Not clear which business metrics we are taking ownership - Only after we are clear on our mission & vision can we start measuring - We don’t have any feedback loop, we sometime implement things and don’t check if it was helpful - We are not doing post-mortems checking if our projects are used after a couple of month/years - We are depending on other teams to measure outcomes - Support rules apply - not hearing complaints means you are doing at least okayish --- ## *Health check assesment* ### Deliver value early and often - Yellow but improving bc of Kanban and better tickets but we are missing feedback from other teams, so we don’t know if we are actually delivering value [Health check notes here](https://docs.google.com/document/d/1926y41dgTs8erQV_Nvj8eX8UmcFftF4RhH2rNbKjOEM/edit) --- ## *Key points* - Our docs are hard to follow, having a system in place might be themissing cog in our process. - We lack metrics to support a detailed view of how the company is doing reliability. - We don't have much free time, any solution must be very efficient otherwise it is not worth the effort. - Maturity evaluation is quite simple to understand and implement. - Does not require much from us, also this should improve our docs and how we create docs. --- ## *Examples* - Google does it! *or at least thy tells us that we should do it* 😅 [Here](https://services.google.com/fh/files/misc/cloud-cre-production-maturity-assessment.pdf) - NY Times does it! [We Don’t Get Bitter, We Get Better](https://open.nytimes.com/we-dont-get-bitter-we-get-better-b5d2783d5cd3) --- ## *How To* - We can start writing docs about how to acheive each of these maturity levels using our tools. - We can also have a meeting agenda defiend around how our team can evaluate the current state of the team's product, how we can support them to improve their apps. ---  all of this would be much better taken care of if upper management is on board. 🙄🙄🙄 --- ## *How To* - Docs: we write docs about how to get to a maturity level to the other. - Meetings: we go to a meeting and provide guidance about the current state of the team's apps. ---  this is all a way to systematically engage the teams on improving app resiliency 🦾🦾🦾 --- ### How to get support from other teams❓ - Present a good amount of docs ready to use. - Present stats about reliability. - All of this must be super easy to implement and maintain. - Getting a report of the current state of the team's apps must be super easy. - We must be a shiny example here too, very early we must adopt this model so we can more easily support other teams. --- ## Roadmap: 1. We evaluate this proposal, if it all makes sense we start adopting it internally. (decide now❓) 2. Second step is to evaluate our situation. 3. Then we make our first round of improvements. 4. Second evaluation happens 5. If it all still makes sense, we begin documenting how to work with maturity levels. 6. With good docs and more experience, we open weekly slots for team interested in embracing the maturity model. 7. We review the state our tools bi-monthly and align improvements with our other company goals. --- ## Roadmap: ### Second step is to evaluate our situation. The doc from Google is good enough as questionnaire, by answering it we can evaluate our state and record it on GDocs [We can use this](https://docs.google.com/spreadsheets/d/1kFpNvk6gAACgR-ttZARkBHzL36GIf3nOD2QCMKk_9fU/edit❓usp=sharing) --- ## Roadmap: ### Then we make our first round of improvements. We decide together what we cand o to improve, create a few tickets and let it roll. --- ## Roadmap: ### Second evaluation happens After two months we repeat the evaluation Discuss how we've felt about it all Was it worth the effort❓ --- ## Roadmap: - If it all still makes sense, we begin documenting how to work with maturity levels. - With good docs and more experience, we open weekly slots for team interested in embracing the maturity model. - We review the state our tools bi-monthly and align improvements with our other company goals. From here on, it is all surfing as part of our day-to-day operations. 🌊🏄🌊🏄🌊🏄 --- ## *First Things First* Does it make sense❓❓ Should we put a little bit of energy in this❓❓ <style> .reveal { font-size: 32px; } </style>