The comparison of a software delivery team to a football team (all can kick the ball but only some will become an excellent goalkeeper or a forward) can be a nice input for further thought regarding division of labour and specialists vs. generalists.

So, it seems more to me than just "you should never try to hire a DevOps team" - because if you hire "a football team" you do not just want "somebody kick the ball in the FIFA World Cup", but you possibly want to have an idea what makes the team having chances to win.

So, winning teams can be a product themselves (can't find the reference for that but there are enough startup acquisions, I'm sure it is not always just about the product) - what is the recipe for success? For sure there is a lot of soft skills/cultural related context, but this would be true for virtually every team.

What are mandatory DevOps specific requirements to skill sets for a winning team setup? Will be there a relationship between numbers of CI/CD experts and those who focus on development, or operations?

Note: this question is not a duplicate of "why you shouldn't try to hire a DevOps Engineer" as a specific question is after required skills setup. E.g. would you have a CI-focused profile or expect developers to include pipelines as code to their projects? Clearly, just hiring somebody with the DevOps claim does not answer this question.

  • Related: devops.stackexchange.com/questions/2703/… Commented Nov 27, 2017 at 18:06
  • Possible duplicate of Why shouldn't I try to hire a 'DevOps Engineer'?
    – 030
    Commented Nov 27, 2017 at 23:26
  • DevOps is not a team or a skill - it's an organisational structure, and an understanding that everyone's on call now.
    – Gaius
    Commented Nov 30, 2017 at 20:18
  • Exactly, I think this question should be asked rather on what should be the organizational structure of a team taking advantage of the DevOps culture and values and how to build such team, rather than simply what is the composition. After all, coal and diamonds are both just made of carbon, the structure makes a difference. Commented Dec 5, 2017 at 20:41

5 Answers 5


I believe DevOps is orthogonal to your question, i.e., it changes nothing compared to a "classical" approach (or to hiring any team at all, not only for software development). You identify what your key needs are (for example, an "architect" who is able to structure large software systems; some "hacker" who is able to fix a Kernel driver if needed; a "tester" who likes to test and such; and finally maybe a "DevOps engineer" who excels in creating good CI/CD tooling).

But all of them need, to stay with your image, to be able to kick the ball. I.e., they all need to work together in the context that the team is working in. They all need at least some basic understanding of what the other team members are doing; if you have a strict CI/CD pipeline, then they all need to be able to develop in that frame; and so on.

  • This answer does not talk about the way how to structure the team. Yes, all might be needed, but how do you connect people together? Organization building is like system engineering. It has its clear rules and the DevOps culture and values have a lot to say about those rules. One such example is the Conway law. Commented Dec 5, 2017 at 20:27
  • I believe I comment on that, @JiriKlouda. Ideally, everybody on the team has an understanding of what the DevOps-related techniques mean; in the same way as every, say, programmer has to know the programming language in use. There will be buffs and newbies as usual, but you need a broad knowledge. I don't see where I could have more to add - the question is not "what's the greatest DevOps team structure", but "recipe for hiring a winning ... team". Recipe as per the answer is to hire a good mix, which will likely be different depending on circumstances.
    – AnoE
    Commented Dec 5, 2017 at 22:39
  • Team without structure is just a disorganized collection of people. Commented Dec 6, 2017 at 0:09
  • Ok @JiriKlouda, I don't understand you - you are surely correct, but I didn't write anything about team structure. The OP is about hiring a team and my answer says that hiring a team is not much different whether you subscribe to DevOps or not.
    – AnoE
    Commented Dec 6, 2017 at 7:48
  • And I simply state you are, in my opinion, wrong in this point and that is the reason I have downvoted your answer and commented to give you opportunity to amend it :) Commented Dec 6, 2017 at 8:45

Since DevOps is a hot trend in IT, companies are seeking top-notch DevOps talent. However, before you begin assembling your team, there are a few things you should consider:

  1. What kind of DevOps?

Imagine a rock band is searching for a new guitarist. There are lots of people who know how to play the guitar, but there are so many music styles that can be played on the guitar, plus there is also another important factor, which is how well this guitarist gets along with the rest of the band.

When you are searching for candidates, imagine asking an IT guy if he plays DevOps. There are so many successful manifestations of DevOps teams that you need to understand it in the context of the business that they support, because, ultimately, this is the value of DevOps. The customers expect a certain pace and DevOps is the only way to deliver at that pace.

  1. Emphasize culture over tools and roles

