DevOps (“development” meets “operations”) is still an evolving field. Asked for a definition, even some in other technical roles might struggle to pin it down. The best way to think of it, though, is less as a specific collection of skills necessary for a specific role, and more as a culture or philosophy about how to develop software.
The core creed of DevOps revolves around the idea that inter-departmental collaboration, communication, and constant improvement are the keys to a successful and efficient software development cycle. Teams of DevOps engineers or managers, then, are simply engineers and managers who combine their role-specific skills with DevOps best practices.
However, working on a DevOps team is not for everyone. Engineers who prefer long stints of working alone may be frustrated by the constant feedback exchanges. It takes a specific type of person to succeed in one of these positions. These seven attributes will serve you well in a future DevOps role.
Since DevOps is such a constantly evolving field, the ability and motivation to teach yourself new skills are critical. Anant Agarwal, CEO of edX, says, “It’s hard to learn something that seems to evolve as quickly as the lessons are taught. Self-learners are the perfect candidates for embracing and pursuing DevOps adoption, as it requires a roll-up-your-sleeves, trial-and-error, do-it-yourself, continuous learning approach.”
Lisa Phillips, VP of Site Reliability Engineering at Fastly, adds, “Being a DevOps professional means knowing 1,000 things pretty well, not being a specialist in just one. To be successful, you have to be open and willing to learn every step of the way, and re-learn things that have proven to be wrong (or become wrong over time).”
DevOps, by its very nature, sees all the different technical teams in an office as part of a unified whole. Agarwal notes, “DevOps combines both development and operations, and therefore it’s imperative that all team members are able to adopt a team-first mindset.”
Omri Gazitt, Chief Product Officer at Puppet, emphasizes that the best DevOps professionals will always be thinking about how they can help the team. “Any problem is everyone’s problem, and a great engineer always makes those around them better.”
“Long gone are the days of the grumpy cave-dwelling Ops persona,” says Ben Porterfield, co-founder and VP of Engineering at Looker. “DevOps folks need to be able to work with the entire engineering department, with a product, and often with a host of other departments that use internal tools. DevOps engineers regularly communicate with people of all levels of technical background and need to be able to adjust their communication level to make sure there is understanding.”
Agarwal notes that communication goes hand-in-hand with collaboration. “Communication is key to effective collaboration. Setbacks and successes, as well as what the team learns each step of the way, must be transparently and immediately communicated across the entire organization. Also, the big-picture end-goal of a DevOps adoption needs to be clearly communicated across the organization — from even before day one.”
Another core tenet of DevOps is continuous improvement–which sometimes means pivoting quickly to another strategy if the first one is unsuccessful.
“Working in such a fast-moving area of IT demands a lot of work and trial-and-error,” says Agarwal. “DevOps demands new ways of critical thinking and skillsets that are not ingrained in the standard day-to-day responsibilities of business professionals.”
It was noted earlier that DevOps requires being familiar with many skills and knowledge sets rather than narrowing your focus to one. That goes hand-in-hand with being able to “zoom out” and see how it all interconnects.
Gazitt agrees: “DevOps requires a generalist mindset. Specialized skills are important, but it’s even more important to be able to understand and assist in removing bottlenecks in the overall system. By caring about the outcome as opposed to merely their part in the overall ‘supply chain,’ they will have the right instincts around how to best optimize for end-to-end success. “
Greg Warden, VP of Engineering at DigitalOcean, has a specific name for DevOps professionals with this talent. “I think it’s important for people working in DevOps to be good ‘systems thinkers.’ By that I mean you need to be able to think in terms of dependencies, and potential failure modes. You have to understand who might be impacted by any changes to the system or application you are working on, and how your system might be impacted by changes or failures in another person’s system or infrastructure. It is also important to understand the resources your systems use, and how those change as your system scales over time.”
When so many different things require your attention, it is crucial to be able to sort out the immediate-priority tasks vs. those that can wait a little longer. Eli Flesher, Engineering Manager at Lyft, says, “The ability to prioritise is extremely important in DevOps. There is an ongoing tension between developing for the future and operating what’s right in front of you. Some of the best DevOps people I’ve seen have the ability to stay focused on the broader goal of operations and the things they need to build for the future, while also prioritising the timely, more short-term pressing tasks at hand.”
Finally, when you’re working so closely with other people, it’s inevitable: mistakes will be made. There will be delays. Things won’t go as planned the first time around. If you can take it all in stride and be understanding, you’ll help create an environment where people work together to move past those setbacks rather than pointing fingers.
Phillipps notes, “Things will break–failure is part of the game and blaming others never helps. A strong DevOps professional will put him/herself in the shoes of her team members and act accordingly.”
Also – take a look at 3 Steps to Prepare your Organisation for DevOps
Neil ran his first SAP transformation programme in his early twenties. He spent the next 16 years working both client side and for various consultancies running numerous SAP programmes. After successfully completing over 15 full lifecycles he took a senior leadership/board position and his work moved onto creating the same success for others.