DevOps Skill: Become a Yes-Man Who Frequently Uses No

“Sometimes ‘No’ is the kindest word,” says Vironika Tugaleva who probably doesn’t even care about any DevOps skill.

But honestly, no quote would clarify the importance of saying “no” in the realm of the Developmental Processes better than that. In fact, the art of saying no is a must-have DevOps skill.

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.

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 would omit further regrets for invalid nods.

Dance to Your Tune and Say No to the Strange Rhythms

As a vital DevOps skill, an engineer would 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 blend-in part 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. Take your time, get to know what’s what, and then opt to offer some solutions.

A sudden change in the principles of a developmental process would 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 all sorts of processes leaving a part or two with manual nature is not optional.

“Partial automation is not automation and you have to deal with it.”

It’s understandable that some believe the Automation is in the 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 nods—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 one, software development teams utilize various tools, procedures, APIs, etc. for certain tasks. So, I just need to clarify that it’s not a mega-fact.

However, what I might suggest as a mega-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 an improper tool/procedure—still, refusing to change for the better.

So, as a piece of friendly expert 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 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 a while I get into contact with teams that have a rigid mindset toward the flaws. These so-called result-oriented people have the only goal of ‘solving issues’ in their minds. 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, the thing is that they are not valid to become your go-to.

If you consider the 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.

Spreading Yourself Too Thin Is a No-Thing

DevOps experts are multi-taskers of the team—and it’s hard to knock that. But hey, 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 ayes. 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. By contrast, you need to see it as the most positive word to save the butt of 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 blood-sucking issues throughout the developmental processes.

Show More

Related Articles

Leave a Reply

Your email address will not be published.

Back to top button