Admin Identity with LeeAnne Rimel and J. Steadman

On this episode of the Salesforce Admins Podcast, we bring on Principal Admin Evangelist LeeAnne Rimel and Lead Admin Evangelist J. Steadman to discuss identifying as a Salesforce Admin.

Join us as we talk about what it means to identify as a Salesforce Admin. 

You should subscribe for the full episode, but here are a few takeaways from our conversation with LeeAnne Rimel and J. Steadman.

Becoming a Salesforce Admin

The title of Salesforce admin can often be hard-earned. LeeAnne had to lobby for the title to make sure her instance got the support it needed. “At that point in my career, I really didn’t know that there were other names that the people who managed the Salesforce instances were called,” she says. Even today, “a lot of employers don’t know how to ask for a Salesforce Administrator and a lot of Salesforce Administrators don’t know if people know what they do”

“I printed out the certificate I got after my cert and hung it on the outside of my cube,” J. says, “and I got a lot of really strange looks.” But he was so proud of getting his certification that he would tell anyone who listened. There was a lot of pride around being a Salesforce admin, but also a lot of ambiguity around what that title actually meant.

Hybrid Titles and How the Ecosystem Is Changing

Some admins used hybrid titles like “declarative developer” or “citizen developer” or even “admineloper.” The desire is to express that admins do things above and beyond what people think a typical system administrator is capable of. You’re building Flows and custom objects and fields, but you’re still the Salesforce administrator.

“There was a point in time when we had to make modifications and additions to how we talked about Salesforce administrators in order to translate it to the type of work that was happening in the technology hiring ecosystem,” LeeAnne says. But now, the unique skillset that admins have calls for a greater sense of community around the role, and a larger view of what admins do in general.

Podcast Swag:

• Salesforce Admins on the Trailhead Store

Social:

• Technically, Everyone Is "Technical"
• April Wensel: @aprilwensel
• LeeAne: @leeanndroid
• J.: @J__MDT
• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

Full Show Transcript

Mike: Welcome to the Salesforce Admins Podcast, where we talk about product, community, and career to help you become an awesome admin. This week, we're switching it up a little bit. I am talking with principal admin evangelist, LeeAnne Rimel, and lead admin evangelist, J. Steadman about identifying as a Salesforce admin, really putting that in your job title, assuming that identity and all the different variations and terms that seem to be out there. So, it's a fun podcast, I love our discussion. Let's get LeeAnne and J on the podcast. So LeeAnne and J, welcome to the podcast.

LeeAnne Rimel: Thanks so much for having us.

J. Steadman: Yeah, thank you.

Mike: It's been a while since we've chatted, J, I feel like it's been an episode.

J. Steadman: That's probably true.

Mike: Probably true. One thing to talk about, so we've delved deep into a few different topics in the month of December, and I'm hoping everybody enjoys these podcasts while they put up some holiday decorations or something, maybe make some party mix. But one thing that I had always come up on my radar and I know LeeAnne it's come up on your radar and J as well, because you do a lot of volunteering with Pathfinders is the term Salesforce admin, and how we see it pop up in different pieces of content. So I know the term has always been pretty close to me. I've always identified that way and never really chose to use a different nomenclature, but I would love to get your thoughts on that as we kick off this discussion.

LeeAnne Rimel: Yeah. That's a big question, right? What does Salesforce admin mean? I know my own personal history with the name. I became a Salesforce admin, that was something I really aspired to. About 14 years ago, I was working for Kaiser Permanente and I was doing database work, and I was really trying to take over our Salesforce instance basically. And I had to lobby to get my title changed, to be the Salesforce admin, so I owned our Salesforce instance and I could guide it and make decisions about it and advocate for budget that we needed to fix it. And so it was interesting for me when I joined Salesforce because I didn't really know that there was other names that people called the people who manage Salesforce instances at that point in my career.
And so I feel like one of the things when we work with the admin community is we really spend a lot of time sometimes sifting through the different names and the different language that people use to talk about the job duties and the role and the individuals who manage and implement Salesforce, right? So that's a little bit of my, I guess, background with that job title or label or whatever we want to call it. And to me it's always been a little bit interesting, I think, probably because part of my own history was that I really wanted that role, and I really was so proud to build that into my career. So I was a little surprised and had to understand more when I saw that, that's... I think a lot of employers don't know how to ask for a Salesforce administrator and a lot of people out there don't know if they say Salesforce administrator, if people will know what they do.
And so Mike, and I know we've spent a lot of time talking and working on this, how do we help everyone know what Salesforce admins do and how do we help people understand what the job does both on the hiring and the job candidate side?

