SPEAKER_00 0:02

Welcome! You are listening to the CRM Success Show, where you will hear from CRM executives who have overseen some of the most interesting and complex CRM implementations. Your hosts, David Mastri and Kiro Whitey, will be bringing you real stories, real insight. Follow along on social media for updates on new episode releases, exclusive content, and much more. Enjoy the show and thanks for listening.

SPEAKER_04 0:28

Welcome to CRM Success Show, where we deep dive into CRM Success and Failure. Today we're talking with Ankar Gupta, the Director of Software Engineering at Siena. So welcome, Ankar.

SPEAKER_01 0:43

Thank you, Maz. Thank you, Carol. Nice to meet you both.

SPEAKER_02 0:47

You as well. And um so so, Ankar, we had a chance to meet at Dream Force um in person in the flesh. How would you summarize Dream Force uh quickly in a few words? What was your impression this year?

SPEAKER_01 1:00

Uh definitely a continuation of Agent Force, right? And um, I mean I was definitely stoked uh from the last Dreamforce we had. There was a lot of new products Salesforce had uh you know launched last Dreamforce. This year, I think Salesforce was more focused on how to make an agentic enterprise, basically taking it one level further to say, okay, we have the AI, but how to make sure we are able to put it into action? How do we actually groom our teams or enterprise to work on the AI projects? So I would say it's it was more of a continuation uh and you know definitely gave me some insights or some food for thought on how I can I can make my team more AI focused and future ready.

SPEAKER_02 1:48

Amazing. Well, I know we're gonna cover some of that uh later on in the show, but before we do, why don't you tell our listeners a little bit about you, Anka, and and your background, please?

SPEAKER_01 1:57

Absolutely. So, well, now been working in the software space for now 20 years, right? Have been into software space from my education when I did my engineering in computer science, and then you know, started my work into the software industry as well. Funny thing is, out of those 20 years, 19 of those have been dedicated to CRM applications. You know, I started working as a product development software engineer for SIBO at that time. SIBL, you know, CRM used to be the top CRM product at that time. And then, you know, actually I was part of a couple of their big releases they had, uh, SIBL 8.1, 8.2, if you know, if anyone of you have worked on SIBO. But then after that, I moved on into the consulting space to see, okay, the product that I have built, how does it actually look when it's implemented for a customer, right? That's when I joined IBM and then you know implemented quite a few SIBL CRM projects, greenfield ones for a lot of their customers. And then within IBM, then of course, tides were shifting, you know, things were changing from on-premise software systems to SaaS. Of course, Salesforce were at the at the forefront of it. And then I would say at that time I switched my, you know, it was a very natural shift for me to just move from SIBL to Salesforce, at least the CRM pieces remain the same in terms of domain knowledge. And then I've been now, I'll say I've been working in Salesforce for now 10 years. Yes, 10 years, actually, 2025, so 10 years. And uh, it's been a pretty exciting journey on Salesforce so far. Um, the reason I love Salesforce is Salesforce always is keeping itself very um uh latest and greatest with the technology that are coming up. You can see Agent Force, Salesforce is not lagging behind in any way, they are definitely gaming up with everything on the tech stack that they can build.

SPEAKER_02 3:56

So yeah, that's a fantastic, fantastic, great overview. So you worked at Oracle, uh you were doing Seble CRM there, and then like many, they switched from Sebol to Salesforce. You spent time at IBM, PWC, and now the last five years, you've been on the customer side with Siena. So um Siena are, I mean, they're a beast uh of a company in terms of size, but until I met you, I didn't know what Siena did, to be honest. So why don't why don't you tell our listeners? I'm sure there's a few thinking Siena, what do they do too? So high level, what does Sienna do?

SPEAKER_01 4:29

Yeah, absolutely. I mean, you know, it's funny that uh Siena has been in the industry for now, it has been in since 1992, and it is uh advanced networks uh engineering company, basically. It largely works on the optical network systems, it creates those products and routers, switches, softwares, and services, and then its major set of customers are all the internet service providers across the globe. Plus, now for the past few years, our cloud network or cloud providers like Amazon, Meta, and Google, they are all customers of Sienna as well because they are setting up their uh data centers that requires a lot of network bandwidth. In case you don't know, uh Siena has uh the fastest commercial product for networking available. And I don't know if you can imagine it's 1.6 terabits per second speed, uh, which is the fastest available speed on a commercial uh networking equipment. Yeah, it's pretty cool. So that that's what CNA is all about.

SPEAKER_02 5:38

Uh amazing. And and your role there is director of software engineering. Uh that's a traditional title, so most of us could assume what that entails, but um very very quickly, you you lead the global Salesforce team, right? Very high level. What you know, how many people is that?

SPEAKER_01 5:56

Yep. So as I I'll build upon our CNN, you know, um introduction is uh CNN now sells hardware, software, and services to its customers globally. And so for that, how to interact with customers? That's where Salesforce comes in. Salesforce is being used uh to serve our customers when it comes to sales cycle or even post-sales support. And then we also use Experience Cloud to directly touch base with the customers. We have pretty active user base on this org. Like I would say, internal users, we have uh about 4,000 and then external, you know, 50k plus on our total, very active. And as you asked me about my team, uh, I have a global team of around 50 ish people, uh, multiple time zones within the US as well as uh in India, and uh uh you know, some you know one person in UK as well. So it's a pretty global workforce, and uh it's pretty pretty cool to see uh these guys working as software engineers. And the reason I say software engineers isn't because they don't just work on Salesforce as a technology. This team actually works on all the technologies that are also connected with Salesforce in our ecosystem, whether it's the AWS tech stack, actually, some of the team members in my group work on.NET as well, because there are some legacy applications and then Slack as well.

