Four Roadblocks To ‘Technical’ Challenges in Agile/DevOps

I do a lot of work in automation, and oftentimes we run into roadblocks to getting all of the tasks into an automation pipeline.  A lot of the time, when going over automation steps for a project, I’ll hear people say things like, “Well you can’t do that,” or, “That’s just not possible”, and unfortunately, a lot of people take those reactions as gospel and stop going down the path without asking the most important question: “Why?”

I could recount numerous stories where I ran into blockers that were absolutely able to be overcome, but because an organization has simply “always done it this way” they were not inclined to go any further down the road to make a change.  Usually, these blockers can be throw into one of four buckets – Technology, Process, Legal, or People.  Once you know what bucket it goes in, it becomes easier to decide what’s needed to approach the problem, make a recommendation, and get it resolved.

Technology

Technology problems are, in reality, oftentimes not the root problem.  When it is, it’s usually because the application doesn’t support the methods and goals that you’re trying to achieve.

Say for instance, you’re attempting to automate the process to create a virtual machine.  And the network team issues static IP addresses and logs what is being used in a spreadsheet.  Or, you’re attempting to automate the process for onboarding new employees, but the HR department is using an antiquated system for how they track new employees and who they work for and isn’t designed to be integrated with any other application.

These are technology problems which are relatively easy to fix.  You can use existing technologies like a database to track these things, or you can get dedicated modern applications that integrate with other platforms to be able to accomplish tasks.

Really, the biggest challenge to a technology problem is whether or not your organization is willing to make an investment towards the change.  This investment may be monetary, and if it is, that can be solved with buy-in from management and budgeting.  The other investment is putting in the effort to get the work done – in either case this stops becoming a technology problem and it becomes a people problem.  More on that later.

Process

Just about every company runs into this one.  I once worked with a company that had a 27 day SLA to deploy a single virtual machine.  27 days!  When my partner and I got a hold of the process flow, a lot of it was manual process and approvals of all of the different organizations involved.  When we laid out what could be automated, we were able to boil that process down with automated checks and balances that could get the same amount of work done within a few hours.

The problem, however, was that the documented processes and procedures that the company had been beholden to required that the manager of each organization manually sign off on the approval.  When those processes were challenged, none of the stakeholders were willing to champion an effort to drive the changes necessary.

Bart Schlatmann, former COO of ING Nederland I think put it best when he said, “Agility is about flexibility and the ability of an organization to rapidly adapt and steer itself in a new direction. It’s about minimizing handovers and bureaucracy, and empowering people.

You are as agile as your most rigid process.

Legal

Legal challenges don’t often come up, but when they do, they often can be solvable.  The most frequent I’ve seen is with open-source licensing.  Oftentimes, organizations will just issue a blanket “no” across the board for open-source software.  This is a mistake.

Yes.  Understand the licenses involved for using open-source.  Yes.  Ensure your company is reasonably covered when using it.  But if you are taking open-source entirely off the table for use, you’re hamstringing yourself and your initiatives.  No one moves to innovate and improve product faster than the open community.

For anything outside of that, the important thing to remember is to ask questions.  Understand the legal issues at hand.  Most importantly, understand what would be needed to stay within the legal lanes and still get the job done.

People

The most common, and the hardest to solve.  For the most part, people can be innovative, creative, and passionate about their work.  But they can also be territorial, stubborn, and unyielding to change.

Everyone should recognize this; not only of their peers, but of themselves as well.  Change is scary.  Habits are hard to break.  And when someone requests a change to something that you’ve worked so hard to build, it can be easy to say no.  Recognizing this in yourself is equally important as recognizing it in your peers.  Instead of a knee-jerk reaction, take a moment.  Think about the reasoning for the change and ask questions.  Understand the problem that the requester is trying to solve.

Perspective is valuable.  It’s based on our experiences, and thus everyone has a different take on things.  All perspectives are equally important.

People that are willing to embrace innovation and change are the ones who will enable an organization to move forward.  Those who fear change, and refuse to challenge their own ideals become anchors.  They will slow a company down, if not bring it to a grinding halt in terms of progress.

In this day and age of disruptors who surpass industry juggernauts in market share and value, it’s important to understand and evaluate the challenges you have to move your organization forward.  Keep your company flexible and adaptable to change.  Understand processes that are holding you back and adopt new ones to address the same risks but allow you to move forward.  Evaluate your people.  Coach them to ask questions of themselves as much as their peers, and reallocate those who are unwilling to adapt.

