Meraki's upcoming downfall - Senior Software Engineer Meraki Employee Review

Meraki Management has always been the biggest struggle point with Meraki. Most management and executives are people that started working with Meraki before being acquired by Cisco and haven't shifted their mindset from being a bare-bones startup company. For whatever reason, there are large sums of money to go towards activities, lunch, snacks, and events. But when it comes to headcount, or investing in infrastructure or processes to make things flow better, it all falls on its face. You're always fighting an uphill battle since the startup company mindset isn't to invest in process, it's to ship your product as fast as possible. This is fine for startups, but not for a company making billions a year. Now, we are so riddled with tech debt making us incapable of releasing anything. Though, for whatever reason, management and product teams are holding a whip demanding that we ship more since they are seeing that we are falling behind competitors. A lot of the code needs to be refactored ground up while implementing best practices. Engineering management has demonstrated that they have zero idea how to lead a state-of-the-art engineering organization. They hear buzzwords like "Agile" and "CI/CD" and reiterate these at the "all hands" meetings, but I'd challenge them on actually knowing what it looked like. Management thinks that being agile means that people can swap to putting out fires quickly and going back to working on other things. Or that being agile is shipping "MVP", which to Meraki, means that we are shipping a Frankenstein POC that we hope customers like. Then we spend a year or more trying to stabilize it IF we actually prioritize it. So our product is filled with half-baked features that are buggy. Everything is largely a monolith and people that write bad, overreaching spaghetti code are praised instead of reprimanded. The problem is that people writing the extremely poor code are in senior engineering positions and are the ones gaslighting management that this is how it is. The largest problem with this is that there is zero accountability for this bad behavior. And trying to tell management that they need to change how we design and write code is an uphill battle that will likely be a lost cause. This is a reason why good engineers leave. Meraki has turned into a place where it incubates bad engineerings who like the monolith and who know how to maintain the monolith. There is also a problem where a lot of engineers are people who came from internships or college, so there's a lack of _true_ senior engineers who can provide guidance. Senior engineers happen to be people that have been in the role for 1-2 years and are promoted due to a number of reasons. This turns into very bad practices such as redesigning things ground up instead of either leveraging open source projects or paid services. This is really bad because a team will create an internal tool, and once it's done, won't support it anymore. Even though it's used by multiple teams. This leads to a graveyard of tools that are never used. But then when a need arises again, instead of using one of the old, forgotten tools, the same one will be _recreated_, repeating the cycle. Cisco. Meraki was acquired by Cisco in 2013, but Cisco has been hands-off until recently. This is largely due to the cloud not being a crazy thing until recent years. Now that Cisco knows that they better step up their cloud game, they are trying to "Merge" us. I think it's worse now than if they did this at the acquisition time, since now we have our own identity. The silver lining with Meraki is that we _try_ to be agile. The problem with Cisco is that they are the biggest waterfall you could ever hope to come across. They have a process for literally everything. If a process isn't defined, they go into process lock and no one knows (on Cisco side) what to do. Also, if something was not explicitly called out in the executive commit over two years ago, you have no hope of working on it or changing it. They are so backed up with an inefficient process that they can't even look up to see that it's not working for them and everyone who's worth anything has changed their ways of engineering in the early 2000s. The longer you work with Cisco people, the more you will realize they are also cutthroat, bureaucratic, and two-faced. They will play the politics and the blame game heavily, and go preach this to their leaders. The personality of Meraki's people doesn't work with this. We don't argue since people just want to build and design cool things. We don't _want_ to get into the politics, but it's being forced because this is what Cisco does. It's quite literally the most toxic relationships I have ever had. In my many years here, I have never once enjoyed working with Cisco people for this reason. In recent years I have had to work with them a lot more. So the only guidance I can give is that you HAVE to document everything. After every meeting, you better send meeting minutes, since in the future, if you don't have proof that something was said or agreed upon, they will try to change it or hold it over your head. But they will do this while making it seem like they care. But after many engagements with them over years, you really start to figure out people's intentions.