SPEAKER_02 7:26

So fantastic. And I know we're gonna cover a little bit more about that team and and uh because it wasn't always 50 plus people, so we're gonna talk about that uh a little later. But um one of the things I know from our conversations leading up to this podcast is you're you're a hands-on um you know leader. You you still are very active when it you know on the development front and and you like to build yourself. So um this is a good segue into uh the topic that Maz is gonna pick up on, um, which is around a product that you built focusing on proactive monitoring. So um why why don't you uh over to you, Maz. Why don't you why don't you leave with that?

SPEAKER_04 8:05

Yeah, when when uh when we first met when Kierho introduced us, um it was uh this is one of the things we discussed prior was you know the being proactive in monitoring Salesforce, what users are doing, what's working, what's not working, what's going wrong, so you can really be proactive um and I get the way to deliver an outstanding experience to your users. Um so yeah, it's it's not something that's widely done. Um you don't often see the level of proactivity. Um so yeah, tell us uh tell us a bit about that, maybe how it got started, what was the rationale behind it, um, and then even dive a little bit into the architecture, how you built this thing.

SPEAKER_01 8:46

Absolutely, Mass. Thank you. Um well this definitely is very closer to my heart because one of the things that I don't like as a leader is to be reacting to situations. I I like to deal with things ahead on. And then, you know, when when I when I joined Cienno, one of the things that I noticed was we were seeing certain limit issues on the platform, right? I mean, if you're working on sales for I'm pretty sure everyone understands what governor limits are. You know, they always catch you by surprise, say something stopped working, and then after some triage, you'll get to know, you know what, we actually consumed all the limits for some something, for example, platform events, right? So what I used to hear a lot when I joined was uh, you know, our integrations have stopped working because we and we used to figure out that you know we have consumed our platform event limits because we have certain limits that we have as part of the platform and we have not purchased anything. So every time that happened, the point was why do we get to know about that when only it has happened? Why can't we just know about it ahead of time so that we can take action on it before it happens? So that's where this whole idea of observability came in, where we knew that we have a shield platform on our uh you know, Salesforce.org, which spits out the event logs. Now, event logs are very good way to figure out what all consumption is happening, what all errors are happening in the system. Plus, we also have REST APIs that are available by Salesforce to figure out what the limits are. Right now, we wanted to feed that into a system that can actually actively work on those logs, and then without any human intervention, can actually alert us, you know, once we have configured our thresholds for different logs or these kind of limits. So that's where we leverage this enterprise observability platform. It's called Datadog that we use. It's you know, there are other competitors in the market as well. I'm I'm sure you have heard about Splunk. Splunk also has you know that kind of a systems available. But the whole idea there is all the event logs that the Shields spits out, and there are the two kinds of logs actually, real-time as well as those batch ones that are actually spit out every few hours. And those logs are being fed into this data dog, and then we have created a ton of monitors, different kinds of monitors. I mean, limits is just one of us one of those many, but you can also think if someone is doing a huge data load that can bring down the system. Another one of the common problems in Salesforce, we have a monitor for that as well. It tells me, hey, you know, someone has actually loaded 200,000 plus records in the system in the past few hours, it'll alert us so that we we are ready to see if there's anything going down in a few hours or not, right? So there are so many other things that we have now scaled it to. We don't just have these sheen logs, we also have our custom logging framework created so that if there is anything that we want to monitor from a user experience perspective, we can send that into Datadog to create some pattern-based analysis as well. So the idea is all of this information is being fed into a centralized logging system or observability platform, as I say it. And then I have created a lot of monitors on top of that. And that if there is a critical one, critical alert that we have to publish, and let's say if those are off hours, we also have a paging system integrated with this, which will page us or let's say call us automatically to alert us saying something is going down, so you need to look at it. So that's that's what it is.

SPEAKER_04 12:41

Wow. So um, so a couple of questions. What what exactly is Datadog? Is it like a traditional analytics platform and then this is built custom on it, or is it specifically made for system monitoring and it is it is specially made for this purpose.

SPEAKER_01 12:56

It's used by a lot of software engineering teams across the industry. And you know, as I said, Datadog is not the only tool available. You will also hear about app dynamics, for example, Splunk is another one. I I really like this product, by the way, because it is it is it's very easy to configure. It's very the UIUX of this tool is pretty cool. Uh, and that that's my personal opinion. They have not paid me for it.

SPEAKER_04 13:22

Okay, cool. Um, I I think I think it comes with shield, um, like CRM analytics with a templated dashboard for monitoring. Have you checked that out at all?

SPEAKER_01 13:33

Yes, we have that too. And that's too yes, we have that, and the reason we use that is for historical data analysis, because you can keep a lot of data in your um uh um for a longer time with the Einstein analytics. So we have that dashboard as well. So for example, if uh something happened, we got to know about some incident in the system, let's say security problem with the data, let's say something, and then we have to see well, was that a problem for the past few months? Then we look at the analytics, CRM analytics to do that analysis because we have a lot more data there versus data dog where we archive the logs after a certain point to keep the costs in check.

SPEAKER_04 14:19

So you're using data dogs, I guess, for like more immediate type of alerting, and then uh the serum analytics for looking at historical trends.

SPEAKER_01 14:29