J. Steadman: Yeah, on my side of things, I had a very similar experience to you, LeeAnne, when I became a Salesforce admin, this would be, I think, 2012 I accidentally admin-ed myself, and I really fell in love with it. I really sought out that title of Salesforce administrator and surprised people at work by going out and getting my credential. And I printed out the certificate that I got after I passed my cert and I hung it on the outside of my cube, not the inside of my cube, and I got a lot of really strange looks. Very small company and people were like, "What are you doing?" And I was like, "Well, let me tell you," and I would explain it to them. And it was really, really exciting, right?
I think as I consider the title, Salesforce administrator and our awesome admin community, and I think through other terms that I've seen float around in various places, what I think I often see is people or the intent... We see phrases like declarative developer or Mike, I think you were telling me about you saw a portmanteau of admin and developer that was admineloper or something like that.

Mike: Yeah. I've seen that pop up in a few presentations, admineloper.

J. Steadman: Yeah, I think the intention is less about... And this is just my gut, right? I don't have any hard data on this, but I think... my gut tells me that system administrator is a title that has existed for a very long time before Salesforce came around, right? And I think people are... they want to differentiate themselves and they want to indicate that the skillset that they have may go deeper than what a traditional system administrator does.
And so some of these other terms pop up here and there, but I think what's unique about Salesforce and Salesforce administration is that a Salesforce administrator is an individual who is doing declarative development. That's the thing that you're doing, building flows, right? But you're still the Salesforce administrator. You're building custom objects in fields, but you're still the Salesforce administrator. You are meeting with the business and gathering requirements, but you are still the Salesforce administrator. And it makes me consider what is a Salesforce administrator and why do we like this title? Why do we hold onto this title? And for me, at least being a person who has only recently joined the team about six months ago here in the evangelist group, there's community, Salesforce administrators unite. If I were to say that, the Power Rangers Voltron around a bunch of people would suddenly rush into the room and we'd be able to solve an awesome problem. But if I were to say admineloper unite, I'm not sure that I'd have that same community that would respond.
So for me at least, I have talked about things like declarative development in the past to differentiate the way in which I develop business logic, which is through declarative tools, and yet I remain a Salesforce administrator. And I think that the power of our community and the breadth of what we do, that's what defines us as Salesforce admins.

LeeAnne Rimel: So two things jump out to me from that J, one, I had to look up what portmanteau was. Thank you for adding a new word for [crosstalk].

J. Steadman: It is a combination of two words. Yeah.

LeeAnne Rimel: Well, I now know this because I dictionary.com-ed it really quick. And from what you're covering, is how that importance of having that common shared language. And it almost feels like sometimes there was a point in time when we had to make modifications and additions to how we talked about Salesforce administrators in order to translate it to the type of work that was happening out in the technology hiring ecosystem. I think we felt like we had to add things maybe to our resume or to our title or how we described ourselves to maybe when there wasn't as big of a Salesforce ecosystem, there wasn't as many admins, there wasn't as many customer companies. And then now on the flip side of that, it becomes more important to use that common language so that we can leverage the power of the community and connecting with others, and accessing those best practices, those recommendations, that community element of what are those duties in my job? What are those things that I should be doing? What are those skills I should be developing? What type of roles should I be looking for?
Where language should change as the landscape changes, and so maybe where it did at times make sense 10 years ago to say, "Yes, I do a lot of declarative development or I'm a citizen developer on Salesforce," or whatever language you're using, it's like now employers know what they're looking for, for the most part with Salesforce admins. They know what a Salesforce admin is for the most part, they know what that job is, so now it becomes more important to rationalize and update our language.

