Writer reviews

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.

Pace and burnout risk: The cadence can be intense, especially around customer commitments and quarterly pushes. More structured "cool-down" periods after big launches, and clearer expectations around on-call and after-hours availability, would help. Meeting load: Recurring syncs have been creeping up. A periodic meeting audit and stronger async-first norms (written updates, recorded standups, decision docs over live debate) would give engineers more deep-work time.