Yes, exactly.

SPEAKER_04 14:31

Yeah, so um and this is on top of the shield logs. I'm not a super expert in shield. Shield has like um what's it called? Like uh uh event logs. Yeah, the event logs, but they trigger alerts, they trigger call-outs to data log when something happens, or you have to push every event like a CI C D type thing going out.

SPEAKER_01 14:57

No, it it happens automatically. Uh now the good thing is Datadog has a connector with Salesforce available, so it can pull in all those event logs at a certain frequency. We we pull it every three or four hours, but the even in the event logs, there are two kinds, as I said before. One is real time, they are pushed immediately, any event happens, and there are a limited set of those logs, probably 12 or 15. But the broader set of events are in the batches, which are like 60, 70, or maybe I don't know, probably 80 now. So all of those are being pushed into the system, and we have created uh monitors on all of them.

SPEAKER_04 15:40

Real cool. Um, can you give us a couple of examples of like this kind of saved you?

SPEAKER_01 15:45

Yes, limits, for example. I mean, limits is not through event logs, first of all, by the way. There is a different REST API for that, but it because it is being pushed in there, as I told you before, we used to have a lot of uh platform events related uh issues before, right? Because we were acting reacting to them versus understanding what the pattern is.

SPEAKER_04 16:07

Somebody's using up all your API calls. Okay, so now what are you gonna do? Tell them stop.

SPEAKER_01 16:12

Well, no, well, we didn't even know which platform event because it was not very clear to understand what is the usage of platform events until you create a case with Salesforce, right? Now we have we have because we are looking at the limits ahead of time, you know, what we found as a pattern was at the end of every month, the consumption used to spike up because of certain business activities at the end of the year.

SPEAKER_04 16:36

That makes sense.

SPEAKER_01 16:36

Yes, exactly, right? So when we found out that pattern, what we did was first of all, we were able to pinpoint, okay, what is happening? Which platform event would it be out of those uh tens of platform events we have on the system? Then we pinpointed a few after that, and then we were able to remediate the process or redesign that process so that that problem was gone. The whole thing I'm trying to say is because we have all these events coming in, we were able to find a pattern in the system, and we were able to pinpoint the root cause of the problem, and then we were able to uh correct that. What we also did, by the way, after that, we also bought certain additional platform even limits.

SPEAKER_02 17:21

Got it. So I know this whole initiative was to support, I guess, the idea of identifying problems before users report it, right? That was the premise of why why you set out about going about this. Um how how long did it take to kind of put this together and have it implemented up and running? Was that was that a big uplift for to build it, or was it a quick win per se?

SPEAKER_01 17:46

Or um it it actually took, um, I would say it was more of a side project, to be honest. I mean, it was not kicked off as something like a full-blown project, but it was like, okay, let's let's see what happens when we do this. And then that was done within a couple of months, and after that was an incremental because when we started off, it was just probably four or five monitors in the system. If you look at this now, three years, you probably have between 80 and 100 different monitors because the program has been widely successful. And in fact, it has been uh so successful that other software engineering teams within CNR also have also implemented that kind of system.

SPEAKER_02 18:29

Fantastic. So good success there. It's been expanded into different teams, other teams are benefiting from that. Um, yes. It I I I guess it could be difficult to maybe ask you how successful it was in terms of a metric, but the the key is to success, it's been embedded and implemented elsewhere. But any any kind of headlined facts that you're pretty confident, you know, we saved X amount of issues or I can say, I mean, what I can say is we used to get at least uh one or two limit issues, for example.

SPEAKER_01 19:04

If I just focus on the limits for the past probably two years, we haven't had any limit issues at all.

SPEAKER_02 19:11

Wow. Okay. So that in itself, just for that one purpose alone, the limits, it's been a success. So um, because they can do pricey, right? I I believe if you hit them and you need to extend them and and so on, there's a financial impact, I believe.

SPEAKER_01 19:26

Can be, yes, because uh, I mean, Salesforce is courteous enough to they will they will raise the limit by courtesy, but you know, you cannot ask them every month, right? I mean it's not a courtesy anymore, then if you're asking every month. Exactly.

SPEAKER_04 19:41

Yeah, it's often done when migrating to a new org, you gotta just load a ton of data or something, and you're gonna trigger a ton of API calls and whatever. Yeah, um, so that's sometimes you'll ask for that kind of courtesy. Um, did you ever look at this from a financial perspective? Um, in terms of how you're utilizing what features, and maybe should turn something off or expand the usage of something or negotiate with Salesforce.

SPEAKER_01 20:05

Very good question, Maz, because uh we have uh signature support from Salesforce, which is their top-tier support level, right? Now, one of the things signature support promises is that we I mean the same same same narrative, right? That uh we will tell you the issue before you get to know about it. But the reality is because of our own implementation, we get to know that issue much before Salesforce notifies us.

SPEAKER_04 20:39

So um it's it's funny. So I have a strong database background, right? Um people who know me obviously work with data a lot. Um and uh and uh and you know that obviously from your Oracle SQL days, right? If you're doing your job well, which you clearly are, nothing happens. Um and then you kind of how do I say not get credit for nothing happening? It's like you're not doing anything. Um you ever struggle with that kind of stuff? It's like like why do I need your team? Nothing goes wrong, and you're like, nothing goes wrong because I have a team.

SPEAKER_01 21:15

Well, then there are things that can go wrong, especially in the same.

SPEAKER_04 21:24