J. Steadman: Yeah, I agree. And I think it's interesting when we look at the work that admins do, right? We build reports and dashboards, we can modify the objects and fields, again, the schema, we build business logic, we maintain pages, we manage users, we make sure that our data is clean. And most of the time when I see folks starting to waffle around the title admin, it's usually when we're playing around with that business logic piece. And it feels to me like there's this implicit belief out there perhaps that if I'm touching business logic, that must mean that I am thinking like a developer or I am doing developer work. And while configuration in this way is in fact development, it's well within the purview of the Salesforce administrator. And to anyone who's listening that has strong feelings about things being done in an org, I'm talking about doing things the right way, of course. There is a right way and a right solution to choose, and declarative solutions are not always the right tool to choose, but it is possible to have well built, well configured, declarative business logic.

LeeAnne Rimel: Well, and I would say actually that should always be evaluated first.

J. Steadman: Yes, of course. Upfront you want to say, "Hey, we have this business challenge or this business objective or this requirement." And then hopefully at our business, we have established what we would consider to be our design standards. And we have determined which solutions are appropriate, given the requirements. And then we go ahead and we design and we build those solutions and then of course they get deployed. And yet no one that I'm aware of is really concerned about calling themselves a data scientist or an analyst if they're building reports and dashboards. This name differentiation that I tend to see usually orients itself around folks that are touching business logic.
And it's interesting because one of the things that I've been most drawn to is I've grown through the past nine or 10 years on the platform is this ability to bridge communication and organizations between Salesforce admins and Salesforce developers. Realizing that we're all part of the same larger team, or we're all on the spectrum or the rainbow of doing stuff on the platform together. And I'm curious if either you or Mike, have thoughts about this. What feels to me like an implied division where, "Yes, I can modify the data structure. Yes, I can design solutions. Yes, I can modify pages and give a better user experience and design things well for my users, but if I touch logic, then I have to make sure I'm telling people that I'm doing something different." Where do you think that comes from? Is that something that you see as well? Is that something that I'm finding just in my own anecdotal experience?

LeeAnne Rimel: I don't know that I've seen... I don't know that I've seen as much of that, as much of the hesitation to embrace the business analysis piece as an admin. I feel like what I encounter or in my experience working with admins more often is that... Well, I'm thinking about these experiences with admins and this compulsion to feel like they need to sometimes adjust their title in order to feel legitimate in the work that they're doing. To me, I feel like that's what it boils down to, right? No matter what the subject matter area is, it feels like sometimes there's times that Salesforce administrators feel like they need to add a lot of asterisks or a lot of addendums to their title in order to feel comfortable occupying the space that a Salesforce administrator occupies.
And I don't know if those pressures come from... There's rampant, toxic elitism in the tech industry, there just is. It's just reality, it's not unique to Salesforce, it's not unique to developers, it's not unique to... It's just there. And we talk a lot about imposter syndrome and toxic elitism. And so I don't know what those forces are that make people feel sometimes like they need to claim some different language in order to feel valid or comfortable doing that work. To me, it comes down to feeling empowered to do the work that you're doing and to not feel like you have to. Because also at the end of the day, a title's a title. It's to embrace the work that you're doing, to embrace the community that you're a part of.
And I always found the admin... And people used to talk about admin to developer, admineloper and all of that. And I was an admin who coded, but personally, I never had any interest in becoming a full-time developer. My personal opinion is that the declarative platform is just incredibly, incredibly important for Salesforce and for the community. And you can be a really, really good admin without knowing how to code. I think you cannot be a good developer without knowing how to do declarative work. I've seen a lot of really messy orgs when people tried to go code first. It's like, "Oh."

J. Steadman: Cosigned. Yeah, me too.

