Back to resources

Making the Connection Between Developing a Product and the Real-World Consequences of Failure


21 May, 2021

Aravinda Gollapudi
Aravinda Gollapudi

VP of Engineering at Sage

Aravinda Gollapudi, Vice President of Engineering at Sage, takes her role as the gatekeeper protecting her userbase from unintended consequences very seriously. When your work is the difference between a life well-lived and a devastating reversal of fortune, how can you make sure that every step that you take is in the correct direction?


One of the challenges of being an Engineering leader, especially when at the head of a company that is involved in real-world transformation by way of technology, is how you figure out and pick the OKRs that you rally, framing your goals to the team.

At one of my previous companies, we were in the process of doing a massive transformation from investing in microservices. Timely delivery when onboarding and ramping up on those new technologies and delivering on services was at the forefront. What we were building was essentially a content management system that was a website builder, which was sitting at the top of a back-end loan-processing platform.

The issue was not in our ability; we were able to ramp up in terms of headcount and learning in terms of the new technology in the stack, building this platform, containerization, and deploying it into production. We felt pretty good about it, but one of the harsh lessons learned was the importance of resilience in design from the perspective of technology. Leading the technology had its own challenges, and what I mean by that is that when it reached the hands of our consumers, although our success rate was nearly 95%, we found that it was the 5% that made the biggest difference.

We learned the importance of not losing a loan ever; we lost some of the loans as they made their way through the system, and this led to a significant drop in customer satisfaction. It was a little bit of a wake-up call in terms of figuring out how to define OKRs and defining what our criteria of success really meant.

Actions taken

Addressing the problem required pivoting the framing in terms of investment portfolio allocation. We wanted to ensure that we were building resilience and monitoring our domains. We wanted to instate measures and processes that facilitated cross-functional collaboration and visibility for post-release metrics; we re-doubled our means of error-detection within the system to ensure that we were able to react in a timely manner. Customer support implementation and account management could then both step in to resolve the issue.

Strengthening the communication between Engineering and Operations prevented problems before they occurred. Now, few incidents degraded into outcomes where the loan did not end up processing. This involved measuring and understanding metrics that gave insight to the connections and investments that we needed to be making. It also entailed a regular update and communication between the cross-functional team on what we were doing, what we were finding, and our metrics in terms of what we were producing.

The experience that the customers were going through was large. We ended up spending close to three quarters to address some of these challenges in terms of the error rates that customers were experiencing in order to bring back their confidence and to re-launch, this time, not leading with the technology.

It takes some time as a leader at the helm of a large organization to learn these critical lessons. It was a really humbling experience.

Lessons learned

  • Even if the probability of failure is very low, the confidence level for certain industries is much more volatile, leading to a much bigger ripple effect if the technology does not succeed in their query.
  • Taking accountability, by being at the forefront in terms of communicating early and often, was very helpful. I made sure that it was my responsibility personally to be the face of the communication. I wanted to create a feedback loop. This gave the fieldwork organization a chance and a voice to give their opinions. This fed back into and advised Product and Engineering on a regular basis. The collaboration became better and tighter.
  • In Engineering, there is a battlefield that involves the pride of the work. Getting Engineers to understand and to relate what they’re delivering is honestly more helpful for them to grow personally. All levels of leadership should embrace this, to figure out how to tap into it and to build that ability. Spend a little bit of time on the what and the why, rather than just to the how and the when.
  • Hiring rank-and-file Engineers, instead of making it a numbers game from an investment standpoint, becomes about bringing the right people onto the bus and articulating to them why we are investing in what we are investing in. For them to grow in that lane, they need to have the visibility and the leaders who will coach and guide them. It is also so important in terms of how their role relates to a business deliverable. This leads to an enhanced understanding of their impact on the business and the intended user of the product.
  • From a business standpoint, it is important for us to understand what our R&D investment is. Where does it go? What are we investing in, short-term versus long-term? What is the business model that we are operating in that affects that investment portfolio? This ensures that we help to bridge the gap and to make sure that the engineers do not become a commodity or a number on a spreadsheet.
  • There are a lot of times where we get so focused on what we’re building that we forget the importance of the impact that we have. There is a sense of anxiety when our work may have a negative effect on the intended user that trusts it with something life-changing. If your product results in a successful transaction or the guidance that informs an important decision, this is a huge impact. Having that higher purpose allows us to better relate and to have a sense of belonging and ownership to what we’re doing.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

How I failed at my startup

14 October

There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Mission / Vision / Charter
Scaling Team
Building A Team
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Scaling Team
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Management Chose Me

23 June

My accidental journey into product management

Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Intermediate Engineer Syndrome

16 June

How not to stuck at the Intermediate Engineer level

Changing Company
Career Path
null null

null null

null at Unit21