So for example, your database is spiking, your API calls are spice spiking, so you take action, you intervene, nothing stops, everything runs smoothly, trains are on time, nobody's complaining.

SPEAKER_01 21:35

Yes, I mean, you know, I think it's good to have no such kind of an action happening, to be honest, because when whenever there is a P1, you know, the the there is this whole it comes along with a lot of uh um headaches, you can say, at that time. So I think I definitely do not want those. Now, one of the metrics that we have at the leadership level is also at the quarterly the Quarterly meetings we have is did our application end up in a P1 kind of a situation? And honestly, we celebrate if there were zero P1s on our application. So that's that's the measurement of success. That if there were no issues in that quarter, it means there was something done very right there. Because everyone understands that it's impossible to not have any issues. But if you really have that zero number on your quarterly review, it means something has been done right. I'm not and I'm I'm not saying that with uh arrogance or something, but it's we can still have issues. We still have issues. I mean, it's not that all the monitors we have created, you know, is a 360-degree you know coverage of everything, but every time we have a new one, we create additional monitors so that we don't have that same issue ever again.

SPEAKER_02 22:53

So that project, whilst you obviously led it, uh it was a team effort, um, which brings us on to our next uh area of focus for today, which is your team. So um when you when you joined CNR, how big was your team initially, Anka?

SPEAKER_01 23:14

So I would say the team was largely full-time employees at that time, and then it was I would say about 20-ish um people and um right now we are a much larger combination of FTEs, full-timers plus contractors, because we are scaling in that fashion, and we are sitting at between 45 to 50 people. It comes on and off because we are able to scale up and down with contractors much easier.

SPEAKER_02 23:48

Yeah, I don't know at one point in that time as well, it even reached a higher peak. So, so all in all, you've kind of seen this uh you know almost 3x growth of that team. And uh one thing we we know is that that team is global. Uh, you touched on that in your intro. So I'm curious, um, you joined the business five years ago, it's a heavy FTE model. Was that all onshore FTEs when you joined?

SPEAKER_01 24:16

And good question. Well, definitely there was much more presence in North America to start with, because we had people here already. But one of the things that was happening was also that we need to scale in other geographies also, not just for cost benefits, but also for a better coverage, because we also have business units, not just in North America, we also have business units in different parts of the globe. So we, in order to serve that, we wanted to have the follow-the-sun model as we call it, that you know, have a 24 by 7 coverage to take care of our stakeholders. So that's why you know we have definitely expanded in India region for sure. And uh at this time I would say our ratio is 4060, North America and India. So and that that ratio also considers um does it? No, just FTs, I think.

SPEAKER_02 25:18

FTs, okay. So I like I like the follow-the-sun model. So let's let's focus on that for a second. So the idea of 24-7 support, it sounds fantastic, right? Um, somebody's always gonna be online uh around the park and work's being done whilst the other teams sleep. I mean, it sounds dreamlike, you know, that's an ideal scenario for a leader, but how do you make that work in reality? Because you can't have your onshore team working India hours, for example. They might do it for a couple of months and then they're gonna get frustrated and they don't want to be on calls at 5 a.m. or 9 p.m. at night. So how do you do the follow-the-stun model sustain sustainably whilst also ensuring that you don't have what feels like mini business units that don't really interact with one another at the same time? I guess from your experience, you've probably done that in the past as well. But what are some because this is a very hot topic right now, right? Um, some of it is cost saving, some of it is round-the-clock support. Um but how did you go about that?

SPEAKER_01 26:22

Uh, I mean, well, one thing I want to clarify support is not really the production support. It's basically working with our business. Because, in fact, I would say a large portion of my team, I would say 90% of my team's bandwidth goes into um transformational work largely. Or transformational plus, you know, upgrading the existing functionalities. Because as you know, as you obviously know, now CNS business is growing very fast now. Stock price, you would know. So, which means that there are even more transformational objectives coming in. Now, follow the sun model there is definitely where it's it's about the team mix, right? When you're working on the on those projects or initiatives, as I call it, you know, is to make sure the team has at least a decent mix of the time zones so that we can support the project. It shouldn't be one time zone aligned, which creates problems unless unless all the business unit is in one time zone. So that that may change the equation because we definitely have, for example, certain business units who work out of India only, because CNR definitely has a lot of business uh out of India also. So can have some teams that are completely just working out of India that are working directly with the business from there, but otherwise, you know, we always make sure that the team makes is in a way that we have people on both sides and work is not stopping, and then sometimes we do have issues, but I try to balance it most of the time. That's the idea.

SPEAKER_02 28:02

And and do you feel um, you know, employees in different teams that maybe they're not unsure as much or have that interaction with the onshore folk? Um, do you do you think there's any kind of disconnection in the decision making as a result for those teams? Or is that more of a model where here's the here's a task you go away and report back end of week type thing, a bit more transactional versus or or have you been able to build it in a way where they're still involved in those kind of design choices, development choices?

SPEAKER_01 28:36

Well, you know, the way I have created my teams, I have multiple teams working fast-paced with the business. The way at least my intent has always been that people are able to make their decisions on their own, given then they have the guidelines to follow, right? I definitely have my own Salesforce Technical Architecture group within my group that serves as the you can say uh uh one place to at least give some guidelines to the team on how to make decisions. For example, if there is a Service Cloud team, for example, they're working with the business directly, and we work in a scrum fashion, sprints. So they are working directly with the business day-to-day basis to get things done for them. And because they have guidelines, they they work based on those. And if they still have questions, we have a forum created for them so that they can come in and ask those questions. And if they need additional help, they definitely can be helped. So we are not that's one of the things I do our really trying hard as a leader is to make sure it's not a hierarchical structure of leadership, it's actually a leadership where people are able to make the decisions because that's the only way I think we can scale. Otherwise, it's gonna be there's gonna be a lot of bottlenecks everywhere.

