One of the aspects of being an old guy writing code is that I see a lot of behavior from younger and/or less experienced developers that comes off as unprofessional to me. I try not to judge anyone for being unprofessional – I was no better when I was young. But I had older people around who would occasionally call me on my behavior and explain to me that there may be better ways to handle things.
Hence this blog post – a few pointers on taking accountability for your own work.
The over-arching rule is that you are responsible for the results of your work. Whether your work is working as you intended or not, when one of your users has a complaint about it, you need to address that complaint.
Here are some typical comments that I see in online discussions or status updates, and how I would have handled them differently:
Disclaimer – people can probably rip my responses below to shreds, too. The point is to take responsibility for your own work in a polite and professional manner, and these scenarios are just examples to illustrate that point.
1) In the case of downtime of your app.:
- Bad – “Our data provider went down. It wasn’t our fault.”
- Better – “We had some problems with our infrastructure. We have identified where the problems lie, and are working with the correct parties to correct the issues.”
- Best – “We identified the root causes of the problems, and our internal staff and vendors are working together to prevent future occurrences of these problems.”
2) In the case where a user’s environment breaks your code.
- Bad – “It works on my system.”
- Better – “The problem is due to differences between our systems. Can you work with me to help troubleshoot it so I can fix it for you?”
- Best – “I have found the problem, and updated the product to work in your environment, as well as updated our test processes to ensure we test for your environment in the future.”
3) In the case where a user thinks something is broken because they don’t understand your system.
- Bad – “It is working fine. “
- Better – “I see where the confusion is coming from — that feature actually works like this…. <insert explanation here>”
- Best – “Although this is working as we intended it, clearly that wasn’t what you were expecting. Can you explain what you were expecting, and what you were trying to accomplish so we can improve our product?”
4) In the case that a bug is actually in a framework you are using, not code you wrote directly:
- Bad – “This is not my bug. It is a bug in X”
- Good – “This is a problem with X. We can work around it by doing Y until they have a chance to fix it.”
- Best – After working around it in your code, working with the developer of the framework, writing the bugfix yourself and submitting it, or putting in a whole new framework if need be, to resolve the issue…. “Thanks for finding this for us – we have put out an update that should resolve it for you. Please let us know if the update is working for you.”
The bottom line is that at some point, someone is going to take responsibility for problems with software. As a coder, you are often already the 2nd or 3rd person someone has dealt with when looking for help. Passing the buck frustrates the customer, and can frustrate your coworkers. Taking accountability for problems will improve your code, improve your understanding of the larger infrastructure in which your code operates, and help you understand your customers better. These will all result in a better product, and will make the difference in how people perceive you – as just a coder, or as “the guy” to go to to get things resolved.
It should also be noted that taking accountability does not mean taking blame, nor does it mean that you are responsible for the fix. Sometimes it really is someone else’s job to fix the problem. But there is a huge difference between responding, “Let me help get the correct people together to get this fixed” vs. “Not my problem – Ask Joe.”
And yes, there is a flip side to this, wherein if you own everything that passes by you, you’ll never get your own job done. The key is the perception to your customer. Do they feel that you care about helping them with their problems, or not?
Details of what problems you own, and what you pass on are going to vary based on your organization and your role. My best recommendation is simply to take every issue seriously. Make sure that you understand the problem, verify whether or not you have control of fixing it, and then respond in a way that best supports your customers.