LeeAnne Rimel: "Tell me more about your entirely custom built forecasting platform because you didn't know we had a forecasting..." I don't know, so I think some of it is just leaning... It's that comfort. How do we remove some of that or mitigate some of that toxic elitism that comes with the language that we use and who deserves to be in what space, and where do Salesforce admins belong?

Mike: I think one of the things running LeeAnne off of what I heard from you, there's a few things that I took from what you and J said. I think the name differentiations seem to be caught up in the admin world often around the task that the admin does or tasks, right? And so I was trying to think of another industry where more than one word exists for... And I think title's different than identity, but for an identity.
And we say adminelopers like, "Well, I'm really an admin that writes some code." So you're an admin, right? Or J, you said build a lot. You could call yourself a builder, but it's often encompassing. So often I have to identify myself as a Salesforce admin first and then also attach all of the tasks that I do. I'm a Salesforce admin business intelligence analyst, I have to tack on all of the things that I have to do, whereas I'm sitting back and I'm thinking like, "So why don't airplane pilots do that?" Because you walk up, go to an airport, talk to somebody, they could introduce themselves, "I'm an airplane pilot." They don't tack on all of the tasks that they do.

J. Steadman: And I also navigate.

Mike: Yeah, and I also...

LeeAnne Rimel: I like to land.

Mike: Yeah. Well that's exactly what I was... LeeAnne you took my example, but-

LeeAnne Rimel: I'm sorry.

Mike: ... nobody says, "I'm an airplane pilot takeoff specialist." No, they just, "I'm a pilot." There's tasks that I do, and I'm wondering if it's because it's such a new identity in the space because we don't talk about developers in the same manner.

J. Steadman: I think it's important too to... You have introduced a new concept here in the conversation. Not only is it a new identity, but the technology that we work with, the Salesforce platform is something that is continually evolving, growing and changing in ways that are unique. So you could be a Salesforce administrator and the stuff you could be using, maybe messaging like Slack, integrations like MuleSoft, data analytics like Tableau or Tableau CRM, or core platform where you're making custom applications, a mobile application. You could be an admin, that's only doing reporting. You could be an admin that's only doing user management. I've met admins that are doing all of these things or any combination thereof, not to even begin... What about the various clouds that we have? Sales Cloud, Service Cloud, Experience Cloud, right? There's so much stuff and that hasn't always been the case.
I think maybe I'm suddenly like chaining us to a really heavy load to lift, but it makes sense then that sometimes people would feel a little bit... If what we have to do is communicate what it is that we do with our title, which we often do in short conversations with folks, and communicate to them that they can trust us. We have to establish trust with the people that we talk to in our business, our stakeholders, our users, it can be important to convey to them the things that they need to hear. And so it falls to folks like us, Mike you, LeeAnne you, and myself and Jen and the rest of the broader admins relations team. Part of the burden is we got to make sure that it's really nice and easy to convey some of those things, which excites me about some of the work that has been done recently on the team.
We previewed some of this content at Dreamforce where we talked about admin skills and the responsibilities. We've got the great Essential Habit series that has been around for a very long time, Mike, with the work that you've done. And I think in the way that I'm sitting and looking at it, it's important for us to make sure that admins understand very clearly that, "Hey, if you write some code, great, you can still be an admin. Hey, are you using Flow Builder all the time? Great. You can still be an admin." The idea that you're using a developer's mind as opposed to a builder's like, "Yo, you're doing business logic [crosstalk] in the platform, that to me sounds like admin, good job." And that one should be proud of those things.

LeeAnne Rimel: Yeah. I think you gave a really S overview there, J, and something that really sticks out to me is that sense of you're not using a developer's mind or you're not using... this is encompassing of the role of Salesforce admin, of the identity of Salesforce admin. And I think, I know I'm a broken record with this stuff, but I feel like a lot of it comes... To me, I feel like a lot of it comes back to some of the forces out there around tech language and around the language of who is technical that's... If you want me to go off on a total rant, someone will say that someone isn't technical because they don't code, because what does technical mean? It means you use a tool to accomplish a task. That's what it means. And so when we gatekeep words like that, I think some of the residual effects is that it makes people second guess some of the titles out there, second guess themselves and their legitimacy in claiming some of those titles and what it means for them.
Whereas I feel very strongly like if you can build something with a tool, then you are technical. You might be a marketing expert in building a complex email campaign. You might be building out a bunch of automation for your social channels as a social media professional, that means you're technical. And so I think the more that we move away from gatekeeping some of the words that are out there, I think that makes it feel safer for people to really embrace and feel like, J you said pride, and I feel that really deeply, feel pride around their accomplishments as a Salesforce admin, for example.

