Pros: Working at Writer has been one of the most rewarding chapters of my engineering career. The company sits at a genuinely interesting intersection — building enterprise-grade generative AI before most of the industry knew what that meant — and the technical problems reflect that. As a Senior Software Engineer, I get to work on systems that are both deeply complex and visibly impactful: shipping features that real Fortune 500 customers rely on every day, not toy demos. What stands out most is the quality of the engineering culture. There's a strong bias toward ownership and shipping. Engineers are trusted to scope their own work, push back on requirements, and make architectural decisions without bureaucratic overhead. Code review is rigorous but constructive, and there's a healthy respect for craftsmanship — performance, reliability, and developer experience are taken seriously, not treated as afterthoughts. The bar for hiring is high, which means the people you collaborate with consistently raise your own game. The product direction is another major plus. Writer built its own family of LLMs (Palmyra) and a full-stack platform around them, so engineers get exposure to everything from low-level model serving and inference optimization to product surface work, RAG pipelines, agent orchestration, and enterprise integrations. It's rare to find a company where you can move that fluidly across the stack without context-switching feeling forced. Leadership communicates clearly and honestly. May Habib and the executive team hold regular all-hands where strategy, customer wins, and challenges are discussed openly. Roadmaps are transparent, and individual contributors have real input into what gets prioritized. Compensation and equity are competitive, remote flexibility is genuine rather than performative, and the benefits package is solid. Areas where I'd love to see continued investment: the pace can be intense, especially as the company scales and customer commitments grow, so guarding against burnout requires intentional effort from both managers and ICs. Internal tooling and documentation occasionally lag behind product velocity — a common growth-stage problem, but one worth staying ahead of. Cross-team coordination can also get heavier as the org expands, and continuing to refine async communication norms would help. Overall, Writer is a place where senior engineers can do their best work: meaningful problems, strong peers, real autonomy, and a clear mission. If you care about applied AI, enterprise software done well, and being part of a team that ships, it's hard to beat.

Cons: 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.

Pros: Writer is one of those rare companies where the mission actually means something day to day. The engineering team and AI talent here are exceptional — you're working alongside people with serious depth, PhDs, and a genuine passion for building something that matters for enterprise. The C-level team is remarkably accessible and open — I never felt like my voice didn't count, which is rare at this level of company. The culture genuinely encourages you to speak up, and when issues arise, the company is actually trying to act on them. The technology is on an exciting trajectory — the foundations are being overhauled and what's being built now is going to be top notch. If you want to work on something impactful in enterprise AI, this is one of the best places to be right now.

Cons: Like any fast-growing AI company, things move quickly and processes are still maturing. Vibe coding is often encouraged over engineering rigour, which builds up tech debt that will need to be addressed as the company scales, but I think it is the world's reality nowadays. Tech lead selection criteria could benefit from putting more weight on engineering maturity, technical depth, and quality alongside speed and delivery. People management and coaching skills across leadership are an area with room to grow, especially for technically heavy managers. Product decision-making can sometimes feel more technically driven than it should be. These are real growing pains that you can encounter in any fast-growing company, but the company is aware of them and moving in the right direction.

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.