SPEAKER_04 29:58

Yeah, so how do you deal with scaling up a response team that follows the sun? Right? Because there's so much you have to know, you gotta understand the system, you understand the problems, um, and often they're not involved in the development, right? They're the backup, so they don't have the intimate details, uh, let's say, and then at the same time, particularly when you have a very strong uptime, they don't deal with problems often. So now you have somebody, maybe he's East Asia, he deals with an issue with the system once a year, right? How how do you how do you keep him up to date in terms of what's going on, how to troubleshoot something, the changes in the architecture and the code and the releases, and um in a way that he's still effective and not just responding to the user, hey, got your message, I'll let you know, then wait for the morning when you know the let's say the core team is really uh available.

SPEAKER_01 31:02

No, all of my teams are actually core teams, is where I was going. I mean, it's not in a way that there are support teams different from core teams or development teams, it's one and the same team largely. It's like as I if I give you an example of let's say there is one team, Scrum team, as I call it, or product team as I call it, is a combination of product owners and the engineers who are working together to create a product or build new features. Now, this is also the team that is responsible for any issues that may come up after they have shipped the product to production, right? So they j the way the teams are structured is everybody in that group is highly intimate with the features. Now we can expect that from let's say outside contractors, for example, Mass, to your question. You know, the people that I have in my team, I call you can call them as SMEs or architects who actually know their areas very well. Now, sometimes there might be some gaps, let's say, when they're working with additional staff ops that we have through our vendors, right? Our contractors. Now, there is that's where the gap might be, and that's where our full-timers actually help.

SPEAKER_04 32:17

Yeah. I I think what I'm asking is how do you take that? So great, you have a team, they're experts, but how do you take that and then span it across all time zones, right? So you get that 24-7 coverage because you end up with people that never talk to each other, right? Um, because they're just very good question.

SPEAKER_01 32:32

I mean, it's it's a it's a large team, there are different teams as well. So there is definitely an element of silo between, let's say, if someone is working on the service cloud team, they would obviously know what's going on in service cloud. But what if service cloud change impacts something on the sales cloud because they're sharing the object and whatnot or functionality? So, for that, what we have done is there is a continuous learning that we do within the whole group, and that brings the whole team together onto the common pace saying, you know, they are not just the owner of service cloud, they actually own the whole platform, and everyone at least has a baseline understanding of what this platform means for the whole Cienna. And that, you know, that that has been very transformational, to be honest. This is something I created about say, let's say 18 months back or so. It's called Learning Series in my group and has been very effective, has at least from what it was 18 months back, definitely has you know brought people together to understand the common objectives of the team. But there is still, I would say, definitely a lot more we can improve. But for such a large team, definitely these are some of the challenges that we have to deal with.

SPEAKER_04 33:44

And uh learning it's it sounds like it's a big benefit because you have a big team, you're able to do that. If you're a small team, it's just not possible.

SPEAKER_01 33:52

Um as positives and negatives, yeah.

SPEAKER_04 33:56

Yeah, go ahead, Joe.

SPEAKER_02 33:58

What about what about some of the um maybe infrastructure challenges of building global teams? So um we like to think obviously in the US or UK, whatever, the reliability of things like Wi-Fi and and the infrastructure is more established, it's been around longer, um, whereas perhaps I I know like Latin sometimes they have big outages, and maybe maybe these countries are impacted a lot more by weather conditions or whatever, right? There's a ton of different factors. I guess when you're building your teams, like how and and you're interviewing resources, whether they're individuals or through a company, whatever, right? Do you are you mind is that something you're mindful of and you pay attention to? Like do they have the physical infrastructure set up to be successful in their role? Do they have the right laptops, equipment, and audio sets and Wi-Fi speeds? Like, because sometimes people, I think customers can sometimes see the hiring processes the same as going and getting somebody in the US, and it's not, there's more you have to kind of consider. Uh, for example, like you know, I know that the currency changes with USD to Indian rupees, for example, in the last 10 years has dramatically uh changed and the cost of hiring in India has gone up as a result. So there's a lot more outside of a normal US hire. So, what are some of those considerations you would advise other leaders that are building global teams to take into consideration?

SPEAKER_01 35:25

I mean, if it's if the question is about hiring Carol, right? I mean, or let me come to your first question if I understand it correctly. Infrastructure-wise, I haven't, at least for the people we have on board already, I haven't seen any infrastructure issues with people. I mean, there's no noise in the background, things are pretty quiet, people are very professional. And one of the things that I've seen at Siena is that Siena is very good at providing infrastructure support to its employees, whether the person is in the US or India or anywhere in the globe, you know, they will provide them the very good infrastructure support, whether it is for set up their home office, network is never a problem with us generally, right?

SPEAKER_04 36:10

Yeah, you're giving them a terabyte a second, and that that's expensive, but it's not a problem for anyone, so that's that's a good thing.

SPEAKER_01 36:21

