A few years ago I was part of a web service project, it was volunteer weeknight work. The project was a web service that would help a lot of people. Which is what I love to do. At the start of one of the development meetings the head developer brought to our attention that the code wasn’t in sync. It meant that we were doing work twice or the work that we did do was getting overwritten and left out of the application. It was a huge mess that affected several thousand files.
The head developer was furious. He yelled and screamed about the messed up code and files. He laid blame. He yelled at us for not synchronizing our code every time we worked on the project. It was a shameful display. The head developer stopped all work on the project and spent a week straight fixing the code. He wouldn’t let any of the other developers help fix the code.
Over the next few weeks more blame was laid, rumors and discontent ravaged the project. The code was fixed but the damage was done. By the third week most of the developers, including myself had left the project.
I found out from one of the developers who did stay that the synchronizing issue was due to a bug in a program we were using to keep track of the code changes. The synchronization issue had happened again on a much smaller scale a months later. He pointed out a simple Google search revealed that there was a patch. Once applied it fixed the issue and the sync problem never happened again. We remembered that the patch had been brought up to the head developer a few days after the development meeting but he had dismissed it because he was so fixated on the problem.
The project ended up falling apart and the web service never came to be.
The head developer owned the situation in the wrong way. Instead of owning the solution and getting down to the bottom of it, he owned the problem and the feelings that came along with the issue. From the developers that I talked to, they didn’t leave because of the problem with the synced code. Mistakes happen, it is a part of life. It wasn’t anyone’s fault and even if it was, it’s still fixable. They left because how the problem was handled. It was a repeat process of putting the blame on someone or something. The focus of the project had shifted from helping people to blaming people.
When it comes to owning a situation you always have a choice. In simple terms, you can own the negative part or you can own the positive part. By owning the negative, the head developer chose to focus on the problem instead of the solution. If he owned the positive part he could have owned the solution. He could have organized the developers to figure out what was causing the issue, fix it and fix all the messed up code. The project would have continued. The development team would have felt great about fixing the issue and getting back on track.
By choosing to own the positive it doesn’t mean you are going to ignore the issue. It means that you are taking ownership of the part that will be a solution or help you move on.
Mistakes happen, it is a part of life, whether we cause them or not. If we never make a mistake we will never learn. But it is what you do after the mistake that matters. Own the solution.
