Don’t Be That Guy

Nobody likes the “brilliant asshole”.  Don’t be either of those things.

Doesn’t matter how much good work you do if you’re an insufferable jackass.  You might be right or have good ideas but nobody’s going to want to work with you.

Doesn’t matter what you have to say or what you have to show for your efforts if people hate your guts.  You might do something fantastic; doesn’t mean a damn thing if no one gets behind it.

Don’t be that guy.

Common Sins of Systems Administration

I feel as though I’ve spent enough time doing Systems Administration that I figure it’s time to vent a bit and point out some common fallacies and reasons why these are anti-patterns for both successful SysAdmins as well as overall health of tech organizations.

“Just restart the service/host.”

If companies wanted this kind of response to a problem, they would just invoke an event-driven service to restart services or hosts when a failure is detected.  This just masks the problem.

Instead:

  • Ask “Why did this fail?”
    • If you’re not asking why, you’re behaving much like the oft-maligned “Windows Admin” or “Bastard Operator From Hell (BOFH)”–restarting services or servers and not digging in deeper.
  • Look at logs.
    • If you’re not looking at logs for a service or a host, you’re missing a huge part of the work that makes Systems Administrators one of the most important roles in a technology organization.
  • Look at service and/or host statistics.
    • Back up your assertions with data, otherwise you’re just conjecturing.

“It’s not important/it’s intermittent.”

Bullshit.  If it’s important enough to page someone, it’s important enough to debug and find a way to keep it from happening again.  If it’s intermittent, then there’s a cause.  Ignore the symptoms, find the source.

“I’m too busy with other stuff.”

Again, bullshit.  If you’re too busy, say so.  It’s your job to tell someone (your manager, your peers, your employees, whatever) that you’re over-subscribed.  Anything worth doing is worth doing right and devoting as close to your full attention to as possible, so speak up.

“I don’t know how to do this.”

Then you’ve just been gifted with a learning opportunity.  The best SysAdmins use learning opportunities rather than avoid them.

  • Read documentation.
  • Look at logs.
  • Debug the problem.  Try to duplicate it.  See how it differs given different conditions.
  • Understand the services and hosts that you’re responsible for.
  • Be thorough and verbose in your investigation.

“This is never going to be fixed, so why bother?”

Your entire job is predicated on the notion that you’re supposed to help provide context to decision-makers around impact of bugs, flaws, and failures.  If you’re not doing it or aren’t interested in doing it, then why are you even working?

  • File bugs/stories/incidents.
  • Provide data to back up your assertions/findings.
  • Dig in.  Look at logs and statistics for commonalities and outliers.
  • ADVOCATE.
    • If people aren’t listening, take it up to the next level.  Find the Product Owners or Product Managers.
    • Explain why it’s a problem and what they could do to resolve it.
    • Talk about the cost of the problem in terms of payroll hours wasted (this generally gets people’s attention).

These are definitely common sins, but this is by no means a complete list.  What do you think?  Have any you’d like to share?

Permission

A tree doesn’t ask for permission to grow.  It just does it.

The same can (and ideally should) be said of doing what needs to be done.  Doing the most good and minimizing harm; that’s the hallmark of work that needs no permission.

Doing what we need to do for ourselves requires no permission, no leave need be begged-for.  If we can’t reconize the deepest needs in our hearts, then maybe we’re not looking hard enough–or we’re in denial.

Stop asking for permission to do what you know to be right.  Just start doing it.  We’ll thank you for it later.

Why?

Lead with it.  It might seem inscrutible, impossible to comprehend the reasons why depending upon what subject is being queried.  But the impossibility of starting with it begs the question itself: why not start with “why”?

Take, for example, an engineer.  Brilliant, but utterly fearful and ineffective at communicating.  Why?

Perhaps that very same brilliant engineer might have been smothered or abused early in their life.  An educator or authority figure might have told them they’d never be able to communicate well.  A parent who could never be placated or pleased tore them down at every turn.  Maybe that’s why.

Maybe moves us closer.  Why gives us an opening to insert insight, perspective, and empathy into the discourse.

When we’re confronted by difficult choices, disagreement, or discontent, we have the agency to ask the magic question.  It’s up to us to dig deeper.

