Mahitha is based in Pleasanton, California, and is a mother of two amazing children. She loves traveling with her family and recently went on a trip to Zion National Park. Since then, she and her family have set a goal of visiting at least 10 new national parks this year.
In your own words, tell us about your roles and responsibilities at Okta.
I’m a senior enterprise architect, mainly focused on enterprise integrations. My primary responsibility is to have an overarching view of the organization and knowledge of its capabilities and potentials so I can drive the strategic roadmap for the organization. I have a wide breadth of knowledge across all of the SaaS systems within the business technology area, and I have a lot of experience in architecting and implementing multi-year, cross-functional programs across the GTM, Finance, and HR spaces.
How did you get started in business technology?
After I graduated from college, I worked as a Java developer, working on a lot of custom-built applications, and I just loved building anything from scratch. At my previous company, 8x8, which is a unified communications provider in the telecom space, I managed the self-service portal for customers and, believe it or not, our CRM system was completely custom built on .NET.
In case you’re not familiar with the telecom industry, the ordering process is incredibly complicated because you have to work with tons of vendors for address validations, E911 validations, shipping, taxes, monthly billing, and more. I was the one who was managing and building all of the vendor integrations.
It was clear at the time that we needed to go through a business system transformation and start bringing in outside technologies like Salesforce, Service Cloud, etc., but the core developer in me challenged that thinking because I believed I could build a much better system from scratch. While we were having some heated discussions about this, a very wise person told me that they didn’t think I was cut out for business technology because I was so rigid in my thoughts and that I should move into product engineering. That really hit a nerve in me, and I felt like I needed to take on the challenge and show that I could actually be in business technology. I ended up leading the whole Service Cloud implementation at 8x8, was part of a new CPQ implementation, and the rest was history.
What do you like most about your role? What interests you most about this industry?
Problem solving and thinking ahead are my two most favorite parts of the job. As an architect, it’s my job to not just solve the problem at hand, but also to continuously work to assess the capability gaps that the organization has today. What is the business need, what capabilities do they have, and what are they missing? I need to understand the gaps so that I can build strategic roadmaps, be it through people, processes, or technology. Building these roadmaps to fill the gaps and solving these problems is really fun.
What do you see as the biggest challenges in your role?
Time is the biggest challenge because there are so many things to do. If you go talk to ten salespeople or sales engineers, you’ll find at least 50 problems that you can solve immediately. On top of that, you need to keep track of the company’s goals and targets for the year. Having that right balance of prioritizing projects based on the company’s goals versus innovation goals and functional goals can be tough. Having your team work on these things with a constant list of backlogged items that you strive to get to is, I think, the biggest challenge. There is never enough time to solve all of the issues.
What best practices do you follow for successfully implementing, maintaining, and using a CPQ system?
The biggest lesson I’ve learned is to not rush into implementation. You need to have a proper balance between getting things out the door versus doing it the right way. I always tell my team to take a minute, understand the problem that the business is facing, and to do a proper assessment of what needs to be done. This includes understanding what systems will be impacted, what the technical and business outcomes are for this change, and the way to measure the outcome.
Not every developer would know if writing one line of code can actually bring in a million dollars of revenue or can actually solve 500 hours of manual labor. That’s why I keep telling engineers to understand the problem you’re solving and how you can measure that outcome, and then start designing, keeping in mind the bigger picture of current and future goals. If you can take that one minute to assess the overall picture, I’m pretty sure every design will be close to flawless.
Another rule I always keep in mind is understanding how we can solve a problem more efficiently. Not everything has to go through code changes. Maybe it’s just a configuration or process change that can solve the problem. Or maybe it’s a change that needs to be done in the upstream system. If something is broken in NetSuite, maybe it’s a problem with Salesforce. So it’s important to think about the right way to fix the problem rather than just jumping straight in.
How do you balance speed and building things the right way?
You need to understand that spending more time upfront will save you a lot of time during implementation testing and in the long run. By first putting in a proper design and understanding the overall assessment and all the impacts, you’ll save so much time versus finding a gap halfway through testing and having to go back and fix it.
What’s a mistake you see get made all the time with CPQ, even by smart people and smart companies?
A lack of understanding of the complete end-to-end processes, even for people who directly use, support, or manage CPQ. I’ve seen it happen so many times when people who were directly involved with CPQ didn’t know the complete picture of the product catalog, the pricing rules, the quoting validations, or how a change made in the quoting process might impact the revenue recognition process. Not understanding the end-to-end process is the biggest mistake I’m seeing.
The second biggest mistake I see is that people don’t spend enough time to implement a governance council to track changes. Because there are so many ongoing changes happening, you need to have some kind of governance on what is being done. If you don’t keep track of the changes and document them, you’ll end up at square one in a year or two.
What’s a common complaint you’ve seen from the end user of a CPQ?
Common complaints I hear are: “Why is it taking so long to do my job?” “Why is the UI taking so long to load our process?” “Why is the quoting process not intuitive enough for users?” I think all of the answers to these questions go back to everything I’ve said until now. We have to understand the bigger picture and get into the user’s shoes before we make any changes. A lot of times, we are so deep into solving a certain issue that we don’t think about the user experience or the non-functional requirements, and they need to be considered as part of your design.
What do you see as the next big thing or next big innovation in the CPQ space?
The next big innovation is AI. I think every company is trying to make their footprint in the AI space. I would love to see these systems remove a lot of the manual work of creating quotes, since a fair amount of quotes are pretty straightforward and could be automated. Another area is to read through contracts to understand what the customer has bought so we can use that information on the support side — analyzing the contract, assessing the usage, and then going back to the customer to create the right upsell opportunities.
CPQ Masters is an ongoing interview series with experts in revenue operations, business systems, and business operations who have significant experience implementing, managing, and maintaining a CPQ system. CPQ Masters aims to highlight and share the unique perspectives, experiences, and knowledge of these SaaS industry experts in order to better educate other practitioners on CPQ best practices. Read more CPQ Masters interviews here.
