From Nattu’s desk
I relish meeting leaders and experts who have climbed the success ladder through hard work, talent and most of all deep commitment to the craft.
During my visit to the bay area this month, I had a chance opportunity meet a VP of Engineering who was both articulate and accomplished. Here are excerpts from the interaction…
Inside world class engineering at Egnyte
👋 Meet Shishir Sharma:
Shishir leads engineering at Egnyte, where file sharing and data governance scale to hundreds of millions of users and billions of files.
As VP of Engineering, Shishir helped Egnyte grow from a cloud file server to a full-blown content platform trusted by enterprises worldwide.
He’s seen firsthand how UI teams can either elevate a product—or quietly wreck it.
In this conversation, he goes deep into what separates average frontend work from world-class engineering, how failure modes reveal maturity, and why culture—not just code—keeps complex systems running clean.
About the company:
Egnyte, a bay area based SaaS platform serves thousands of enterprises to manage files, govern data, and enable asset sharing at scale.
The company recently made headlines after being acquired by private equity at a $1.5B valuation—a quietly profitable powerhouse in the SaaS ecosystem.
What’s more exciting is how the company is built.
According to ‘Comparably’, Egnyte won 2 awards in 2025 and 9 awards in 2024. In 2025, Egnyte won for Best Company for Diversity 2025 and Best Company for Women 2025.
🧠 Core Themes from the Interview
1. Frontend is not the hero—but it can break the movie
When frontend goes wrong, it ruins user experience, system availability, and even backend performance.
Key insights:
- Poor error handling and ungraceful failure handling are red flags.
- UIs must degrade gracefully when modules fail—especially in enterprise SaaS platforms.
- Polish and UX expectations have risen globally; visual bugs or clunky interactions are no longer tolerated.
2. Mature teams don’t just ship features—they think in failure modes
“Good frontend doesn’t just work in the happy path—it anticipates edge cases.”
Key insights:
- Teams often underestimate how data volume, richness, and edge cases will evolve over time.
- Great teams anticipate future scale or data complexity—even if not asked to.
- Frontend devs should escalate risk scenarios proactively (not just solve what they’re told).
3. Signals of a strong frontend team
"You know they’re good when the backend team trusts them."
Key insights:
- Look for stakeholder feedback from architects, senior UI devs, or principal engineers.
- Valuable artifacts include open source contributions, reusable components, and documented learnings from launches.
4. Release anxiety is real—and UI can cause it
“I worry about UI frameworks that break entire apps instead of failing gracefully.”
Key insights:
- Pluggable, modular UI architecture is a hedge against cascading failure.
- Strong frontend teams must understand observability, error reporting, and post-release monitoring.
5. Culture is the real productivity multiplier
“A strong kickoff and shared clarity at the start prevent 80% of delivery issues.”
Key insights:
- Great engineering cultures invest in project setup: locking designs, anticipating dependencies, prepping shared components.
- Weekly forums, code review norms (2+ reviews), and peer discussions build engineering maturity.
Interview excerpts: Questions and Answers
Q: What is the frontend tech stack you're using at Egnyte?
Shishir: We started a long time ago with jQuery when it was popular. These days, most of our stack is in React and Backbone
Q: In your past experience, what does poor frontend work mean to you, or when have you seen frontend fail miserably?
Shishir: There are different components to that expectation. First is the basic polish level. As the web has matured, users are used to modern-looking applications, so deviations are not well-tolerated. Another pattern I've seen is when developing with diverse teams across the globe, sometimes just basic error handling is missed—what happens if you submit something or try to go back. These are smaller-scale functional issues.
On a larger scale, especially as Egnyte grew from a startup to a bigger platform, UI plays a significant role in maintaining system availability. Many enterprise products have different modules. When a module fails, which is not uncommon in SaaS applications, the UI has a choice: it can help us fail more gracefully and only take out that specific module, or the UI framework might blow up, making the whole application inaccessible. This causes a serious business continuity problem for customers. So, poor frontend can range from polish issues to critical system availability problems. Graceful error handling is essential so the frontend can deal with unexpected backend data and not expose a bad user experience.
Q: Besides error handling, are there any other non-functional aspects that immature teams sometimes miss compared to mature developers?
Shishir: Absolutely. Speaking from our experience at Egnyte, which is an open platform, we've grown from users storing thousands of files to hundreds of millions. This means the backend can throw a very large amount of data. In basic designs, developers might only consider the happy path, like showing a list of records. But mature teams think about what happens with a very large number of records and how to efficiently unpack richer data over time. This requires intuition, similar to thinking about DOM versus SAX parsers back in the day. It's crucial to be aware of potential problems, even if you don't solve them immediately. This awareness leads to better inter-team communication and allows for conscious technical debt decisions
Q: From a release perspective, what worries you most when it comes to the frontend?
Shishir: The biggest worries come from those system-type failures. For example, if a framework gets compromised. We've done specific work to create a more pluggable architecture that can fail gracefully, but framework issues are still a concern. Adhering to standards for new, large product footprints like our data governance platform is also a worry. The rest involves encouraging testing at all stages, using automated UI tests, and augmenting testing with GenAI. Problems that worry me most typically come from concerns related to developing at a wider, modular level.
Q: What kind of quantifiable metrics do you look at to get a sense of whether UI teams are progressing well?
Shishir: Primarily, we look at dev velocity. When assessing a new feature, functionality, or product line, we estimate the functional complexity using t-shirt sizing. Then we work closely with the design teams. Real development starts once designs are frozen. Designs influence technology choices and whether new components need to be built, which impacts the effort needed. These factors contribute to determining the required level of effort. Once the effort is estimated and the pipeline is laid out, we have faith in the team's ability to execute, which develops over time.
Q: What do you see as good ways to build a healthy engineering culture, and what has worked for you at Egnyte?
Shishir Sharma: I like to think we have a healthy culture. A few things are important. First, it starts with the leadership style. I believe in overcommunicating the 'why' behind what we're doing and what's planned for the future to ensure everyone has a similar picture.
A really good start is half the journey done. So, the project kickoff must be extremely high quality. Once things are well-defined and ready, I have complete faith in our teams to execute. Most mistakes happen during the takeoff phase when requirements aren't clear, designs aren't ready, or the interlock between dependencies isn't planned. We try to use senior leadership and engineers to lay out the pipeline so that by the time the main team starts, most needed artifacts for a successful takeoff are ready.
Combined with this, we have a parallel track of good engineering habits and 'right shift' practices. This includes having frameworks for observability, traceability, production monitoring, and error monitoring. A combination of these factors is extremely important. It's also crucial that the support teams can troubleshoot when issues arise, which requires solid logging and leaving a footprint of user actions. The entire team is responsible for a feature successfully reaching the user; we need to identify and address failure points together, regardless of where they originate."
Wrapping up:
For us at CodeWalnut, this was a useful lens into what experienced leaders care for when it comes to scaling frontend: not just more engineers, but more ownership, sharper alignment, and stronger engineering maturity.
Thanks to Shishir for the clarity and candor—especially when we dropped without notice like an unexpected prod bug
.webp)
When to Hire CodeWalnut?
