Category: DevOps

Posted on

Trust, Expectations, and Working From Home

More and more these days, I’ve been seeing some interesting conversations on social media outlets such as LinkedIn regarding work from home policies. Oftentimes these conversations are in reaction to shared articles such as this one from Forbes, or this article from Inc.

I’m a very big proponent of the work from home model for a myriad of reasons, many of which are covered in the aforementioned articles, so feel free to read through them. But right now, I’m much more interested in talking about a particular reaction to these posts that I see quite frequently regarding trust. Most of the comments I’ve seen can be boiled down to this:

“How can I trust that my employee is doing their job if I can’t see them?”

Trust vs. Expectations

Trust is almost analogous to faith. I trust that my best friend won’t get a pile of speeding tickets or in an accident if they borrow my car. I trust that my partner won’t go blabbering about my private comments to our friends.

Why do I trust them in this? Because we’ve built a rapport over time and built a relationship that establishes this trust. I have no real evidence that they won’t do those bad things, but because I’ve known them for a period of time, I can have faith that they won’t do them.

It’s understandable, as creatures who rely on positive interpersonal relationships, that we want to trust the people that we work with or for. Trust is part of what makes a good team. And a trust that is broken between co-workers can have serious effects on providing a good product to customers – both internally and externally. But when we hire someone to a position, it isn’t because we trust that they’re a good worker – we hire them because we expect that they can do a particular job.

I expect a co-worker will perform the tasks that are assigned to them, regardless if they work above, below, or alongside me in the reporting structure. Likewise, I have tasks that I need to perform, and my co-workers expect that I will accomplish what is necessary to achieve the end goal.

So the question you should ask yourself is simply, “does the person in question meet the required demands within the deadline assigned?” If the answer is yes, then the question of whether or not you ‘trust’ an employee becomes moot. They do the job.

Another comment that I frequently see is, “I’m worried that my employee is going to spend the majority of their day playing Xbox or PlayStation and not actually working!” This one actually makes me giggle a little bit inside for a few reasons.

First, if you’re employee is meeting your expectations of delivering quality work in the time allotted, then why is this a question? Second, if it takes them two hours out of the day to accomplish the work, and they’re playing their preferred gaming console for the other six, then you are failing to leverage your assets effectively. The only difference is that if you are doing so with them in the office, they’ll replace video games with Facebook or something else they can do from their computer.

The Solution Is Easy and Manageable

Any good manager should understand, at least fundamentally, what their employee’s job is and what they need to do to get the job done. With this information in hand, you can not only set those expectations, you can measure the results.

Those expectations should include how much time the employee expects that the work will take to accomplish. If those tasks aren’t filling out their 40 hours, then you can assign additional tasks. If you don’t have any tasks to assign, there should be no problem in allowing the employee some idle time – in or out of the office – to allow them to blow off some steam. If something comes up and that employee has the idle time, then you have flexibility in your team to accomplish those unforeseen tasks and avoid overtime.

Pure, plain, and simple. You don’t trust an employee to do a job; you expect them to. If your employee isn’t meeting those expectations, then that’s a problem that can be solved by coaching, education, or dismissal. Where they work from isn’t important – it’s whether or not they get the job done that does.

Posted on

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.