And uh as far as the you know uh equipment is concerned, you know, everyone gets pretty good equipment as well. So as far as RFTs are concerned, or even the contractors who haven't seen any issues in terms of the infrastructure for hiring the external one. One advice I would definitely give, especially in this remote first world, is always keep your cameras on. Because I, you know, I have seen in certain instances that the interviews have not gone as they were actually. How should I say it? The the the feedback we had on the interview in a closed camera situation and after we hired was totally different. Uh so keep your cameras on, make sure you are actually talking to the right person when you're interviewing.

SPEAKER_02 37:12

Yeah, I think um maybe the oldest trick in the book, I think, um, is that scenario, right, where um cameras off, one person does the interview, another person's hired. I mean, that's been a big, big problem over the years, and and especially it's been accelerating in the Salesforce ecosystem over the last five years as well, pretty much uh pandemic it pandemic time. Um but but um I I I guess with remote teams offshore, some some companies adopt the model of okay, we'll just have a physical presence, a physical office in a certain part of it doesn't have to be in the Philippines, whatever, right? We'll have a physical hook so we can control the environment a little more. Um obviously for you, you make sure as a business you set them up for success by providing the right infrastructure, the right tools and equipment for them to be successful. Do you think there's a right way or a wrong way, or is it just preference of the business? The fact does the fact if the business is a remote first business anyway, does that dictate maybe what they do offshore? How how how would you kind of think on those lines? What's your what's your personal opinion?

SPEAKER_01 38:22

You mean the work division between onshore and offshore?

SPEAKER_02 38:25

Or like if you're hiring you know offshore teams, do you think they're more effective in an office environment for offshore teams than completely remote? You know, I have customers, for example, that they are remote in the US, but their offshore teams are in a physical office. I was wondering if you've got opinions based on your experience of working with global teams over the years.

SPEAKER_01 38:46

Well, I I do like the fact that the people uh are within uh defined range so that they can meet with each other often. For example, uh we have our office in India, and then we tend to hire people around that region so that at least it's easier for them to come come to the office once when whenever they want and meet each other, because that definitely helps. I definitely am a believer that uh sometimes the things you can achieve within a closed conference room within a couple of hours can take days sometimes remotely when you're setting up meetings and all of that. So I do see value in that. Generally speaking, though, it has not been a challenge because people have been very flexible and accommodative to their schedules and making sure they are actually meeting the objectives, even though we have a pretty tight uh work schedule for my team, given that Salesforce is in high demand for meeting the business objectives. I think the team has been, I would say, fairly mature to actually level up and meet the objectives. So that's what I was saying.

SPEAKER_02 39:56

Any fantastic. Any final thoughts on advice or things to take into account for individuals, especially leaders that might be uh tasked with building a global workforce in 2026? Any other advice you would provide or thoughts?

SPEAKER_01 40:14

Um I mean, one of the things I don't know if I have seen anyone else doing, I don't know, but uh because we have a global workforce, it means my my idea has always been to give enough power, as I was saying before, for people to be able to make decisions so that they are also feeling accountable for what they're working on. Plus, they are also feeling something that they can feel proud of if they have done it because they they have you know they are working on this. So that feeling of pride is very important for our people. Whether it's a person in the US, North America, whichever part of the world, I think it's very important that they feel the ownership of the work they are working on. And I think everything aligns very well when that happens. That's what I would say.

SPEAKER_04 41:12

Yeah, so um yeah, the other or one of the other things we spoke about previously was how you guys are using uh AI at Sienna. Yes. Um yeah, why don't you tell us uh a little bit about that? Uh if you're using Agent Force or what AI tools you're using.

SPEAKER_01 41:30

Yes, absolutely, Maz. Um well I'm not gonna talk about the AI that's embedded into our network products. I'll just talk quickly about our what is my realm of responsibility, which is Salesforce and its uh adjoining um technology. I mean, we do have Agent Force enabled on our Salesforce.org as well. I mean, we in fact enabled even before it uh was called Agent Force, when came out as co-pilot, we had the case summary, some of the features on the services side enabled. Case summaries was one of them. Einstein replies, as it used to be called at that time, were enabled. We had an AI on certain, even before GAI came in, which is like customer sentiment, which was all purely based on predictive AI, right? So those things were there. We are we have also enabled Agent Force for our sales teams. Um not heavily adopted so far, but there are more uh features that we are going to build in. Um what I would say where the highest usage of AI, at least in my team, is using Microsoft Copilot because we have a very developed and mature process, CI C D processes for development and deployment to our production. Um, what we have done is uh obviously everyone can use MS Copilot for development. We have given them the licenses for that, and it's been, I think I would say in a year already when people have been using it. So much so that we are now saying people sometimes you know make sure uh you know follow the some of the design best practices for code as well, because sometimes people get really lazy and then they prompt the co-pilot to say, just write the code, and then they forget that you know there are some better ways to do it as well. So that has happened recently, but uh proud of the fact that the team is very good with uh using MS Copilot in their VS Code for development, not just for code Apex LWC tests, but also for sometimes metadata creation also within VS Code.

SPEAKER_04 43:33

Yes, yeah, real quick. I believe you also said you were using it for code reviews. Yes. Right as a standard, yeah. So tell us about that.

SPEAKER_01 43:40

Yes. So as I said, we have a mature CI CD process, nothing goes to production without a pull request review. Now, whenever the pull request, which is basically a technical term for saying that you know, my code my changes are ready, they're available in GitHub repo for review, you know, the the co pilot reviewer comes. In and automatically reviews the PR and creates a whole summary of what the changes are, what changes were done. Is there anything that should be you know done differently? So it's like a first-level review before a human comes in to say okay, everything is good or not. It reduces our cycle time because now the developer has a bot reviewer, you know, enabled by Gen AI to say, okay, code, this is something you should do differently. And then the developer will go back to change the code and come back to commit the code back to the PR, and then the human can review. So it reduces the time that another peer developer has to review, and also, you know, it reduces a lot of friction between the team as well.

