Being Right, the Other Side

Home / Professional Development / Being Right, the Other Side

I read an excellent article by Camille Fournier about the importance of recognizing that being right is not the only factor that needs to be taken into consideration when making a decision. You could even change it from “being” right to “doing” right. Although, I mean it in a technical sense, not a moral one.

If you haven’t read it already, go ahead, I’ll wait…

I agree with her.

I’ve been that guy… more than once…. okay, okay, a bunch of times. You know that guy. The one who just couldn’t see past the point that we were doing something wrong, something stupid, something that would bite us in the butt for the next three or four years. Oh yeah, that guy. The popular one (not at all). The one the that causes the to boss starts to cringe whenever that guy heads towards the office. Been there, done that, have the embossed external hard drive.

Now… over the last several years, I’ve made an honest and sincere effort to not be that guy. I’ve tried pointing out the flaws, making my arguments, and then, if they get shot down, lose quietly & gracefully. Sometimes I’ve been successful. Other times not so much (times 100). I usually gaged how successful I was by how angry one member of my team, who never compromised, became.

The only thing is, well, sometimes, that guy (or gal), is 100% correct.

Not only that, but the boss/program team/consultant/whoever on the other side of, what to mean seems a silly argument, ready to toss common sense out the window in order to deliver software faster (because it always seems to come down to how fast we deliver the software) is 100% wrong. Not only are they wrong, but they’re destructively wrong. Project wrecking wrong. I’ve seen it happen, multiple times. That’s why those of us who do tend to act like that over-wrought freak-out queen put on our performance. I know we’re crazy to thins it’s a really bad idea to throw out relational integrity, stop designing databases for optimal storage, rely on the app for all integrity checks, use an ORM tool as an OOM tool, skip testing for deployments, stop maintenance routines and monitoring, or just flat out ignore the laws of physics. We’ve seen the projects fail because we understand how things work. We just can’t always explain that understanding to others.

So the real key here is that you have to split this hair mighty fine. Yeah, giving up on some processes, some best practices, in some situations, that really can make all the difference in getting software out the door faster & more efficiently. No question. But, those same compromises can lead to absolute failure. Management has to be able to listen to weed out the best practice complaints from the technically unsound complaints. And we geeks have got to stop having the vapors every time a developer proposes making a change to the system or a process. Otherwise, we won’t be listened to when it really counts, like the Boy Who Cried “Wolf!”


  • G Bryant McClellan

    I’ve also got t-shirts. So does my former boss at my last employer. We were always on the same side of the fight. If he believed it was the right thing to do, that is what he fought for. He lost a lot of battles but he never gave up.

    Sorry, I cannot agree with backing down because you become the manager and you just don’t have the desire to fight and lose. That is the antithesis of moral courage. Once she made that leap, Camille sided with the terrorists.

    Having moral courage in a work environment is not easy. Doing the right thing requires more than knowing how to identify it. Kind of like the reasons why common sense is so uncommon.

    I’ve stood up and would not relent and paid the price for it. The benefit is that I now work for an organization that values moral courage and doing the right thing.

  • John Dempsey

    Grant, this blog post timing was great. I have just been dealing with this problem once again and trying to do some self-evaluation surrounding it.

    I have always tried to do things the right way and often argued my point to get my way as you explained. But the longer I am in IT, the more I realize this will continue to be a viscious cycle and will not change much. I am realizing the only change I can control in these situations is me. So, I am trying to figure out how I can overcome my “doing the right thing nature” and reduce internal stress produced by not doing it right but just getting it done.

    You mentioned you have been making “…efforts to not be that guy”. Can you expound a little further on what you have done towards this goal.

    I’m currently searching for some tangibles that I can use retrain myself from being the A-type “do it right the first time” guy. The goal is to transform myself into the guy like you mentioned, makes arguments & points out the flaws, but can complete the task without it the extra stress of knowing its not the best way.

    Sorry for the long comment. Great blog post and perfectly timed for me. I hope to hear from you and others the process to become the new guy.

  • The main thing I’ve been doing is trying to evaluate how important what I’m getting ready to argue for is. Is it just slop that we’ll have live with… then maybe I can live with it. Is it going to cause a minor to noticeable performance hit… maybe I’ll live with it. Is it going to cause crashes or a major performance hit… I’m riding it to the ground to try to get rid of it.

    It’s hard when you know, in your toes, that the accumulation of lots of little compromises (oh, it’s not that big a deal if we don’t qualify table owners in the queries) are going to add up to put you at thresholds where something more severe will bring things screeching to a halt. It sucks. I know. You just have to acknowledge that forward momentum might outweigh long term, but minor, issues.

OK, fine, but what do you think?