The development team that I managed the longest – the one with the Gumby – was a typical bunch: a group of people with varying strengths, interests and personalities. In different combinations they mostly liked, sometimes loved and occasionally hated each other. And after a couple of reasonably successful projects, I led them off a cliff.

We can do it! (I'm almost sure)

I committed us to a schedule we could not keep, based on a technology that did not work. I made the call and it was wrong. It happens. To be clear, various people screwed up along the way in that disastrous project: Fred didn't make his schedule, Jill couldn't make the driver work, George never got the kinks out of the installer. But the fundimental error was mine: The damned thing was never going to work and I should have know it.

Critically I comitted the group to a tight schedule that in turn depended on another company hitting an even more impossible timeline. When they missed their dates, we experienced a failure chain reaction. I learned a lot from that disastrous project:

• Don't believe people just because you like them and they seem – and probably are – earnest. If you have a hunch that they can't make a date, don't be shy.

• No matter what your management does to you, don't commit to an impossible schedule: imagine what they will do to you after you miss it.

• That faint clanging sound you keep hearing inside your head is your common sense, trying to tunnel out through all the rock.

And so the project failed. Several million dollars – and this was in the days when several million dollars was real money – down the drain and not a thing to show for it. They say that success has a thousand parents but that failure is an orphan, and that was one lonely failure.

Owning up

A couple of weeks after the project ended, with the post cancellation depression hanging around the office like fog, I met with the engineering team. I was upset about the project. I was upset that I had screwed up. And I was woried about the future of the team. During the meeting I just blurted out that it was my fault. I was the one that messed up. Not them. I should have known, hell I did know, but I hadn't acted on what I knew.

It did me a lot of good to just say it, but it did the team a lot of good too. Two things changed after that meeting. Some, not all, but some, of the depression lifted. And those people began to act as though they would follow me off that same cliff again. Well not actually all the way off the cliff. And certainly not that same cliff. It did, however, seem like they might follow me into areas known to have similar cliffs. Somehow, just by telling them the truth, by admitting that I had screwed up, I had restored some of their confidence in me. Sure Olsen is an idiot, I imagine them thinking, but at least he isn't blaming us.

Be right about something

It goes against something in us, especially as we get into management jobs, to admit that we were wrong. But when you are wrong, especially when you are wrong in a way that causes the whole team to fail, you gotta own up. Not that mistakes were made. Not that it could have been done better. Not even I did the best I could. No, it has to be I was wrong.

You can't change the past. You can't remake that wrong decision and be right. But you can be right about being wrong. Teams thrive on accountability and you need to show people that you are accountable too. By showing them that you can take your share of the blame, you can demonstrate to the team that the team is important to you too.

Next time we'll look at one of the keys to avoiding needing to admit that you were wrong – hint: it does not involve shredding documents and blaming someone else.

– Russ