For this episode of the Salesforce Admins Podcast we’re chatting with Gloria Ramchandani, Senior Director of Strategy and Business Operations at Copado.
Join us as we talk about what DevOps does and how working over a holiday weekend on production deployment set her up for the career she has today.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Gloria Ramchandani.
If you haven’t checked out the Essential Habits for Salesforce Admins module on Trailhead, make sure to give it a look. We’re really excited about this new trailmix!
“The term ‘DevOps’ was coined in 2009, to better describe better ways of collaborating between Developers, who actually build new capabilities on a platform, and Operations, who maintain existing production systems,” Gloria says, “and so the term DevOps is really a combination of Developer and Operations and bringing those two concepts together.” It’s people, processes, and tooling combined together into one role.
In tech, there can be certain concepts that can be really fuzzy—even when we’re trying to avoid gatekeeping and keep things inclusive. The problem is that many of these conversations are experts talking to other experts.
A misconception about DevOps, for example, is that it’s only for Developers and not for Admins. Gloria tells us the tale of her first production deployment. It was over 4th of July weekend, “and instead of hanging out with the rest of the family I was up in my father-in-law’s office,” she says. They had to do so much planning and coordination among their team and it was the first time her eyes were opened to the world of DevOps. “It was less about the ANT scripts themselves and the tooling, but it was more about the organization of the work and the team we had to support it,” she says, “that’s what so beautiful about DevOps: it’s not just the tooling at face value, it’s all the planning that comes with it and the processes and procedures and how you collaborate together as a team.”
Nowadays, Gloria works at Copado, an organization focused entirely on Developer Operations. “DevOps is just as much art as it is science,” she says, “so trust your instincts and share what you’ve learned from others because the whole purpose of DevOps is collaboration and working together to continuously improve.”
“If I hadn’t spent those nights and weekends doing all of these releases, I probably wouldn’t be where I am right now,” Gloria says. That’s why she works in an organization whose mission is to end release days. “The better you can get at DevOps and working together as a team, the more time you can have back with your family and with others so you don’t have to spend a weekend doing a release,” she says.
Listen to the full conversation to learn about the Toyota system, why if you’re an admin you already have the skills to be a product manager, and how DevOps is like getting a perfectly cooked pork chop and a cool crispy salad to hit the table at the same time.
J. Steadman: Welcome to the Salesforce Admins Podcast, where we talk about products, community, and career to help you become an awesome admin. This week we’re talking with Gloria Ramchandani, Senior Director Strategy and Business Operations at Copado, about the connection between waiting for your dinner to be served at a restaurant and DevOps. But before we jump into that, I have some exciting news. Available now on Trailhead is a new module for the essential habits for admin success. That’s right. The webinar/Trailhead Live/presentation you have all loved and listened to is now a learning module on Trailhead. The link is in the show notes. So after this episode, head on over to Trailhead and be one of the first admins to get the new essential habits Trailhead batch. Now, let’s get this pod to casting.
Aha. And so we are here. Hello, you want wonderful, wonderful human beings. I hope you are having just the very best day in the entire universe. I remain Jay Steadman. I am filling in as host of this Salesforce Admins Podcast. I am a lead Admin Evangelist here at Salesforce, which means I evangelize Salesforce administration. That’s as easy as a description can possibly be. I’m really excited about this conversation today. We are joined by Gloria Ramchandani, who is a Strategy and Business operations who… Wait here, Gloria, what’s the word that comes after this? You’re strategy and business operations, that the full title?
Gloria Ramchandani: I am as Senior Director of strategy [crosstalk].
J. Steadman: There we go. I was missing the level. You are a Senior Director of Strategy and Business Operations at Copado. That’s fantastic. I found myself at the end of that title and I was like, “Where do I go from here?”
Gloria Ramchandani: It’s okay.
J. Steadman: So I am excited because we’re going to be talking about… Well, I’m excited because I am always excited. If you’ve been listening to the pod for a little while, you know that I’m either excited or asleep. But I am particularly excited today because we are talking about how we can demystify DevOps or developer operations. Before we get into that content. I want to kick things over to Gloria. Gloria, can you please introduce yourself to our wonderful admin community?
Gloria Ramchandani: Yes. Thank you, J. So I am Gloria Ramchandani. I’m based out of Atlanta, Georgia, and actually I’ve lived in Atlanta my whole life, so…
J. Steadman: Oh, wow.
Gloria Ramchandani: Yes. Fun fact, there’s not many of us. I’m right now currently running a strategy and business operations team at Copado. Very familiar with the Salesforce ecosystem. Actually started out in the ecosystem as an admin, a solo admin…
J. Steadman: We love that
Gloria Ramchandani: … at some small startup called AirWatch. I do not have a background in Computer Science. I actually studied hospitality in school. And so I have a really unique path in terms of how I landed in the Salesforce ecosystem. And I’m so excited to be here today with you.
J. Steadman: Well, I love learning that you have a hospitality background. Full disclosure, as I was growing up, my dad was a chef, my mom was a baker and we owned a restaurant for a little while.
Gloria Ramchandani: No way.
J. Steadman: Way, way. So I’ll be interested to see if I can pick up on elements of how the hospitality industry and that perspective comes into the way that you approach your work. I have often found that professionals have a unique set of perspectives that come from their previous experiences. And for those of us like myself, that like yourself, that have come from these backgrounds that aren’t Computer Science, I’m always really fascinated to see how that enhances or augments their perspective on the technology that they’re working with. So this is going to be pretty exciting, I think.
Gloria Ramchandani: Yeah, I’m super excited.
J. Steadman: All right. So one thing that I try and make sure that we do on the pod is let’s say that we’ve got an admin out there who is listening and has never heard of DevOps before. At Salesforce, we’re a world of acronyms and abbreviations and portmanteaus, which is where you combine two words together into one word like DevOps. And sometimes, for those of us that are unfamiliar with the concept, that can seem really intimidating. So if you had to give a 30 second elevator pitch to a person that had never heard of DevOps or developer relations, Gloria, I’m going to put you on the spot. What would your 30 second elevator pitch of, “You don’t know what DevOps are? This is what DevOps are.”
Gloria Ramchandani: Yeah, the term DevOps was actually coined in 2009 to really describe better ways of collaborating between developers who actually build new capabilities on a platform and operations who maintain existing production systems. And so, the term DevOps is really a combination of developer and operations and bringing those two concepts together.
J. Steadman: Got it. So what I’m hearing here is it is the process ,an organized process, system or methodology, of taking changes that have been made by developers. Or in our case, could be administrators, could be an architect on the Salesforce platform, who are trying to make changes. And then get those changes from a test or sandbox environment or a scratch work into the production environment. Is that correct?
Gloria Ramchandani: Yes. And I think it’s so much more on the planning side. And we’ll talk a little bit more about demystifying what DevOps really is. But it’s people, processes, and tooling. Tooling is a small piece of it.
J. Steadman: I love this. Okay. So first I love whenever we have a demystifying topic, right? I feel as though in tech, even when we are trying to be very inclusive and we’re trying to avoid gate keeping, there are certain concepts that can be just really, really fuzzy. Especially because we often have experts talking about them to other experts. And so since we’re like really emphasizing demystifying developer operations here, and you’re bringing up that it isn’t just technology. It’s people process and tools. I think this is like a great place for us to start. So if you were to take a first step toward really making DevOps accessible and understandable to our audience, where would you begin?
Gloria Ramchandani: Yeah. And I’d love to just tell a little story about my background. I started out as a Salesforce admin, and that was back in… When I landed my first Salesforce job, it was 2012. And this is when Steve Molis was probably the most popular person in the community and who I relied on to do my day job.
J. Steadman: He may still be.
Gloria Ramchandani: And so I feel like DevOps, when you think about the term DevOps today, I think there’s a misconception of, “It’s only for developers. It’s not for admins.” And when I think about my experience as a solo admin going in and doing configuration, managing the planning aspect of what features we need to roll out at what timing, the roadmap. And once I moved on from my admin role into consulting, in consulting I really wore a lot of hats. I was a BA, I was a configuration consultant and I was a release manager for a really long time.
But a release manager, back in 2013, was really different from what a release manager does today. And at that time, there were not that many tools out there. And so, when I was a release manager, I would spend a lot of my nights and holidays and weekends… And I’ll never forget my first production deployment. My first production deployment was for a company called [inaudible]. It was over 4th of July weekend. And I remember this so vividly because we had to drive up to Charlotte to go and stay with my in-laws over the weekend. And instead of hanging out with the rest of the family, I was actually up in my father-in-law’s office.
J. Steadman: Oh, no.
Gloria Ramchandani: I know. And the reason it’s so memorable is because I spilled coffee all over his desk and I will never forget that. But that production release took me a total of three to four days. And it was not so much of the release itself that took time, it was the trial and error. It was the planning around what actions you take first. So we had a long RACI matrix of who does what, and at what time it needed to be done. And we used [inaudible] scripts at the time. So I feel like I’m dating myself in the Salesforce ecosystem, but it was a pretty manual process back then. And it was so painful and sometimes I feel like if you don’t feel pain, you don’t really feel the joy and efficiencies once the process [crosstalk].
J. Steadman: Ooh, interesting.
Gloria Ramchandani: And so release management for me was the… The pain that I felt in release management was enjoyable in some self inflicting way because it took so long. It took so long to perfect it. And it was you kept trying to deploy. And then when you got it, finally got a successful deployment, it felt so good to get that successful deployment into production.
And I would say that is the first time that I opened up my world to DevOps, to really release management. And it was eye opening for me because it was less about the [inaudible] scripts themselves and the tooling, but it was more about the organization of the work. And when things got done and the people, the team that we had to support it, it wasn’t just me. We had our tech arc involved, we had our business analysts involved. And it was really us accomplishing the production release as a team. And I think that’s what’s so beautiful about DevOps. Is it’s not just the tooling at face value. It’s all the planning that comes with it and the processes and the procedures, and really how you collaborate together as a team.
J. Steadman: Okay. So for those of you that are listening along, a few things that I’ve heard in this conversation that I think it’s important to underline and maybe explain a little bit as well. Early on Gloria, you said that you had picked up a role as a BA and a configuration consultant. For those of you listening along, business analyst is a BA. We’ve talked about business analysts before in the past. And you talked about a RACI matrix. RACI matrix are something that we use here internally at Salesforce as well, particularly on projects that need a lot of eyes on them. And I just want to break that down for our listeners a little bit. RACI is spelled R-A-C-I. And a RACI matrix, basically identifies line items. And then in those line items on a project who is responsible for that line item, who may be accountable for that line item, who should be consulted on that line item and who needs to be informed on that line item.
And in my experience, and Gloria I’m sure that you have the same experience here as well, defining these roles on particular tasks in a project can be incredibly helpful. For example, if I need to be informed on something, I know that I don’t need to be responsible for it. So I can read up on it, I can make sure that I have relevant information, but I don’t need to feel as though I am making decisions on it. So it gives me a really good understanding of how I’m supposed to contribute to the project.
Gloria Ramchandani: Exactly. And I think in today’s age, when we think about Salesforce development and also even being in an admin role, there’s so many people involved with a single deployment. And so, having something like this is really helpful in clarifying and defining roles and responsibilities, especially in a cross-functional environment when you have multiple departments, multiple types of roles. And everyone really needs to align on a greater process and that’s why I feel like it’s so great to have something like that, especially when we’re talking about devOps and coordinating teams.
J. Steadman: So that’s fantastic. I love the idea of having a structured way of assigning cross functional teams, who is doing what, and what level of involvement they have for all of these things. It also keeps a single source of truth for a release, right?
Gloria Ramchandani: Yes.
J. Steadman: As you mentioned, you were initially at a place where you were a solo admin, but then you moved into a functional role. And then throughout your career, you’ve now moved to this place where you are Senior Director of Strategy and Business Operations at a place Copado, that focuses entirely on developer operations. And it’s really important that you’re able to identify who is doing what, when, and where. Especially as you’re working in orgs that can be a variety of different complexities. And as you get closer and closer to the complex end of the spectrum, you want to make sure that you definitely know who is doing what because you don’t want collisions, you don’t want overwrites, you don’t want errors of that nature.
Gloria Ramchandani: Exactly. And I think just one reminder. A reminder that DevOps is as much art as it is science. So using your knowledge and recommendations from the community, trust your instincts and share what you’ve learned from others. Because the whole purpose of DevOps is collaboration and working together to continuously improve.
J. Steadman: Yeah, I think that’s one of the things that is often overlooked as organizations are looking at development methodologies. Maybe they’re using DevOps, maybe they’re going pure agile. It is actually vital for the business and IT to talk with each other on a regular basis. That communication doesn’t have to be spoken words. But that communication of information flowing between relevant parties that is crucial to making sure that any releases that you’re planning to push to production are high quality and low risk.
Gloria Ramchandani: Yes, exactly.
J. Steadman: I really like too, that you said, “If you don’t feel the pain of an experience, you don’t feel the joy when efficiencies are brought to that experience.” I’m finding no matter who I’m talking to on the pod… I’ve talked to developers, I’ve talked to architects, I’ve talked to other admins and now I’m speaking with you about developer operations. Everyone seems to have this inciting incident that involves a memorable moment where something was just really hard to do. And the folks that I’m speaking with, including yourself, it’s suddenly an invitation, that they want… Like, “I want to know more about this. I want to do this better. I want to alleviate the pain for other people.” Which I very much adore.
Gloria Ramchandani: Yeah. And I feel like I get the question all the time of, “Why did you join Copado?” It’s a DevOps product. And I really strongly feel like if I did not spend those nights and weekends doing all of these releases, I probably wouldn’t be where I am right now. But I just feel like DevOps, there’s so much room for automation, there’s so much room for efficiency. And that’s why I really love what I do. I really believe in our mission is really ending release days. And I feel like the better that you can get at DevOps and working together as a team, the more time that you can have back with your family and with others so that you don’t have to spend a weekend doing a release.
J. Steadman: And when you talk about ending release days, it feels to me like you are referencing the golden ticket of continuous delivery and continuous deployment. Am I right in saying that?
Gloria Ramchandani: Yes. And there’s an acronym in DevOps, CI/CD. And not many are familiar with what that means. CI/CD, continuous integration, the CI portion, that’s really what CI stands for. And continuous integration, it’s really a coding philosophy and a set of practices that drive your development teams to implement these small, bite size changes and checking your code to a version control repository more frequently. And because most modern apps, they require developing code and different platforms and tools, the teams really need a mechanism to integrate and validate their changes.
Now, CI again, continuous integration, is the first part of that CI/CD term, but then we also have CD. And continuous delivery really picks up where continuous integration ends. And so, CD actually automates the delivery of applications to selected infrastructure environments or Salesforce environments. And most people these days are really working in multiple environments. And so the term CI/CD really brings together this philosophy of continuous integration and then continuous delivery and continuous deployment.
J. Steadman: I love that. So we’re taking the code, we’re bringing it together all of the time. And we’re taking that code, which has been tested and verified that it’s safe. We are delivering it all the time. That is if we get to that point of CI/CD.
Gloria Ramchandani: Yes. And I would say the state of Nirvana is really when CD automates the delivery. When you have automated deployments on demand, that is level five in maturity for DevOps. You’ll hear a lot of these terms with DevOps, but the goal is to… And this goes back to a lot of the concepts in the Toyota production system. For those that are not familiar…
J. Steadman: Lean, I’m familiar with this.
Gloria Ramchandani: I feel like I’m bringing out a lean six Sigma black belt. But for those that are not familiar with the Toyota production system, I actually recently learned this and so I’m happy to explain. But Toyota did something very fascinating, right? And if you Google it, you can Google the Toyota production system. And a lot of the concepts within the Toyota production system go back to concepts around efficiency. And there’s a lot of terms around defining waste. Waste in a manufacturing plant. How do you get faster at manufacturing?
And these concepts in manufacturing were actually later adopted by software delivery. So the concepts of eliminating waste, continuous improvement, continuous integration. These, we were much later in discovering these when we were building software. They were actually founded in manufacturing. And DevOps includes some of these concepts. And so, for me, when I think of DevOps, I also do think of lean. I do think of, in a process, where can you eliminate the waste? Where can you move a little bit faster? And some of that may go back to automation, right? And that’s where the Salesforce platform is so relevant. Is when you’re thinking about efficiencies gained, thinking about even on the platform itself, where can you automate your processes with flow? Where can you automate your processes with page layouts and dynamic forms? And there’s so many ways to look at it. And so, that’s why I feel like DevOps is so much broader than just moving changes from one environment to the other. It’s about the whole process surrounding software development.
J. Steadman: Absolutely. I love that you brought up the Toyota system. I was introduced to it right when I was starting my own Salesforce career. I started around the same time you did 2012, 2013. And it was really fascinating for me to learn the way in which, kind of menu factoring managers, but also individual employees, kind of all co-owned a process together. And what was interesting is I learned those concepts first and then I got into software. And I just kind of took some of that with me. And then I found out about agile and I was like, “Ah, agile is essentially just lean but for software.”
For the admins that are listening here, we’ve been talking recently about essential habits and we have just recently re-released the essential habits in a new format on Trailhead. And in our essential habits, we actually talk a lot about some of the key aspects of this approach. It involves, in the Toyota method in lean, they refer to going back to the gemba, which is a Japanese term, which means the working space. And Salesforce admins, we are very passionate about going and talking to our users on a regular basis. And making sure that we are communicating with our users, finding out what isn’t working for them. Discovering bottlenecks, learning how you can remove the bottleneck. And that process never stops because you remove one bottleneck and then what happens?
Gloria Ramchandani: Find another one.
J. Steadman: That’s right. There’s always going to be a bottleneck. This is great.
Gloria Ramchandani: Yeah. And it’s so relevant to… Going back to my consulting days, one activity that I had to do, which was actually a lot of fun, it was super exciting. I was doing a service cloud deployment. And as a part of that digital transformation, we were working with a call center. And when you talk about that term, going back to where the users are and the actual place where the real work is done. As a part of our discovery work, I had to spend 72 hours in a call center. And my sole job was to sit next to the call center reps and observe how they took phone calls and what their pain points were. And for me, that was so eye opening because as a consultant, or even as an admin, you get so lost in requirements.
As you’re building through your requirements, you have your roadmap, you have your change management plan. But very few people go back to the actual place where the real work is done to observe what the real pain points are. And after I spent those 72 hours with the call center agents, I really revisited what we were prioritizing and I began to ask questions like, “What is going to truly provide value to the end users?” Our customers, and our end users at that time were the call center agents.
And I think that exercise really needs to be done in every area where you’re building software. Regardless of if you’re doing a service cloud deployment or sales cloud. Or in my scenario, when I’m working on DevOps software, people really need to go back to the actual place where the real work is done and really ask themselves, “Where are we truly delivering value?”
J. Steadman: Yeah. And so we’ve got this idea, right? We’ve talked a little bit about your background and how your interest started to develop around DevOps. And now we’re talking about these foundational principles of developer operations. Going back to where our users are and learning what they are really struggling with so that we have good user stories. We’ve got great requirements gathered. And then, inevitably, we have to do things like prioritize those stories, right? We have to have our developers develop those stories. We need to make sure that our developers are testing those stories. That they are integrating all other, their code together. Or for admins, configuration is all being put together into a single environment and tested together.
We need to run a suite of tests to make sure that we aren’t introducing any regressions into our org. And then eventually, we got to get to a point where QA is looking at everything. They have rigorously tested it from a QA perspective. We’ve got user testing where we’ve got users that have to come into an environment, touch everything, perform their daily tasks. And then finally, we get to release. And the reason that I just threw all of that out, like [pah pah pah pah pah] is because when you talk about organizing people and process and technology and tools there’s a lot of moving parts in what I just outlined.
Gloria Ramchandani: Oh, there’s tons of moving parts. I mean, it’s all the way starting from the planning cycle like you had mentioned, like planning your work, your stories, your release planning, your resource planning, building and actually doing the development. And then move being through test and delivering. And I think all of those are critical pieces to the overall DevOps process.
J. Steadman: And so, let’s say that we’ve got an admin that’s out there in listening right now. And they say, “Whoa, that was just so much. There’s no way that I’m going to go from what I’m doing today, which is…” And this is against all recommendations and advice, but there are admins out there who are really strapped for time or they’re under-resourced. And so they’ve got to make a few changes directly in production and they hope that it doesn’t cause an issue. And we just laid out all of this organization around people and process and tools. But I want to ask you, I have my own opinion on this. Does it have to be all or nothing, or is DevOps a process that you can continuously improve and start to grow toward?
Gloria Ramchandani: No, I don’t think that you have to do all of these things. I think that there are different levels of maturity in DevOps, right? There’s definitely those that are coming in that I would say are just entry level to DevOps. It’s just situational awareness. You’re getting familiar with your planning cycle, maybe some level of version control familiarity, but I would say that’s not even required. And then I would say, as you move up the various levels. When you move to up to step two and then step three, step four, step five, I would say that the fifth level of maturity, the most advance is when you have a large team. That’s really when it’s critical, is when you’ve got hundreds and hundreds of developers. At that point version control is really critical because when you’re merging your changes, you want to make sure that work is not getting overwritten.
When you’re releasing you want to make sure that you’re not introducing something that’s disrupting the business. You’re not introducing another bug that’s going to take a feature down. And so I think there are various levels of maturity. I don’t think that you need to be doing all of it. And I think that if you can even just get to step one, which is just awareness of DevOps, I think you’ll be successful because even for those that are solo admins, and I think of my time as an admin. I think what’s most critical is getting a good handle over the planning cycle.
When you are in an admin role, you’re getting so many things thrown at you from various departments. And I think the prioritization exercise is really critical. And understanding what is going to deliver the most value to the business or create efficiencies. If sales is a priority for your company and you want to help the sales team grow, maybe thinking about where are they going to gain some efficiencies and save time. What’s time savings versus what’s going to generate new revenue?
J. Steadman: This is fantastic. And I’ve lived this kind of in my own experience, as I was moving various external Salesforce roles where I was a customer or I was an admin or a consultant or a product manager at a variety of different orgs. So you’re talking about business prioritization. And what I find often is for Salesforce professionals, especially… So Salesforce isn’t always owned by IT, right? Sometimes Salesforce is owned by the business and in other times, Salesforce is owned by IT. And that can create its own series of challenges wherever you end up. Either side of the coin, you’re going to have some pros and some cons.
I love that you brought up this idea of business prioritization of these stories. I’ve often been in the situation where I’ll get kind of this relentless list of things that the business wants, but the business is totally separated from any kind of prioritization or value conversation for those things. And that makes it really weird as a person who is tasked with configuring changes and delivering value to the business, when you’ve given me 55 different user stories and requirements and I don’t know which one of those is most important to you from the business. That causes quite a mess. So as we look at this idea of Salesforce DevOps on a maturity scale… I saw this image once that I really like a lot, that of an acorn. An acorn when watered grows into the mighty oak.
Gloria Ramchandani: Yes.
J. Steadman: But initially it’s just an acorn. And for a lot of folks, the acorn could be a single view of all of your requests for Salesforce enhancements.
Gloria Ramchandani: Yeah. And I’m laughing on the inside because I think every admin experiences this, so you are spot on.
J. Steadman: And I encourage any admins out there right now that are struggling with getting the changes that the business wants into production. Take a moment and ask yourself, are all of your requests coming in through a single channel? Or are you aggregating all of those requests in a single and visible channel? And when I say visible, I mean, you want the business to be able to see all of the requests that are coming in. And there are a variety of ways that people handle this. I’ve been at some companies that actually have the backlog on a public screen. So as you’re walking around in the office, you can actually see what the backlog is. And if you work at the company and you see something that’s not valuable, you’re going to talk to your manager about it. Your manager’s going to talk to the developers about it, whatever that might be.
So whatever transparency means for you. In my previous life, this is, I think just before Copado was entering the scene. Is like a full DevOps tool and other partner tools weren’t really available on the app exchange. We just used cases. We used cases, we created a creator case form. Anyone who had an enhancement request would submit that way. And then I had a business council. And that business council was like six people, leaders from each of the different kind of legs of the business. And they would all be able to vote and give a point value to each of those user stories. And it was based on business priorities.
Gloria Ramchandani: Yeah. And I think tooling, prior to Copado even entering the market, we used spreadsheets. We used Google sheets and that’s where our backlog was. So I think there’s tons of tools out there. Use what works for you, but transparency is the key. And I love the platform. I love the Salesforce platform because you have that collaboration aspect. So I think I would encourage people to move towards the platform because you can utilize chatter and just some standard platform features to bring visibility into your backlog or what you may have on your roadmap.
I think relentless prioritization, when I was an admin… And then you talk about the story about different departments coming to you with requests. I think every admin lives that. And for those admins out there, what’s really funny is I was an admin for years and then I was a consultant. And when I was looking to get into product management, I had someone tell me that I didn’t have a background in product management so I could never do product management.
J. Steadman: Meh.
Gloria Ramchandani: But I want to make a statement for everyone. That’s listening to this. If you are a Salesforce admin, you already are a product manager today. You are doing relentless prioritization. And this is what product managers experience day in and day out. Is hearing customer requests, except your customer is your various departments. So I think that that is a critical skillset in being able to take feedback from multiple sources and prioritize based off of some sort of voting scale. Or prioritization scale based off of what methodology you follow. And I want everyone that’s in an admin role today to just know that they are product managers today for their CRM tools.
J. Steadman: Absolutely. Admins have so many responsibilities. And very often, our admins are product managers, our admins are release managers. And when we say release managers, we mean the person who is aware of and owning the package as it moves from environment to environment and ultimately is deployed into that production environment. I have to say I actually think I track a pretty clear correlation between hospitality and restaurant hotel work and what we’re talking about here. And I’m going to say, to me, for folks of you out there who haven’t worked in a restaurant or worked in a hotel, this might not be as clear to you. But the operational aspect of a restaurant, the throughput, for example, I’m more familiar with restaurants than I’m with hotels, I’m going to stick with that. It’s kind of an allegory.
To be able to get the food from distribution, shipped into your restaurant, prepared so that it can be cooked by a cook after a server talks to you at the table, making sure that everything comes out on time and beautifully done. What we’re talking about is continuous delivery of food to mouths. It seems to me like there’s a really good connection here.
Gloria Ramchandani: And I’ll give you the term for that. That’s actually called lead time.
J. Steadman: There you go.
Gloria Ramchandani: The lead time that it takes for you to deliver the food to the table. Lead time is a DevOps term that’s very popular. But that’s how long does it take to get a feature from the planning cycle, all the way to production and released.
J. Steadman: And I think this example is probably our most powerful example of demystification and it’s probably a great place for us to end the conversation. But if you go to a restaurant and you order a Caesar salad, and a friend of yours who orders from the restaurant orders a four inch thick pork chop, the lead time on those two requests is very different. That Caesar salad can be made in a minute, minute and a half. But that pork chop, that needs a lot of time on the grill so that it can cook appropriately.
And as we think about managing releases, when we think about the effort or the lead time that it takes to get something done, you have to start the pork chop first, work on it for a while, and then just as you’re about to throw that pork chop on the plate, that’s when you go ahead and tell your garde-manger or your salad person to make that salad so that they can go both out at the same time. And your diner, one of them experiences a really fresh, crisp, delicious, cool salad and the other one has a piping hot, perfectly cooked pork chop.
Gloria Ramchandani: Exactly. I couldn’t have said it better.
J. Steadman: This was a good conversation.
Gloria Ramchandani: And now I’m hungry.
J. Steadman: Thank you so much for joining us. Yeah, now it’s time to go and eat some food.
Gloria Ramchandani: Yes, I think I’m going to resort to Chipotle for lunch today.
J. Steadman: Ooh, nice. I am a fan of the quick casual Mexican cuisine. Maybe I’ll do the same thing.
Gloria Ramchandani: Awesome.
J. Steadman: Awesome. Well, thank you so much for joining us today, Gloria. I will have some links in the show notes for some of the stuff that we’ve talked about today. And I’m so excited that we had a chance to talk with you about demystifying DevOps.
Gloria Ramchandani: Thank you. Thank you. Thank you, J.
J. Steadman: If you want to learn more about all things Salesforce admin go to admin dot Salesforce.com to find more resources, including all the links we mentioned in this episode, as well as a full transcript. You can stay up to date with us on social. We are @SalesforceAdmns on Twitter. I am @J__mdt. And you can reach Gloria @ThisIsTechChat. Stay safe, stay awesome, and stay tuned for the next episode. We’ll see you in the cloud.
Today on the Salesforce Admins Podcast, Admin Evangelist Josh Birk sits down with Kat Holmes, Chief Design Officer and EVP at Salesforce. Join us as we chat about diversity, accessibility, and her book, Mismatch: How Inclusion Shapes Design. You should subscribe for the full episode, but here are a few takeaways from our conversation with […]
Today on the Salesforce Admins Podcast, we talk to Lizz Hellinga, Consultant and Salesforce MVP. Join us as we chat about why product management principles in Salesforce are crucial if you want to take advantage of new AI tools. You should subscribe for the full episode, but here are a few takeaways from our conversation […]
Today on the Salesforce Admins Podcast, we talk to Tom Leddy, the Product Director of Decision Guides at Salesforce. Join us as we chat about decision making in the age of AI and why cleaning up your data is more important than ever. You should subscribe for the full episode, but here are a few […]