So, why not?

Unconventional

The word “unconventional”, when used in the pejorative, reveals more about the user of the word than the subject itself.

A lack of imagination can inflict a tremendous amount of damage.  When we lack imagination, we tend to let fear, uncertainty, and doubt drive our decisionmaking and our responses.  We allow ourselves the luxury of remaining still in our reasoning rather than moving toward a place of understanding and growth.

Rather than dismissing something out-of-hand simply because it lies outside the bounds of convention, turn a curious eye toward a single question: “Why is this unconventional?”

Insanity is doing the same thing repeatedly and expecting a different outcome.  Maybe being more unconventional is what we really need.

You don’t need…

You don’t need anyone’s permission.

You don’t need anyone’s “final answer”.

You don’t need anyone’s approval.

You don’t need anyone’s negativity.

You don’t need anyone’s doubt.

You don’t need anyone’s fear.

Now that you know what you don’t need, what do you really need to do the work?  I’d bet the list is a lot smaller than you’d think and found more readily than you want to admit.

There’s more how-tos, tutorials, instructional videos, raw materials, and collaboration available to the average person than at any other previous point in human history.

So what are you waiting for?  What do you need?

Mental Health & The “Technology Industry”

My relationship with the “technology industry” has been contentious in many ways.  I’ve been diagnosed with and am currently undergoing treatment for PTSD, struggled with depression, and have intermittently contemplated suicide.  Constantly fighting with myself, battling Impostor Syndrome, and pushing back against my own unrealistic expectations of things is as exhausting as you might imagine.

“The industry” has talked at-length in recent years about figuring out ways to reduce or eliminate burnout, and it’s been helpful as far as exposure is concerned.  What hasn’t improved is the actual effort around improving things.  Organizations can talk all day about giving people more breaks, encouraging contributors to take more vacation time, refer them to specialists, and add more “perks” like nap rooms, alcohol, spaces and activities to socialize, but addressing the root of the problem requires getting into the sharp, thorny thickets of human emotion and understanding the human costs of doing business–a subject that few organizations seem interested or able to engage in.

I had a recent conversation with someone that travels in the same circles that I do in the New England technology industry after they posted an article about an Uber engineer that recently committed suicide due to work-related stress.  I took great pains to point out to them that the tech industry does a great job of increasing visibility–but that’s generally where the effort stops.

Let me be clear: visibility does not solve problems.  People solve problems.  Engineering problems, people problems, organizational problems, global problems.

Just because you know someone is close to burnout doesn’t mean that their situation is magically going to improve.  It requires communication.  It requires an immense amount of trust.  Effective communication and trust require vulnerability.  Vulnerability veers into territory that most organizations, whether explicitly or implicitly, generally steer individuals away from.  While organizations might make “diversity” and “inclusivity” core pieces of their mission statements, the actual work that ends-up going M.I.A. is the actual skills around having difficult conversations and how to provide support for each other.

In my own experience, the organizations I’ve worked for have actively avoided all of these conversations and haven’t built a reasonable framework for disclosure or discussion.  A significant number of the experiences I’ve had so far basically boil-down to some variation of the phrase “don’t let it become a problem”, implying that not only do the organizations not care, but that there are also potential consequences if the individual “can’t keep a lid on it”.

Organizations make it easy and expedient to avoid communicating with each other about the things that make work-life balance possible.  On top of that, there’s always the implication in larger or cut-throat VC-funded organizatons that the point of the business existing in the first place is (ostensibly) to make money.  “Human costs” of doing business are so poorly defined and nebulous that making them part of the overall calculus often results in nothing changing.  Unless an enterprising soul is able to tie the costs of “toil” (in the parlance of Toyota) or “unplanned work” directly to a revenue stream or cost-center, the business, to be utterly blunt, just doesn’t give a damn.

“That’s what we hire you for!  You do work, we pay you.  End of story.”

All things being equal, it’s been implicit rather than explicit that there’s a core belief in every tech organization: “if you can’t hack it, you have no place here”.  Which further implies that there isn’t support availble internally for problem solving, training, or even simply to “check something out with someone”.  I’ve completely lost count of how many times I’ve wanted to walk over to a Product Manager or an Executive and ask them why de-prioritizing a change to reduce toil was a good idea.  Or how the calculus of employee churn compares against expected costs in a given group or department (hint: it doesn’t).

