<p>IMHO it's not a good idea to directly and immediately apply a team's gains from its DevOps transformation into scaling the team <strong>down</strong>. At best you'll lose just the team's motivation to do any such improvement in the future. But most likely you'll lose most/all the talent in that team.</p>

<p>Instead:</p>

<ul>
<li>allow the team to appreciate the benefits of the difficult transformation they went through, so that they spread the word to your other teams that will have to go through (or are already struggling with) the transformation</li>
<li>focus on delivering better quality products/services, faster - with the same team - this is now possible due to the transformation.</li>
<li>in many cases your business will pick up speed because of the transformation - soon you'll more likely need to hire people - IMHO it's better to use the experience of the ones you already have rather than educating new hires</li>
<li>allow voluntary attrition to work for you and get the effective downscaling down the road.</li>
</ul>

<p>But generally the DevOps transformations tend to not happen fast enough to allow for the above choices :)</p>

<p>Now onto scaling <strong>up/out</strong>.</p>

<p>Ideally the DevOps transformation should have greatly increased the predictability of your sw development and delivery process. You should be able to tell with a great degree of precision you existing team's capacity: how much sw/services of a certain quality can your current team get done in a certain amount of time. </p>

<p><strong>When</strong> you need more stuff done, or done better/faster than the current team's capacity you need to scale the team up/out. The exact details come from whatever process/methodology you use for your day-to-day activities, probably some agile variant (see also <a href="https://devops.stackexchange.com/questions/333/does-my-organization-need-adopt-agile-soft-dev-before-adopting-devops">Does my organization need adopt Agile Soft. Dev. before adopting DevOps?</a>)</p>

<p><strong>How</strong> - <em>apparently</em> easy: hire more people to handle the overflowing activities. If you're worried about how fast you can get them onboard and actually handling that overflow work at the expected rates: start hiring earlier, based on projections.</p>

<p>The reality can, however, a bit more difficult than that. Scaling a software product/service or the development process and tools supporting it is not necessarily straight-forward, even for a DevOps-empowered organisation.</p>

<p>One of my favourite examples is the weakest DevOps link <strong>when it comes to scalability</strong>: Continuous Integration. If the CI build fails there can be no Delivery/Deployment (kinda undermining the "continuous" term in the CD context).</p>

