For this week’s episode of the Salesforce Admins Podcast, J. Steadman hosts a conversation with Stephan Chandler-Garcia, Lead Developer Advocate at Salesforce. We learn how to navigate a world where roles overlap as well as how to bring more vulnerability into your collaborations.
Join us as we talk about Salesforce roles as a spectrum, being a T-shaped person, and how working at a gym can make you an excellent Salesforce professional.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Stephan.
Even though Stephan is now on the developer side of things, he also has experience as an admin. We’ve been looking at the spectrum of admin to developer and how the two roles can work better together, so we thought Stephan would be great to hear from. “I’m lucky to have worked my through the ranks as many different roles in the Salesforce ecosystem,” he says, “and I’m able to hold a little bit more of that perspective.”
This all goes back to Stephan’s first job. His mother was an aerobics instructor, so he and his siblings all worked at the gym in customer service at the front desk. If you think about it, it’s a bunch of customer-centric interactions: managing your contract, making appointments with trainers, buying snacks or equipment, etc. “When I got my hands on Salesforce for the first time it was all super familiar,” he says. The bottom line is that there are tons of experiences that can help someone succeed as an admin in ways that you might not expect.
One thing Stephan brings up is the concept of T-shaped people. The idea is someone with a very broad set of soft skills that help them leverage their deep expertise in a particular area. They also happen to be the ideal person to work on a cross-functional team. “Those soft skills are core to getting your message across and delivering it to your colleagues and to the business,” Stephan says.
The important thing here is not that some people are T-shaped and some people aren’t. It’s that these soft skills are just as important to develop as our expertise, and cultivating them is key to succeed in admin/dev collaborations. For Stephan, one of the most valuable ways to start is to teach yourself when to say, “I don’t know.” Admin Identity with LeeAnne Rimel and J. Steadman is ultimately about bringing vulnerability into your interactions so you can figure out the best way forward together as a team.
There’s so much more in our conversation with Stephan, so be sure to listen to the full podcast to get all the details.
J. Steadman: Welcome to the Salesforce Admins Podcast, where we talk about product, community, and career to help you become an awesome admin. This week, we are talking with Stephan Chandler-Garcia, Lead Developer Advocate here at Salesforce about Salesforce roles as a spectrum, being a T-shaped person, and how working at a gym can make you an excellent Salesforce professional. I am your host, J. Steadman, filling in for Mike Gerholdt as he enjoys some much-deserved time off. And let’s get this podcast started. Stephan, would you mind introducing yourself to our awesome admin community?
Stephan Chandler-Garcia: Yes, of course. Hello everyone. I’m Stephan Chandler-Garcia and I’m a developer advocate here at Salesforce. So sitting on the other side of the table from J over here, figuratively and literally today.
J. Steadman: I love this. Something that I wanted to talk with you about today is while you wear that developer advocate hat at the moment, you like all of us have a history. You weren’t sprouted whole cloth into the developer advocate space. You actually have experience being an admin and then kind of working through that role into this new developer space. And one of the things, if you’ve been paying attention to the pod recently, that we’re very interested in is uncovering this distinction. Where does admin stop? Where does developer begin? And then in addition to that, how do we best work with those people that might have a different role from us?
Stephan Chandler-Garcia: Yeah. And I think it’s a great topic and a great place to start. I’m lucky that I’ve sort of worked my way through the ranks as many different things in the Salesforce ecosystem. And I’m able to a little bit more of that perspective. I mean, as Jay mentioned, I started out as most of us did kind of getting thrown in Salesforce in some way or another, and ended up having to just sort of jump into a role where I was the core administrator. I was owning the platform and I was getting to learn Salesforce as I was taking responsibility for a lot these tasks. And I think that’s where a lot of us really get our core skills when it comes to administering Salesforce is sort of trying having to kind of having to figure it out on the fly.
J. Steadman: Yeah, that’s absolutely right. So you started as a learner and doer, and that’s also something that I am very familiar with because I got my first office gig at 30 and I just happened to get this role where I was responsible for Salesforce. And I had to kind of learn as I did. It sounds like you had that same experience as well. How long were you sitting in that admin seat and what are some core kind of principles or responsibilities that you learned while you were sitting in that seat?
Stephan Chandler-Garcia: Yeah, totally. So I’m actually going to backtrack a little bit to before I even knew what Salesforce was. And when I grew up, I like to say that I kind of of grew up in the gym, not actually using the gym because my mom was an aerobics instructor. And so all of our first jobs were at the gym, working in customer service, working at the desk.
And if you think about when you’re going to the gym, you have a contract with that gym, you scan your membership card, you check in, you buy things from them. You are scheduling appointments, you’re attending your personal training sessions. There’s all of these things totally centered around that person’s information, that member database. And that is something I’m incredibly thankful for because when I was able to sort of get my hands on Salesforce for the first time, I was like, oh, this is all super familiar. I can do all of these things all centered around this person’s data. And I have a lot of experience in playing with that kind of software and fixing that kind of software and being that tinkerer IT type person when it came to that.
J. Steadman: Gotcha. So pardon to interject here, but this concept of what is relational database, what is a system that an employee might have to interact with on a day to day basis, or even what are some of the hurdles or the challenges or the pains in the [inaudible] that a user might face, these were familiar to you through your gym experience?
Stephan Chandler-Garcia: Yep, totally. And it was all the same to me. And I was able to quickly learn the fact that I can do this myself. I can pop into setup. I can create different database tables or objects as we know them in Salesforce, I can create processes. I could update page layouts. This was long before lightning was a thing and was really responsible for making sure that we had and were collecting all of the data that we needed, that it was in the right place at the right time. And that everything was sort of going to plan against what we needed to within the data. And at some point in time, I’d had this job. It was great, found it lucrative in my career to try and move to a proper Salesforce role where I was the owner of Salesforce and of company.
And I was able to take those skills I learned just kind of getting thrown in a corner with Salesforce and turn them into an actual job, owning the platform at a business. Now, at some point in that timeline, when I was at the second company, I was starting to get frustrated with things that I couldn’t do and this organization that I was with it, the best way to explain it is like a government funded tech accelerator, where everyone in the room is a hardcore engineer around blockchain, artificial intelligence, et cetera, and trying to innovate new technology.
This was back in like 2015, 2016, a bit earlier than that. Actually, now that I think back and feel old for a second. I was like trying to get these super smart engineers to use Salesforce. And I had to learn how to speak their language. And in that I was starting to push my boundaries of what I could do with Salesforce and almost felt like I had to go and learn programming again in different languages so that I could actually communicate to these people what Salesforce was, why it’s important, and how then we could start to integrate it into all of the stuff that they were doing.
J. Steadman: Gotcha. Now, I love this. I want to go back a little bit. I’ve got a couple of questions for you, but then I want to come back to where we just ended. So one of the things that we talk about with our admin community, and one of the things that admins talk about quite a bit is especially folks that are looking for their first role. There’s this idea of finding and translating relevant skills. Like if I wasn’t a Salesforce admin, but I wanted to break into the technology, how can I take those experiences that I’ve had outside of Salesforce and how can I add them to a resume or how could I communicate them in an interview in a way that would make sense to a hiring manager and land me the role. One of the things that I love about the way that you explained your experience working at a gym is you were talking about how you were using the system. Yes.
But you were also talking about these day to day interactions, right? Like, of course it mattered how you were storing customer data, but that’s only because it was really important how you were managing the customer experience with the customers, right? I have a similar experience. When I was growing up, my folks worked in restaurants and they started me working in restaurants with them when I was very, very young. And so this idea of [inaudible] there’s a place for everything and everything in its place, that was something that was really, really relevant to me. And that’s something that I’ve been able to take with me. Even today, I had a meeting earlier today where that skill was paying off in this technology job. So before we dive into this wonderful moment where you’re starting to see a gap in language between you and the developers you’re working with, I’d love to hear how your experience at the gym just taught you some skills that then translated into the technology or helped you in the technology space. So could you speak to that for just a little bit?
Stephan Chandler-Garcia: Yeah, totally. So I’ve always been a tinkerer for one, so tearing things apart, putting them back together, whether it be toys when I was a child, computers when I was a teenager, and I love to learn and dabbling in code was something that I kind of always did when I was younger. And so there was this great computer game that I was obsessed with called Rollercoaster Tycoon. I’m sure any of us over 30 have played it at some point in time and you could actually build custom scenery. And so you could start to tinker with the style sheets and things like that to build custom scenery, because I wanted to build a Harry Potter themed park obviously at that point in my life. And so I’ve always been that that person who would kind of read the manual, dig in, figure things out, try and figure out how it works.
So then when I got to actually starting to work at the gym and all of these different places, I was the one who had to know how the software worked, why something was breaking. How come when we created this prospect record, this other thing didn’t happen. Why is it going wrong? And so I would end up being also that IT support person for that member management system. And then eventually we switched over to another system. And so I was the person that got sent in all the training to go and figure out, okay, what backend stuff do we need to know? How can we modify these values? Obviously not as flexible as Salesforce, but I was always the person sort of put in that, I guess you would say, admin position internally as a business user of the technology. And so, that obviously is a direct translation to Salesforce, except with much more flexibility and much more ability to change as an administrator in setup, et cetera, in places like that.
J. Steadman: I love that. And I’m going to just highlight for the folks that are listening out there. At Dreamforce this year, the admin relations to team we introduced… I don’t think the concept is new, but it’s the first time that we really kind of codified it and started boldly claiming certain skills that really benefit a Salesforce admin. So you named two things that I think are really, really important, especially for those of you out there who are listening and have yet to land your first gig or per perhaps you’re just beginning your career on Salesforce technology.
You have called out something that I think is so, so important. The first skill is learners mindset, right? Which is this idea that wherever we’re at, if we approach challenges and that’s shout out to Renee Winkel Meyer, if you have listened to the governance podcast that we did not too long ago, when a challenge arises, what can you learn from that challenge? How can you take that challenge apart? And how can that process reveal a solution to you? Right? This learner’s mindset I think is incredibly important to all careers in tech, all roles in tech. And it makes a lot of sense to me, Stephan, that this is thing that you were embodying, right? You called out how you would take apart toys when you were young and you would take apart computers.
And of course, we don’t all have to be doing that to exhibit learner’s mindset. I think the core of it though, the seed of that learner’s mindset is a sense of curiosity about those things that may be unknown to us, challenging to us, or sometimes irritating or painful to us. Right? So I love hearing learner’s mindset in action, where you’re seeing issues and challenges and you want to understand how they work and then you want to improve them, which of course takes me to another skill that’s very, very important, which is process automation, right? You called out early processes and we’ll talk about code in just a little bit here, but I think the first step of-
J. Steadman: … Talk about coding just a little bit here. But I think the first step of process automation, there was a nice conversation about this happening on Twitter earlier, I think that the first step of process automation is understanding what is currently happening right now, seeing where the inefficiencies are, and then mapping your manual process into some kind of automated process while taking advantage of those efficiencies that you’ve seen. So I just want to highlight those skills to our listeners, because whether we’re sitting at an admin seat or we’re sitting in that developer role, we’re talking about the same skills here, and they have a real benefit to the work that you’re doing. By having this learner’s mindset and by observing process and using process automation, I am assuming that there was a benefit to your gym. Am I right?
Stephan Chandler-Garcia: Totally. Absolutely. I could tell you countless stories or interaction that I had in those early years of my career that have gone on to later influence decisions that I’ve made, ways of working, and even apps that I’ve built, unbelievably. Stories for another time around privacy and security, but there’s a lot that comes from that. And now when you’re talking about things like the learner’s mindset, though, that really brings me right to a concept called T-shaped people. Have you ever heard of T-shaped people or referring to someone as T-shaped, J?
J. Steadman: I haven’t, but I’m so excited to learn about it.
Stephan Chandler-Garcia: So T-shaped people comes from this whole idea around building cross functional teams that have different skill sets, work in different domains, and bringing them all on the same team to come up with a common solution. And a T-shaped person, in theory, is the perfect person to have on your team or to work with and they have very broad skills. So broad is right at the top of the team, and so they have super soft skills around communication, empathy, and creativity that then translate and help them establish and give influence with their deep expertise. And so you’ve got broad and deep. And so a T-shaped person is someone who has excellent soft skills, but deep, deep expertise in a specific subject matter, technical ability, and experience. And while we can all be an expert in something without those soft skills, it’s very hard to work together to come up with a solution or to be a good developer or an excellent admin or architect. Those soft skills are core to really getting your message across and delivering it to your colleagues and to the business.
J. Steadman: I love this. And the reason that I love it is A, it’s a new thing for me to think about, and I always enjoy having the opportunity to take a new concept like this and mull it over and see how it applies to my day to day work and the people that I’m working with. But I also really love this because the skills that we’ve assembled and presented at Dreamforce and will continue to present to the admin community, I think that it really represents this T-shaped person idea really well.
Included in our bucket of skills that Salesforce admins would find useful are things like having good communication, having good project management skills, having good business analysis skills, and those are the top of the T, right? Being able to communicate with those around you, understand those around you to a certain degree, to a certain depth, and then having your own level of expertise that can contribute to conversations, often this will be a technical skill or skills. Not always, but often in the Salesforce space, it is a technical depth. I love that this is a concept that exists on your side of the table, if we’re talking about being on opposite sides of the table.
Stephan Chandler-Garcia: Yeah. So J., you are the best flow builder in the entire world. You’ve built the coolest flow that’s going to change your business’ process. Same thing, I’ve built the coolest lightning web component that is going to make everything much faster. But what happens if we can’t write the instructions to that component? What happens if the process isn’t clear and the language isn’t correct that we’re using inside of that tool? What happens if we can’t talk about our innovation to the rest of the organization? We lose a whole chunk of the value of that main amazing thing that we’ve built because we have yet to learn how to communicate that or how to share that with the world.
J. Steadman: And I promise everyone listening out there that this isn’t contrived, but this is the perfect moment, I think, that you’ve teed up for me here, Stephan, which is if we don’t have the skills to communicate with one another, it may be that this flow that I have could really benefit from incorporating your lightning web component on a screen or vice versa. It could be that your lightning web component could really benefit from some of the flow logic that I have here. And if we’re unable or unwilling to have that communication, or let’s just say unskilled, if we’re underdeveloped in this space of collaboration, if we’re not T-shaped, if we’re just I-shaped, our company is going to suffer. Because your solution and my solution may either combine and become more powerful, or as they currently exist might be company changing on both sides. But when both implemented, we could actually cause a really big problem.
Stephan Chandler-Garcia: Yeah, totally. And I’m going to let you in on a little secret. This is my secret to success in my career, in my life, and it’s three words. And those three words are, I don’t know.
J. Steadman: Yeah.
Stephan Chandler-Garcia: When you can teach yourself to just say, “I don’t know,” about something, about writing a trigger, whether or not this is the right solution. Or if you asked whether or not you can do this with a flow, if you can say, “I don’t know,” instead of, “Yeah, I probably can or maybe I can figure it out,” no matter what you’re doing, you can start to find the right solution. And it’s very difficult for people to admit that they don’t know something. And the second that I was able to say, “I don’t know how to do this. Let me go and find someone that I can ask or let me go and ask the community or let me do this,” I was able to really unlock a lot of potential in myself to go out and find that person, find the right solution, and then learn from those things instead of trying to figure it out somehow on my own without talking to anyone or admitting to my boss that I didn’t know how to do something.
J. Steadman: I had a similar discovery of myself just a few years ago. I’ve been in the Salesforce space for nearly 10 years now, which I always feel like I’m just brand new to technology. But it’s actually been about 10 years, which is, “Hey, congratulations me. Good job, 2022.” I’m going to focus on the positive here. Like, “Wow, that’s a lot of experience. Good job.” But this idea of I don’t know, you had mentioned that it’s really difficult for people and in frustrating moments or moments where we’re trying to build something, we can see a challenge like this, sometimes it’s hard to give people the benefit of the doubt on, “Why is it hard for you to just say you don’t know this?” We’ve all been in a meeting where it’s clear that maybe the whole room doesn’t have a clue of what’s going on, but no one will admit it.
And so I explored that personally. I can’t ever know what’s inside someone else’s head, obviously, at least not with the current technology that we have today. I’m looking at you, Metaverse. But I don’t know what other people are thinking, but I do know what I’m thinking. And what I found in my own experience is when I had these exchanges where I was reticent to admit that I didn’t know something, it was really about being vulnerable. Oftentimes, we’re seen as experts when we’re sitting in the space of technology. We are expected to know how to solve things, whether we’re talking with our business counterparts or another admin or a developer or an architect. And I think we are afraid that if we are perceived as unknowing, that that’s the same thing as being ignorant or stupid or less than or a whole pile of negative words.
In other words, admitting that you don’t know something is a kind of vulnerability. And I think historically, it is not common for people doing business with one another to be vulnerable with one another. And so what I found is I tried a little experiment and I am still way imperfect with this, but I have found those moments where I’m able to admit that I don’t know something, but I’m interested in finding it out, almost always lead to a super great outcome and I have never actually gotten into a situation where I’ve told someone I don’t know how to do something where I get “in trouble.” Not knowing, there are memes about this for developers specifically. Stack Exchange, not knowing how to write the code, and then when you can write the code, you feel like a champion of the world.
I think we should embrace this idea of not knowing, and I think it also unlocks more of that learner’s mindset that we talked about initially. It’s hard to be curious and to find out more if we’re unwilling to say that we know how to do something. And just to be specific, I have had customer interactions as a solution engineer here at Salesforce where I step into a business model that I’ve never worked with before, and I’ll be the first person to raise my hand and I’ll be like, “Look, I need you to talk to me about this like I am a child,” and it actually lightens the room. And these are big deals where a lot of money is at stake, and I have never found it to backfire. So I appreciate you bringing that up.
Stephan Chandler-Garcia: Yeah, no, I think I’m very fortunate that I’ve been in a position in the past to be able to hire a lot of admins, developers, architects. And one of the one criteria that I see in many companies, not only just for my own hiring, is being able to admit that in an interview as well. Because there have been times where I’d be interviewing someone and I’d ask a specific question about something that I would expect them to know, and people will feel that they have to answer and make it up on the spot.
And when you are making something up on the spot in an interview, it goes to show that you may do that with a customer, you may do that in development. And it’s very difficult because you may really want to hire this person, but because they cannot admit that they don’t know the answer to this and will, in effect, lie or make it up as they go along, it makes it very difficult to bring that person onto a team. And that’s a major criteria nowadays, and most tech companies, when you’re interviewing, is being able to find the right person for an answer instead of trying to make it up on the spot on your own.
J. Steadman: Yeah. So there are two things I think that are really important to this concept. The first is I want to be very, very clear here that neither Stephan or I, I’m going to speak to you for just a second here, Stephan, some places have bad culture and some people want to punish folks for making mistakes. So the thing that we are talking about here is, of course, not about places like that.
J. Steadman: … about here is, of course, not about places like that. If you’re currently in a situation where you’re just not able to admit that you don’t know something or you know that failures are punished, that is of course a sign of a bad or a toxic culture. And so, don’t put yourself at any kind of additional risk, right?
Stephan Chandler-Garcia: Totally. Yeah, 100% there.
J. Steadman: But assuming that you are at a place where that isn’t true, and again, benefit of a doubt to human beings, let’s assume that we all have good intent, we all have noble intent, we want to see the people around us succeed, and we don’t want to punish people for not knowing things, I think when you’re in that interview situation, I’ve been in a panel interview here for a role at Salesforce, and I was asked a really complicated question about identity providers and authentication. And it had been a while since I had studied the content, and I was asked to just whiteboard it on the fly. The way that I handled it was, I was like, “Oh, look, I don’t know.” Flat out. I don’t know. And if I get up and I put this down on the board, I want you to know that I’m really spitballing here and this is not content that I am comfortable saying is the right solution.
However, here is how I would find a solution that I’m comfortable with. And then, I would explain my process, right? And at the end of the day, the interviewer was really gracious. Still asked me knowing that I was not going to be able to come up with an appropriate solution, to step to the board and do my best, which I did. And it went very, very well. Right? It ended up in a positive outcome in the interview process and I was very excited about that. And it was the way you’re explaining things, it resonated with my lived experience. Right? And that piece of explaining how you would solve a process, that relates to so many of the skills that admins rely on, right? There’s a big chunk of communication in that. I’d say, there’s also, this isn’t a skill per se, but like there’s some courage being vulnerable with people who are actually trying to give you a job or not give you a job.
But to your point, I think it’s such a better answer than what you know is gibberish, right?Don’t just make something up whole cloth. Internet access exists for a reason. We’re constantly researching things and pretending, otherwise, I think, is only going to cause us all more difficulty and more challenges.
Stephan Chandler-Garcia: Very much so. Very much. There are lots of tech companies who do coding interviews and require you to solve challenges and problems like that. And that’s just not personally where I feel that we should come from because we have tools like the internet. You can quickly find the best solution in Google, and it’s a tool that we should all be using as admins or developers, to be able to try and find the right or best answer at most times, which is available for you at any point in time when you’re doing your job. So that’s a totally different point to that, actually having to make up the solution on the fly. But it’s important to know and trust in the tools that you have and the tools that someone has to go and solve a problem in the end.
J. Steadman: Yes. And for the person inevitably who may be listening in and saying, “Pish posh, we should all know everything,” I would just like to highlight the fact that before the internet, it was documentation, right? It’s very rare that you would ever just from whole cloth without going to the business or going to a colleague or going to the documentation or going to the library or going to your source materials. We’ve always been doing this. The thing that’s changed is how quickly we can access it and how available that information is.
So for me, it makes a lot of sense that rather than driving over the library and picking up five and bringing them back and going through, it’s all hyper texts now, and that’s the way it should be. It saves us a lot of time. And frankly, at the end of the day, admitting that we don’t know something, explaining how we would solve the problem and/or the challenge, and then going through and trying to solve that challenge, that produces better outcomes. Better technology, better code, better automations. I like this, Stephan. I like this. This is good.
I want to change gears slightly to one of the things that you said right in the very beginning, and there’s this moment where you explained being at an organization, and you realized that there was a challenge communicating with engineers and bringing the value of the technology that you were advocating, which was Salesforce, to their world, illustrating to them that there was value in incorporating or implementing Salesforce and some of the things that they were doing. And you started to talk about how you needed to revisit code so that you could have a better conversation with them.
Now, this is interesting because I both want to learn your personal experience and why you made that decision. I also want to hear your perspective on how an admin can increase their ability to communicate with engineers without going full dev, right? Those are two things that I’m interested in exploring. So have at it Stephan.
Stephan Chandler-Garcia: Well, let me paint a picture for you here. We were a tech kind, pretty much a tech company, we can put it that way, who was going to build everything from scratch, do everything on their own because that’s what they did. And so, they built this super cool new website for everything, taking applications for grant money, showcasing all of the projects that we’re working on, and opening up for job applications and recruiting all on the same website. And we actually managed all of our HR and recruiting processes in Salesforce.
Previously, we were doing it in, and at that time, community cloud portal, now Experience Cloud. You would log in to the experience cloud site, submit your application, check your application status. This was all through an app exchange partner at the time. That’s no longer in business. Our web developers wanted to all of those forms and put them onto the website. They didn’t want anyone to have to interact with the Experience Cloud site anymore. It needed to be in this fancy new website that they’d built from scratch, which is fine. I assumed that it would be possible. However, I hardly knew where to get started. And so, I was then able to go in and understand how you would put data into Salesforce from a third party service with the APIs, this was my first real exposure to the Salesforce APIs, and be able to send requests and put all the information, insert it into Salesforce.
And so, I had to go and learn, okay, number one, how do I find out what fields sit behind this form on the Experience Cloud site? How do I find out what’s triggering the automation behind it? Maybe there’s some magic back here that I don’t know about and go through, document out the entire process, and figure out how I could tell these web developer to get this information into Salesforce, how to query data from Salesforce back to the website, et cetera, and go through that process. That’s just one example of a way that I didn’t have a Salesforce developer to help me. I had to go and figure this out. I really wanted to do it to impress everyone else at the company, obviously. And so I was able to go and do that.
J. Steadman: So there are a couple of things that I want to highlight here that I think are particularly relevant to this conversation. The first is you had a goal that you highlighted there at the end, right? Which is here’s a problem, or here’s a challenge … Sorry, Renee. Renee is always watching me. This is how I feel now. Renee’s always over my shoulder saying, “Don’t say problem. Say challenge. So you saw this challenge and you took it truly as an opportunity. You were like, “Look, I’m scrappy. I can do this. I can bring a nice T-shaped conversation to my engineers. But in order to do that, because I don’t have any other staff to work with, any other coworkers or resources, I’m going to have to do a little bit of that dev lifting myself.” And the objective is like, “Look, you all. I was able to do this. How about that?” Right. Which is fantastic. I love that.
Also, underlying this, I’m detecting an obstacle or a negative outcome you were trying to avoid, which is that the company made a decision to remove a front end that essentially cut off data flow to an implemented system that the company was using. If we use the website and only the website, and there is no way to bridge it into your existing Salesforce implementation, then where does that Salesforce implementation go? How does it have value? Are you suddenly doing manual data loads all the time? Are those build it yourself developers now suddenly going to stand up their own database and then put a front end on that database and is Salesforce suddenly gone? Is that an accurate reading of the situation?
Stephan Chandle…: 100%. I wanted to keep as much of that data in Salesforce as we could because it was very important to some of the work that we were doing outside of just the recruiting itself. This was successful so it also opened up more opportunities. Fast forward, maybe a month, we were building this brand new IoT platform for internet of things devices and connectivity around London. And they wanted to feed all of the data that they were collecting around who was registering devices, the types of devices and projects that were running on the network into Salesforce, which I’m super excited about, because then we have more data to analyze. We have more data in the org that we can play with. And they were like, “Okay, Stephan, you are now on the scrum team for this project. We’ve got this Node.js platform that’s all written in JavaScript that we want to integrate with Salesforce. How do we do it?”
And obviously not knowing where to start, talk to the right people in the company, do my research, we were able to do that. Very easily, to my surprise. And I think at that point, I was like, “Okay, I’m a developer. I love this. This is a lot of fun. What’s next?”
J. Steadman: So I guess my question for you is, let’s explore the multiverse together. Let’s say that there’s a version of this experience where you had a developer partner. You were able to have these conversations with the developer partner who would be doing some of the developer responsibilities here. Would you have found yourself in the same position? Did you find yourself kind of by a little bit of happenstance and a little bit of due diligence, suddenly now here you are, accidental developer? Or do you think that even with a developer partner, you would’ve been just as interested in learning from them and making the transition from admin to developer?
Stephan Chandler-Garcia: I think my curiosity would’ve put me in that situation anyways, because I have worked at that point with developers multiple times. I don’t like the mystery of not knowing how something doesn’t work, how something is working.
J. Steadman: Sure, sure.
Stephan Chandler-Garcia: And so, I would like to pair a program and sit with someone and see how they’re doing it, what they’re using, what parts of their computer they’re using to make this magic happen, to really understand. And even working-
Today on the Salesforce Admins Podcast, we talk to Andrew Russo, Salesforce Architect at BACA Systems. Join us as we chat about Salesforce Foundations and why it’s a game changer for solo admins and small orgs. You should subscribe for the full episode, but here are a few takeaways from our conversation with Andrew Russo. […]
Today on the Salesforce Admins Podcast, we talk to Eddie Cliff, VP of Product Management at Salesforce. Join us as we chat about Salesforce Foundations and how it can give you access to even more capabilities within Sales, Service, and beyond. You should subscribe for the full episode, but here are a few takeaways from […]
Today on the Salesforce Admins Podcast, we talk to Lisa Tulchin, Senior Curriculum Developer at Salesforce. Join us as we chat about user learning styles and how to use them to create better training sessions. You should subscribe for the full episode, but here are a few takeaways from our conversation with Lisa Tulchin. Choose […]
