The DevOps Skills That Matter

What skill set is desirable for an engineer in a DevOps organization? Let’s take a look. Surveying DevOps job posts, you need to be intimately familiar with dozens of technologies you’d never use in a non-production setting. Reading articles on devops.com, you need to be able to write 1,500 words without really saying anything at all. Attending DevOpsDays conferences or DevOps meetups, you need to have a finely-tuned sense of empathy. So many things, what should you focus on?

In this post I’m going to talk about the top three DevOps skills I’ve seen to be most important for engineers, in no particular order.

Code

There was some controversy over this when DevOps first became a #TrendingTopic, but I think we’ve settled it now: If you’re an engineer in a DevOps organization you need to be able to deliver solutions as code. It doesn’t matter if you’re dev, ops, QA, DBA, security, data analytics, etc - the stability that comes from modeling our systems in code far outweighs any complexity introduced.

Note that I said ‘deliver solutions as code’, not just 'write code’. Meeting the 'definition of done’ is one of the concepts that teams pay lip-service to but don’t often actually implement. See also: postmortems, continuous integration, data-driven decision-making. The definition of done for a piece of code is not 'pushed to Github’, it’s 'delivering value to customers’. Customers include internal stakeholders.

Websites that teach you to code often miss this point. The artifact you produce to move on to your next lesson is a class or function that passes the tests that they’ve written. People take a 'Learn Ruby’ course and are discouraged when no one will hire them to write Chef cookbooks for production systems. To be clear, I’m not saying you can’t learn to code online. Just be aware that, as an engineer, writing code is a subset of your value to an organization. I’ll cover this more in a future post.

Empathy

When we talk about empathy in DevOps, we’re actually talking about experience-based empathy. Uninformed empathy can be devastating. You often see this when engineers escalate problems. An example:

Harry (dev) is unhappy with with a code review he received from Kate (ops). His code works fine and he thinks Kate is just being pedantic. So Harry comes to Wes (dev manager) about the conflict. Wes looks it over and sends out an email saying that, from now on, ops code reviews will be done only before a full release. Ops is slowing the dev process down.

Continuous delivery destroyed.

If you’re thinking to yourself “This would never happen”, it happens all the time. It’s happening right now at a company near you. This is localized empathy. Wes has plenty of empathy, sure, but only for his team. He doesn’t understand the ops domain well enough to make a good decision. That’s understandable. But he didn’t take the time to listen to the other party (ops). That’s negligent, the result of localized empathy.

This is why CAMS is not CAM. Sharing information, which often just means listening, is a key practice to foster experience-based empathy. Hone your active listening skills and vote with your feet if you’re in an organization that doesn’t value them.

Communication

hard_engineering_problems = [
    'naming things',
    'cache invalidation'
]
hard_engineering_problems.append('communicating effectively')

Smart people aren’t immune to overconfidence. Engineers are smart people. But do we plan our conversations? No, not really. If I need something from someone, I’ll just go talk to them. It’s obvious what I need and why I need it. They would be dense not to give me what I need.

<conversation>
So I need...
...Let me explain it another way...
...I didn't know about that...
...Fine, but this is a mistake.
</conversation>

Sound familiar? Yeah.

Planning your communication is a vital skill as an engineer. Whether you’re going into a sprint planning, one-on-one with your manager, or asking someone from another team for help, preparation is key. This is especially important for the difficult conversations that often come up when moving to DevOps.

At a minimum, you should know what you want to get out of a conversation before having it. These are your goals. Write them down. This is especially helpful for questions you need answers to. It’s too easy to get sidetracked and come out of a meeting with your questions unanswered. Think about the concessions you are prepared to make and write them down too. Bring your notes to the meeting. Use pen and paper, a laptop is distracting.

Here’s the thing: if you’re not doing this you are putting yourself at a disadvantage. Odds are you are coming into a conversation less-prepared that the other party. If their goals conflict with yours, you have very little chance of getting what you need. Effective communication is about preparation. Preparation beats being clever.

Thanks for reading! I hope this was helpful.

Later this month I’ll have a guest post on the topic of effective communication by Howard Perlstein, a friend with more than 20 years of experience helping organizations improve communication and embrace change.