If you’re a DevOps engineer who is constantly fighting fires and trying to keep your head down, it’s easy to get stuck in a rut of “You ask, I build”. Heck, it’s easy to think that way even when everything is running smoothly.

But that’s not what the job should be, or at least what the job can be. Not asking the right questions leads to more firefighting down the road and smooth operations devolving into mediocrity.

If you have a desire to be better at your job and build truly helpful, effective tools, before any code is written, there are (at least!) three questions that must be answered.

1. Are we solving the right problem?

Unfortunately, this question almost never gets asked and when it is asked, the answer is often “no”. A Dev or PM will send an email that says “We need to automate X.” and the DevOps engineer will asks a couple of technical questions before starting the build.

If you’re a DevOps engineer and you aren’t asking questions about process and goals, you are a bit pusher, not an engineer. You have unique insight into how the systems you work on interoperate and feed one another, you think in terms of systems and dataflows— you have a contribution to make that’s more than writing playbooks and scripts.

If the teams you’re working with aren’t volunteering their goals, you need to ask for them “What are you trying to accomplish?” Having this context is critical if you want to provide real value. What you were asked to build is often not the right solution to the problem that needs solving.

Before you build tools, build relationships with the developers you work with and get in the habit of asking questions that aren’t just “what version of this plugin do you need?” Ask questions even when you’re offering feedback.“What if we did it this way? Would that work?”

2. Is building a tool the right solution?

If you’re confident in the process, the next question you should ask is “Is building a tool the solution to this problem?” In a lot of cases the answer is “yes”, but thousands of custom tech fixes have been built to solve problems that could have been solved more appropriately with an email, a Google form, or God forbid, two people actually talking to one another.

This is when it helps to get someone in the room who isn’t an engineer and can provide a sanity check against the “when you have a hammer, every problem looks like a nail” problem.

Being competent with Python or Ruby is not an excuse to try and solve every problem with a script. I don’t know how many discussions I’ve sat in on where people were arguing about how to build a custom tech fix and I wanted to scream “JUST HAVE THEM GO SIGN UP FOR A DOCUSIGN ACCOUNT! WE DON’T NEED TO SOLVE THIS PROBLEM WITH CODE!” or something similar.

Find someone who will call you on your BS and tell you when you’re being myopic. That person is your new best friend.

3. Who is this tool for?

Hopefully the answer to this question will come out of defining the process, but that’s not always the case.

If you find that you’re only building tools that you or your DevOps team can use, you have a problem. There are certainly circumstances where having an internal-only tool is appropriate, but the majority of what you build should be usable by the people you’re trying to help.

Don’t build a script that you run on your local machine to deploy servers that the developers ask for. Build a portal that allows the devs to deploy without your involvement. That local script may be a first step, but fight tooth and nail to remove you and your team as a dependency for getting something done.

Some engineers think they’re being helpful by responding to requests with “Sure, I’ll build that.” But if you’re doing the same thing over and over (deployments, updates, etc.) you are not being helpful. Likely, you are slowing everyone down and have the potential to bring the dev process to a complete halt.

If you want to be a SysAdmin, keep on keepin’ on. If you want to be a DevOps engineer, build tools that others can use, then get out of the way.

Originally posted on BestTech.io