The Choices We Make

Home / DevOps / The Choices We Make

If you keep your head up and look around you’ll see the choices people make all the time. I saw a recent example online in this story about two experiences, shopping at Home Depot vs. Lowes (very minor NSFW warning due to language).

I don’t want to get into a debate about the two stores. That’s not the point. The point is, we all have two sets of priorities that we have to serve. The first set of priorities are the ones immediate to us, the rules and regulations we create and enforce around our jobs. The second set of priorities are the ones that are at least a step removed from us, the service and services we supply to our “customers”.

Make no mistake, we’re all serving customers to one degree or another. I know my consultant friends are already completely on top of this concept (mostly, I suspect a few of you aren’t thinking it all through either). However, I think that a lot of us (Dev, DBA, makes no difference) tend to fall into the camp of that horrible Home Depot manager who made a whole series of crappy choices. He followed every rule (or at least his interpretation of them since that first manager saw them all in a different light) yet drove off his customer.

Please, next time you try to bypass your DBA team because they slow you down or you stop innovation from the dev team because it’s too much change too fast, think about the repercussions of that choice. We can only afford to drive away so many customers before we’re in a world of hurt.

Side note: I’m saying this with the experience of having lost effectiveness at my last job because I had been overly dogmatic and resistant to change. Please, learn from my negative example.

4 Comments

  • Yeah DBAs shouldn’t slow innovation. Our job is to take what the devs want and make it happen safely in prod. We may not always be able to give it to them exactly the way they want, but we should always be able to get the result. Usually when they want to innovate with excessive change, it means modernizing their code, and I’m always all for that.
    So yeah, don’t say no, but make sure they’re doing it in a way that’s safe and supportable. Saying yes doesn’t mean capitulating everything.

    • Total agreement. My favorite new phrase is “Yes, but…” and then we outline the things we need to do to make what they want happen in the best way possible. Just say “No” to “No”!

OK, fine, but what do you think?