I can now say I've worked in 3 types of environments:

1. "You can only work in these specific versions else everything will implode".
2. "Yeah, we're pretty 'flexible', but we prefer you stick to these technologies...".
3. "We're 'easy' baby! Work with whatever technology you want but remember you have to support it".

While each of these outlooks on technology may have a long list of pros and cons, I'm purely going to focus on my experience working in a technology-agnostic environment. So, without further ado - notes from my technology-agnostic life.

Great for recruiting.
Without a technology structure, communities need to become flexible - this isn't always a bad thing. But it can lead to the formation of splinter-groups hyper-focused on specific areas.

Communities will form, and drift, and form again.
Without a strict technology structure, communities are also forced to become flexible - this isn't always a bad thing. But it does lead to the formation of splinter-groups hyper-focused on specific areas.

Support doesn't just mean customers
A big thing I've found from the agnostic world is the importance of supporting other developers. Where we have the pleasure of selecting the technologies we use, we automatically become the 'experts' in using them. Also, when other people come along who need to integrate with our part of the system, we need to be prepared (and have the headroom) to support them in their integration. Without this, we can end up becoming the blocker we fear.

Documentation is king.
Continuing the previous point: documentation is a great resource for supporting both our own and other teams (plus those who come after us). Having reliable (and up-to-date) documentation can remove the need to support others in a 'hands-on' manner. It will also speed up any time on-boarding new team members into your team. Unfortunately, developers are notorious for not wanting to document their work.

Get ready to repeat yourself, to repeat yourself.
If you have to make a change across multiple areas of your business, be ready to re-write your changes in every technology being used. Get ready to change that button colour in three different technologies.

The paralysis of choice.
Having all of the incredible technologies to take your pick from can have a paralysing effect when you need to make a choice which can impact the future of your work, your team, your company, and even the world. Every decision becomes a spike of research so you can be sure you're doing the right thing.

Technological Happiness
More excitement about the technology used makes happy developers of those making the choices. But it also makes unhappy develops of left to support afterwards.

Being a flexible host is tough.
Something we've noticed is the slow down of infrastructure based work, where the paths are varying it seems like more of a chore to open our systems up for traffic from other sources. If everything was housed together, cross-system communication would be a lot smoother to orchestrate. A centralised infrastructure team of experts goes a long way to avoid this.

Sharing and caring.
I like finding ways to share my code, be it UI components or logic modules. Being agnostic sometimes restricts how often code can be reused, which can lead to more overhead.

Don't count the pennies
If you're worried about how much your system is costing each month this way of working might not be for you. Being flexible requires a flexible budget as different teams need different tools to keep the lights on. This can all mount up.

My takeaway.
While I enjoy having the freedom to export all the technologies I like sometimes it's better to be boring and keep somewhat aligned with my peers. I find this makes integration between systems easier, I can ask more questions, and I'm able to share my code and knowledge. That's not to say we shouldn't innovate and try new things. I just think we should consider what we do and try not to use new technologies just because we can.

That's it really. As always if you fancy reaching out, please do.