SPEAKER_04 44:46

So it also uh it also reviews its own code, right? Which was previously written, I guess, with the developer and using Copilot. Yes. Um, and it ever give you some interesting results.

SPEAKER_01 44:58

It's actually very good. It's actually way too, I mean, it looks for perfection, obviously, right? Sometimes you have to say, you know, this is okay, we know about this, but it's pretty good. We are we are we're liking it so much that we also had this whole um um static code analysis tool uh embedded into our repo. I mean, we are seeing that Gen AI will become so good that we can just uh create those rules for the copilot itself, and then we can do away with the static code analysis tool that we had for years.

SPEAKER_04 45:33

Really?

SPEAKER_01 45:34

Yes. I mean, not there yet. We'll have to create certain rules. Say, okay, we'll be going to give you some instructions so that you can just review the code based on those instructions.

SPEAKER_04 45:47

So did you by and large write these instructions, or copilot figured it out by itself? Like, for example, like really stupid. I hard-coded a token into my code, right? Big no no. Um copilot smart enough to say, hey, don't do that, or you have to tell it check for hard-coded credentials, check for inefficient loops.

SPEAKER_01 46:08

I think those are standard coding problems that copilot would be able to figure out as a reviewer. What I'm trying to state is, you know, there are certain additional things we would like to do, instructions saying, okay, some the object naming was not as per our standards, for example, there was no description in the metadata. Those things are not checked by default. So I think those kind of rules are checked by the static code analysis. But if we can just code those rules in copilot, then I don't think we'll need static code analysis, for example.

SPEAKER_04 46:38

So, what is an example of one that you had to explicitly tell it? I mean, that was that's a good one. The uh naming conventions and I guess code structure type stuff. Um you wouldn't let it fix that by itself, would you?

SPEAKER_01 46:53

I mean, that's another one that's coming, by the way. There is because we have we are now piloting a feature called Co-Pilot DevAgence, which is a new feature that was released a few um, I would say, weeks back or months back, and we have recently got access to that. What that means is you can create a Jira story with the details of what needs to be done in human language, English, right? And then you can assign it to a co-pilot developer bot, and it'll do everything for you, including deployment to production.

SPEAKER_04 47:35

Yeah, so we we know it's going, we know that's the dream, right? Um, I hear even more so that I hear they want to just feed it the Zoom recordings or the recordings of the business requirements gathering session, the discovery sessions, take that, summarize it, create the JiraStories, then assign JiraStory to a developer agent, and then um we'll we'll see.

SPEAKER_01 48:00

It's not there yet. It's not it's not there yet because I think even with that JiraStory creation, to be honest, because I I am a user of copilot myself. I refine my own requirements when I'm I'm working with co-pilot, for example, say okay, don't do it this way, do it that way, and all of that. So you'll have to be, I think, really prescriptive on the story if you really want copilot to work effectively, independently. So that's why I'm saying we are piloting it. We have not, we don't know if it if it'll work really well. But our guess is let's say if we find a bug in a code, I create a bug to say, okay, just fix it. We have seen Copilot is pretty good at trying to figure figuring out what the issue is and just fixing it with let's say a couple of lines of code.

SPEAKER_04 48:46

Is that true? Even with um with both syntax syntax, I think it'll do a great job at right, but like a more of a logic issue.

SPEAKER_01 48:56

Yes, it does. Oh, it's beautiful. I mean, you you tell it you run the whole code file, for example, uh-huh and say, I got this error from this code, it'll say, I know where it the problem is, it'll auto-fix it.

SPEAKER_04 49:11

Yeah, often it does. Uh I mean, uh I I I struggle sometimes, honestly, with it. Um, I I mean I do a lot of data work, so I'll have it like write SQL code for me on occasion. Um and and what'll happen is it'll I spend so much time reviewing the code, it's like I feel like what am I doing? Um, but it but it'll be like it'll be like, okay, write the code. Great. Now write some test cases, great. Now you failed your own test cases, what's going on? That kind of thing. Uh it's a different, it's definitely different, uh different way of development to take some uh some kind of adjustment.

SPEAKER_01 49:45

It's very different way of development. Yes, you don't worry about syntax, you worry about the logic mora for that. Yeah.

SPEAKER_04 49:53

Yeah. Um, I don't know, maybe I'm just overly cautious. I spent so much time reviewing its code. Just trying to understand it's almost like looking at another person's uh another person's code.

unknown 50:04

Yes.

SPEAKER_04 50:04

Um yes, you gotta try to give it into small correct.

SPEAKER_01 50:08

I mean, I agree with you as well because sometimes the LWCs we have created with Copilot, for example, it adds a lot of tags that are not even compliant with the our uh framework of lightning framework. It adds a lot of HTML tags just to make sure it looks pretty. So we have to be, yes, it's it's it's not perfect, but you know, that's why we say that right now we need a human in the loop for sure to make sure it actually is best.

SPEAKER_04 50:37

So it's kind of switching. You doing anything with uh autonomous bots, agents, or um like like but not like uh like actual an actual bot that goes out and does something.

SPEAKER_01 50:50

We have agents, yes. We definitely have agents.

SPEAKER_04 50:53

