Skip to content

"tempted" vs "incentivised" #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

"tempted" vs "incentivised" #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions pitfalls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ To avoid this pitfall:

This looks like:

* *Inflated availability targets*. Your product managers are tempted to select the maximum availability target and highest on-call level.
* *Inflated availability targets*. Your product managers are incentivised to select the maximum availability target and highest on-call level.
* *Low priority operational features*. Your product managers have little reason to prioritise operational features alongside product features.
* *Weak operability incentives*. Your product teams have low motivation to constantly build operability into digital services.
* *On-call funding pressure*. Your product teams come under pressure to cut corners on on-call spend, whenever opex funding is scrutinised.
Expand Down Expand Up @@ -139,4 +139,4 @@ This pitfall affects operations teams as well. Your app support team may have so

|Lost accountability in retail|
|---|
|I worked on a team at a retail customer, building a shifts app for staff mobile devices in bricks and mortar stores. We built a cloud-based platform in Azure and the mobile app with You Build It You Run It, and the benefits were clear to our customer sponsor. We achieved a time to repair of less than 10 minutes, and we deployed on average twice a day for over six months.<br><br>Unfortunately, once the shifts app became a live service and its user base hit a critical mass, its ownership changed to a different business function within the customer organisation. Some people in this new business function were unwilling to embrace our ways of working.<br><br>An [operations manager became accountable](https://you-build-it-you-run-it.playbook.ee/pitfalls#operations-manager-still-accountable) for the reliability of our shifts app. We remained responsible for supporting the app, but we were no longer permitted to perform deployments without Change Advisory Board approval. As a result, our time to repair non-critical issues increased from 10 minutes to 1 week, of which 5 days was the governance process.<br><br>By the time I left the engagement, we were down to deploying once a fortnight. It was strange, because people celebrated how quickly we could resolve live issues, and yet they didn't quite make the connection to how important You Build It You Run It had been.<br><br>![Julia Wilson](../.gitbook/assets/practices/julia-wilson.jpg)<br><br>[Julia Wilson](https://www.linkedin.com/in/julia-l-wilson/)<br>Developer<br>EE UK|
|I worked on a team at a retail customer, building a shifts app for staff mobile devices in bricks and mortar stores. We built a cloud-based platform in Azure and the mobile app with You Build It You Run It, and the benefits were clear to our customer sponsor. We achieved a time to repair of less than 10 minutes, and we deployed on average twice a day for over six months.<br><br>Unfortunately, once the shifts app became a live service and its user base hit a critical mass, its ownership changed to a different business function within the customer organisation. Some people in this new business function were unwilling to embrace our ways of working.<br><br>An [operations manager became accountable](https://you-build-it-you-run-it.playbook.ee/pitfalls#operations-manager-still-accountable) for the reliability of our shifts app. We remained responsible for supporting the app, but we were no longer permitted to perform deployments without Change Advisory Board approval. As a result, our time to repair non-critical issues increased from 10 minutes to 1 week, of which 5 days was the governance process.<br><br>By the time I left the engagement, we were down to deploying once a fortnight. It was strange, because people celebrated how quickly we could resolve live issues, and yet they didn't quite make the connection to how important You Build It You Run It had been.<br><br>![Julia Wilson](../.gitbook/assets/practices/julia-wilson.jpg)<br><br>[Julia Wilson](https://www.linkedin.com/in/julia-l-wilson/)<br>Developer<br>EE UK|