J. Steadman: I imagine these bubbles floating above all admins, right? And they are the various responsibilities that they have at work. And everyone has different bubbles colored in. One bubble is reports and dashboards, one bubble is data cleansing, one bubble is integration specialist. You can go on and on and on about the various core responsibilities they may have in a day-to-day. But when I look back at my previous work life as an admin and the various titles that businesses can give to that role, but I was working as an admin. I had a peer who had full access to production and who was entirely responsible for interacting with our users there, but I was his peer and I didn't even have access to production. My entire life was in our low environments and doing discovery and building things, using Flow Builder, using Process Builder at the time.
And those are two very different things. If somebody at that org had asked me to build a report for them, I would've had to scratch my head and be like, "Can you tell me more about what you're trying to do?" And I bring this up to say, no matter how many bubbles you have filled in, no matter what your core responsibilities are, no matter what cloud you might be working in, you are a Salesforce admin. Our platform, it's like an ocean of stuff. And maybe when we're trying to differentiate ourselves, we focus more on the conversation about what our, "Hey, this is a responsibility I have. I'm a Salesforce admin at X, and I am in charge of A, B, C and D."

Mike: I like that. LeeAnne, your concept of technology and the level of technology in terms of the tool that we use, I think is very interesting because I love to equate things. And I'm thinking back to when the printing press was invented. And if you look at probably most of the history books throughout the world, it's referred to as a technological advance. But if I were to give somebody a printing press, somebody a typewriter, and somebody a computer, who's the most technical? And it depends on the decade or the era that they're in, but all of them arguably, you could have somebody behind it, who's an editor. And it doesn't change the fact that they know how to edit. The way they edit changes, but all of them are proficient in the tool and the capability of the tool to use it.
And I bring that up because they're extreme examples, right? You go back 10 years ago with Salesforce and to automate something, you had workflows on the declarative side. On the code side, of course you could have wrote triggers. I forget when S-Controls were finally put to rest, but you had different tools.

LeeAnne Rimel: RIP S-Controls.

Mike: Yeah, but that doesn't change the fact that you knew how to do something, right? The way that an editor edits a document meant and prints it doesn't change that they're an editor.

LeeAnne Rimel: I agree. And I think a way language changes and we have to... The purpose of language is for us to be able to communicate with one another and have shared understanding. And I feel like a good barometer or a good self test because there might be people out there that are like, "Well, I'm going to be out here talking about admins and I'm not sure the right language to use, or I want to talk to the entire technical community and what's the language that I should use?" And a lot of my opinion on this or I would say, where I feel like I learned a lot was... Actually there's a woman named April Wensel and she's on Twitter. We'll make sure to include her Twitter link in the show notes.
And she founded this organization called Compassionate Coding. And so she's out here talking a ton about just building compassion into our practice as technologists and everything that we do. And what does that look like? What does that look like in presentations? What does that look like in the communities that we seek to create? And what does that look like in language?
And this was years ago, I'll try to find the thread, I honestly don't know if I'll be able to find it, but she actually did a thread talking about the gate keeping around the language, when we say who's technical. And it was really interesting because I think a good gut check is always, "Why am I modifying language in this way? Why am I using this language? Am I using it to call people into this conversation and to include them to participate or to help them feel like they belong or to notify them that they're in the right place. You found your technical community, because I'm talking about Flow Builder for example, right? Are we choosing our words to call people in and to be compassionate or are we not doing that? Are we doing it for... Maybe we're being absent-minded and we're not really thinking about, we're not being intentional with our language or maybe we're doing it to make sure another community feels special quote unquote.
I think it's just important if you're out here and maybe you write about Salesforce admins or you create content for Salesforce admins, I think, thinking through that exercise of compassion of, am I using, and am I making conscious decisions to include members of the community or am I... And I think what's tough is there's a lot of unintentional and the intent is not malicious, the intent is often just absent-mindedness or just ingrained toxic elitism. But a lot of times, if we don't think about it consciously, we do create exclusive language that doesn't call people in.
And so, I don't know, that's a lot of... I highly recommend looking up April, but I think that we can, as Salesforce admins, think about how we build that into our language. Are we seeking to include people, to help people find a language for their job, for their duties, for their identity, for their community? Or are we creating language that might make people feel like they don't belong?