Give us a couple examples.

SPEAKER_01 50:54

Yes, we have uh sales agent you created using agent force already. Uh it's in production, but it doesn't, I mean it's it's the standard one that we have out of the box. There's no separate customization.

SPEAKER_04 51:11

Right, yes.

SPEAKER_01 51:12

So you can it you can you can talk to the agent and say, tell me the total value of the opportunities, for example. You know, this is pretty much out of the box features. Now, as far as the specific business use cases are concerned, those are in discussion, and then agent force discussion becomes pretty tricky when it comes to pricing them on how much it is gonna cost once we have a business use case. So we are in that loop right now.

SPEAKER_04 51:39

You heard that story? Um the guy went on to uh I don't remember which car company it was, to buy a car and then he was talking to the agent to convince the agent to sell him the car for one dollar and then close the order, um, and then took them to court, believe it, when they refused to sell him the car. Um, he did lose, I will say, when the court said that it didn't have the authority to do that. Um, I don't know if it's whether it's an extreme case, but it does it does introduce a weird like a legal issue, right? Like what do you why am I talking to this agent that doesn't have the authority to make a sale um if it can just backtrack? So it's it's interesting to see where this kind of things will go. Now, granted this is an extreme use case, but at the end of the day, somebody's gonna figure out figure out, right? It's almost like you're conning a junior salesperson, um, except that you would lose, right? Because he had the authority. Um, so it's interesting to see where this is gonna go.

SPEAKER_01 52:46

And uh Yeah, no, I absolutely agree. I don't think it's it's there. I have I've seen some documentaries as well where people were able to manipulate the outputs of the agents uh in a in a totally different way. And uh well, one thing we have at CNI is definitely a security council that reviews every AI use case before it can be actually worked on. It slows down things a little bit, but uh it's actually very good that we have a legal team reviewing those AI use cases before we build them.

SPEAKER_02 53:13

That is different, sorry. Um so so we talked a little bit about AI agents, there's a lot of potential there, um, both for the business, but also just the ecosystem in general, or the companies that are going down the agent force path. Um, anything else that you're excited about next year? Any that you can share or just general trends that you're looking forward to going into next year?

SPEAKER_01 53:36

On the sales, I mean agent wise, AI-wise, certainly yes. I mean, I I think Agent Force is definitely one technology, but it's not the only technology. And as I was saying before, my team is not uh not just working on one technology, they like love to work on others as well. So we already have Microsoft co-pilot agents in production working on certain other use cases, and then uh we are also trying out the Google agent space as we speak uh as well to compare and see which one would surface as an enterprise-wide AI platform, versus what can be more app specific ones, for example, Agent Force. But it totally depends. I think when you talk to Salesforce, we will hear that Agent Force can also be an enterprise-wide platform. That is something that we have to see when that product matures, right?

SPEAKER_02 54:34

So outside of AI Agent Force, anything within the Salesforce product suite that we keep an eye on, or any kind of integration tools or thing you know that have got you curious? Revenue cloud, for sure.

SPEAKER_01 54:47

Revenue cloud, yeah. Absolutely, yes. We we we have CPQ also in implemented with us. And knowing that now that CPQ or Steel Brick is uh has I think probably gone out of support already, or maybe it's going out of support soon. So Revenue Cloud is definitely on top of our mind to see if we can leverage that to um migrate because there were certainly some limitations with Steel Brick that we were dealing with for some years. And we have to try out Revenue Cloud and see if their coding product, this new one, actually can you know bypass or you know has a better solution for all of those problems.

SPEAKER_04 55:27

Yeah, what about uh the Informatica purchase? What do you think of that?

SPEAKER_01 55:32

We are not Informatica customers at Sienna. Um, we have our different technology for analytics. Uh we do use Einstein AI, by the way, but not Informatica.

SPEAKER_04 55:43

It's more ETL. I tend to think of uh Informatica. The rumor is they bought it for the MDM solution. I guess Data Cloud's not cutting it. I I don't know. They think Data Cloud's not an MDM though, so yeah.

SPEAKER_01 55:57

I mean yeah, I I don't have much information information on Informatica or even an opinion because as far as data is concerned, CNI also has a different data team. And uh because we don't use Informatica, we use a totally different tech stack. We do have MDM, by the way, but from a different uh software company. SIBO?

SPEAKER_02 56:26

So um we obviously met at Dreamforce. Any any plans on the meetup space? Are you any any uh world tours? I know it's kind of just missed the the New York one, for example, but um for next year are you planning on any conferences in particular, whether it's Data Force or adjacent tech tech conferences?

SPEAKER_01 56:48

Uh it's hard to say for now, but I think it can be another one at Dreamforce, provided you know, I find something exciting.

SPEAKER_02 56:56

Um I've been coming to Dreamforce pretty often, so hopefully we'll meet up at Dreamforce or Yeah, maybe maybe some of our listeners will be able to find you there as well if they want to pick up the conversation in person. So um so it's a fantastic. So uh any closing statements? This is your podcast. So um anything you would like to share with our listeners before we wrap?

SPEAKER_01 57:18

No, I think this is this was a great discussion, Kira and Maz. I think uh we touched upon some of the very good topics that I had to share with uh with everyone who's uh listening to this or watching this. So thanks for setting this up. I would say, and uh, I hope there was something informative I could actually share that was meaningful to anyone who would listen. So whoever listens or watches, thank you for listening and watching.

SPEAKER_02 57:45

Fantastic. And with that, peace out, appreciate it.