Finally, ask questions.  Don’t take ‘no’, or ‘we can’t do that’ as the final word.  Challenge the response with a question.  Understand the reasoning behind the response.  ‘No’ isn’t a solution.  It’s a roadblock.  Anything is solvable.  But you need to understand the why before you can get to how.

Three Things That Make a Good Technical Candidate

I have this conversation a lot with managers and colleagues in the industry.  It usually starts with, “what do you look for in a candidate when you’re doing an interview?”

Oftentimes, I’ll hear people talk about how their company only hires people with college degrees, or that they look for the number of certifications that the candidate has.  Usually when I hear these two things, the first thing I do is sigh.  While I will never beget someone for taking the time, effort, and financial expense to acquire a college or university degree, it also doesn’t necessarily give them the technical know-how to perform the kind of work we do.  Nor do certifications necessarily reflect technical knowledge.  Most certification exams that I’ve seen don’t actually test your practical knowledge of how something works, but rather your ability to memorize a book.

When I was going for my aircraft mechanic certifications, I was tested on three areas – General, Airframe, and PowerPlant.  Each area required three exams; an oral (spoken), practical, and written test.  Nine exams altogether.  The first thing we learned in mechanics’ school was that when we received these certifications, the only thing that we were really certified to do was learn how to do our job.  Until I gained enough experience performing tasks with someone inspecting my work each step of the way, there was no way I was certified to return an aircraft to service.

The same really goes in our industry.  I am sure as hell not going to turn some person fresh out of school loose on my production environment and simply trust them to do work.  So what really matters is their experience in the field, not the schooling.  But what really makes an exceptional candidate can be boiled down to three things – Critical Thinking Skills, Initiative, and Enthusiasm.

Critical Thinking Skills

When I’m interviewing a candidate for a position, I’m not barraging them with questions to troubleshoot some obscure issue.  That’s just uncomfortable for both you and the candidate.  What I do is give them a scenario and ask them to think the process through to the logical conclusion.

What’s the difference you may ask?

Troubleshooting scenarios usually consist of a lot of back and forth with the interviewer saying, “Okay, that didn’t work.  What next?” and then the candidate following up with next step questions.  It’s annoying and uncomfortable.  Often, this line of questioning devolves into a power struggle between the interviewer and candidate.  Stop it.

Instead, give them a problem scenario and ask them what they would do to investigate it.  Question them on why they chose the particular path they did.  Find out the reasoning behind it.  I want someone that can think about the task logically and follow the thread to it’s conclusion.  Ultimately, we are all going to run into issues that are going to be beyond our experience, and following a checklist isn’t going to help.  I need someone that will work methodically and logically and outside of the box.

Initiative

This is where the troubleshooting scenario also tends to fall short.  Oftentimes it follows a scripted, linear scenario.  This only proves that the person I’m interviewing is going to follow a scripted, linear process.  On top of being boring, it doesn’t help in those real-world scenarios that aren’t documented.

Don’t ask, about some obscure error code with the expectation that they’re going to blurt out what it means.  Ask them about situations that will show how they will go about finding the information.  A very basic question that usually weeds out a lot of candidates for me is, “If you’re looking through a co-workers code and you see a PowerShell command that you’re not familiar with, how would you find out what it does and how it works?”

I actually had a guy tell me that he would just run the code.  Awesome.  I want you looking at stuff in my production environment.

On the other side of the coin, I was once given a scenario question where I received an error in SCCM, and they asked me what log file I would look in to investigate.

Dude, really?  Do you even know how many log files are in an SCCM server depending on the role?

When I told him that I’d look up the error online first to nail down which log to look at, he wasn’t impressed with my answer, and I wasn’t really impressed with his response.

Enthusiasm (Willingness to Learn and Share)

Finally, enthusiasm.  You don’t want someone who’s going to come and and just do a job.  Our industry is changing every day and it affects every aspect of what we do.  There are going to be new technologies and challenges.  Our way of approaching problems is changing as we implement new things.  You want someone who’s always looking to the next thing, learns something new, and shares it with their team.

Ultimately, if they aren’t willing to learn something new and share it with others, they are going to slowly become a liability that holds the organization back from growing.  If they can’t go beyond a script to troubleshoot a problem, I can’t rely on that candidate to handle an issue that isn’t documented.  And finally, if the candidate can’t think logically, I can’t trust them to make the right decisions based on the available data to get the job done.