Make Failure Acceptable

In response to Supporting Peer to Peer Appreciation I received the following question on Twitter.

@lee_winder can you talk more about praising behaviour, not outcomes?

— Andrew Frey (@tenpn) October 19, 2015

I replied with the following

@tenpn It’s worth a post TBH, but it’s about moving away from success at all costs and rewarding experimental or positive actions even if …

— Lee Winder (@lee_winder) October 20, 2015

@tenpn … it resulted in failure or mistakes. Because those experiments of positive actions will, long term, lead to higher levels of success

— Lee Winder (@lee_winder) October 20, 2015

But as I indicated in the first reply, it’s worth a post in it’s own right.

Two Very Different Outcomes

Lets take two examples

“Frodo is a pretty good developer, always develops on time and gets the apps finished and released to the customer. In his most recent project he managed to hit his deadlines, but to get there he took a couple of short cuts. He didn’t spend as much time reviewing code being posted by other developers, he didn’t post some of his code for review either. Since he was pretty much concerned with his own work he didn’t use feature branches all that much and used a branch simply called ‘frodo’.

When the app is released to the customer, they love it and say it’s the best app they’ve ever seen.”

“Lorlas is a good developer to, pretty much on par with Frodo. He’s working on a separate project with a tight deadline, but him and his team are working hard to meet their delivery date. Lorlas has been looking at extending the build server to automatically package and distribute the app without user interaction which would save a couple of hours each week from the release chain.

He gets it working and tests it locally and it seems to be working so he rolls it out onto the actual build server.

Unfortunately there is an environmental issue which results in the wrong assets being bundled with the app and distributed causing a lot of confusion and unnecessary bugs being raised which ends ups costing the team two weeks and delivering the project late.

The customer is pretty annoyed by this and the company takes a hit in reputation as a result”

In these two situations, who should be praised and highlighted as an employee you’d want on your team?

Frodo?

“When the app is released to the customer, they love it and say it’s the best app they’ve ever seen.”

Lorlas?

“The customer is pretty annoyed by this and the company takes a hit in reputation as a result”

If you look at the above statements it’s pretty easy isn’t it? Frodo released something that the client loved and Lorlas released something that damaged the companies reputation.

Highlighting the Work Frodo Did

If we highlight Frodo, we’re approving not only the end product but how he got there because the two elements are intrinsically linked.

This is what we’re approving

“to get there he took a couple of short cuts. He didn’t spend as much time reviewing code being posted by other developers, he didn’t post some of his code for review either.”

So what is Frodo going to do next time? What are the other developers on his team or nearby going to do next time.

They’ll do exactly the same thing because they see what Frodo is doing and the benefit he gets from it.

This is not a good thing.

Frodo might be an absolutely awesome, correct first time, never wrong developer and might not need his code reviewed. But lets be honest these types of developers do not exist and even if they did, you don’t have a team full of them.

Before you know it, you have a whole team taking short cuts and taking risks in the name of getting things done. Eventually the luck you had previously is going to run out.

And when it does those shortcuts are not going to help you in any way, and the state of the project will be in a seriously decayed state due to the amount of shortcuts people have taken.

Highlighting the Work Lorlas Did

So what if we highlight Lorlas?

Again we’re not only highlighting the result but how we got there. In fact, in this case we’re actually highlighting the process more because everyone knows a negative outcome when they see one, and understand that is not what the focus is all about.

And this is how we got there

“extending the build server to automatically package and distribute the app without user interaction which would save a couple of hours each week from the release change.”

We got there by Lorlas experimenting with a process improvement, which if it worked and was rolled out to other team could save days of work for people in the release chain. He tested it, checked it worked and verified it was good before rolling it out.

A simple mistake was what caused the experiment to fail.

But when the project is done, Lorlas can go back to that process and fix the error. He’s also incredibly aware of making sure things are done right next time.

So again, people will see what you value.

Valuing Initiative, Experimentation and Progress

They will see that you value trying to improve, innovate and experiment to increase the efficiency, productivity and velocity of the team and will themselves bring their ideas forward and experiment with improvements when possible.

You have to make it clear that in this case we also value Lorlas’ attempts to fully test and verify the work (because again this is behaviour that should be encouraged) but we should not neglect to reward this behaviour because otherwise we get the opposite.

A team unwilling to experiment and a team scared of failure which will eventually lead to a team that stagnates.

Originally published at managing-game-dev.com on November 5, 2015.