Filed under Management , Methodology , Opinion , Software Development , Staffing , Strategy
I’m going to tell you a story about how I almost failed as a manager. I say almost because it was only because of Bob Smith that I recovered and really understood the error of my ways. Bob is a factious character because the innocent should be protected. However, the situation is real and the lesson is a good one that I would like to pass on.
One of my first experiences managing development teams was an incredible opportunity. I was young, enthusiastic and motivated. I inherited a team of folks with great capabilities but a relaxed attitude towards owning issues. I’m positive we were not the first shop to experience this! During the first few weeks of taking over this team I hired Bob as a replacement for a team member who left just before I took over. Bob was my first hire. Bob is an incredible technician. He knows code, architecture and the urgency of our craft.
I think I’m preaching to the choir when I say that inevitably there will be an issue in IT. I, as a young manager, experienced this within two weeks of Bob coming on board. I remember it clearly. The guy Bob replaced left a code base and an architecture platform that, well, let’s just say was suboptimal. I called everyone into a room and said this is the ‘hottest’ issue. Let’s dedicate all our resources to getting this solved. I got a lot of blank stares. Bob however, was the guy on the beat. Within five minutes he knew what to do, how to solve it and what needed to happen. I was in love.
We were a young shop and there were about two more ‘major’ issues that came up within the next six weeks. Each time I leaned on Bob. He was my go-to guy to fix the issues that the team couldn’t address, with his help we satisfied the customers and pleased the execs. Then came the dreaded lunch! Bob and I went out to lunch and he let me know that he was thinking about leaving the company. Imagine my face at this point. Bob was my get it done guy. However, it was exactly why Bob wanted to go.
Bob had other ambitions. None of them having to do with fire fighting others misfortunes. Bob was a team player, but in his words (Bob doesn’t speak the best English so this is the best translation) he said “I’m always willing help out, but you need to help others know how to win”. Prolific need I say more!
What I learned from Bob is that teams need to learn how to fail as much as they need to learn how to succeed. Winning feels good, I think that anyone that’s been a part of a winning team can sense what a winning team ‘feels’ like. You just know. Failure is the same. You just know when something doesn’t feel right. Winning and losing is intrinsic in our psyche.
Failure is painful but inevitable in our business, just as much as success is. The problem is that most people, as a team, don’t know what it’s like to manage through ‘failures’. It’s not natural. We naturally separate into individuals when we sense failure. The whole ‘It’s someone else's problem’ is a common reaction. Arguably it’s a healthy reaction designed to help us cope. However, in our business, the business of providing technology, it’s a toxic attitude because we can only solve problems as a team.
Bob taught me that when a crisis occurs hold the team accountable. The easy way out is always rely on Bob to fix the situation. Bob is not the long-term fix. The team needs to know what pulling yourself from failure ‘feels’ like just as much as they understand what success ‘feels’ like. Just like people know what ‘winning’ and ‘failure’ feels like, your team needs to understand what pulling success from the jaws of defeat feels like so they can repeat the behavior each time something goes wrong. It's like muscle memory!
6a0aee79-d061-4009-b587-89c6440cbdec|0|.0