I work as an embedded software developer for a growing company that manufactures physical products and, in my opinion, is undergoing some growing pains due to its rapid growth. For decades, it was a fairly small company with only a couple dozen engineers across all disciplines, not just software, a kicked out a relatively small number of products
The product development model that's typically been followed has been to assemble a team of engineers from every discipline, (software, electrical, mechanical, marketing, manufacturing, etc) and then the team works to deliver the product in an agile-ish fashion. At least that's how it's supposed to work in theory.
In reality, the work is extremely silo'd, since I as a software engineer am not able to update CAD models or layout a circuit board, and likewise my other team colleagues have no clue how to write software. Instead of a cohesive team, it ends up being a sort of group of 1-man teams, all going about their discipline specific work and checking in for a status report during our stand-up meetings.
Until recently there was no real shared software model, each project would essentially fork the code base from a similar product and make whatever modifications necessary for the one being developed. As expected, this resulted in a plethora of disparate variations of very similar implementations, but there's been more of an effort by some developers to create a shared library to mitigate this problem.
Most of the developers agree this is the direction we should move towards, but everyone has their own idea of how it should be accomplished and there's no mandate one way or the other so nothing ever comes of it. There's one internal library in particular created and championed by a senior developer that is the most promising and widely used, but some of the other developers don't like its architectural style thus don't use it. This senior developer is also in an different R&D division separate from product development where myself and the other product developers are, so he has no authority to issue any sort of mandate either.
Our software manager hasn't done actual development in a long time and is more of a personnel manager instead of a true tech lead, and the actual product leads typically come from other disciplines than software, so their eyes tend to glaze over when any software conversation comes up. And since each product usually only has one software developer assigned to it, there's not much accountability to uphold any sort of consistent style or architecture.
The number of products we're developing as well as their complexity has grown tremendously in just the past few years, and I feel like we are riding dangerously close to a cliff of disaster if our current model continues the way it has been.
TLDR: We have about a dozen one-man software shows in the same department with no real mandate about how our software should be structured.
How can I best go about advocating for a better organization where the software teams are more collaborative and less silo'd? Several of us have suggested having the software team tackle projects as whole unit instead of having just one developer per product, but the current organization method is driven from the VP level, and I'm not sure my own software manager would even have the power to make such a change even if he wanted to.
I've only been with the company for a few years so I'm not sure I'm the best person to be suggesting such radical process changes, but at the same time I feel there could be so much improvement with the proper structure in place.