Do Be a Gatekeeper

I read this fascinating blog post called “Don’t Be a Gatekeeper” by Julie Zhuo. Please read that first.

It really resonated for me in a lot of ways. Everything she said is 100% applicable to our jobs as data professionals. Work to make things more robust. Create processes and structures and an environment where you don’t have to be the hero all day every day. Yes, absolutely. But… ah, there’s this nagging little voice at the back of my head. Let’s ignore it for a moment.

Are you a gatekeeper for your developers? Why? Get out of their way. Listen to what Ms. Zhuo has to say. Your development team doesn’t need you squatting on their servers preventing them from moving as fast as they can. In fact, they need you to help them out. Create mechanisms and deployment best practices that assist them. Get your database into source control. Implement continuous integration. Explore the concept of continuous deployment (ABCD, Always Be Continuously Deploying, Coffee is for deployers).

Are you a gatekeeper for your testing teams? They don’t want you to be either. They need the ability to quickly, and easily, on their schedule, reset from a set of tests. Preferably without having to wait on you. Again, listen to Ms. Zhuo. She is right. You’re not the hero because you’re the only one who has access to do fundamental processing that can, fairly easily, be automated and then released to the teams that need it.

Are you a gatekeeper for your production environment? No? Well, here I say, you better be. I’m now going to let that voice in the back of my head out to play.

First, those data professionals among us who are tasked with being DBAs (or some equivalent) are expected to be on call for production problems. That means we’re responsible for what is there in production. Which means… it’s not a question of whether or not there should be gates or gatekeepers. It’s a question of WHERE the gate is. Because, in order for me to sleep at night, I need to do the things listed in the previous article, make things robust where I don’t have to be a hero. And that means controlling what goes in there as much as I reasonably can (have to use weasel words here). This environment, the one the business depends on, can’t be out of control and crazy.

Second, there are regulatory requirements about who can have what kind of access to certain information. Legally you can’t just open the production environment up to the entire company. Again, WHERE the gate goes is the question, not whether or not there is one. If the government tells you to put a gate up, you usually put a gate up.

Third, Uncle Ben (by way of Stan Lee,), while educating young Peter Parker/Spiderman, said it best, “With great power comes great responsibility.” You are the data pro. You are the one. When push comes to shove, when the server goes offline, when the database is corrupted, when the query is running too slowly… It’s you. You’re the hero. Time to step up. You have production access and now you have the responsibility that comes with it. Thank the gods we don’t have to deal with the Joker in our little corner of the universe. But if we did, would you want the local cops to track him down, or Batman? I’m putting my money on Batman. He has a unique set of skills that makes him qualified for just such a task, as do you data pro, as do you. You’re Batman. But, if you’re being Batman for your databases and servers 2-3 times a week, you’re doing it wrong.

Largely, I think Julie Zhuo is dead on accurate with her approach. But, I do think there are places where gates are necessary. So, the important point, for me, is not whether or not you have gates and gatekeepers. The important point is, where do you put them. Do be a gatekeeper. But, you must very carefully consider where you place the gates.