LogRhythm Software Engineer reviews

If you think the "pros" are bad... Take every stereotype that follows the story of a Private Equity firm buying a moderately successful software company, only to ruin it completely before ditching it in a fire sale... and multiply all that fun, many times over. Incredibly toxic culture. Executive and Senior leadership consistently refers to people as "resources." General company "strategy" is to hire people at below market rate, then expect those single people to do the job of three people. Turnover is extremely high. When employees and contractors offer suggestions, or raise concerns, or in many cases ask simple questions, they're told to "stop complaining and figure it out." In a recent all-hands, the company announced that "leadership is not going to pay too mention attention to feedback from exit interviews," and they want to focus on "stay interviews" instead. Because sure, people who are afraid to lose their jobs, or just want to stay here and coast, are going to give honest answers, right? Despite everything you'll read in this review, and in other reviews on this site, release scope, timelines, and customer commitments have not changed. Not at all. Engineering has no leadership. And I mean NO leadership, literally. The CTO was fired months ago, and there's still no timeline for replacement. The CCO was put in charge of Engineering for the last few months, because there is no SVP/VP. As of this writing, there is still no executive or senior leadership for Engineering. Half of the Dev Managers have left in the last 3 months. The company's product vision involves grand ideas that no competitors or peers in the industry (most of whom have 2-5x the number of employees and budget of Logrhythm) have been able to accomplish, yet there is regular anger, frustration and blame when Engineering "fails" to deliver on these ideas. Top-performing engineering employees, who have been doing the actual work for the last few years, have been leaving in droves recently, replaced almost exclusively by contractors. Onboarding of these contractors is hilariously brief and incomplete. Testing and QA is basically nonexistent, with just one SDET team responsible for covering 20 dev teams. The entire company transitioned to SAFe by providing only 2-3 hours of optional training on the framework and methods. As a result, every job function and team follows processes differently, and there is no coaching or governance to help with consistency or improvement. The Product Management org has had no leadership for a year, and the Product organization was built from a sales and support background. Decisions on scope, prioritization, requirements, and yes/no answers are extremely difficult to get. The Product Owner org reports through Engineering rather than Product, and are not involved in requirements gathering. PO is largely limited to managing Rally and doing PMO work, because there is no PMO org. The company says that UX is at the foundation of success in the new "next gen" platform, yet like other key functions, the UX org reports through Engineering, has no UX leadership, is understaffed, and has very limited experience with complex or enterprise software.

- Ever since the pandemic began, compensation & benefits have been constantly decreasing. First they took away the 401K match, then cut our salaries 20% for 3 months with no plan to ever make us whole, then they decreased benefits, and removed a small "health-plan opt-out credit". - There is no PTO, you can still take a reasonable amount of vacation, but you can't save up the PTO and get the money if you leave the company. - The "greenfield" project is also pretty process & meeting heavy. it can be very difficult to get things done at times. - Poor implementation of "agile" that's requires too many meetings, and includes odd rules that slows, or sometimes prevents, work from being done if a team finds themselves ahead of their plan. - There's an unfortunate culture of "all things must be the same", so each micro-service has to have the same design regardless of how appropriate that design is to that particular service's domain. - The architects have a tendency to micro-manage, which they can't do given the scope of the project, so it causes delays, frustration, and sub-par output from the teams. - Product Management is mostly absent. Engineers do not get requirements, and are forced to guess what needs to be done, resulting in re-work, delays, and more meetings.