J. Steadman: LeeAnne, are you familiar with crabs in a bucket?

LeeAnne Rimel: I have seen crabs in a bucket in real life because I'm from the San Juan, but I feel like you're talking about something else.

J. Steadman: Just in general, the idea of throwing the crabs in-

LeeAnne Rimel: I have put crabs into a bucket before, but I feel like you're talking about something more specific than that.

J. Steadman: Yeah. So I ask because I certainly don't want to explain something or review a concept that's already been discussed. So there are two things based on what you're saying, LeeAnne that really occurred to me as being important. The first is we've mentioned technical a number of times, so I dictionary-ed technical because I just want to make sure that we're all drawing from the same definition. And this is mostly for folks in the audience, let's demystify the word technical for a minute, because you'll get people saying, "Hey, are you technical?" Or you'll hear in passing, that person is slash is not technical. So when we say, "Hey, I'm technical," the definition of the word technical is relating to a particular subject, art, or craft or its techniques requiring special knowledge to be understood. That's where it ends. So there's nothing in the definition that's like must be able to use the command line.

LeeAnne Rimel: It's just passion.

J. Steadman: Knowing how stuff works and being able to use it or explain it well. That's the definition of the word technical. When I bring up crabs in a bucket, I think that this is really important because it pertains to some of the gatekeeping or the toxic elitism that you've you've raised here.
So there's a natural behavior, and I haven't actually tested this because it sounds cruel to me, but to my understanding or at least the legend or the myth goes, if you take a crab and you put it in a bucket and it tries to get out, and if it can hook a leg over the edge, it'll get out. There won't be any problems. If you put a couple of crabs in a bucket, and one of them tries to get out, if the first crab that's in the bucket has previously failed, it will actually grab the second crab and pull it back from getting out of the bucket. This behavior will continue if you add more crabs to the point where people like crabs will actually yank each other's legs off. And what they do is they enforce everyone to stay inside the bucket. You can't get out because I tried to get out and I couldn't.
This is apparently a thing that really happens in life, and I think it's a great metaphor for people that have experienced difficulty, challenges or adversity where they believe, "Well, I had to go through A, B and C to get where I am today. Therefore, other people must as well, or it is not valid." And I empathize deeply with that point of view. I went to college and I stupidly racked up way too much college loan debt. If somebody else were to tell me that they got to go to college for free, the initial response that I used to have was like, "Oh really?" That isn't right. But the fact of the matter is if somebody could go through college and not have to pay any dollars at all, that's great for them. And just because it didn't happen to me, that's all right.
And I think that this applies to our jobs as well. And I think we need to be really, really cautious about saying, "10 years ago, this is a thing that could only be done by writing code." Therefore, if it's done in a different way, now it is somehow intrinsically less valuable. I just don't think that's true, and I think we have to challenge ourselves to find those moments and ask ourselves, "Am I actually responding to this situation, because I went through adversity in the past, and I think that one must go through adversity in order to thrive? Can I actually celebrate? Or can we totally flip the model on its head, and can we be a crab that helps other crabs out of the bucket?" Because at the end of the day, I don't think the crabs really want to be in the bucket. I don't think the bucket ends up... That's not good outcome for the crabs. I think the finale is probably a pot somewhere and then someone's belly-

Mike: And [crosstalk].

