If you read my end-of-year post (you did, right?), you’ll recall that I mentioned that 2013 was a tough year for me. I’ve (the whole team actually) been stressed, unhappy, and just generally miserable in my job. At one point I was looking for a way out. Things are getting better, due in part to some hard conversations, some soul-searching, and an overall shift in my own personal thinking. I came across one thing however that really hit home. Keep reading and I’ll tell you what that was.

As a production support/operations guy, I’ve been conditioned to see myself as a gatekeeper, responsible for protecting production stability at all costs. This, of course, leads to a lot of friction, conflict, shorter-than-expected hugs, and just general “us vs. them” thinking with the development staff. Their motivation is to change things, ours is to keep things stable and running. There’s a natural conflict there, and I had convinced myself over the years that this is just the way it is, it can’t be changed. They’re stupid and reckless and don’t understand what it’s like for us, it’s all their fault. In my eyes, they were getting worse, the conflict was growing, and my job was killing me.

I decided that I had two choices – leave my job that I’d had for 8 years, throwing away that investment and the equity that I’d built up, or I could try to fix the problem. I’ll write more about this later, but I started to consider the possibility that maybe I, yes me, was part of the problem. I know, I was shocked too. Since I can’t fix 200 developers (who can?), I had to try to fix myself. I’ve been reading leadership blogs, lots of Tom LaRock’s stuff, self-help books, etc., but one day I came across a comment that was one of those whatchamacallits. An epiphany?

The original comment is on Brent Ozar’s blog, and he wrote the comment. I’ve altered it slightly to put into into the first-person perspective so that it feels more personal. Here it is:

My job as a database administrator is to solve pain points. I can’t make everyone code everything perfectly, so I should try to only focus on the areas that are causing people pain.

When they complain about slow performance, we can solve that together, and I can show them why a certain technique can’t perform well.

Otherwise, if I try to just make people change for “Best Practices”, they’ll think I’m crying wolf – because it does seem to work even when they don’t follow best practices.

I’ve been doing it wrong all this time. In MY world as a production support guy, a pain point is that blocking that occurs at 3:00am because of your stupid code that you wrote. A pain point is complaints about slow performance during the midday peak because of that stupid code that you wrote. Why aren’t you following best practices, are you a moron? SELECT * in a production query – where do they find you people?

Seriously. If Brent had walked up to me and slapped me in the face, it would have had a similar effect. I’ve been so focused on my OWN perceived pain points that I haven’t been able to see the real ones. Those real pain points lie somewhere between the development world and my world. My job is not to dig a moat around the castle. My job is to get on a horse, leave the castle every single day, riding around the countryside, rubbing elbows with the peasants, listening to their problems and their concerns, and helping them through those problems.

This was a game changer for me. It’s scary and a bit depressing to think that after 20 years of doing this work, I hadn’t figured this out for myself. I guess that proves that it’s never too late to learn.