Let’s face it: we don’t like to fail. Even a weird guy like me, although I say “failure is the best teacher”, I still think it sucks to fail.
But I just read an interesting take by John Sonmez, on a great way to learn from failure.
His suggestion is to make a Fail Journal. Keep track of the mistakes you made, why you made them, what you learned from them, and then you’ll have a record to look back on later.
The first thing we might want to do is sweep our mistakes under the rug. That really does us a disservice though–we forget the important points and risk making the same mistake again.
I’m gonna do one better. So, starting with this post, I’m making a new category called Epic Fails, where I’ll write down mistakes I’ve made in the QA/Automation space, along with what I learned, so that not only I but you can benefit from it.
Here’s a story about how I failed, and what I learned from it.
Once Upon a Time…
I was working at a client which had a lot of dark, gritty automation in place, but nobody could debug, maintain or extend it. It was written at a really high, codey-looking abstract level, and the people who wrote it left suddenly, and nobody there who was left had enough time to dig in, understand it and work with it.
So here I come. And I notice this and think: I’m gonna write a new framework. And I’m gonna teach the testers how to use it.
Things started out ok. It didn’t take long to put together a proof of concept, and each iteration to improve it went fairly smoothly.
But, when it came time to get the teams to adopt it, I fell on my face. Although people paid plenty of lip service about how cool it was, there was enough resistance to it that it didn’t make it mainstream.
I failed to realize that:
- If you plunk down a solution, it doesn’t mean it’ll get used,
- Ego runs both ways,
- Playing the Hero Card doesn’t work well.
Ego is a powerful force. We all have it. Great things can happen if it’s harnessed and focused.
So I learned that, to get a solution adopted, people appreciate more when they earn it a little bit, rather than just having it handed to them.
If I’d gone about it with a more iterative approach, and constructed the framework with them, it would’ve been better for two reasons: one, they have more ownership of it since they helped make it, and two, they probably have (and indeed did) some neat ideas to be built into it.
Even if we went directions where I knew it would cause maintenance or debugging problems, it would’ve been fine. They could learn why certain patterns were wonky, and earn some brain wrinkles, instead of me just saying, “We shouldn’t do this because [xyz]”.
To get something adopted, it’s more than just winning the minds of people, it’s winning the hearts of them too. This is a lesson I decided to carry forward to every client after that.
Fun fact: I don’t like being comfortable. So I willingly run into places where I might get battle scars, because each scar teaches me something that I can pass onto you.
Are you beating your head trying to figure out where to go next in your QA, automation or DevOps strategy? Let’s talk. You can learn from my mistakes 🙂