Whoops

Reblogged from Captain by Rank

As I mentioned at the end of last week's post, there's an important complementary policy that you must have if you want a strong ownership culture. You can probably guess what it is by now - it's fostering a culture where it's safe to make mistakes. This week, I'm going to talk about why that's important and what that looks like.

As Mr. Einstein indicates, you have to be willing to make mistakes to try something new. As much as we'd all love to be perfect at something the first time we do it, that's simply not the case. All of us have to try, fail, and try again. Where this is potentially a loop of N, with N being a very  large number. ;)

We are an industry of innovation. Without fail, almost every project has aspects that have never been done before. New game mechanics, new hardware, fewer people than you'd like, more features, new team members, etc. Innovation is our life blood. Therefore we must take risks, we must try new things, and by definition we must occasionally fail. Giving people strong ownership certainly helps them feel comfortable taking risks, but what about when they fail? It's easy to think you have a culture of strong ownership but how you treat mistakes or failure is the litmus test of if you really do.

Back in the day, I was not a good manager. When someone screwed up because they attempted a different solution from what I suggested, I'd get angry, I'd tell people they did it wrong, and worst case I'd simply take away the task and do it myself. Charming, I know. Oddly enough, this didn't work (you're shocked, I'm sure). Instead of getting innovation, instead of having people who were happy to work with me, I got fear. And on the "plus" side I also got way more work than I could actually handle. Everyone began playing it safe. They wouldn't take any risks and they'd do the thing that wasn't risky. They'd do exactly the solution I gave them. The problem with that is that centralized planning rarely works. We have this fantasy that one person has the whole picture in their head. I am not that person. No one is. That person doesn't actually exist. The reality is that the best you can do is give general direction and goals. Research this family of algorithms, keep in mind that this system has to interface with this other system, consider using simpler data structures, etc. But trying to give fine detail direction almost always misses the messy details of what's actually going on. Therefore the people who are closest to the problem usually know better where to take risks and what solutions will likely work. (I highly recommend Adapt: Why Success Always Starts with Failure for lots of good data on why this is so. And also lots of good data on why failure is so important in case that wasn't obvious. ;) )

To be honest I still struggle with the tendency to take away ownership and not allow people to make mistakes. The difference is that these days, I'm constantly asking myself, "Am I taking away ownership? Am I punishing mistakes?". If I feel even a hesitation that I might be doing either of these things I take a step back, reassess the situation, and try again (see, there's the try and fail loop in action. :) ). And that seems to be the key. Be paranoid that you're always overstepping, and most importantly, allow yourself to make mistakes as well. Nobody's perfect. You will make mistakes as a manager. Be the first to admit them and talk about how you're going to fix them. That right there is a good start towards showing the team that mistakes aren't the end of the world. Also, much like publicly acknowledging the strong ownership policy, you need to publicly acknowledge that mistakes won't be punished because without it your strong ownership culture will die. Your internal wiki is always a great place to start. It's amazing how just writing something down affirms it in a very concrete way.

Hopefully by now I've convinced you that allowing mistakes is a key companion to the strong ownership model. However, you should be aware of some pitfalls.

No matter how tempted you are, don't just give someone the answer. Even if you really do have enough fine detail information to simply give them the solution for a particular task, don't. One of your jobs is to be a mentor. Even if the team member is ok with you simply giving them the solution, you need to be investing in them. Help them work through the problem so they can get the same insight and experience that you have. Give suggestions, give advice, have them talk to other team members, but ultimately your goal is to teach them so they can do it on their own. Teach someone to fish and all that jazz. ;)

Another common pitfall is to not monitor risk. You need to make sure the team isn't taking on too much risk. It's very easy to just step back and let things ride. However, as I mentioned last week, you have to be engaged and you need to pay attention to overall project health. One of your jobs needs to be constantly assessing risk of the project at large. If you see someone taking on more risk than is probably safe for the project you need to talk to them. Make sure they understand the overall situation and most importantly make sure they understand the consequences if their approach doesn't work. However the final decision still needs to be theirs and if it doesn't work they are very much on the hook for fixing it. One really good approach is to encourage people to take smaller risks. Sure that algorithm you found in a research paper sounds cool, but do you want/need to bet the farm on it? Are there smaller incremental risks you can take? Do those instead. Small, incremental risks are your friends.

Another pitfall is how to handle a team member who's made too many mistakes or failed one too many times despite your guidance (you have been providing guidance and oversight, right?). However, this is a huge topic and once again I'm out of time and words. ;) Which means this will be the topic for next week's post!

Until next time. Agree or disagree with anything I’ve said? Questions? Let me know in the comments below or via Twitter, Facebook or email contact at captainbyrank dot com.

Cheers,
Shaun