Sometimes consolidation of tech stacks between teams is pushed for.  The reasons vary.  Here are a few that you hear often but that might not have super-clear payoffs.



## Easier to Switch Teams?

Some would say that consolidating techs makes it easier to switch teams.

But when someone switches teams, it's almost always a proactive thing.  That person _chooses_ to switch teams because of something he hopes to gain.  It's his choice.  It's not thrust upon him.  He'll go to the other team with eyes wide open.  He and his teammates will anticipate him to be less proficient until he learns the new skills.

Plus, when does this ever happen?  Relatively rarely.  Optimizing for this is like optimizing for other mythical creatures like the designer who writes code or the product owner who writes tests.

## Easier to Support?

Consolidation is sometimes motivated by the feeling that we have too much to support.

We can only support what we have capacity for, true.  But if we start consolidating, how much do we consolidate?  And to what?  And when do we then expand?  If we lock in our support to only a certain set of things, which is surely a subset of the universe of tech choices, what happens when that universe changes (tomorrow)?  

We need to make sure not to shut the door completely and permanently to tech in our zeal to consolidate.  We might even accidentally shut out some tech that makes our support easier by its _addition_.
,
## Easier to Learn?

Sometimes we want to consolidate because there's just so much to learn, and we're tired. 

We have been here before.  There's some new tech thing, and it promises great new results but looks vaguely like the generations of things before it.  We're skeptical.  And maybe we should be.  But we're also the technologists of the company.  We are likely _the most_ progressive people around when it comes to learning new tech.  It's our job to find the best tools for the job, and yesterday's best will likely not be best for long.

True, we can only learn [so much at a time](https://jaketrent.com/post/learning-thresholds-quotas/).  But we need to embrace change generally.  To avoid this is to fight against the nature of our field.

So, should we consolidate techs between teams?  Maybe. But maybe it's not going to be the total solution we imagine it to be.

Sometimes consolidation of tech stacks between teams is pushed for.  The reasons vary.  Here are a few that you hear often but that might not have super-clear payoffs.

Costs of Inter-team Tech Consolidation

You are just doing what you think is best.  You might not go with the flow.  You might go against the grain.  For this, you gain a bit of a reputation as a rebel.  Later, that might change.  It may be found that you indeed a visionary.



## Solution Mismatch

At Pluralsight, our architecture recommendations used to include Cassandra as a primary data store.  There were a number of reasons for this, based on valid interpretations of current use cases and reasonable predictions of future use cases.  There was a basic problem, however.  Most teams didn't know how to use this tool very well.  But most wanted to be good citizens, so projects adopted it and tried to figure it out anyway.  Overall, expertise and competent use increased, but there was still continuing pain.  Sometimes it felt like a solution mismatched to the problem space.

One of the project teams didn't understand the whys or hows of this tech recommendation either.  They had other expertise in another database tech, Postgres.  So they refused to use Cassandra.  This team shared their good experiences.  They helped others understand the gains they had experienced.  Soon other projects started picking up Postgres and having their own success.  Soon the usefulness and fit of Cassandra in the architecture was being widely questioned.

## Enacting Change

This led to a change in the basic architectural recommendation.  It was clear the need for Cassandra wasn't there in most cases and that real use cases were better addressed with something else.  Postgres became the de facto replacement recommendation, and soon most were happy to use it instead of the previous thing.  Thus the rebels became visionaries.  They had followed a method that they felt worked for them, shared it with others who were interested, and eventually the results of what they were doing spoke for themselves. 

If you're on a path that works well for you, be true to it.  Don't abandon it if other recommendations don't make sense.  Give it time to shake out.  Help others that might be feeling the pain of a potential mismatch as well.  You may eventually be re-branded visionaries.

What is a tech decision that your team has made that went against the grain but eventually was seen for its own merits and adopted more widely?

When you go against the grain, just doing what you think is best, you're branded a rebel.  Later, you might be a visionary.

autonomy