NinjaOne reviews

I spent three years at Ninja, and it’s been an odd blend of growth and severe frustration. For the first two years, I was fully invested and genuinely loved my role. But things deteriorated significantly, and the last year became difficult to endure. The majority of managers in the Austin office are exceptional. Truly dedicated, compassionate, and committed to protecting their teams from poor executive-level decisions. I witnessed firsthand how hard they fought for their people, often at personal cost. While the outside hires were fantastic, the only internal hire was promoted through clear favoritism and contributed significantly to a toxic environment. Supporting team members who were being bullied by their manager became an unexpected and emotionally exhausting part of my job. Despite the challenges, my immediate team felt like family. I would gladly work with any of them again. That camaraderie made it even harder to witness their ongoing struggles for fair compensation, respect, and support. Perks like catered meals and frequent happy hours were nice in theory but ultimately felt like shallow attempts to offset a culture of poor treatment. It became routine: a month of unrealistic expectations, gaslighting, and pressure, followed by a social event intended to smooth things over. Speaking up about issues was met with defensiveness, denial, or retaliation. I often left the multiple weekly meetings more frustrated. Promotions are virtually nonexistent for the Austin team, with clear preference shown to the Tampa office. The culture of favoritism was blatant. Those who stayed silent and aligned themselves with leadership were rewarded—with better accounts, more visibility, and even having client churn reassigned. I began my time in leadership’s good graces and understand the appeal of that spotlight. But once I raised concerns about compensation and fairness, I was asked to resign—without a performance improvement plan or clear rationale. Compensation was another major pain point. Pay structure changed frequently with little or no communication, and commission reports were delayed or unavailable for months at a time. I had to build detailed spreadsheets to prove discrepancies in my pay. Even after being underpaid for two months, I received no apology—just a vague acknowledgment and a backdated check. Without persistent self-advocacy, I would not have been compensated fairly. Quotas were set monthly (not quarterly, as is standard in most companies) and often misaligned with account realities, making it difficult to earn more than the already low base pay. When the team voiced concerns about churn and account quality, leadership dismissed them as “sandbagging” and introduced churn rollovers that worsened the situation. KPI expectations were inconsistent and constantly shifting. Every few weeks it felt like we were chasing a new metric, with little transparency or follow-up. The emotional toll of this instability was significant. The "hybrid" policy is misleading. In reality, we were allowed only three remote days per month and were expected to come in whenever leadership visited. We were reclassified from a customer success org to a sales org with no notice. This resulted in higher quotas, less time to support clients effectively, and a push toward short-term sales tactics over long-term relationships. Several former clients reached out to express their disappointment. Benefits were also lacking—there is no 401(k) match, and the "unlimited" PTO policy came with restrictions. Time off was often denied during the last week of each month and over the holidays.

I can't speak for all teams, but I felt that the upper management I interacted with during my stay with one particular team, lacked experience. It was somewhat evident in the interview process, through some of the questions that were asked, but I ignored it. It became extremely apparent on the job as time went on. There were a number of practices and culture values that were red flags. There were members of management and the development team that had between 5 and 8 years of total experience, but felt they were experts in their field based on those statistic alone. Granted, I've run into some with 20+ years before that made a mess, as years aren't a measure of aptitude, however I can say there was a severe lack of humility and open-mindedness in dialogs. 1) No comments in code I've never worked anywhere in my career where developers and management were actively against comments in code. I literally got told by senior developers to delete code comments after spending a week or more figuring out what a class or method does. More than half the bugs I ran into were because previous developers made bad assumptions about what a class or method does. Upper management says, "Let the code be self documenting" and "I expect everyone to read the code"....which is unrealistic in a large, complicated code base, much less one with accumulated technical debt. No developer is going to read 100s of 1000s of lines of code and memorize every unexpected side effect from every call each time they write a new line. They will look at the function stub and make assumptions, which turn out to be incorrect more often than not. Some teammates claimed it took 10 or more months to understand the codebase at any usable level. This is due to the reliance on memorization vs documentation. 2) Rejections of PRs with more than a dozen or so line changes. I am really not exaggerating. PRs were continuously rejected based solely on how much green they contained. If more than a few dozen lines were changed, regardless of whether they addressed the ticket, fixed a bug, or brought code to standard, they were rejected. I don't think I've ever had to spend days arguing explaining why I added a default constructor, a log statement, or some comments, at any previous employ, much less have it called "risk". I completely understand the need to contain scope creep, but the amount of fear in encountered goes way beyond addressing scope creep. All code needed to pass the same couple reviewers, and they all followed this procedure. I don't feel as though they took more than a few minutes to understand the code in question, or grasp the effects of the changes. At the same time, they expect bug tickets to be fixed. Many times they suggested extremely hacky quick fixes as alternatives. It is my belief that this stemmed from a codebase that has become so fragile, due to poor practices, design decisions, and accumulated, technical debt, that management is outright terrified any change will break the product. This is fairly common when technical debt gets out of hand. 3) We have a standard, but don't follow it There is a coding standard, but it was actively ignored with excuses like, "Well, in this case I don't feel that applies" and "Let's not change existing code." There was no plan to bring existing code inline with standards at all, which left a unhealthy mix of coding styles that will stay mixed for eternity. 4) Tickets Times We're all used to constant "Is it done yet?" from project managers, but this has got to be the first place in my career where tickets were expected to be done in 1 or 2 business days from the time they were assigned. This is coupled with the expectations described in (2). Time was not allotted to fix anything properly. The amount of pressure to get the quick and easy fix without questioning it, was overwhelming. While the sky didn't fall if more time was taken, I did constantly encounter "What's taking so long?", "Do you need another developer to help you?", "Why is this so complicated?", before information gathering for a ticket was even close to done, one or two days after it was opened. I also felt that team success was largely based on the number of tickets closed, rather than what was done to close them and what it meant for long term product health. 5) Bizarro world Things that most software engineers spend their careers being told are good are treated as bad. Most leaders absolutely beg their team to document code, create unit tests, to write confluence pages, to provide advice for QA, to trace bugs to their root cause and provide that information. At NinjaOne all those practices were treated as though the developer did something wrong. Usually because it costs more than 1 business day to complete. 6) Rogue Programming While there were code reviews, some new components were completely designed and implemented by one individual. This leads to the reappearance of any misconceptions, bad practices, or anti-patterns that individual employs. There should always be checks and balances. Code Reviews are not enough when people don't run the code and aren't forced to consider the design. When multiple people work on a component, consideration of the impacts decisions create are forced in the day to day.