J. Steadman: So that's crabs in a bucket.

LeeAnne Rimel: I appreciate that explanation. I definitely will always remember that now, and now I wish that when I had actually been crabbing and put crabs in a bucket, I paid closer attention, because I don't feel like I remember this, but I appreciate learning about it. And I think it's a really good point. I think it's thinking about how do we revisit, be in that growth mindset where we're constantly updating our knowledge of the platform, our knowledge of what's possible and a career path, our knowledge and our perception of what roles do. Because I think just as I've been in this ecosystem for 14 years and you both have been in this ecosystem a really long time as well, and the growth and the change in the ecosystem is just... and in the role is just massive. So we have to be constantly updating how we think about it.

Mike: I think so J, listening to your crabs in a bucket scenario, and LeeAnne you're familiar with this, what I heard was the hero's journey, which is really hard to unlearn. I'm not saying we can't unlearn it, I'm not poo-pooing on the idea, but to your example, J, of going to college and racking up a lot of debt versus somebody that went to college and didn't rack up a lot of debt, congrats for them. What's hard for the person that went to college, racked up a lot of debt, paid it off and has a great job is they feel they somehow earned it more. Have you ever heard that they paid their dues?

J. Steadman: Yep, hundred percent.

Mike: Paid your dues, right?

J. Steadman: A hundred percent.

Mike: And that is so ingrained into every storytelling system built, right? The hero goes on a journey, something happens, they have to go into the special world, they have to learn something and they have to come back. They have to-

J. Steadman: There must be conflict.

Mike: There's got to be conflict, they have to come back, they have to defeat that. And then they bring with them the solution. They had to earn that solution.

LeeAnne Rimel: This is where we come back to leading with compassion.

Mike: Yep.

J. Steadman: Yeah.

LeeAnne Rimel: Because I think that, for me reading about this compassionate coding was life changing because it really caused... I think examining, everyone has a different journey to get to where they are, everyone has a different breadth of expertise. Someone might be in their first year as an admin and they might have a huge amount of expertise in other areas, maybe they manage a restaurant. So maybe they know a ton about POS systems and different types of supply chain planning for food products. Everyone has... And I think that that whole leading them with compassion piece and respecting and honoring that we all have these really different backgrounds and different things that were probably difficult for us to learn, or to overcome. And trying to always center on that, I think, helps mitigate a lot of those complicated feelings around wondering who deserves to be where, because I think a lot of times it's what it boils down to is if we spend time thinking about who deserves to be where, who worked harder to be in this conference room that I'm in?

J. Steadman: And this is something... So I've got a kid and she's not even two, she'll be two in January. And when I look at her, and her experience might not be all experiences, and she's my only kid, so kid two might be different if we have kid two, but she certainly isn't sitting there going like, "How hard am I working compared to the person sitting over there?" She's just like, "Hey, can I have a good time? Hey, can you have a good time?" And I think this idea of like, I need to compare how hard I've worked to how hard you've worked, and then look at the outcomes of how hard we've worked, and is it the same? And if it's not the same, that's not right. I don't know. There's something in that that seems forced upon me.
If we're a part of a community, if you are successful, fantastic. If I am successful, fantastic. No matter how hard we've had to work to get there. I think sometimes because we've suffered, we look at somebody who hasn't, and we think, "I got dealt a really bad hand. And it really bums me out that that happened to me. And it would've been so much easier for me if I hadn't been dealt this bad hand." And so we start to become angry. And speaking as a person who's gone through my fair share of downs, I totally understand that point of view. And I think it's our responsibility to look at ourselves and say, "Hey, I'm having this reaction right now. What is this reaction?"
And I'm going to use a totally ludicrous example. I listen to a lot of music, and I used to be a musician professionally, and I listen to a lot of music that's coming out right now. Because one thing I never wanted to do was be a person that was stuck on the bands that I loved when I was in high school, which coincidentally, I still am, but I also want to love modern music. And I want that to be true forever, which means that I've got to face down trends. And sometimes, I'll hear a song and I won't just dislike it. It'll be doing something musically that just makes me angry like, "What is this?" And I make it a point to myself to stop and say, "What is it about this song that is grinding your gears?" And I'll actually take that song and put it on repeat over and over and over again for a day. I once listened to Corey Feldman's album-

