“Do we need a DevOps team?” – this question I hear constantly from many organizations. DevOps is on the peak of the hype that was previously taken by Agile.

The answer is: Absolutely and unequivocally NO! Should you create a Tooling and Automation team? – may be.

DevOps is a culture and not a specialization. If you create a team that is in charge of DevOps, you’re going to get yet another silo. This culture is not going to propagate outside of the boundaries of so-called DevOps teams.

“So what should we do? How do we get started?” – you may ask. The answer will depend on a set of factors and, primarily on the size of your organization.

If you’re a start-up with 4-5 developers that are co-located in a single room, you’re going to make a grave mistake to split DevOps function. You’ll have a person/people with a specialized knowledge. They are going to become the bottle necks for that function. In a small organization creation of functions and specializations should be done deliberately and thought through carefully. Should you invest time in improving and simplifying your existing build and delivery process – absolutely. Should you assign one of the guys to concentrate on the work to speed it up – sure. Should these guys stay in “DevOps” capacity – absolutely not! Spread this knowledge across the team and assume shared ownership of the process. This what will start the real DevOps culture in your team.

If you’re a large organization 15-20 developers and more, the communication channels slowing down. It takes a while for the knowledge to propagate. The sprawl of decisions and directions is increasing. In this case you’d like to have a person that will be a lead for the function, the person that can guide the direction of the evolution for the Tools and Automation. The person that can provide a good vision for the direction and translate it into tactical steps.

The centralized coordination for the direction and decisions is not necessary, but can drastically help to reduce the waste. You should encourage a healthy experimentation with the ideas, but disorganized sprawl of tools and approaches will lead to a lot of wasted time and energy. Your organization will receive a hudge-pudge of tools and scripts that are not going to work well together, there will be no cohesion and this will not benefit the stability of the end-to-end delivery of the automated processes.

And, if the pipelines are not stable, if the tool set is not reliable, your organization will be hesitant to use the defined process. The trust will start to corrode until it totally disappears. Your team members will start avoiding the process you’ve invested in and will start looking for the alternatives. This will spike the sprawl of tooling and approaches and will feed the “shadow IT”.

The delivery process should not only be stable and rock-solid, but simple to use and fast (relative to your organization). If the process is slow and clunky, requiring 100 steps and configurations, manual steps and approvals, the members of your teams will become hesitant to adopt it, will start skipping steps and finding their way around it. This, in its own, will start to corrode the trust in the process until the trust totally disappears.

Bottom line, make the decision that works best for the size of your team and the organization, but, please, do not create yet another DevOps silo – it’ll not help you in the log run and will create distaste in the DevOps culture message.