<p>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). </p>

<p>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.</p>

CC BY-SA 3.0
2017-12-05T20:27:49.793Z
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.
Jiri Klouda
CC BY-SA 3.0
2017-12-05T22:39:56.877Z
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
CC BY-SA 3.0
2017-12-06T00:09:45.340Z
Team without structure is just a disorganized collection of people.
Jiri Klouda
CC BY-SA 3.0
2017-12-06T07:48:01.057Z
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
CC BY-SA 3.0
2017-12-06T08:45:48.517Z
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 :)
Jiri Klouda
CC BY-SA 3.0
2017-12-06T10:30:21.300Z
Fair enough, @JiriKlouda. ;)
AnoE
CC BY-SA 3.0
2017-11-27T19:58:40.853Z
2017-11-27T19:58:40.853Z
AnoE
<p>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:</p>

<ol>
<li>What kind of DevOps? </li>
</ol>

<p>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. </p>

<p>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. </p>

<ol start="2">
<li>Emphasize culture over tools and roles</li>
</ol>

<p>When you get down to it, <a href="http://squadex.com" rel="nofollow noreferrer">DevOps</a> 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. </p>

<ol start="3">
<li>Be careful of how you word the job description</li>
</ol>

<p>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. </p>

CC BY-SA 3.0
2017-12-26T21:44:46.450Z
This is honestly the most under rated answer here.
Matt O.
CC BY-SA 3.0
2018-01-02T17:44:29.027Z
`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.
James Shewey
CC BY-SA 3.0
2017-12-26T09:22:21.857Z
2017-12-26T09:22:21.857Z
DevOps Jedi
<p>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. </p>

CC BY-SA 3.0
2017-12-05T13:49:43.593Z
keen to know what does IoP do with DevOps
Ta Mu
CC BY-SA 3.0
2017-12-05T14:09:13.603Z
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.
Morgan Martins
CC BY-SA 3.0
2017-12-05T13:22:40.387Z
2017-12-05T13:22:40.387Z
Morgan Martins
<p>DevOps is a "team" of people that includes the development and operations teams.  (security/compliance combined). </p>

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

CC BY-SA 3.0
2017-11-30T19:11:48.203Z
2017-11-30T19:11:48.203Z
Jeff Garrett
<p>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".</p>

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

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

<p>In short:</p>

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

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

<p><strong>Failing is good</strong></p>

<p>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.</p>

<p>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 <strong>primordial</strong> 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.</p>

<p><strong>Always failing is not good</strong></p>

<p>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, <strong><em>deploying with crossed fingers</em></strong> 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.</p>

<p>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 <strong><em>team must</em></strong> learn from it or it <strong><em>will die</em></strong> from it.</p>

CC BY-SA 3.0
2017-12-26T21:44:00.777Z
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.
CC BY-SA 3.0
2017-12-02T20:28:00.490Z
2017-12-02T20:28:00.490Z
gmolaire
<p>The <a href="https://devops.stackexchange.com/questions/2703/are-ci-and-cd-devops-team-tasks-or-are-these-separate-professions">comparison of a software delivery team to a football team</a> (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 <a href="https://devops.stackexchange.com/questions/2590/adam-smith-vs-fullstack-developers-and-productivity-in-devops">division of labour and specialists vs. generalists</a>.</p>

<p>So, it seems more to me than just "<a href="https://devops.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-devops-engineer">you should never try to hire a DevOps team</a>" - 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.</p>

<p>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. </p>

<p>What are <em>mandatory</em> 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? </p>

<p>Note: this question is not a duplicate of  "<a href="https://devops.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-devops-engineer">why you shouldn't try to hire a DevOps Engineer</a>" 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. </p>

CC BY-SA 3.0
2017-11-27T18:06:59.390Z
Related: https://devops.stackexchange.com/questions/2703/are-ci-and-cd-devops-team-tasks-or-are-these-separate-professions
Dan Cornilescu
CC BY-SA 3.0
2017-11-27T23:26:33.107Z
Possible duplicate of [Why shouldn't I try to hire a 'DevOps Engineer'?](https://devops.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-devops-engineer)
030
CC BY-SA 3.0
2017-11-30T20:18:31.153Z
DevOps is not a team or a skill - it's an organisational structure, and an understanding that *everyone's on call now*.
Gaius
CC BY-SA 3.0
2017-12-05T20:41:09.643Z
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.
Jiri Klouda
<team-role><human-resources>
Recipe for hiring a winning DevOps empowered team?
Ta Mu
# Recipe for hiring a winning DevOps empowered team?

(Asked by: username_0 on 2017-11-27)

The [comparison of a software delivery team to a football team](https://devops.stackexchange.com/questions/2703/are-ci-and-cd-devops-team-tasks-or-are-these-separate-professions) (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](https://devops.stackexchange.com/questions/2590/adam-smith-vs-fullstack-developers-and-productivity-in-devops).

So, it seems more to me than just "[you should never try to hire a DevOps team](https://devops.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-devops-engineer)" - 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](https://devops.stackexchange.com/questions/797/why-shouldnt-i-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.

**Tags:** team-role, human-resources

> **Comments:**
> **username_1**: Related: https://devops.stackexchange.com/questions/2703/are-ci-and-cd-devops-team-tasks-or-are-these-separate-professions  
> **username_2**: Possible duplicate of [Why shouldn't I try to hire a 'DevOps Engineer'?](https://devops.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-devops-engineer)  
> **username_3**: DevOps is not a team or a skill - it's an organisational structure, and an understanding that *everyone's on call now*.  
> **username_4**: 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.  

---

## 5 answers

### Answer by username_5 on 2017-11-27. Score: 8

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.

> **Comments:**
> **username_4**: 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.  
> **username_5**: 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.  
> **username_4**: Team without structure is just a disorganized collection of people.  
> **username_5**: 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.  
> **username_4**: 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 :)  
> **username_5**: Fair enough, @JiriKlouda. ;)  

---

### Answer by username_6 on 2017-12-26. Score: 3

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.

2. Emphasize culture over tools and roles

When you get down to it, [DevOps](http://squadex.com) 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.

3. 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.

> **Comments:**
> **username_7**: This is honestly the most under rated answer here.  
> **username_8**: `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.  

---

### Answer by username_9 on 2017-12-05. Score: 1

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.

> **Comments:**
> **username_0**: keen to know what does IoP do with DevOps  
> **username_9**: 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.  

---

### Answer by username_10 on 2017-11-30. Score: 1

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.


---

### Answer by username_11 on 2017-12-02. Score: 0

I tend to agree with username_5'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.

> **Comments:**
> **username_7**: 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.  

---

