Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-05T20:27:49.793Z
Answers: 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.
Answers: Jiri Klouda
Answers: CC BY-SA 3.0
Answers: 2017-12-05T22:39:56.877Z
Answers: 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.
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2017-12-06T00:09:45.340Z
Answers: Team without structure is just a disorganized collection of people.
Answers: Jiri Klouda
Answers: CC BY-SA 3.0
Answers: 2017-12-06T07:48:01.057Z
Answers: 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.
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2017-12-06T08:45:48.517Z
Answers: 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 :)
Answers: Jiri Klouda
Answers: CC BY-SA 3.0
Answers: 2017-12-06T10:30:21.300Z
Answers: Fair enough, @JiriKlouda. ;)
Answers: AnoE
Answers: CC BY-SA 3.0
Answers: 2017-11-27T19:58:40.853Z
Answers: 2017-11-27T19:58:40.853Z
Answers: AnoE
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-26T21:44:46.450Z
Answers: This is honestly the most under rated answer here.
Answers: Matt O.
Answers: CC BY-SA 3.0
Answers: 2018-01-02T17:44:29.027Z
Answers: `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.
Answers: James Shewey
Answers: CC BY-SA 3.0
Answers: 2017-12-26T09:22:21.857Z
Answers: 2017-12-26T09:22:21.857Z
Answers: DevOps Jedi
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-05T13:49:43.593Z
Answers: keen to know what does IoP do with DevOps
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-12-05T14:09:13.603Z
Answers: 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.
Answers: Morgan Martins
Answers: CC BY-SA 3.0
Answers: 2017-12-05T13:22:40.387Z
Answers: 2017-12-05T13:22:40.387Z
Answers: Morgan Martins
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-30T19:11:48.203Z
Answers: 2017-11-30T19:11:48.203Z
Answers: Jeff Garrett
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-26T21:44:00.777Z
Answers: 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.
Answers: Matt O.
Answers: CC BY-SA 3.0
Answers: 2017-12-02T20:28:00.490Z
Answers: 2017-12-02T20:28:00.490Z
Answers: gmolaire
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-11-27T18:06:59.390Z
Comments: Related: https://devops.stackexchange.com/questions/2703/are-ci-and-cd-devops-team-tasks-or-are-these-separate-professions
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2017-11-27T23:26:33.107Z
Comments: 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)
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-11-30T20:18:31.153Z
Comments: DevOps is not a team or a skill - it's an organisational structure, and an understanding that *everyone's on call now*.
Comments: Gaius
Comments: CC BY-SA 3.0
Comments: 2017-12-05T20:41:09.643Z
Comments: 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.
Comments: Jiri Klouda
Tags: <team-role><human-resources>
Title: Recipe for hiring a winning DevOps empowered team?
UserDisplayName: Ta Mu
ThreadText: # 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://username_6.stackexchange.com/questions/2703/are-ci-and-cd-username_6-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://username_6.stackexchange.com/questions/2590/adam-smith-vs-fullstack-developers-and-productivity-in-username_6).
  
  So, it seems more to me than just "[you should never try to hire a username_6 team](https://username_6.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-username_6-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* username_6 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 username_6 Engineer](https://username_6.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-username_6-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 username_6 claim does not answer this question.
  
  **Tags:** team-role, human-resources
  
  > **Comments:**
  > **username_1**: Related: https://username_6.stackexchange.com/questions/2703/are-ci-and-cd-username_6-team-tasks-or-are-these-separate-professions  
  > **username_2**: Possible duplicate of [Why shouldn't I try to hire a 'username_6 Engineer'?](https://username_6.stackexchange.com/questions/797/why-shouldnt-i-try-to-hire-a-username_6-engineer)  
  > **username_3**: username_6 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 username_6 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 username_6 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 "username_6 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 username_6 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, @username_4. Ideally, everybody on the team has an understanding of what the username_6-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 username_6 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 @username_4, 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 username_6 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, @username_4. ;)  
  
  ---
  
  ### Answer by username_6 on 2017-12-26. Score: 3
  
  Since username_6 is a hot trend in IT, companies are seeking top-notch username_6 talent. However, before you begin assembling your team, there are a few things you should consider:
  
  1. What kind of username_6?
  
  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 username_6. There are so many successful manifestations of username_6 teams that you need to understand it in the context of the business that they support, because, ultimately, this is the value of username_6. The customers expect a certain pace and username_6 is the only way to deliver at that pace.
  
  2. Emphasize culture over tools and roles
  
  When you get down to it, [username_6](http://squadex.com) is all about culture. If you take a group of IT engineers and traditional developers who understand and embrace the username_6 culture you can build a successful team. However, if you hire so-called username_6 experts, who know Puppet, Chef and Docker inside and out, but do not accept and adapt to the collaborative and cooperative nature of username_6, 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 “username_6 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 username_6.
  
  > **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 username_6 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 username_6  
  > **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
  
  username_6 is a "team" of people that includes the development and operations teams. (security/compliance combined).
  
  You shouldn't think about the username_6 "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 username_6 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 "username_6".
  
  You already have the definition in mind, but I'd like to bring Wiki's:
  
  > username_6 (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 username_6 movement is to strongly advocate **automation and monitoring** at **all steps** of software construction, from integration, testing, releasing to deployment and infrastructure management. username_6 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 username_6 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.  
  
  ---
  
  