The development world is changing in a big way. We all know it. And it usually happens first with the early stage startups, who have the luxury of adopting new approaches from day one. One of those major shifts is consolidation of team members, where automation is taking over previous roles. In the modern development shop for example you are not just a front-end developer, you are a data scientist, a tester, a orchestration master, and a release manager. There are a lot of upsides to this consolidation, but a lot of downsides as well.

Often when we talk about process improvement, we are speaking about ways to automate things so that fewer individuals need to be involved to accomplish the same tasks. But there is no way to replace the individual(s) who need to oversee the automation. Though it’s typically a fraction of the previous amount of effort, someone in the organization needs to watch the processes, unless they do away with them all together. This usually means oversight shifts from a FTE who was originally 100% accountable for a task, to an individual who never was, but can be, and will be.

For example, release managers used to be a must in all development teams. Especially in the days of Win32 applications. Now with great release automation tools, and functional testing tools, all the release manager is left doing is clicking the deploy, or revert button. So, the role can be consolidated, and has been handed to one of several individuals, the R&D manager, the QA Manager, or even one of the developers.

However, it is not just the manual time that is at question. What logical space have you now consumed in the person’s life? He/she now has to think about this process more than they would have before. And what objectives have you shifted? The recipient of this function is now more critical about passed tests and thus faster releases than ever before. Which seems like a good thing, but in some cases can create bad motivators. For example it might encourage, if it is a developer, to focus on less risky features. If it is a QA person it might impact the way tests are created and run, and if it is an R&D manager, it just might make everyone’s life difficult.

Don’t forget about the personal impact. Maybe the individual really detest testing for example. And the fact that they now have to do it puts risk to them staying around. If the new function actually increases workload and makes them less efficient at their current job, then it is even worse. So whatever automation you do, it better be spot on.

I started with the bad, because really this shift is also hugely beneficial. There are the obvious benefits: lower head count, lower HR costs, faster releases. But the biggest one in my opinion is less cooks in the kitchen. Which means fewer opinions. Don’t get me wrong, there needs to be diversity in thought, but too much has diminishing returns. After all we all talk about how transparent we are, but the cost of transparency is tremendous in teams greater than 5 even. It also means faster decisions, faster results, and faster response to issues.

It is absolutely critical that application teams have some autonomy when making decisions beyond what the roadmap dictates.  And often, while this is an objective, large teams prevent this by as small of a thing as the number of people you need to talk to or emails you need to respond to on each topic area.

But you need to hire smart people. Not just smart in one task but many. Try to write that job description, it’s hard. People that can think both technically, and strategically. And they need to be able to communicate. Because in a small team you are only as good as your worse communicator.

I really like mean and lean teams. One way to bridge the gap of the additional burden put on them is to silo teams based on specific applications, or subsets of an application. Like the BigData Team, and the customer app team. This does imply an overarching management layer. But still gives the benefit of each smaller team moving very quickly. It also means that you have some big architecture decisions early on.

As we allow more automation to improve our processes we need to think about the impact of consolidation before it surprises us. Done correctly you will be surprised at how effective the team can be, and the increased number of results. Smaller backlogs, and less screaming for new features.