The effect of org structure on development even has a name, it's called Conway's Law. And I absolutely agree that this effect exists, here is an example...
Several years ago I was working in a team that did everything related to application integration. We supported the planning process of project leaders, we designed the architecture, we've built interfaces, we deployed them, and we also run the servers. So all the tools we've developed for ourselves could've been used from anyone on the team.
Unfortunately when DevOps became a thing some managers decided to do the opposite to my team and split developers and operators into separate teams, even separate departments. This resulted in chaos. Not only was it difficult for us to decide which of the existing tools and processes belonged to which department, but also everybody else in the company (our "customers") didn't know when to go to which department.
In the following years we could solve some of our internal problems by splitting tools & processes and specify exactly what dev has to deliver to ops. But we never could make it clear to our customers when to address which group, but that's another topic. Concerning your question: yes, after splitting the team, our tools started (and had to) represent this split.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The effect of org structure on development even has a name, it's called Conway's Law. And I absolutely agree that this effect exists, here is an example...
Several years ago I was working in a team that did everything related to application integration. We supported the planning process of project leaders, we designed the architecture, we've built interfaces, we deployed them, and we also run the servers. So all the tools we've developed for ourselves could've been used from anyone on the team.
Unfortunately when DevOps became a thing some managers decided to do the opposite to my team and split developers and operators into separate teams, even separate departments. This resulted in chaos. Not only was it difficult for us to decide which of the existing tools and processes belonged to which department, but also everybody else in the company (our "customers") didn't know when to go to which department.
In the following years we could solve some of our internal problems by splitting tools & processes and specify exactly what dev has to deliver to ops. But we never could make it clear to our customers when to address which group, but that's another topic. Concerning your question: yes, after splitting the team, our tools started (and had to) represent this split.