devopsy.kinsta.cloud

Tag: job titles

  • The Value of ‘DevOps Engineer’ as a Title

    The Value of ‘DevOps Engineer’ as a Title

    Now that DevOps is proliferating in the enterprise (many companies including Disney, Nike and Walmart, for example, are all on the adoption train) the term is starting to creep up more and more in job titles. This is challenging organizations to consider the significance of DevOps Engineer as a role and the value of having someone with “DevOps” in their title on their team. There are steps you can take to ensure that DevOps candidates are the right fit for your company.

    When you are looking for someone with “DevOps Engineer” as their title, you are seeking someone who not only has the skills you need to complete technical work but also embodies the DevOps values and mindset. Part of the interview process needs to get at the DevOps culture you are seeking to create. You should ensure that you ask questions such as:

    1. What’s the most important business outcome for a DevOps team to deliver?
    2. Have you been able to achieve continuous delivery on the projects that you’ve worked on?  What were the keys to ensuring that you could deliver that value to the business?
    3. What’s the most important character trait for DevOps engineers to have to make sure that the team is successful?
    4. How do you ensure that the DevOps team communicates effectively across team boundaries?
    5. What’s the most important operational requirements to ensure that you understand early in the process?

    The goal of these and other questions is to dig into a candidate’s ability to work across teams, communicate effectively and understand of the full spectrum of DevOps capabilities. Communication skills are core to what we do as a consulting and digital software engineering services firm, so we may have an easier time and more background assessing the communication skills of engineers. But, we’ve seen clients also be successful by combining their typical technical interview process with some additional behavior-based communication questions.

    It is also important to understand that being a true DevOps Engineer entails technical capabilities and there are specific tools that need to be mastered if someone claims to be an experienced DevOps Engineer. So, in addition to soft skills and values, it’s important to understand the technology and deployment environment specifics to effectively assess a candidate for such a position. There are big differences in technologies depending on what development technology (Java, Node.js, C#, React, or some combination of all those things) and what deployment environment (Azure, AWS, Google Cloud, etc.) you are working with. These differences are critical and must be understood. You should look for candidates who have experience with the tools your organization uses.

    It also can be helpful to look for someone who has skills that matches your clients’ needs or the needs of a particular project. In some cases, you may be looking for a pure AWS DevOps Engineer who will work completely in the cloud deploying Node.js applications. In other cases, you may be looking for an engineer who might be skilled with Microsoft technologies for a hybrid deployment (on some cloud, some on-prem) of a .Net core application.

    While progress is being made to try and abstract the platform differences, those technologies still require DevOps engineers have a good understanding of the underlying tools and infrastructure that will support the software.

    Bottom line: Candidates who seek DevOps positions and self-identify as DevOps Engineers are good candidates for the general set of skills you are looking for, but be sure you have solid technical evaluation in place to ensure that your hard skill requirements are also met.

    — Jonathan Fries

  • DevOps Job Titles Emerging in Enterprise IT Organizations

    DevOps Job Titles Emerging in Enterprise IT Organizations

    IT job functions and, by extension, individual titles inside the classic enterprise have been relatively constant. Various hierarchies of developers labored separately alongside IT operations teams that focused mainly on infrastructure. However, the emphasis on continuous integration and continuous development (CI/CD) within the context of a modern DevOps environment is starting to blur the lines separating who does what inside these organizations. In fact, Phil Guido, general manager of IBM Global Technology Solutions in North America, says new titles such as DevOps engineer and Scrum Master, which better reflect new roles many IT professionals taking on, now are emerging.

    At the crux of this shift is the rise of programmable infrastructure coupled with a need for IT organizations to be more agile. Instead of rolling out a few applications and associated updates a year, IT organizations today are being urged by business leaders to roll out more applications and updates at a pace associated more often with web-scale companies than the classic enterprise. Much of that demand emanates from shareholders and Wall Street to accelerate investment in digital business initiatives that generate higher-margin revenue.

    To achieve those goals, enterprise IT organizations are trying to emulate as many of the DevOps processes employed by web-scale companies. For example, web-scale companies make extensive use of CI/CD technologies and processes to roll out as many new applications as fast as they possibly can. Overseeing those processes are developers who now are accountable for not just writing but also maintaining the application. The theory is that if developers are held accountable for the quality of the application, they will focus more on making sure that application attains a level of quality. The trick is to empower those developers to own everything from the code itself to the programmatic infrastructure it runs on. Because of that requirement, many of those developers adopted a “cloud first” mentality because deploying applications on a public cloud such as Amazon Web Services (AWS) eliminated the need for those developers to engage with IT infrastructure professionals altogether.

    However, most traditional enterprise IT organizations have a much smaller number of application developers. Every minute those developers are not writing code reduces the number of applications an enterprise can roll out. Because of that issue, many enterprises have been trying to find a way for existing IT operations teams and developers to work together hand in glove.

    That requirement, Guido says, is creating a lot of demand for advice from IBM about how to manage DevOps. IBM advises organizations to go slow to ensure they have a few quick successes under their belts before propagating DevOps across the entire organization, he notes. If an organization tries to do too much or move too fast, there’s a good chance that employee resistance to change will only increase. Above all, Guido says, organizations should avoid being too prescriptive in how they define DevOps.

    Of course, not everyone agrees that changing job titles is always the best way to go about fostering change. But human nature being what it is within large organizations, some job titles will have to be reclassified to bring about permanent change.

    — Mike Vizard