<p>Just because a certain team is happily using CI with decent results it doesn't mean the same will happen if the team size doubles. Nope, the results could be devastating - the delivery process can grind down to a halt (in extreme cases). I'm trying to explain this in <a href="https://www.apartsw.com/insights/2016/11/15/congestion_in_traditional_ci.html" rel="noreferrer">Congestion in Traditional CI Systems</a> (<strong>disclaimer:</strong> I'm the founder of the company owning the referenced page and offering a solution to this problem).</p>

<p>Another example could be, for example, the version control system (VCS) being used: as the software being stored into a repository evolves so does its change history, pushing the limits of the VCS system, sometimes beyond acceptable performance levels. Switching to a more scalable VCS system or splitting the codebase into multiple repositories could be an approach to address the problem.</p>

<p>But evolving the development processes and tooling supporting them alongside the evolution of the software products/services being delivered are fundamentally just what a mature DevOps team does. They just need to also be taken into consideration when in the team's scaling up/out strategy.</p>

<p>With that in mind, the <strong>how</strong> can be, indeed, reduced to just increasing the team size to cover the additional amount of work necessary for execution of the above-mentioned strategy.</p>

CC BY-SA 3.0
2017-11-27T19:42:23.817Z
Maybe worth noting that the expertise spectrum also changes when scaling the team size and, IMHO, should be taken into account in the `how`: https://devops.stackexchange.com/questions/2590/adam-smith-vs-fullstack-developers-and-productivity-in-devops/2607#2607
Dan Cornilescu
CC BY-SA 3.0
2017-11-27T17:58:25.463Z
2017-11-27T19:34:10.703Z
2017-11-27T19:34:10.703Z
Dan Cornilescu
<p>Given that DevOps allows IT staff actually to downscale and do more through all the automation, what are limits to that? </p>

<p>That is, what are rules of thumb - if there can be any - where you would know you need more people despite <a href="https://devops.stackexchange.com/questions/2635/from-6-months-to-16-seconds-grokking-devops-speedup-data-from-devops-report-by">rapidly progressing rates of automation</a> and introduction of RPA (<a href="https://devops.meta.stackexchange.com/questions/243/is-rpa-robotic-process-automation-a-topic-for-devops-and-so-on-topic-here">Robotic Process Automation</a>)?</p>

<p>Note: this is about the staff size of the whole IT departments altogether put in relationship to your business size, structure and function (size of a single team is well defined by the <a href="http://blog.idonethis.com/two-pizza-team/" rel="nofollow noreferrer">two-pizza team</a> concept).</p>

CC BY-SA 3.0
2017-11-27T12:30:33.570Z
Related reading: http://blog.idonethis.com/two-pizza-team/
Tensibai
CC BY-SA 3.0
2017-11-27T12:50:00.270Z
@Tensibai here is larger context/scope.
Ta Mu
<culture><automation><human-resources>
IT staff sizing in the DevOps era - how and when would a DevOps team scale up?
Ta Mu
# IT staff sizing in the DevOps era - how and when would a DevOps team scale up?

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

Given that DevOps allows IT staff actually to downscale and do more through all the automation, what are limits to that?

That is, what are rules of thumb - if there can be any - where you would know you need more people despite [rapidly progressing rates of automation](https://devops.stackexchange.com/questions/2635/from-6-months-to-16-seconds-grokking-devops-speedup-data-from-devops-report-by) and introduction of RPA ([Robotic Process Automation](https://devops.meta.stackexchange.com/questions/243/is-rpa-robotic-process-automation-a-topic-for-devops-and-so-on-topic-here))?

Note: this is about the staff size of the whole IT departments altogether put in relationship to your business size, structure and function (size of a single team is well defined by the [two-pizza team](http://blog.idonethis.com/two-pizza-team/) concept).

**Tags:** culture, automation, human-resources

> **Comments:**
> **username_1**: Related reading: http://blog.idonethis.com/two-pizza-team/  
> **username_0**: @username_1 here is larger context/scope.  

---

## 1 answers

### Answer by username_2 on 2017-11-27. Score: 8 | Accepted answer

IMHO it's not a good idea to directly and immediately apply a team's gains from its DevOps transformation into scaling the team **down**. At best you'll lose just the team's motivation to do any such improvement in the future. But most likely you'll lose most/all the talent in that team.

Instead:

* allow the team to appreciate the benefits of the difficult transformation they went through, so that they spread the word to your other teams that will have to go through (or are already struggling with) the transformation
* focus on delivering better quality products/services, faster - with the same team - this is now possible due to the transformation.
* in many cases your business will pick up speed because of the transformation - soon you'll more likely need to hire people - IMHO it's better to use the experience of the ones you already have rather than educating new hires
* allow voluntary attrition to work for you and get the effective downscaling down the road.

But generally the DevOps transformations tend to not happen fast enough to allow for the above choices :)

Now onto scaling **up/out**.

Ideally the DevOps transformation should have greatly increased the predictability of your sw development and delivery process. You should be able to tell with a great degree of precision you existing team's capacity: how much sw/services of a certain quality can your current team get done in a certain amount of time.

**When** you need more stuff done, or done better/faster than the current team's capacity you need to scale the team up/out. The exact details come from whatever process/methodology you use for your day-to-day activities, probably some agile variant (see also [Does my organization need adopt Agile Soft. Dev. before adopting DevOps?](https://devops.stackexchange.com/questions/333/does-my-organization-need-adopt-agile-soft-dev-before-adopting-devops))

**How** - *apparently* easy: hire more people to handle the overflowing activities. If you're worried about how fast you can get them onboard and actually handling that overflow work at the expected rates: start hiring earlier, based on projections.

The reality can, however, a bit more difficult than that. Scaling a software product/service or the development process and tools supporting it is not necessarily straight-forward, even for a DevOps-empowered organisation.

One of my favourite examples is the weakest DevOps link **when it comes to scalability**: Continuous Integration. If the CI build fails there can be no Delivery/Deployment (kinda undermining the "continuous" term in the CD context).

Just because a certain team is happily using CI with decent results it doesn't mean the same will happen if the team size doubles. Nope, the results could be devastating - the delivery process can grind down to a halt (in extreme cases). I'm trying to explain this in [Congestion in Traditional CI Systems](https://www.apartsw.com/insights/2016/11/15/congestion_in_traditional_ci.html) (**disclaimer:** I'm the founder of the company owning the referenced page and offering a solution to this problem).

Another example could be, for example, the version control system (VCS) being used: as the software being stored into a repository evolves so does its change history, pushing the limits of the VCS system, sometimes beyond acceptable performance levels. Switching to a more scalable VCS system or splitting the codebase into multiple repositories could be an approach to address the problem.

But evolving the development processes and tooling supporting them alongside the evolution of the software products/services being delivered are fundamentally just what a mature DevOps team does. They just need to also be taken into consideration when in the team's scaling up/out strategy.

With that in mind, the **how** can be, indeed, reduced to just increasing the team size to cover the additional amount of work necessary for execution of the above-mentioned strategy.

> **Comments:**
> **username_2**: Maybe worth noting that the expertise spectrum also changes when scaling the team size and, IMHO, should be taken into account in the `how`: https://devops.stackexchange.com/questions/2590/adam-smith-vs-fullstack-developers-and-productivity-in-devops/2607#2607  

---