Mike: Oh, wow.

J. Steadman: ... Angelic 2 the Core on repeat for an entire week.

LeeAnne Rimel: It's like auditory self-flagellation.

J. Steadman: Yeah, so I could understand. And I have to be honest with you, it truly is just a terrible, terrible album, but I did this for a week so that I could understand. And you know what? Sometimes you're right not to like something, but a lot of times, especially when it's new stuff or changes, it's because of this thing that you're bringing up the end, this idea of, "Well, I understand music to be," and then you insert your own definition. And the thing that makes me angry, calls itself music, but it's doing something different, and that's not right. And so I encourage everyone that's listening when you're looking at any term that defines anything in your reality, because we are going deep on this podcast. I think it's important to ask yourself, "What is it that's making me angry about this?" And rather than spending your time expressing the anger, hopping on social and talking about the differences between generations, which is a very common thing that I see, that's a good example of it. Instead of doing that, ask your self, why it is causing you discomfort or anger or frustration?
And I think in exploring that, I think that you'll find something more valuable than the expression of anger itself. I find anger or frustration, that's an opportunity to better understand yourself and hopefully come to a place of improvement.

Mike: I like that. That's really cool. I don't want to end on the subject of anger, but I feel like we're in that realm. I'll give you this. Can each of you share a final thought for Salesforce admins?

LeeAnne Rimel: Sure. I will say, having been in this ecosystem for a long time and being a Salesforce admin myself, I think this is a really amazing and growing role in ecosystem, and the job duties are expanding and growing and getting more interesting and more flexible. And I would encourage everyone out there to embrace it, to embrace their Salesforce admin role, and lean into that community. We love meeting new people in the community. So very selfishly, I love seeing more admins in the community, and seeing what they're working on, and seeing the things that they're sharing with other admins. And I'll just reiterate what I said before, if you're out there talking to admins, talking to the community, if you're someone in a role where you're helping create content and communications for admins, I would ask that you just think about, what does it mean to call people in? And how can we actively, with any role that we're working, with our developers, with our architects, with our trailblazers, with our admins, how are we really perpetuating this inclusive community and calling people in and really using thoughtful language with compassion?

J. Steadman: I think my final consideration following up after LeeAnne's amazing wisdom here is when you find yourself running to a different word, stop and explore, ask yourself why, and find the real reason, and if it's a good reason, great stick with it. And if it's not a great reason, then change. And I can promise too, that myself and the other folks that are here in the admin relations team, we are constantly examining the things that you're responsible for as admins. And we are trying to ensure that we are defining that role well in ways that employers and companies and other admins can see, and that definition will evolve and change over time. And we'll do our best work to try and support you and make sure that you don't have to go out of your way to justify the work that you do. And instead that the title can bring with it, the things that you do.

Mike: That was very cool. I'm glad both of you had the opportunity to spend the time with us today, so chat about the admin ever changing admin identity.

J. Steadman: Thank you, Mike.

LeeAnne Rimel: Thanks for having us. This was fun.

Mike: So I enjoyed that conversation with LeeAnne and J. We'll be sure to put the link to April's Twitter on the show notes. And of course, if you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find more resources. We've got some pod in the Trailhead store. Really cool swag, I like it. I drink my coffee every morning out of that podcast mug, of course we'll include the link in the show notes. You can stay up to date with us on Salesforce admins on social, we are at @salesforceadmns, no i on Twitter. Of course, you can follow my co-host Gillian, she is @gilliankbruce. I am @mikegerholdt and I will also put LeeAnne and J's Twitter on there as well so you can give them a follow.
And with that, I want to remind you next week is our admin retro episode for December so we're looking back at everything content-wise for December. Also, the last podcast for 2021 so we're going to bid 2021 adieu and get ready for 2022. So with that stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.