A masterclass in failing up
Pros
On paper, this company should be crushing it. The business model is actually solid and well thought out, and the core technology is genuinely interesting. There are smart, hardworking engineers here who want to build something great, and when things are working, you can see the potential. It’s one of those places where you think, “if they just got out of their own way, this could be a top-tier company.”
Cons
Unfortunately, the reality is… kind of a dumpster fire from an engineering perspective. The biggest issue is a leadership culture that rewards loyalty and tenure over operational competence. A lot of engineering leadership came up internally from the company’s early startup days, but the organization never really evolved its practices as it scaled into an enterprise software company. There’s a noticeable lack of experience when it comes to building and operating reliable enterprise-grade systems, and it shows. The irony is that the company has aggressively pivoted toward enterprise and strategic customers, while many of the technical leaders guiding that transition have never actually delivered software at enterprise scale before. The mindset and operational discipline required for enterprise software—structured QA, operational ownership, release rigor, scalability planning, incident management—often feels either underestimated or actively resisted. Many of the company’s most severe incidents are self-inflicted and entirely preventable. Basic QA processes, regression testing, and change management are frequently bypassed in favor of speed and centralized control. Production changes are pushed with little rigor, and when things inevitably break, the same people responsible continue to gain influence and promotions instead of accountability. It creates a very real “failing upward” culture that has become a running joke internally. What’s particularly frustrating is how the company’s stated culture—Connect, Challenge, Own—plays out in reality. “Challenge” is only encouraged when it aligns with leadership’s opinions. If you push back on poor decisions, inconsistent standards, or obvious favoritism, concerns are quietly ignored or swept aside. There’s little meaningful accountability for leadership decisions, even when they directly contribute to outages or instability. “Own” is similarly inconsistent. A small handful of teams carry the operational maturity for the rest of the engineering org, while many others still lack basic ownership expectations. During incidents, getting the appropriate engineering teams engaged can be a complete crapshoot. Despite having incident management tooling available for well over a year, many teams still don’t have formalized on-call rotations or operational accountability structures in place. The frustrating part is that the company genuinely has enormous potential. The market opportunity is real, the technology is compelling, and there are talented engineers trying hard to improve things. But leadership bottlenecks, favoritism, and resistance to mature engineering practices continue to hold the company back.
