Failing is a big part of success!
I know what you’re thinking: what? Failing is not good! But failing might just be the best thing that happens to your team.
Before we start
I hate losing. I really do. I’m that guy that when a big screw-up happens I have to go out for a drink (several…) or go to an open field and yell curse words. Loud. I get really pissed off.
That’s ok, I’m emotional. The next day I put on headphones, go out for a run and my pride kicks in. Ready to go back, get up, kick-ass again.
Fail Fast, Fail Cheaply
At OutSystems, we have the small book a few big rules. These are very simple rules that are part of us. It’s like breathing: you don’t have to think about it, it’s just automatic. These rules are under our skin too.
In this little book, you can find this quote:
Fail Fast, Fail Cheaply
“At OutSystems errors are acceptable. How are you going to learn if you don’t make mistakes? Just make sure that you learn from those mistakes and that those mistakes do not end up being a major crisis. Fail fast and fail cheaply, but don’t be afraid of trying. Be proactive.”
Failing happens at OutSystems and we know how to deal with it.
But we also fail… big time!
It happens. It’s not common, but it happens. In a recent project, we failed big time. Simplifying things, we brutally underestimated a project. Something that we estimated in “x months” will actually take us twice the time with the same resources. That’s… inconceivable!
The reasons why this happened are out of the scope of this post, but assume we went down. We went down big!
The first task after hitting bottom
Assume the mistake to senior management. Be very clear, raise the flag that something didn’t go well. Most people try to hide the problems or “beautify them” in front of senior management to avoid impact in evaluations, but this is wrong. These people are there to help you and if you are afraid of them, something is not right with management, not you. Of course a failure should negatively impact each individual’s evaluation: we’re professionals! But not assuming things is worse. Go down, assume you went down. Then bring your best and prove to everyone that you are the best and you want to win!
Post-mortem
Now that everyone is on the same page, do a post-mortem (PMBOK refers to it as lessons learned) with the team. You must understand the root causes of why it happened. If you don’t know what went wrong, how can you act? Clearly identify causes, don’t point fingers but be specific (e.g.: don’t focus on the individuals, focus on the tasks and the team). You should get out of the post-mortem with clear action items, assigned to people, that will move the team and the project forward.
Hint: In post-mortems, “biases” kick-in. “Oh, how did you guys didn’t see that? It was so obvious!” Keep cool, this is hindsight bias (common tendency for people to perceive events that have already occurred as having been more predictable than they actually were before the events took place). There are lots and lots of biases, make sure to not let them ruin the exercise.
Hint #2: After the post-mortem, before anyone goes home, gather everyone around, like a sports team. Just say… “team, go home, think about what happened and this day. Come back tomorrow with a fresh mindset.”
The next day
Team spirit will be in bad shape. People will feel lost, without purpose. It’s very important that you do one-on-one meeting with every team member. Understand how they felt about things, what they think of the post-mortem meeting and if the action items are aligned with their expectations. Everyone will still be “shocked” by the screwup and low on energy. It’s still “pain” time, let things sink in.
Hint: Be “comprehensive”, but make sure everyone understands the consequences to the company. Example:
We estimated the project for “x months” and will take double the time. So, are you willing to work “8 months” but only get paid for “4 months”? Or, alternatively, work 4 months receiving only half the money? Ouch. But that’s not all. There’s the cost of opportunity. The product will now be released too late and we won’t be the first ones in the market, losing millions. Similarly, you want to sell your car and there’s a buyer that will pay you lots of money for it today. But now you can only sell it in four months and that buyer won’t wait… And then there are investment decisions: Would management invest in this project knowing this timeline? Or put the money in other projects?
Gather the troops — the next weeks
We quickly started to apply the action items. Yes, we had to apply mitigation strategies to make sure we deliver the project in an acceptable timeline, but the biggest change we needed was actually pretty simple: our working methodologies. A simple example: define a “sprint gatekeeper”, the person in the team that is accountable for the success of our sprint — makes sure our daily standups are effective (we talk about blockers and so on), that we are sharp on the sprint goal, that there are no sprint scope changes, that we are focused on deliveries, etc. These little things were key to getting everyone back to life. We reinvented ourselves, as a team.
I was actually surprised. I was not expecting the team to get up in such a good shape and so quickly! The team is very particular (aren’t they all?) in a very complex technical scenario with high project uncertainty. But the way everyone quickly accepted failure, moved on and committed to improve was really surprising.
Hint: Team building is a really cheap investment. Most managers out there think of team building as an expense, but it’s an investment. Having your team 2h out for beers, karts or a segway ride has such a high return on investment that it’s scary why managers don’t do it more often. Yeah, we usually do regular team lunches and so on, but spending more time together is essential. At OutSystems, we actually have assigned budget per team for these events. Celebration moments (a release) or failures are a great time for team building events.
Share it with the entire organization
Our first sprint review (that is shared across R&D) had these two slides:
Why? There’s a sentence from the book 10x rule that fits in here really well:
“Never take the position that things just happen to you; rather, they happen because of something you did or did not do. If you are willing to take credit when you win, you have to take credit when you don’t! Increasing your responsibility level will inherently enhance your ability to find solutions and create more success. Blaming something or someone else only extends how long you will be a victim.”
So, be honest. Don’t hide from the bullets. Be ashamed of the failures, but show them. You and the entire organization can hugely benefit from your “lessons learned” and failures. Then raise your head and kick ass!
Aftermath — I though about leaving OutSystems
Of course, it hurt. A lot. And sometimes we still “feel it” and we know we’re going to get hit in yearly evaluations (senior management at OutSystems is as supportive as it can get, but we’re professionals and part of an individual’s growth is to receive negative feedback). Personally, I even considered leaving OutSystems (have I mentioned I hate losing?). I didn’t because…
- My pride wouldn’t let me;
- I couldn’t turn my back on the challenge. If I leave one day, I’ll leave after a huge celebration, not a failure;
- I know people trust me;
- I love the team, I love our R&D;
- Sh*t, I love OutSystems.
Keep an eye
We can’t fail again, no way! So, we’re doing things the right way. And it’s great to see how much we evolved. It’s amazing to look at all the data, release burndown, control charts, version reports… and all is sharp.
Final note, sharing this post was not easy. But we do have a great backtrack of successful projects and hey, maybe you can also learn something from this.
