Engineering Growth At Sigma: Feature Creep, Trade-offs, And The Art of Saying "No"

Early in my career as a junior engineer, I said "yes" to almost everything.

"Can you take on this extra task?"—Yes.
"Can you build a new feature for our customers?"—Yes.
"Can you finish this by this quarter?"—Sure, I'll try.

Saying “yes” helped me learn quickly. It exposed me to different parts of the codebase, different teams, and different challenges. I was eager to grow, and saying yes felt like the fastest way forward. But ever since joining Sigma, I learned that saying “no” for the right reasons can be even more valuable than always saying “yes.” 

The hardest part of building: Knowing what not to build

At Sigma, we support everyone from small businesses to global enterprises—each with distinct needs. As our feature set grows, so does the complexity of making everything work seamlessly together.

That’s how I came to realize that growth doesn’t come from simply doing more. It comes from doing what matters most. As I gained experience, the most important lesson I learned was the power of saying “no.” But that doesn’t mean being unhelpful—it means being intentional. It means understanding trade-offs, protecting your time, and focusing on high-impact work. It means asking the hard questions:

Growth doesn’t come from simply doing more. It comes from doing what matters most.

• Does this align with our existing features?
• Are we solving the right problem?
• Should this even be built? Or is it an anti-pattern for our architectural direction? 

In shifting my mindset, I finally understood what Steve Jobs meant when he said "it's only by saying no that you can concentrate on the things that are really important."

“No” is not a weakness. It’s an opportunity.

One challenge with our Audit Log brought this into focus. This feature helps customers monitor user activity, with logs retained for 30 days. To give them long-term access, we allow exports to their own cloud storage where they can build custom pipelines into their data warehouses.

Over time, a pattern started to emerge: customers began asking if Sigma could load that data directly into their warehouses. At first, it sounded like a reasonable request, and we explored ways to support it. But as we dug deeper, several concerns emerged:

• Customers would need to configure complex storage integrations between our cloud and theirs.
• We would have to expose our cloud storage to external data warehouses—raising security concerns.
• Diagnosing failures or user errors would be challenging, especially without visibility into their pipelines.
• Our audit event schema can evolve over time, and changes could silently break their ingestion pipelines.

After weighing the engineering cost, maintenance burden, and security implications, we said no to this request. But we did say yes to digging deeper and better understanding the challenge our customers faced. What we needed to do was find a more scalable solution that meets our customers needs.

We said no to this request. But we did say yes to digging deeper and better understanding the challenge our customers faced.

Instead, we proposed a long-term solution—an API that allows customers to continuously access their audit data in a secure, reliable, and future-proof way. It was a win-win—we reduced implementation complexity while offering customers a clearer integration path.

We also discussed how to simplify the audit log pipeline and define meaningful customer-facing SLIs. Initially, we considered building a dedicated audit log service for more flexibility, especially since we currently maintain three separate pipelines across different clouds. But then we realized that the core functionality—decoding events and writing to S3—was simple enough that cloud-native services could meet our needs, and reduce the cost of ownership. By choosing managed cloud solutions, we avoided the complexity of ensuring availability and reliability ourselves.

Driving impact across the stack

We used Sigma to debug latency issues in the audit pipeline. I added a timestamp for each event’s Snowflake load time and used Sigma to surface high-latency events. Turns out, some events weren’t getting published promptly. Once we fixed that, we locked in a clear SLI: 99% of audit events must be published within one hour of creation.

To drive alignment, we used RFC-style design docs—writing proposals, gathering async feedback, and surfacing hidden complexities early. In typical Sigma fashion, we used a lightweight approach to quickly streamline reviews and give every engineer a voice in the debate regardless of title. Engineers were encouraged to bring ideas forward, question assumptions, and contribute beyond their immediate ownership.

And the improvements didn’t stop there. We:

• Defined customer-facing SLIs, gaining trust through a customer-facing service level agreement
  
  
• Simplified the development process, improving speed and helping developers deliver more audit events
  
  
• Collaborated with our infra team to plan a disaster recovery strategy for the audit log service—ensuring reliability even in the event of regional outages.
  
  
• Refactored shared Terraform code to support multi-region deployment, reinforcing our commitment to resilience without overengineering.

Engineers at Sigma are empowered to drive impact across teams, leverage the power of data, and make thoughtful technical decisions together.

This project gave me the opportunity to work across different layers of the system, from application logic to infrastructure. It’s a great example of how engineers at Sigma are empowered to drive impact across teams, leverage the power of data, and make thoughtful technical decisions together.

“No” is how you move forward

Saying “no” isn’t easy—especially when you want to be helpful and move fast. But as engineers grow, so does the importance of prioritization, clarity, and long-term thinking. Learning to say no is what allows us to say yes to the things that really matter.

‍