Vrftjkry

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.

You mention your manager isn't extremely technical so this would be a good opportunity for someone on the team to step up. It seems like you have an interest and some ideas, so perhaps you can take this on yourself. You'll probably want to give your manager a heads up, but no need to involve he or she too much at this point. In stepping up and taking the lead on this, a good manager will appreciate the fact that you care and that you've taken the initiative to help improve the team and the company, especially given that your manager may lack the technical knowledge to do so personally.

The first step is to do your research and compile the results. Identify the issues, as you see them, and explain how they negatively impact the company. It's completely normal for a growing company to struggle in this way, so look for other examples and case studies to back up your claims. Next you'll need to come up with potential solutions. Be thorough in explaining the costs and benefits. Note you may want to include your team members here as it sounds like they have ideas as well, both with the problems and the solutions. Just be sure to keep things focused and not let it become a distraction.

Once you've identified some issues and potential solutions that can be acted upon, I'd recommend turning it into a presentation. Schedule a meeting with your team (manager included). The goal of this meeting is to a) get feedback and b) get everyone on the same page. At the conclusion of this meeting, it's critical that you begin planning on how to implement the agreed upon changes and a timeline to do so. If you need approval from higher up, this is when you'll need the help of your manager. At this point, you've done the work to help empower your less technical manager and hopefully given them the tools needed to get the ball rolling.

The last thing is to make sure that what you've decided on as a team is actually implemented. There will likely be things that you and your team members can act upon immediately and others that may require larger changes/purchases/etc that require help from management. I recommend setting up a recurring meeting to check in on the progress and identify any obstacles that may be holding you up. Consistency and accountability are key to the successful implementation of these new processes.

One final note: If you don't feel as though you've been at the company long enough to take this on personally, it can be applied to a senior team member or taken on as a group. Customize to fit your needs.

Take initiative, and find and fix one recurring issue the team has

You say all the developers agree the current way of doing business isn't working, but no one agrees on what to do. You need to find one thing that has been a recurring problem and implement a solution.

Talk to other developers you know and get at least 3 or 4 of them on board with your plan. Then execute your plan. Once it's done tell the rest of the team and your boss about it.

When you tell people what you've done, focus on the fact you're wasting time because of a bad process. Something like...

After I missed event/deadline XYZ I decided to fix this problem. The insert issue problem put me in a really bad position where I had to miss an important life event/deadline. I'd really like to hear what everyone thinks of this solution.