Failing on Steroids

Kai Klostermann May 9, 2019 experience.io
Kai Klostermann

How do you fail at work?

When I started to think about a good topic for our official blog, my mind instantly pondered about technical content. In which unique way we addressed structural problems within the code, what tools to use, how our development process works and so on. None of them being anywhere near satisfying. Overly complicated, too techy. Ultimately, I shut my computer (admittedly a little harder than usual) and asked myself: “What is the question, this company gave me the best answer to?” Apparently “what are your employee perks” is insufficient according to our social media crew. Therefore we have to stick with “How do you typically fail at work?”. A straightforward question, the response is incredibly fundamental, and yet most of us lack an answer.

Hi, I’m Kai, a Frontend Developer and in this article, I want to shed some light on self-organised decision-making and how failing at Mercedes-Benz.io works!  

Self-organised decision making   

Being self-organized and professional

from the listing of every Mercedes-Benz.io member’s accountabilities  

Before heading to the failing part of that essay, it’s necessary to explain how we decide accurately. A wrongly taken decision is no more than a failure. Alternatively, the other way around, without a proper fail culture, you can not expect people to make critical choices. To work self-organised means to ‘just decide’. Well, a lot more than that but it represents quite a significant part. Instead of discussing, we do something. This approach may sound anarchic being typically used to traditional work environments but allow me to set it this way: if you align with five people there’ll most probably be five opinions or personal truths, and every single one of them can be wrong thus lead to failure. Having the decision taken single-handedly results in a considerably faster process while not being any riskier. Nevertheless, you should still consult people for valuable information.

Also, this is only legitimate for the ones you are entitled to take. You never define anything not being within the particular scope of your job’s accountabilities. Naturally implying, however, that there need to be strict role descriptions in the first place (which we have and which is fantastic, but that’s another topic).  

Failing at Mercedes-Benz.io

So what happens if you decide wrongly? In case of apparent failure. What do we respond to the initial question? In a nutshell, ‘failing’ at Mercedes-Benz.io rocks!

When all the safety measures did not pounce, and finally something is broken, we solely take it as the novel situation. The new present state, not being any different from succeeding, despite one remarkable thing, carefully checking whether it is necessary to take action to avoid the flaw in the future. Directly following the familiar slogan “Fool me once, shame on you. Fool me twice, shame on me!”. Nothing more is left to be done. There is no practical sense in figuring out whom to hold accountable. There is no sufficient reason to finger-point or seek a scapegoat. This wastes resources. Nothing more. I can’t stress enough how important this is. Think about it. No matter how big the mess-up was, you don’t gain the smallest thing from comprehending that someone or who is responsible. We establish a proper mindset of merely accepting the altered state and move on. There are typically a few notable exceptions, however. Needless to say, if it is your job to expose someone to hold liable, let’s say for example a police officer 👮‍♀️, you don’t follow the given advice.

“Mindset” is indeed a convenient phrase. All this behaviour in a vaster sense is more or less just how you culture-wise deal with acknowledged failure — genuinely having this figured out results in positive vibes consistently developing a drive to do, learn and be active instead of gossiping. Scribbling it down without working collaboratively on the culture doesn’t make sense. You will end up pretending. The goal is, of course, to actually not give a hang.  

Me and my assistant Auri failing at taking a photo

A story about misconfigured development tools

Let me tell you a story from my early days at Mercedes-Benz.io. Just as a prime example of how all of this works. In our product team, the developers usually use so-called git hooks.

In case you are a little lost now, a short explanation of what git-hooks are: you can set up a program to run before you add your modifications to the codebase. Here it executes a few scripts to apply our guidelines and ensure that there is nothing unnecessary left. Compare it to a chef observing you while cooking. They provided a recipe and allowed to alter any ingredients. The only crux is that with each modification the originator got to explain everything to them. When pleased, they let you go on. In any other case, well, not. This annoyingly judgy cook is the git-hook-script.

When I was onboarded, I somehow managed to have them not configured properly ending up sending code not being verified. Regardless of this, it always follows a mandatory QA step, the so-called Pull Request. Developers review the uploaded changes and can block or approve making them eventually part of the product. I will never forget what happened next: my first real Mercedes-Benz.io moment and it was so wholesome! When I started work the next day, I recognised several private messages on Slack, our internal messenger. All of them providing tons of links, scripts and other stuff to help me out. They were all positive: no blaming at all, no finger-pointing, just genuine offers to help. Still, I was quite shocked since I was new to the company and thought I messed up. Opening up the Pull Request in like no time made me realise that it merged already. A quick look at the history revealed that people just did the missing git-hook-step manually! My colleagues have accepted the bad request as well as my misconfigured setup as the new state. It was the present situation now. They reacted to it just like to any other point in time. A fellow frontend-dev came to my desk that day. He helped me figure what was wrong. We programmed my environment correctly, and as he stood up, the whole topic was history. It was not mentioned a single time again. Not that people only avoid to talk about it, they don’t bother. It’s not a big deal whatsoever.

However, we do not stop there, do we? Remember the bit about taking action to avoid the failure in the future? What happens when a new joiner has the same problem than me? At the time of writing this article, we switched our system to husky. It’s the same but kind of server-driven. The developers don’t have to configure anything on their clients anymore, but rather all the former git-hook scripts are getting executed fully automatic, completely avoiding this exact issue from happening again.

That’s my story of how I failed and how all the great peeps just made it an all positive experience. We learned and grew without creating a single frustrating moment! This rocks, doesn’t it?  

Conclusion

Next time you face failure at work, ask yourself whether you are currently actually being productive or just trying to figure out who’s responsible. Don’t waste resources. Just rock on no matter what! If you evangelise and foster this philosophy, you can easily have the needed impact to establish something similar profoundly also in your work environment.

I hope you enjoyed my article about fail-culture at Mercedes-Benz.io and that I could give some further insights on how all of these great minds work together. See you next time! Stay positive, Kai.


Or TL;DR in Michael Jordan’s words: “I can accept failure. Everyone fails at something. But I can’t accept not trying.”