++ categories = [“method”, “devops”] date = “2015-01-21T19:20:10+02:00” description = “Ownership, expertise, and the right to fail” draft = true keywords = [“fail”, “failure”] title = “Let them fail”

+++

TL,DR: Ownership is a right for failure. Correlation: if a team owns a product and wants to fail, they have to fail.

There are two ways of acquiring new knowledges: you learn from others or you experience it yourself. Experiencing is expensive as it cost some damages that have to be taken on a budget could it be money, time, or even health of your own body. So learning from others is very important.

Learning the hard way

But everything isn’t learned from the others. It depends of a lot of things but to make is short: sometime you don’t trust others and need to validate knowledges yourself.

This is what is happening to toddlers when they touch the flam of a candle. It’s not like we haven’t told them before it was dangerous. It’s the same thing for teenagers when we (not so) kindly ask them to be a bit more careful with some objects. It’s because we, as oldies, have seen such things be damaged or broken earlier in our life so we try to transmit knowledges, but they never experienced how it takes only several months for Nature to make wood rot and metal rust.

Failure is not an option. It’s a fact.

In an agile environment, it’s important to empower teams and let them own their code to be proud of it and care for it. Sadly IT is a very complex and huge family of possibilities and it’s not always possible to have all the knowledges of how things should be present into the team. Even if they had all the knowledges one of the motto is “Move Fast and break things” to underline that changing is important and we can’t afford to fear to break things.

So in one hand, the team doesn’t know all of the consequences of what they are doing and they are encouraged to not fear the unknown. And in the other hand, they can miss to learn things from other colleagues outside of their team. So they will fail. Of course you have to inform them about what you think will happen but if they ignore and don’t understand what you try to communicate, the failure will happen.

Breaking bad

The worst is that you might see it coming but they will ignore your advice.

There are several ways to welcome this bad news.

As pitiful as it could be the situation is not that bad: we can know that failure will happen and because of which team. This is a lot compared to a total

#

This is one of the numerous reasons why iterations are also a good approach to go step by step between stable states.

During the SRECON17 Eu, part of the bird of features Building SRE in small orgs, I explained what I would sum-up as “Ownership is a right for failure”. As I also had the same discussion in different contexts, let’s try to write something there.

// # Fail! // https://projecteve.com/wp-content/uploads/2014/03/small__6167125536-233x300.jpg // // One of the stupidest sideeffect of the “Fail fast, fail early, fail often” methodology,

Context

Why? time to discuss experience instead of too much theory

Breaking bad

In this post, what I call a break is an outage of a resource. It could be a silent one, like a failing instance. It could a hard one with an impact on the users. Avoiding them is part of the existence criteria of a company and we work hard to avoid them but they come.

If a fact is coming back

the Use of breaking

Having a break

Breaking is not failing Don break too much

#https://www.azlyrics.com/lyrics/linkinpark/nobodyslistening.html

I hate my rhymes, but hate everyone else’s more