When you get down to it, DevOps is all about culture. If you take a group of IT engineers and traditional developers who understand and embrace the DevOps culture you can build a successful team. However, if you hire so-called DevOps experts, who know Puppet, Chef and Docker inside and out, but do not accept and adapt to the collaborative and cooperative nature of DevOps, this team is doomed to fail.

  1. Be careful of how you word the job description

What happens a lot of times is that companies throw in a bunch of buzzwords and tool names and expect to find the right person for the job. Do not dismiss perfectly good candidates just because they do not call themselves “DevOps experts.” More importantly, pay particularly close attention to the personnel you already have. With your leadership skills, the talent you already have can be quite successful at DevOps.

  • This is honestly the most under rated answer here.
    – Matt O.
    Commented Dec 26, 2017 at 21:44
  • What happens a lot of times is that companies throw in a bunch of buzzwords and tool names - To extend these thoughts, also don't be afraid to apply for a job just because it uses tools you are unfamiliar with. Good bands will often change genres and good musicians will often pick up new instruments. Commented Jan 2, 2018 at 17:44

DevOps is a "team" of people that includes the development and operations teams. (security/compliance combined).

You shouldn't think about the devops "team" as a separate entity but part of the larger organization. Checkout http://web.devopstopologies.com/ for organizational structure. You can see it's about moving together.


I'm currently extending my DevOps team, without forgetting skills, for me, the most important thing is the "mindset". Amazingly, not a lot of people around with the right mindset of continuous improvement.

  • keen to know what does IoP do with DevOps
    – Ta Mu
    Commented Dec 5, 2017 at 13:49
  • I started 3 months ago here, for us the 1st tasks will be about improving our infrastructure to make us faster from idea to live products/services. An agency was brought onto the scene to deliver digital products and services, 2018 will see us being an hybrid solution, aiming to have it full in house in 2019. Commented Dec 5, 2017 at 14:09

I tend to agree with AnoE's answer. Getting the people and giving them the vision are primordial before DevOps should be put in the picture. I would also like to add two more things on top of that. The additions come from the experience with a team that got excited about "DevOps".

You already have the definition in mind, but I'd like to bring Wiki's:

DevOps (a clipped compound of "development" and "operations") is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

In short:

  • You want to build a team of developers, testers and operators
  • Enforce short development cycles
  • Enforce shorter deployment cycles
  • Automate the above processes
  • Due to the agility of the process, enforce monitoring and alerts at all stage of development (e.g. test, qa, production)
  • You need a set of tools that will increase efficiency accross every stage (i.e. Jenkins, Jira, Gerrit, etc.)

With these in mind, I can now bring the points previously mentioned at the beginning.

Failing is good

A baby doesn't learn to walk by standing up and walking. He learns through constant tries and failures. Even if, for an unknown reason, he gets up and starts walking, we shouldn't expect our babies to achieve the same. I usually point that out when people compare themselves to Google, Amazon or any other company with great achievements. Their failures thought them how to get stronger more than ingenious ideas all the time. Right now for example I am improving my english through constant writing and failure to make my points clearer and clearer.

Failures will indicate your football team where improvement is required. These weaknesses will vary from a team to another. It might be in tooling, leadership, lack of vision, roadmap pressure, lack of experience, etc. No matter the reason, it is primordial that you take time to review each development cycle with everyone. Otherwise, you might enter the stage below, which is hell to come back from.

Always failing is not good

Something was wrong. Then something kept being wrong and that something got culturally accepted even though it is slowing down the team. Skipping failing tests, non automated provisionning management, deploying with crossed fingers are among few I had the chance to experience. These are triggers that indicates improvements are required. Failing to notice them can bring you to a hellish state where coming back will require a Genesis project.

My answer is basically, go ahead for all the pros. But be aware that this sort of process will require culture and team monitoring in the sense that when things start getting bad, your team must learn from it or it will die from it.

  • I largely disagree with this answer because of this, "You want to build a team of developers, testers and operators". People who DevOps enablers, or embeds, are usually supposed to be skilled across the board, which I think is what OP is trying to get at. Usually they're people from a SWE or SE background that know how to code and are looking to build a culture of self-service and empowerment within dev teams. What you described is a Scrum Team.
    – Matt O.
    Commented Dec 26, 2017 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.