How do you re-engage an employee who’s lost in their own head?  How do organizations make it okay for someone to have feelings and work on their problems while still providing value as a contributor?  How do we provide real culture in organizations rather than cheerleading sessions and frivolous, alcohol-laden socialization?

We need to create connection.  We do that by helping everyone to understand their inherent value and to really appreciate their contributions, no matter the size.  When we are able to help connect people together and help them realize that the code or the product is just a MacGuffin for connecting people together in pursuit of something greater.  Whether that’s self improvement or improvement of a product or the world writ-large, that’s what we really need.

What are the costs of an employee burning out and leaving?  What is the impact of constant, interrupt-driven events on engineering teams?  What, if anything, can help drive more meaningful interactions between individuals and teams to help take emotional risk from lethal to livable?  How can we take suffering, whether silent or not, out of the picture and instead figure out how to uncover an individual’s “joie de vivre”?

We could start by inculcating a culture of “acceptance”.  Rather than telling or implying to someone “shape-up or ship-out”, we can make room for them.  Ask them what’s going on.  Talking about our personal lives at work is only problematic when the organization makes it a problem.  When fear overrides our common and innate ability to empathize.

To reiterate: businesses don’t like risk or liability.  Personal lives are rife with situations that organizations, whether out of risk-avoidance or cowardice, tend to want to avoid any discussion or mention of.  Human life is exceptionally complicated, with some being more complicated than others.  If we’re not able to talk about what is creating disharmony in our lives, whether it’s personal or professional, like actual adults, then we’re missing the point of working together in the first place.

We could continue progressing through improving communication.  Telling someone that their decisions are creating an unfair burden or that they felt as though they couldn’t speak-up is key to improving the working life of anyone in technology.  Being able to talk openly and honestly about the causes of their stress, whether it’s too much work, feelings of powerlessness or uselessness, or a lack of improvement, being able to respond to and mean what you say goes a long way.  Being able to say “I can see where you’re coming from”, “I didn’t know this was a problem”, “I’m sorry things aren’t going well”, or “I want to help you, tell me how I can help” can help many people in very meaningful ways.

Lastly, we need to start building a culture of “work to live” versus “live to work”.  The technology sector lionizes the hard-drinking, quick-developing, move-fast-and-break-stuff, up-til-3am-saving-this-client’s-butt type of employee, but does little to really incentivize or provide meaningful feedback for people who contribute in a more healthy way.  If the technology industry were serious about work-life balance, there’d be less emphasis on balance-sheets, PNLs, and work-hard-play-hard engineering culture, and instead would make work-life balance their core, internal mission.  Unofficially, where I work currently likes to play with the phrase “No Capes”, but we’re still a long way off from making it a reality.

The technology industry needs to more clearly understand that there is more to be done.  It’s not enough to simply acknowledge it and move on.  It’s not enough.  Organizations need to implicitly, and intimately, understand the impact of work-related stress as it relates to mental health and the health of the broader organization.  Where organizations seem to fail most is making it safe to even start the process–so I encourage you to bypass the organization entirely.

Start with your peers.  You know at least one who probably has a lower threshold for frustration or someone who’s probably having a tough time with things.  If you really care about them, ask them how they’re doing.  They just might surprise you and tell you that they need help with someone that you’re good at or have experience with.

You probably then want to start thinking about your group or your organization.  How can you do better to support people that might be suffering in silence?  How can the group or the organization make it easier for people to get help and to sound the alarm when they’re overwhelmed?

Finally, what can the organization or the business do to make their operations more sustainable?  Are the human costs of technical debt or procedural gaps justified when the quality of life for employees is compromised?  I’d argue that no cost is too high in maintaining a high quality of life for any employee, regardless of position or function.  But the important part is starting the discussion.

We can all do more to help improve the lives of our peers, our friends, our coworkers, our communities, and our loved ones.  If we can at least start the conversation, then we might just be able to improve the lives of the ones who need help the most, but might not have the voice or the words to ask for it themselves.