DevOps Skill: Become a Yes-Man Who Frequently Uses No
DevOps Skill: Become a Yes-Man Who Frequently Uses No
Stay positive while remaining practical.
Join the DZone community and get the full member experience.Join For Free
“Sometimes ‘No’ is the kindest word,” says Vironika Tugaleva, author of The Love Mindset.
The art of saying no is a skill you must have in DevOps.
A respectable DevOps specialist would know when to use affirmatives. However, a professional one would know how, when, and why to use them—and still, get some thumbs up.
You may also enjoy: Saying No — Tips for the Product Owners
No matter how necessary it is to have a couple of Agile yes-men in the team, DevOps specialists must be kept an exception. Indeed, such an expert would be a proper piece of the puzzle only if you let them say “no.”
But don’t get me wrong; saying no in this context is different from refusing to acknowledge one’s responsibility. By contrast, it’s the type of “no” that prevents the mistakes an idle "yes" would create.
Dance to Your Tune and Say No to the Strange Rhythms
A DevOps engineer should know how to blend in with the current rhythms of the project. But hey, that doesn’t mean they have to dance with whatever song the team offers.
Simply stated, the next stage after the blending should be tuning the instruments. In fact, a professional DevOps specialist would start seeing the problems and try to solve them right away.
So, don’t allow the flow of current rhythms of the project to catch you off-beat. Take your time, get to know what’s what, and then offer some solutions.
A sudden change in the principles of a developmental process can only cause more harm than good. Therefore, try to set the ball-of-change rolling slowly and gradually.
That’s “Uh-Uh” for the Partial Automation and “Uh-Huh” for an All-or-None
The point of the automation process is to rescue your team and the project from manual tasks. So, saying no to partially-automated processes that still have a manual part or two is not an option.
“ Partial automation is not automation and you have to deal with it.”
It’s understandable that some believe that automation is in DevOps engineers’ blood. But to be frank, it’s just a DevOps skill that comes in handy when applied properly. And by "properly," I mean "completely."
When the specialists of your team are there to say nothing but yes, expecting satisfying results would not be logical. So, let them avoid unnecessary agreement—period.
But hey, before even thinking about the automation, get to know its proper mindset. Here’s what you need to know about the automation mindset when it comes to DevOps.
Nay with a Useless Process; Aye Aye, the Progress-Friendly One
As a surprise to no one, software development teams utilize various tools, procedures, APIs, etc. for certain tasks. So, I just need to clarify that it’s not a an absolute fact.
However, what I might suggest is an absolute fact is that some of the so-called developmental teams allow the tools and procedures to use them!
Yes, you read it just right. I’ve seen dozens of engineers who got bogged down due to having improper tools and procedures—and refuse to change for the better.
So, as a piece of friendly advice, never have unconditional faith in tools. Instead, bear in mind that they’re meant to be there for you so long as you find them useful. (BTW, having such an attitude towards tools is a stand-alone DevOps skill).
In brief, my engineer friend, say no to a tool/procedure that holds you back—no matter what.
A Make-It-Work Attitude Should Be Out of the Question with a DevOps Specialist
Once in a while I get into contact with teams that have a rigid mindset toward the flaws. These so-called result-oriented people only have the goal of solving issues. And the sad part is that there’s no room for preparing for the future in their mindset.
They opt to solve the problems as fast as possible without bothering to follow the proper documentation process. So they fall into the loop of repeating the solution-finding practice—though they’ve found them before.
A result-oriented team is the one that stumbles upon the same old problems with no failure. That is because such a team would only think about solving the current flaws without considering the future.
The results, however, may seem satisfying to such a team in the short-term. But the long-term upshot would only provoke annoyance.
If you’re expecting to get more from DevOps implementation results, read my article on Software Development: How to Make the Most Out of DevOps and Guarantee the Success.
Workarounds? Well, Yes and No
The title, I believe, is self-explanatory. In fact, workarounds are essential parts of creative modern problem-solving methods. However, they should not become your go-to.
If you consider workarounds as the permanent solutions for your developmental problems, you’ve created a new problem!
These sets of solutions are meant to lend a helping hand with a situation where extra time is a concern. So, you must use them as a temporary way out—and that’s that.
Using the first U-turn on the road to get back to the issues is a DevOps skill. So, avoid brushing the flaws under the carpet of workarounds! Instead, acknowledge your responsibility and find a real-world solution for them as soon as possible.
Do Not Spread Yourself Too Thin
DevOps experts are multi-taskers of the team—and it’s hard to knock that. But, multitasking differs from getting snowed under the unbearable number of tasks.
No matter how fun it may sound at first, having too many irons in the fire would ruin not only your career but also the future of the developmental project.
So, don’t overestimate anyone’s capability of handling several tasks at the same time. Otherwise, you’ll have to get used to out-of-the-blue issues to hold you back constantly.
Expert tip: In case you’re not the decision-maker, say “no” to a new task that seems to be more of a pain in the neck than real work.
On a Final NO-te
In conclusion, I would like to add that a well-played “no” is worth a hundred unnecessary yeses. That’s so because avoiding to get into some problems such as neglecting documentation or false/improper automation process would be your savior angel.
The type of “no” that I mentioned throughout this paper should not be considered as a negative word. In fact, you need to see it as the most positive word to save your projects.
The art of saying “no” is a vital DevOps skill that an engineer needs to be familiar with. And it’s the only way of dodging time- and resource-draining issues throughout the developmental processes.
Opinions expressed by DZone contributors are their own.