Yesterday I wrote about a quote on leadership and that quote reminded me of a nice story about work, disasters and responsibility.
Before that I want to ask a question.
Who’s to blame when there’s human error?
If some colleague on the project you work on screw up, who’s to blame?
If a db gets destroyed accidentally by a colleague, who’s to blame?
In a work environment, where we are judged by the things we do and don’t do, it’s easy to search for someone to blame.
We do it both for defend ourself and to find someone who’s responsible for this.
Now let me tell you a story I read on the internet many years ago.
There was this guy, a junior developer, who got a job in a company that was having a pretty big business in online games.
They had big following and they were making lots of money.
It was a great time.
Their growth was unexpected and I suspect unstructured.
They grew big but didn’t evolve their internal system to a more controlled / secure system, instead they kept playing it easy on the same technology, with some agileness added thanks to the fact that there wasn’t a real structure.
All the developers had access to production data and it was fine because it helped them quick fix things.
The junior developer got the job, but one day he accidentally deleted an entire table. A key table with millions of rows.
Disaster.
He got the blame and was fired in a month.
While reading this, you might think “Oh well, he deserved it”.
It was his fault, yes. But I personally don’t think it was his responsibility.
He wasn’t the one to blame.
If you put that much power (the ability to destroy your business) into a newcomer, that’s your problem, not his/her.
Blame should always be taken from the upper roles, the business man, the manager, and so on not because I don’t want the lower roles to be blamed but because they are responsible for them.
They are responsible for their work, and therefore when they screw up it was their job to avoid it.
To allow them to work at their best without risk the project.
If they did otherwise then they risked, and if you risk and fail, it’s not the fault of the error, you knew it.
It’s like when you bet.
You know that you can lose money, and if you lose it you’re the one to blame.
The same applies to companies.
Aside from this, I think blame is not effective in helping diagnose problem since it puts focus on people instead of processes and collaboration.
When people screw up they rarely do it intentionally, they usually do it accidentally.
Nobody will delete your database because they want it.
So instead of asking who’s to blame, ask “What could be done do avoid this in the first place?”
or again ask “What part of the process/communication failed?”
To add even more spice onto this thought remember to not add complexity, not too much at least.
What usually happens in this cases is that we tend to over control and add unnecessary control structures to the process.
We want people to be trackable and we add a requirement that doesn’t help them do the work.
The job of a leader is to let people do their best work, lessen the screw ups, and handle the disaster.
It’s not the job of the leader to feel safe.
Come on, give me the chills 