WeiJian Chen joined Abnormal's Email Productivity team, the group behind Graymail, nearly two years ago, referred by a friend and drawn in by the pace and the size of the technical challenge. Two years in, one of his most memorable moments wasn't a launch, but a message from a customer.
When the Work Feels Real
A customer shared they were getting more than 300 hyper-personalized AI cold outreach emails a week and spending zero minutes dealing with them, since Graymail filed them neatly into a separate Promotions folder. What stayed with WeiJian wasn't the number itself, but how directly and simply it described the value of what his team had built.
"Shipping something new is satisfying, but hearing that it genuinely improved someone's daily life in a practical way feels different. It makes the work feel real."
As an engineer, WeiJian said, hearing from real users in their own words carries a different kind of weight than shipping something new.
Decoupling a System Without Breaking It
That same attentiveness to what changes someone's day was already at work well before this customer noticed anything. WeiJian joined a project partway through to decouple Graymail's detection pipeline from the company's main detection system, a change meant to improve latency, reliability, and long-term efficacy. It also carried real risk, since this was a production system that directly affects customer experience.
"If the sequencing was wrong, the worst-case outcome would have been service disruption for customers, where Graymail would stop being remediated properly," WeiJian said. Even short of that, the new pipeline risked a degraded experience if it turned out less reliable than the one it was replacing.
Before sending real traffic through the new pipeline, the team built out data collection, observability, alerting, and clear success metrics: the foundation that would tell them whether the system was healthy. When they later hit resource bottlenecks under high email volume, a real blocker that raised doubts about whether the system was ready for general availability, they delayed the rollout to resolve it instead of pushing through. Because the observability was already in place, the team could triage the issue, find the root cause, and fix it quickly.
"It was a good reminder that the instrumentation work often feels slow upfront, but it is exactly what gives you the confidence to make the right call later."
The lesson behind that didn't come from one moment. WeiJian's background is in software engineering, but this project required him to work far more closely with detection systems, where a fix is rarely better in a simple way; improving recall, for instance, can hurt precision if you're not careful.
Unit tests alone couldn't catch everything the team would eventually see in production, which is why WeiJian leans on evidence over instinct. "Speed on its own is not the goal," he said. That process starts with the right tools and workflows, then moves through validation against real evidence, and only then reaches the decision to move forward.
As WeiJian put it, "the real work was building enough confidence in the rollout process so that we were not just moving fast, but moving safely."
From Firefighting to a Reliability Culture
Before this stretch, the Graymail team dealt with a handful of outages each quarter, each with its own level of customer impact. What changed wasn't one fix, but a shift to a more methodical approach: learning from past incidents, following through on postmortem action items, prioritizing the highest-impact fixes first, and putting mitigations in place wherever longer-term work wasn't ready to happen yet.
The team also built stronger production testing and alerting around key workflows, got more proactive about capacity planning, and used AI-assisted tools to identify performance bottlenecks faster.
"The result was not just fewer incidents, but a more disciplined reliability culture that helped us get to zero sev0/sev1 incidents for three quarters running."
A Problem Bigger Than One Team
WeiJian points to Abnormal as a whole as an example of solving problems together rather than working in isolation. Protecting customers well, he said, is bigger than any one person or team. The problem space is wide, so it takes engineering, detection, infrastructure, and other teams working toward the same goal, each owning a piece of it.
That shows up in how WeiJian describes a typical week: building, testing, reviewing, and sharing what the team learns with each other, especially as AI tools keep improving and the team keeps adapting. "We try to experiment quickly, but we also make time to validate what is working, challenge assumptions, and raise the overall quality of the team's decisions," he said. "It feels less like rushing and more like learning faster together."
Better Questions, Faster
AI helps WeiJian most in the early stages of de-risking, where it lets him and his team explore more possibilities than they otherwise would. During experimentation, it speeds up both the quantitative and qualitative work, generating ideas, comparing options, spotting patterns. One concrete example is performance work, where AI helps narrow down likely bottlenecks so the team can focus on the fixes that matter most.
"We are not replacing judgment, but we are getting to better questions and better decisions much faster."
Beyond the Tools
Looking back on nearly two years at Abnormal, what surprised WeiJian most is how deeply AI is woven into daily work here, beyond any single tool.
"What surprised me most is how AI-native Abnormal is as a company. It is not just about using AI tools here and there. It really shapes how people think, experiment, collaborate, and improve the way we work."
It's also what he'd tell anyone considering joining: come for the chance to move quickly, learn constantly, and build with AI at the center of how the company works, the same pace and growth that drew him in when he joined.
Curious how other engineers here think about building for scale? Read more from the team on our Abnormal Builder’s Substack.
