Today on the Salesforce Admins Podcast, we’ve got the Monthly Retro for February. Mike and Lead Admin Evangelist J. Steadman. We’ll review all the top product, community, and careers content for February so you don’t miss a thing.

 

Join us as we talk about Block Kit Builder, how to ask the right questions, and Albuquerque, NM.

 

You should subscribe for the full episode, but here are a few takeaways from our conversation from our Monthly Retro.

Blog highlights from February

Mike was a huge fan of J.’s video about how to reuse Block Kit templates in Slack. He wants the world to know he’s a big Block Kit Builder nerd and he’s not afraid to show it. They can save you a serious amount of time! February was also the month of Release Readiness, and if you’re a fan of automation you just can’t miss the Einstein Automate piece on that topic. “If you do automation in any way, doesn’t matter if you’re using Workflow Rules, or Process Builder, or Flow Builder, check this out,” J. says.

 

• Learn How to Reuse Block Kit Templates in Slack
• Einstein Automate: Flow And Bots

Podcast highlights from February

 

1. podded up a storm while Mike was off on vacation. One conversation that stood out was with Austin Guevara on product design. If you’ve ever wondered how we make the products you use every day from a design and user experience perspective, give this a listen. J. also had a chat with Susannah St-Germain on what it’s like to be an Architect. Her career journey from starting out convinced she would be a professional viola player is truly fascinating and inspiring.

 

• On Product Design with Austin Guevara
• On Becoming an Architect with Susannah St-Germain

 

Podcast swag

• Salesforce Admins on the Trailhead Store

Learn more

• Salesforce Admins Podcast Episode:

 

Social

• Salesforce Admins: @SalesforceAdmns 
• J.: @J__mdt
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

 

Full show transcript

Mike Gerholdt: Welcome to the Salesforce Admins Podcast in the second Monthly Retro for 2022. I'm your host Mike Gerholdt. And in this episode, we will review some product community career content for the month of February. And to help me do that, a very familiar voice on the pod. Welcome back, J. Steadman.

J. Steadman: Oh, hello. Thank you for the warm welcome. I'm glad to be here.

Mike Gerholdt: Well, thank you for pitch hitting while I was out in January, taking a little time off.

J. Steadman: You deserve it. And I am so glad that you had the opportunity to take some time off. And I have no limit of words that I'm capable of saying. So this is a great fit.

Mike Gerholdt: That we know. One highlight of taking time off, for the first time, and probably, I don't know, I might do it again, but for the first time I drove through Albuquerque, New Mexico. And if you're a fan of a certain AMC show about a certain chemistry teacher, oh man, let me tell you, there's a whole Google Map you can download of filming locations.
And Mike might have gotten up super early in the morning so that I arrived in Albuquerque, New Mexico, at a reasonable time to drive around their fair city and take pictures, and completely nerd out at the fact that I was standing right in front of certain people's houses and locations and car washes.

J. Steadman: Did the house still have a pizza on top of it?

Mike Gerholdt: No. Interestingly enough, you should Google that.

J. Steadman: They took if off the roof?

Mike Gerholdt: Well, so I don't have a famous house.

J. Steadman: Uh-huh (affirmative). Uh-huh (affirmative).

Mike Gerholdt: But if you go on TripAdvisor and you Google some of that, they have erected an eight foot non-scalable fence around their house.

J. Steadman: Oh, wow.

Mike Gerholdt: To the curb.

J. Steadman: Wow.

Mike Gerholdt: So I actually feel sorry for those people that own that individual's house, because fans were breaking in and throwing pizzas on the roof or jumping in the back pool. And I'm like, "I love ..." By the way, I went to all the filming locations of a certain 1977 Burt Reynolds movie that was filmed in Georgia. I nerded out over that, man. That was really cool. But some of it's on private land.

J. Steadman: Yeah.

Mike Gerholdt: And you'd just be like, that's their place. And so it was me and a friend and we very respectfully parked a block away in a legal parking zone on the street, walked on a public sidewalk. And then we stopped about, I'd say about a quarter of a block from the house and got a nice picture, but it's private property, people. Look, just have your moment, but also be respectful that it's not yours.

J. Steadman: This is good advice. I lived in Los Angeles for a number of years and LA folks want to see all of the famous places that they've seen. Most movies are filmed in Los Angeles so there's huge film history. There's a way to do it that is non-obtrusive, and then there's the throw-a-pizza-on-someone's-house way. So I love that you didn't throw a pizza on someone's house. Thank you, Mike.

Mike Gerholdt: No. No. I did go to the collectible store. Some enterprising individuals have opened a collectible store. I may have bought a couple bobble heads and some rock candy.

J. Steadman: I was just going to ask if they had some blue rock candy.

Mike Gerholdt: Yes, they did. And I have it. I'll probably never eat it, so I should probably eat it, but it's totally on my credentials. But, yeah.

J. Steadman: Wonderful.

Mike Gerholdt: Anyway, fun stuff you do while you're on vacation. But we're here to talk about cool stuff that we produced in February and everything that you need to listen to, I think. I'm going to kick it off. J., you did a blog post, and embedded in the blog post is a video on how to reuse Block Kit templates in Slack. And I picked it for the sole fact that I am a huge Block Kit fan, because it looks like code if I put it up on screen, but I know what I'm doing.

J. Steadman: Yeah.

Mike Gerholdt: And it produces an amazing Slack post.

J. Steadman: Yes. It seems just a little bit silly that the content of the video is so straightforward, but I really love Block Kit Builder as well. In fact, if I've got any kind of significant communication that I want to send out to teams in Slack, Block Kit is really the way to do it. But I really don't like recreating the Block Kit that I create.
So little URL reuse allows me to quickly and easily get in there into that JSON payload, which is a JavaScript object notation, for those of you out there interested in acronyms like me, and you can just very easily tweak the parts that you want, but you keep all of that fantastic structure that's been put together.
And for those of us that are sending out regular communications, you and I sit in a larger marketing org, we save a lot of time by reusing Block Kit templates.

Mike Gerholdt: Yeah. It'd be great if somebody named Jason started a moving company that they called payload.

J. Steadman: I like that. Yeah. That's-

Mike Gerholdt: Need to move? Call JSON Payload.

J. Steadman: Yep.

Mike Gerholdt: And then everybody in the Valley would call him and then all the rest of us would be like, huh.

J. Steadman: Yeah. It would need to be a Bay Area moving company.

Mike Gerholdt: Yeah. Right.

J. Steadman: Yeah.

Mike Gerholdt: Yeah. Maybe Austin, Texas. I think Austin.

J. Steadman: Yeah. Austin would do it too. Indianapolis.

Mike Gerholdt: Yeah.

J. Steadman: Maybe Chicago.

Mike Gerholdt: Yep.

J. Steadman: There are a number. New York, everywhere.

Mike Gerholdt: It's hubs.

J. Steadman: All of the places. I don't want to live [crosstalk].

Mike Gerholdt: Yeah. Let me just go out on a limb. Kearney, Nebraska? Probably not going to pick up on it.

J. Steadman: We are going to get a direct email.

Mike Gerholdt: Greensburg, Kansas? Not happening.

J. Steadman: We're going to get a direct email now. Someone is going to be like, "I created JSON and I live in this town."

Mike Gerholdt: Yeah.

J. Steadman: Mike, I thought February was the month of Release Readiness and Release Readiness Live. And for all of the right reasons, it's really popular content. So dear Admin listening in here, make sure that you check out the pieces of Release Readiness that are relevant to you. But specifically, if you're anyone that's using automation at all, which I imagine is the vast majority of our Admins, the Einstein Automate Release Readiness Live, I thought was particularly power.
We have been really innovating quickly for flow builder and the other Einstein Automate solutions, and the new addition of collection filters which greatly reduce the complexity of the flows that you want to build. You now are able to add sections into your screen flows. There is the new flow trigger explorer and flow ordering for record triggered flows. All of these things are game-changers. And in the Einstein Automate Release Readiness video, which is now available on demand, they've got a fantastic demo that highlights all of those features all together, in a really understandable way.
And we also talk about a new best practice for how you build and construct your flows. Diana Jaffe breaks it down in a really nuanced way that recognizes a lot of the history of previous best practice, in terms of how we architect our automation. So if you do automation in any way, doesn't matter if you're using workflow rules or process builder or flow builder, check this out because it has content that I think you need to see.

Mike Gerholdt: And even if you're not, I think the future is automated. The more time that you're saving yourself or your coworkers or your company, is more time that it frees them up to do what they do best.

J. Steadman: I think this is a really good call out and something that I probably shouldn't have overlooked initially. The content in the Einstein Automate Release Readiness Live, there's no barrier to entry. If you're familiar with the products, great. You're going to get a lot of value out of that. But if you're unfamiliar with those products or solutions, you should not avoid the content.
No one's going to be speaking above your head or over your head, or anything like that. Instead, what you're going to get is a really nice overview of how you can automate stuff. And if anything, you'll probably leave with a bunch of ideas about how you can automate things in your own work.

Mike Gerholdt: Now, J., you did some pods.

J. Steadman: I did. I did a couple of pods.

Mike Gerholdt: A few.

J. Steadman: I did a few. There are a few more that may ... I got busy while you were gone. I was like, "How many pods can I put on his back?"

Mike Gerholdt: There's 24 hours in a day and it takes about this long to record a pod, and I need this long to microwave a sandwich.

J. Steadman: Yes. Can I highlight a couple of the pods that I thought were particularly-

Mike Gerholdt: This is your introduction to do such.

J. Steadman: Okay. Well, so there are two pods that came out in February that I think deserve your attention. Listen to all of our pods, they're great, but I was really happy to talk with Austin Guevara about product design and how he designs products here at Salesforce. It gives a great sneak peek to anyone out there wondering how we produce the products that we produce, from a design or a user experience perspective.
And Austin also had these really fantastic perspectives on how we engage our users, how we ask questions of our users. So we talk a lot about Salesforce Administration By Walking Around or SABWA. We've really drilled that information into our essential habits content. And this is a great way to hear from a designer, the value of those conversations. So I definitely encourage you to listen to the On Product Design with Austin Guevara podcast.
And then also, I talked with Susannah St-Germain on what it's like to be an architect and her journey to an architect position. And I think that there's a lot of value in this podcast because Susannah is in a role that many people consider to be the height of technical accomplishment in the ecosystem. An architect, that's a serious role in terms of the technical responsibility that goes along with that.
When we think about the role architect in that way, it can create a ceiling. It can separate the idea of the role from who we are and where we are at. And what I love about Susannah's story is it is a series of decisions that she made to pursue her interests. And currently, that step has her sitting in this architect role. So she was not always an architect.
She used to be a viola player. She still plays I'm sure, but she was a classically trained violist that was going to school for music. And she started to make a series of steps into nonprofits, and then into technology, and then deeper into configuring that technology, and then deeper into structuring that technology, which I think is really fantastic.
And it's important for us to realize that our careers are always evolving and that there's no one linear trajectory that is the right way or the wrong way to career. So those are the two pods that I was super excited about in Feb and I think deserve particular highlight for those that are listening in.

Mike Gerholdt: Yeah. When we came back, I was toying with some of our promotional tools that we use for the pod. And I was scrolling through the transcript of the Austin podcast. I stumbled upon the part of the conversation where you were speaking about the nuances of how you ask a question. And I found it fascinating, just thinking through the way questions are framed so as to elicit a certain answer, or so as to pigeonhole the respondent in answering in a certain way, when that's really not your intent.
And so I will leave that as the teaser, but I probably read that part of the transcript like 10 times. Because the way in which you asked the question and the words in which you use are sometimes overlooked as the easy part of getting feedback, when in fact, it's some of the most critical

J. Steadman: Absolutely. And I won't give any spoilers on the conversation that we had specifically with Austin, but I'd say for yourself, myself, and for our listener, we have to be very conscious that oftentimes, I'd argue all times, when we're interacting with people, we have things that we want from them. And we often bias the way that we talk to people toward the things that we want.
This comes from my actor background, but we're always trying to get the things that we want in the world. And Austin was a great foil to that, and he's got great perspective on how you can short circuit that impulse in yourself. Because at the end of the day, confirming your own beliefs is of limited value. Confirming the value that your users need is of much greater value.

Mike Gerholdt: Well, that is a great way to end our February Retro pod. So if you want to learn more about all things that we just talked about in today's episode, go to admin.salesforce.com to find those links and many more resources. You can stay up to date with us for all things social, on Salesforce Admins at Salesforce Admins. No "I" on Twitter. Fun fact, we did a podcast about that, too.
I'm on Twitter at Mike Gerholdt, and Gillian, who is currently on leave right now, is on Twitter at Gillian K. Bruce. Of course, J., don't forget to give J. a follow. You can follow them on Twitter at J__MDT. I think I got that right.

J. Steadman: You did.

Mike Gerholdt: I did it from memory. Sweet.

J. Steadman: That's right. I love it.

Mike Gerholdt: So with that, stay safe, stay awesome. And stay tuned for the next episode. We'll see you in the cloud.

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.

The Essential Habits for Admin Success, now on Trailhead

If you haven’t checked out The Essential Habits for Admin Success on Trailhead, make sure to give it a look. We’re really excited for this new Trailmix.

What is DevOps?

“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.”

How we can end release days

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 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.

 

Podcast Swag:

• Salesforce Admins on the Trailhead Store

Learn More:

• This American Life episode about the Toyota System
• Essential Habits Trailhead Badge

Social:

• Salesforce Admins: @SalesforceAdmns 
• Gloria: @ThisIsTechChat
• J.: @J__mdt
• Gillian: @GillianKBruce@sunnydalelow
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

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.

The Essential Habits for Admin Success, now on Trailhead

If you haven’t checked out The Essential Habits for Admin Success on Trailhead, make sure to give it a look. We’re really excited for this new Trailmix.

What is DevOps?

“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.”

How we can end release days

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 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.

 

Podcast Swag:

• Salesforce Admins on the Trailhead Store

Learn More:

• This American Life episode about the Toyota System
• Essential Habits Trailhead Badge

Social:

• Salesforce Admins: @SalesforceAdmns 
• Gloria: @ThisIsTechChat
• J.: @J__mdt
• Gillian: @GillianKBruce@sunnydalelow
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

Today on the Salesforce Admins Podcast, we’ve got Susannah Kate St-Germain, Lead Evangelist, Architect Relations at Salesforce.

 

Join us as we talk about music theory as tech philosophy and the skills of an architect.

 

You should subscribe for the full episode, but here are a few takeaways from our conversation with Susannah.

The Essential Habits for Admin Success, now on Trailhead

 

We’re really excited about The Essential Habits for Admin Success on Trailhead, and we think you should be too. Jump on board and be one of the first to grab that shiny new badge.

Second fiddle to no one.

If you enjoyed our conversation with Stephan Chandler-Garcia about the spectrum of Salesforce roles. This week, we’re getting up close and personal with Susannah to get to know what it’s like to be an Architect. But before her Architecting adventures, Susannah started things out as accidental Admin, and before that started her masters in viola performance.

 

“I thought I’d be playing viola in an orchestra somewhere but life took me a different way,” Susannah says. She started out working for an orchestra registering gifts and records in a database, which lead to her changing careers and going into fundraising. When she tried out being an Individual Gift Officer, she realized she was much more interested in working with the reports than anything else.

 

“I realized I wanted to always be that person who was always able to give the person who ended up doing the frontline work the information they needed in the format they needed without too much back and forth,” Susannah says. Shortly thereafter, she started working with Salesforce and got her Admin certification.

The road to becoming an Architect.

Over the years, Susannah picked up some skills. It started with trying to get to the bottom of how to make a trigger work as intended and ease the load on a Developer stretched too thin. This led to her participating in RAD Women Code. “It’s the bridge between being a really great Admin and being able to consume and take things away from the Developer documentation,” she says, “RAD Women makes you code literate so you can work with your Developers more effectively.”

 

One theme that comes up several times in Susannah’s story is applying for roles where she didn’t necessarily meet all of the tech requirements but had other experience that would make her effective in the position. She still applied for those roles, made her case, and, in both instances, got the job she was after. Her path to becoming an Architect was similar—when she started, she had a frank conversation with her manager about how her career could progress and what it would take to get there.

 

“The first time I applied to be an Architect, I actually didn’t get the role,” Susannah says, “but I had a wonderful support system that wanted to help me fill the gaps that I had in my background in order to be ready for when there was another role opening.” Again, it comes back to clearly communicating her career goals and getting people invested in helping her succeed.

 

Podcast Swag:

• Salesforce Admins on the Trailhead Store

Learn More:

• Podcast episode: Being a Dev with Stephan Chandler-Garcia and J. Steadman
• Podcast episode: Salesforce Governance with J. and René
• RAD Women
• Essential Habits Trailhead Badge

Social:

• Salesforce Admins: @SalesforceAdmns 
• Susannah: @sunnydalelow
• J.: @J__mdt
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes!

 

Full Show Transcript

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, I'm talking with Susannah St-Germain, lead evangelist architect relations about music theorist tech philosophy, and the skills of an architect. If you enjoyed my chat with Stephan Chandler-Garcia, I think you'll enjoy today. 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 to podcasting.
So let's just get cracking here. Everyone, welcome to another wonderful episode of the Admins Podcast. I am J Steadman, lead admin evangelist. I am your host today filling in for Mike Holt while he enjoys some very much deserved time off. And I'm very excited about our conversation. Today. We are joined by Susannah St-Germain, who is a lead evangelist in our architect relations team. And I want to build on some of that conversation that we had with Stephan a few weeks ago, where we discussed the spectrum of Salesforce roles, like admin, developer, architect. Talk about the skills that correspond to those roles, where some skills may overlap. But also just have a person to person conversation with somebody who has been in an architect role for some time and who has that architectural perspective to share that with you, you wonderful human being or beings that is listening today. So, that is a bit of intro from me. Susannah, would you mind introducing yourself and talking a little bit about your path into technology, into Salesforce and into architecture-dum?

Susannah St-Ger...: Absolutely J. Thank you for having me and thank you for probably bearing with my dog barking in the background. I think the mail man just came, which is always exciting. But I'm here today, yes, to chat about my background, my architect background. And like you I believe, and probably many of you who are listening, I came into the Salesforce world not on purpose. I came into the Salesforce world as an accidental admin, actually. I studied-

J Steadman: We love to hear it.

Susannah St-Ger...: Oh yes. I love accidental admins. Yes. So I started out my career thinking that I was going to be an orchestral musician. We have something in common there, I know.

J Steadman: Wonderful. Yeah. That's awesome.

Susannah St-Ger...: You're a musician as well. So I went to college and did my masters, well part of my masters, in viola performance. So viola, for those of you who might not know, is like a violin but just a little bigger and has slightly different strings. It makes a little bit different lower sound. But that's what I thought I'd be doing with my life. I thought I'd be playing viola in an orchestra somewhere or in a quartet or something like that. But life took me a different way. And I actually the truth is I got burned out a little bit doing my masters in music, and wasn't really seeing a path forward for myself. I wasn't really seeing where I would be in my career. It was a bit of a funny time around 2006.

J Steadman: Oh yeah, that was a very funny time.

Susannah St-Ger...: Yeah. And did what I never really thought I would do and I dropped out of my masters. I took a leap and ended up temping around Boston. I was living in Boston at the time and had this random opportunity to go work at an orchestra in Colorado for the summer and be their fundraising intern. And I took that opportunity and I moved out to Colorado for three months and was doing fundraising, which as it turns out involved working with a database, which I ended up absolutely loving to do. I was entering records for gifts and people that attended events and things like that in a software system called, I'll have to remember, I think it was eTapestry. It wasn't Salesforce, but-

J Steadman: It sounds great.

Susannah St-Ger...: Yeah. I'm not sure that it's around anymore. But just the concept of learning about a new piece of technology and working with it and entering data and running reports was just something that I loved. And fast forward quite a bit, I loved it so much that when I went back to Boston I decided that I wanted to get a job in fundraising because I enjoyed my internship experience so much, and worked at an organization called the Celebrity Series of Boston. It's an organization that puts on concerts in really famous halls, like Symphony Hall in Boston. And there, I ended up also working with a database, still not Salesforce, but we did database migration. And I was the lead of that in addition to doing my fundraising work. Wearing my fundraising hat, holding it on one hand, and then on my other hand I had my database hat.
And I thought, okay, I love this so much, I guess I'm going to be a fundraiser. I guess I'm going to do that for the rest of my life. And being, I don't know, the diligent person that I am, I was like, well, what's the best way to be the best fundraiser that you can be? And in my mind, that was to become what's called an individual gift officer. So sort of like a salesperson, the person who goes out and asks for gifts. And I went out and I got myself a job doing just that at the Museum of Science in Boston. And instantly after I started the job, I say instantly, it was within the first week, I realized that I had made a terrible mistake. Yes.

J Steadman: So I'm laughing there, and I've got some questions about the stuff that we've covered previous to this, but I'm laughing because I think it's an experience that we've all had. I think it's funny to hear that. You take the new role, you're stoked about the new role, you're diving into it and it is just totally wrong. So how did you know it was wrong? And what was wrong about it for you?

Susannah St-Ger...: Well, I knew it was wrong, so I was at my desk and they were like, "Here's your one report. Here's the report that you get on all of the prospects that you need to work with." And I said, "Oh, well, I'd love to know how I can customize this report and how I can put filters on it or get a different view." And the answer was, "You don't, you're not responsible for that. You're supposed to just take the report and go out and raise money." And at that moment, I was like, well, I want to know how this report works. I want to be able to customize it. I'm more interested in figuring that out than necessarily being on the front lines and talking to people and doing all of that work.
So I realized that I missed the back of house efforts and I really missed working with the database. And I realized that I never wanted to give that answer of you can't customize a report to someone. I wanted to always be that person who was able to give the person who ended up doing the frontline work the information that they needed in the format that they needed, without having too much back and forth. So I realized what I was missing when I wasn't able to get that customer report that I wanted without going to a different team and working with them and all of that. So, that's how I realized I had made a terrible mistake.

J Steadman: So what you're talking about, I think, is an experience that most of us as admins we're really to trying to avoid. I'd actually argue that like all of us as admins, very rarely do we want to [styne] anyone's curiosity about the thing that they're trying to explore. Of course there are things like compliance or DevOps procedures or whatever that we might have to follow. Our backlog the amount of time that we've got in a day, those are limitations that can offset what we're able to deliver to people. But rarely do we want to be in a position where we're desiring to say no to someone especially if it sounds like you were the kind of user that was really the reason you were interested in slicing and dicing that data was because you wanted to ask questions of it. You wanted to gain insights from it, so that presumably you'd be more effective in your job as that gift officer.

Susannah St-Ger...: Exactly. Yeah. So I had a lovely experience of having to cobble together multiple Excel spreadsheets because I couldn't get what I wanted out of, again, still not using Salesforce yet, but the database that we were using. And I was like, this is not okay. I want to know how to solve this problem. And it's because of that reason that I made the choice to go and try and find another job that was focused more in operations. I was like, well, maybe I'm not in this frontline fundraiser role. Maybe I want to find a role in development, what's called development operations.
So I actually went out and again, found myself a job at an organization called Citizen Schools, it's based in Boston as well. And it was there that I had to convince someone to hire me, even though I didn't have Salesforce experience. So Salesforce was on the job description and I frankly didn't know what it was at the time, but I knew it was a CRM database. That's about as far as I knew. And I had to convince someone that my transferable skills of all these other jobs that we've covered already were enough. And my desire to learn was enough to hire me as a director of development operations at this education nonprofit.

J Steadman: This is fantastic. And I have to interject because I'm too excited not to, my apologies. I think you who have just given me the most perfect layup. In terms of the kind of content that we talk about in this podcast, or that I've been particularly interested in exploring with our guests most recently, there's this conversation about skills. How skills apply to technical roles or roles that we call technical and how we can have a conversation with folks about this is where I came from and here is how the skills that I developed being a violist, working in fundraising as an intern, being the gift officer and all of the skills that I'm talking to you about, this is how they'll apply to the role that I am looking for right now. And having that conversation when it might not be on the job description.
And what I like about you introducing this concept is, I've been joting down a few notes as I've been listening to your story, and the first thing that I think is very interesting is you played the viola. And for those of you that are listening out there, and of course Susannah I'm open to your correction here, but my grandmother was a violist, I actually started playing upright bass. That was how I got into music. So what's interesting about the viola as an instrument, its purpose is one of harmony.

Susannah St-Ger...: Exactly.

J Steadman: It's very rare that you have a viola that's playing the melody. And for those of you that are just totally not into dissecting music, totally respect that melody is that thing that we all listen along to. It is the lead line of music. It's what people are singing. That's typically the melody.
The harmony is something that other instruments layer into that melody and support the melody. It's very rare that somebody who's playing a harmony is taking center stage. But if you remove the harmony from a piece of music, that melody can feel very empty, it can feel very flat. And so I find this fascinating because it's my perspective that this concern with harmony is actually interlaced throughout all of these Salesforce jobs, but particularly the architect role where you have to look at an entire organizations' implementation of sales source and other systems and ensure that they are harmonious with one another.

Susannah St-Ger...: 100%. Exactly. I've never thought of it that way.

J Steadman: Yeah. So first, I think that that is super fantastic. Second, I think the thing that is really interesting to me is, like our conversation with Stephan, you had this opportunity of a system migration to really push you to a decision point of how you wanted to interact with systems. Then it led you to this place where you got a report and you were in charge of soliciting some gifts and you realized that you were constrained. So this idea of harmony as your experience as an end user, suddenly there is no harmony. You're given the sheet music, play exactly what's written here, there are no other parts, it can't be changed in any way and have fun. And that's where it seems like you drew back a little bit and you said, well, okay, I need to make my own solution, which creates what I think is something that many admins deal with on a regular basis, which is a shadow application or shadow IT.
You were given a report that was produced by your company, and you were asked to work from that report. But to get the value you needed, you had to drive yourself into a spreadsheet that was probably private or shared amongst a small number of people at your organization. It was not in one of those official IT applications. It's very that your spreadsheet didn't exist in the CRM application that your nonprofit was actually working in. And then that leads to bigger problems with the system.
Now we don't have that what we call at Salesforce that 360 degree view.

Susannah St-Ger...: 100%.

J Steadman: And from working in that way, you have then decided, you know what? This sucks. Pardon my lack of a more elegant way to say it. Let me see if I can have a broader impact and strengthen this experience. I don't want other people to have this kind of limited experience where they become frustrated with the system and are driven out of it. Let me start to get into developer operations at Citizen School. So everything kind of came together for me there. I know I just shouted everything out, but that really seems like your experience.

Susannah St-Ger...: It has been, it absolutely has been my experience. And I got that role where I could affect change, where I could actually make those reports that people wanted. And I was able to do that because we were using Salesforce. And it brought that experience of not getting the type of customer service that I wanted to get, not getting the data that I needed. I remembered that experience and was able to provide a better experience to my colleagues in this new role that I was working in and also happened to be using Salesforce. And it was at Citizen Schools where I got my admin certification. I fell in love with Salesforce. I dove into the deep end and I'll fast forward a little bit. I worked there for a number of years and got a couple more certifications, went to my first Dreamforce while I was there and that completely blew my mind

J Steadman: For context. What year was that? Do you remember?

Susannah St-Ger...: This was 2010.

J Steadman: Yeah.

Susannah St-Ger...: Yeah. So a while ago.

J Steadman: A while ago.

Susannah St-Ger...: A while ago.

J Steadman: Pre... No, it was post-Trailhead, but not by much.

Susannah St-Ger...: It was pre-Trailhead, actually.

J Steadman: No. Yeah, you're right. It is pre-Trailhead.

Susannah St-Ger...: Pre-Trailhead. We had the workbooks. So when I studied for different things, there was on how to build a dashboard and the laminated cheat sheets on yep. Limits and things like that. But it was a great time. I was able to learn a lot. As I mentioned, I absolutely fell in love with Salesforce. And over the years, decided that I wanted to learn a little bit more about the development side of the house. So at that time that was learning more about visualforce and things like that. I just missed S controls. I didn't have the joy.

J Steadman: Dodged a bullet there.

Susannah St-Ger...: Yeah. The joy of learning that. But I-

J Steadman: If I could pause you for a second, I'm interested. So you started to take interest in developer stuff a little bit more, what was the trigger for that or the cause for that? If there is one that you can identify.

Susannah St-Ger...: There is one and it's great. It was a trigger actually. So I was working in a relatively, I don't know, a midsize nonprofit. We had one developer in house and there was this trigger on our opportunity object that was doing things that I didn't want it to do. And I didn't want to have to rely on our one developer who was stretched too thin. I wanted to understand how it worked and I wanted to understand how to make the logic work for me. So that was definitely my impetus to learn more about Apex in particular and then also visualforce, just because I knew that it was a thing that existed and I was curious.

J Steadman: Yeah. So one thing that I've heard in common from the conversation with Stephan and in the conversation here with you, and I think is also a big frequent point of conversation is, I'm out there talking with admins in our community, this idea of understanding how things work and curiosity. And the reason that I'm highlighting this learner's mindset is because I find it valuable to and how Salesforce professionals can work with one another across roles. And to understand that devs like Stephan, architects, like yourself Susannah, admins like me and so many others, that we share a curiosity to understand how things work. And often when things aren't happening, for example, you weren't able to get the changes that you wanted out of the trigger. You called out the developer was stretch too thin. And Stephan also had a similar conversation.
So there are these opportunities where if we feel so compelled, we find that there's a bottleneck, our curiosity can lead us into greater understanding, enhance some of our existing skills and bring us what we need to get that next role. So just wanted to highlight that for the admins before we continue, because whether it's trying to understand how a complex flow works or you're cracking into a trigger and trying to understand how that trigger works, or you're looking at the entire system layout that you might be interacting on a day to day basis, including integrations and the upstream downstream effects of data choices, all of this can be approached through this lens of I really want to know how this works. I'm really curious. I want to improve things.

Susannah St-Ger...: Absolutely. And my curiosity in learning more about development led me to participate in a wonderful organization called RAD Women Code.

J Steadman: Yes.

Susannah St-Ger...: Yeah. You've heard of them before?

J Steadman: Yes, I have. Why don't you give us, if you had to give a 30 second pitch to someone out in the audience who hasn't heard of RAD Women Code, how would you pitch it?

Susannah St-Ger...: I would pitch it as RAD Women is the bridge between being a really great admin and being able to consume and take things away from the developer documentation. Because there's a big gap there in being great at customization and being able to read and teach yourself how to code. So RAD Women makes women in the ecosystem who know how to config really well, it takes them and makes them code literate, I would say, so that they can read code and they can work better with their developers, sort of the challenge that I had. And they do that through a 10 week program that's free and is led by two wonderful coaches in the ecosystem. And it really, again, just bridges that gap. That would be my elevator pitch.

J Steadman: I love that pitch. And focusing on this idea of literacy and in increasing your communication skills across roles, again admins, I've talked to you for a while now about this idea of how we communicate with one another and great to know that this is a resource that exists. RAD Women are out there, you can find them on Twitter. We'll make sure that we throw a link to RAD Women as well in the podcast notes, just so if anyone's interested and wants to know more, you can check it out.

Susannah St-Ger...: Absolutely. So I participated in this wonderful program and around the same time I took a solo admin role at a larger organization, which is an interesting move.

J Steadman: Yeah, that's an interesting setup.

Susannah St-Ger...: Yep. It was an admineloper, now we have that lingo, we didn't at the time. But I was their sole Salesforce resource. It was for a larger nonprofit. And I took it because I was interested in the area that the nonprofit was working. It was in global health and public health arena. So again another fork in the road, it was at that role where I realized I'm still doing fundraising stuff 60%, if not 70% of my time. And I'm only spending 30% or 40% of my time on Salesforce. And I would see the people that worked in the IT department at my company and I would think I really want to work in IT I think. There's something missing. I don't want to be doing this fundraising work anymore. I want to be in Salesforce 100% of my time.
And it was that realization that led me to do something that I always like to share because I think it says a lot about networking and getting jobs in this, in, in this current time. But I went on the Trailblazer, well it wasn't called the Trailblazer community at the time, it was the Success community. I went on the Success community in the Boston Mass jobs board. And there was someone who had posted a job for an organization called Boston Scientific. I'd heard of them I think, but I had to Google. I was like they're a medical device company, interesting.
And I saw that posting and they were posting for a business analyst, a business analyst in Minnesota. And I thought to myself, huh? I read through the job description. And I was like, this sounds like something I could do, but it's in Minnesota. So let me reach out to this person who posted the job and ask if they would accept someone in the role in Boston, because they posted it in the Boston group and it had Boston in the name I was thinking I'll reach out and not just write it off.
So I reached out directly to this person and they said, "Oh yeah, of course we'll accept someone in Boston." So they said, "Send me your details." So I sent them my cover letter and resume and they said, "Okay, great. I'll forward it on to the hiring manager." Whatever. 100%, or maybe 99%, but 99.9% sure that I would not have gotten past the automatic screen for this job, because I had never worked in an IT department. I have this weird musical nonprofit background. I've never worked at a for-profit company before and I didn't have a business analyst certification or anything like that. But I was able to make a connection with this person through the community and bypass that blind screen that filters so many folks out when you're trying to make a bit of a pivot in your career.

J Steadman: Yeah. I need to interject a little bit here, I suddenly became it again and you'll have to pardon me. So, sometimes we get into conversations about language here, language is really important to me. And dear listener, you may have listened to a previous conversation with Renee and I as we talked about shifting our thinking from the word problem to the word challenge. I love that you brought up your background and this is something that I talk a lot about as well, because I've got what I call an untraditional background, an unusual background. I come from acting and music and what have you. And when you described your background, you said you have this weird background.
I just want to highlight that because the conversations that I'm having with people out there, I am finding that there aren't... This is my experience. Your mileage may vary listener. Your mileage may vary as well. But this idea of the weird background, especially as we look at Salesforce jobs. I think as long as you do some of the things that you've done here in your story, Susannah, I feel like weird isn't applicable anymore. You have a background and that background is varied and multifaceted and I would argue rich. But weird, to me, and I don't mean to call you out, but weird I think this is an opportunity for us to... Weird? No. Interesting.
And the reason that I say that is what you've embodied in your approach to this conversation as you talked about it is you weren't assuming no. And this is a concept that I think is really important if you're a Salesforce admin that is out there that is trying to get your first role or if you're a junior and you're trying to step up a level or if you're a BA and you want to move into a more technical role. Really anywhere that you're at, taking the time to pause, look at what's being asked on that job description, see if there's a way that you're able to talk to that hiring manager or recruiter, and then reach out with your well thought out and well structured query. Know who the company is, know where they're based, know what they're asking of you, but then come to them and say, actually, here's what I have to bring to the table. Are you cool with that?
Asking the question, not assuming the no. Maybe having, I hesitate to say courage. But it can be scary to reach out to somebody when, as we all know when we look at Salesforce roles, the job descriptions are like, "I need a junior Salesforce admin with eight years of lightning web component development experience." It can be hard because those screeners, they can actually remove a lot of really valuable candidates. So I just needed to interject. I have all of these notes now, I can give you a whole document on your story so far. To me, this is a great background and you have been constantly curious about the technology that you're acting with, but also curious about where you go with that technology. And not assuming no has been a great ally to you. It's allowed opportunities to be opportunities, which I think is just fantastic.

Susannah St-Ger...: 100%. And it's been asking for what I want, without necessarily feeling like I have to know 100% that I'm right. Knowing that you can try something like I did in my individual gift officer job. And it's okay if you try it and you realize you don't like it, because then you realize more about what you do enjoy. And I think that carries over nicely into, I promise we're going to get to my architect background in just a second, that leads me to again asking for what I think I want. And that's what I did in my new role when I arrived at Boston Scientific. It was, again, my first for-profit role in an IT department, I never worked in an IT department before.
And I sat down with my manager who happened to be wonderful, I'm very thankful for that, and I asked about my career path. We had an upfront conversation about what career paths looked like at this organization. And she told me that there are two paths. There's the managerial path where you go from BA to junior manager to manager, et cetera. And then the other path that is the more "technical" path, that goes BA, technical lead, architect, senior architect, et cetera. And I thought to myself, well, I've been waiting to work in an IT department this whole time and work with Salesforce 100%, I want to follow that technical path. And I told her that, and she was like, "Great, well, we'll find ways to get you down that path."
And I was promoted without a lot of fanfare eventually, after a year or so working there, to technical lead. And then I have a, I don't know if it's a fun story but it's a true story, about making that final leap to architect. Because I was an internal candidate, I was told we have an architectural opening and we're interviewing some folks externally and we want to interview you internally as well. And I got all ready and I did those awkward interviews with people that you know, that you work with. And I did my rounds and I got the call and I got informed that I actually didn't get the role the first time I applied to be an architect. And my ego and my first reaction was, well, I'm just going to have to go find another or organization to be an architect at. Or I'll just find another role and maybe they'll appreciate me or something like this. It was this very bruised ego initial reaction.
And I'm so happy that after I licked my wounds, I was able to take a step back and know that there was going to be another role because of the type of organization we were because of how big we were, that there was going to be another opportunity. And that I still had this wonderful support system that wanted to help me fill the gaps that I had in my background in order to be ready for when there was another role opening. And-

J Steadman: I have to pause you there please. I think you've talked on something or you've brought up a topic that I think is really important and is probably vital to this specific experience that you've brought up, which is when you joined the organization, first, you sat down and you had a really transparent conversation with your manager about what your career could progress into. You were very specific about choosing which path was most appealing to you. And then it sounds to me like you moved to achieve what you needed to achieve to get the promotions to lead you to your goal. Right?

Susannah St-Ger...: Exactly.

J Steadman: But beyond that, when you took a chance at something and your desired outcome didn't occur, you mentioned in passing that you had a group of people around you that really cared about you and your growth goals, that understood that there might be places that you could develop a little bit further to achieve those goals.
The reason I'm highlighting these things is as we're looking at roles out there, regardless of the title that we hold, if we're trying to get a job somewhere, the things that Susannah is outlining are culture. This is culture. And having a culture of people around you that cares about your goals, that asks about your goals, that tries to lift you up and send you to the place that you want to be and cares about identifying areas where you continue to develop in the positive way, that to me is an organization worth investing in.
So, as you're looking at roles out there, keep in mind that this is a part of culture. It can be a part of your or interview process as an admin trying to find a new gig, asking questions about this, what is the career progression for this role? How do you support people when they're looking to continue to grow their skills? How often do we receive feedback on the way in which we're performing and what kind of feedback is that? Can I talk to other people on the team who have received feedback? I'd love to learn their experience. These are all things that I want to highlight, because I think that they are just so valuable as you're going through your experience. And I didn't want to lose the opportunity to bring that up to our audience, Susannah.

Susannah St-Ger...: 100%. And one of my personal rules for myself now, having been in the job market for quite some time, is I won't go and pursue a role or accept a role unless I have talked to someone who works there to talk about that culture piece. Because like you said J, that's so important. Other than knowing who your manager's going to be is also an important piece. But just knowing the company culture is absolutely vital to, like you said, being set up for success. Because even if you do the best work of your life, if you're at an organization that doesn't appreciate you, or isn't going to lift you up, you're you're going to have a bit of a hard time. So 100% agree.

J Steadman: To your point, culture is not only the ads that you'll see about working at a company or the employee experience website that you could see for some larger companies. Culture can shift from team to team. And so to your point Susannah, actually having a conversation with people that are doing your role that are on or adjacent to the team that you're hoping to join and really hearing about that microculture and seeing whether or not it lives up to your expectations or your needs. I think that needs is probably the best word here. We all have a need. There's a certain kind of culture that we all crave or that we all hope to work in, that we need to thrive. And this is a great tip. I appreciate you reviewing that idea with us.

Susannah St-Ger...: Of course. And that's how I ended up becoming an architect. That was my first role as an architect. And I was, again, lucky enough to be working on a team where I had some senior folks that I could learn from. It was around the time of the first Trailhead architect boot camps that existed around TDX. So I was able to do some skilling up there and really the rest is a bit of history. I have now, what, something like 23 certifications. Worked as a customer architect and worked at an ISV as an architect as well. And now I'm here in Salesforce working as an evangelist.

J Steadman: And important to highlight this idea that you've had, to me... I'm drawing all of these parallels. I've got the thread and the board with the thumb tacks and the map, I'm drawing all-

Susannah St-Ger...: The string.

J Steadman: Yeah, all the string. That constraint that you experienced as an end user with a report. As you transition from being a Salesforce architect customer into becoming a part of the architect relations team, the ability to impact your end users presumably has increased. Now what you're doing is you're trying to identify other people who have that similar curiosity that you have toward system design, application design, and the entire landscape of how an enterprise might structure things. You want to make sure that people that are doing that job don't feel constrained like you did as the end user. At least in our limited conversation here, that's how it seems to me.

Susannah St-Ger...: Absolutely. So I want to make sure that the folks who are helping define the architectures and the structures that will allow people to make good reports, that those people have the resources and the tools and the knowledge that they need to do their job well. And that's something that I'm incredibly passionate about. And to your point, I think it does probably tie back to that that bad experience that I had. I want to make sure that no one feels like they don't have the tools that they need to do their job, especially as an architect or as an admin or as a developer.

J Steadman: Yeah. I think that this is a wonderful place for us to conclude the conversation. I think my final thought on this idea of making sure that people don't feel limited. To me, when I look at your story, I see it just... Are you familiar with the Grinch Who Stole Christmas?

Susannah St-Ger...: I am. Yes.

J Steadman: So I'm not saying you're the Grinch in any way, but at the end, the Grinch's heart is very tiny and then it grows a bunch of sizes. I feel the same way about your curiosity and your interest in freeing people from walls. It started at the size that it was at, and over the course of your career it has grown and grown. And it has brought you broader and broader vision. From a report, to an application, to the entire system, to how are we structuring the architecture for a company. So you've got this curiosity and this interest in removing barriers of entry to people that has just gotten larger and larger. You are not a Grinch, but you have growing curiosity, like the Grinch had a growing heart.

Susannah St-Ger...: I love it.

J Steadman: Cool. Well, thank you so much Susannah St-Germain, lead evangelist of architect relations here at Salesforce for joining us today. This has been a fantastic conversation and I hope to have you back again soon. I had some other are questions that I'd really love to get your perspective on.

Susannah St-Ger...: Anytime. Thank you, J.

J Steadman: If you want to learn more about all things Salesforce admin, go to admin.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, no I, on Twitter. I am @J__mdt and Susannah is @sunnydalelow. Stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.

The Salesforce Admins Podcast is back atcha with Austin Guevara, Senior Platform Product Designer at Salesforce. He has a great conversation with J. about how he goes about testing prototypes and getting user feedback.

Join us as we talk about how Flow Builder is designed, the importance of user feedback, and the value of accessibility in design.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Austin Guevara.

The Essential Habits for Admin Success, now on Trailhead

If you haven’t already, check out The Essential Habits for Admin Success on Trailhead. Become one of the first Admins to get the new badge!

The basics of product design

Austin is a product designer working on Flow Builder, which means he spends a lot of time “trying to understand the problems related to automation that our Admins encounter. [I] think about how we can help them be more efficient, effective, and delighted when they’re doing what they do,” he says.

As a product designer, his job is to understand deeply what the user experience is like for Admins, what challenges they face, and how they can help solve those problems. That means a lot of conversations with folks like J. to understand what things feel like right now and what other Admins are saying. They also spend a lot of time talking to everyday customers, getting feedback and working through prototypes to figure out what will work best.

How you can use prototyping in your design process

 

Austin spends a lot of time working with different types of mock-ups of the product he’s designing. Sometimes they’re built in HTML to rough out what the finished product will look like, sometimes (if they’re far along in the process) it’s something with a lot more bells and whistles, sometimes it’s as simple as a sketch on a piece of paper. What matters is getting the idea in front of people in a way they can understand and talk about.

This kind of process can be useful no matter what you’re building. Figure out the simplest way to get your ideas out there—usually, it’s pencil and paper—and then put them in front of someone to see if they make sense. “The best thing about creating a cheap prototype,” Austin says, “is that you didn’t put a ton of time into it. The goal is not to be the solution, the goal is to help get more information that will get you to a better solution.”

User research with the help of SABWA

The important thing is to keep getting more information and keep iterating. “Admins are designers: they are designing solutions that end users are going to interact with one way or the other,” Austin says, “and what helps me as a product designer is realizing there’s no black and white about what is the best solution. But with more information and more craft you can create a better solution that most optimally addresses the problem you’re trying to solve.”

SABWA: Salesforce Administrating By Walking Around is a key skill to get a sense of what’s working and what’s not. The important thing is to have a learner’s mindset. Observe what’s going on so you can learn how to make things better. One technique Austin suggests is to sit down with users and have them teach you how to do something in Salesforce. Ask them to talk through what they are doing and explain why they are doing it that way. This can help you understand the thought process behind their workflows and where you can give them a helping hand.

 

Austin has a lot more great advice about how to ask productive questions that don’t lead the responder, where to learn more, and why accessibility benefits everyone, so be sure to listen to the full episode to learn more.

Podcast Swag:

• Salesforce Admins on the Trailhead Store

Learn More:

• The Salesforce User Experience (UX) Designer Certification
• Trailmix: Prepare for your UX Designer Credential
• Article: 7 Tips to Build a Winning Salesforce Homepage
• Podcast episode: Design Thinking for Admins with Adam Doti
• The Design of Everyday Things by Don Norman
• Essential Habits Trailhead Badge

Social:

• Salesforce Admins: @SalesforceAdmns 
• Austin: @AustinGuevara
• J.: @J__mdt
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Love our podcasts?

Subscribe today or review us on iTunes! 

Full Show Transcript

J.:
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 Austin Guevara, senior platform product designer at Salesforce about how Flow Builder is designed, the importance of user feedback and the value of accessibility in design. But before we jump into that, I have some exciting news.

J.:
Available now on Trailhead is a new module for the essential habits for admin success. That's right, the webinar slash Trailhead live slash 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 the Trailhead and be one of the first admins to get the new essential habits Trailhead badge. Now let's get Austin on the podcast.

J.:
Hello, you wonderful admins out there. I have a great guest here. Hi Austin. I am joined by Austin Guevara today, who is a senior product designer for the Salesforce platform. Austin, you and I have known each other for quite some. We've worked together pretty consistently during that time, but that is not true for everyone that's listening out there. Could you introduce yourself to the awesome admins who are listening today? Tell them a little bit about who you are, what you do.

Austin Guevara:
Yes. I would love to. Hi admins. It's great to be here. Thank you so much for having me, J.. Like you said, my name is Austin and I am a senior product designer. And the team that I work with is platform automation, which means that I am lucky enough to be a designer for Flow Builder.

Austin Guevara:
That is the majority of what spend most of my time thinking about and trying to understand the problems related to automation that our admins encounter, and think about how do we help them be more efficient, more effective, and just be more delighted when they're doing what they do.

J.:
Yeah. Could you just describe to our listeners the way in which you and I work together?

Austin Guevara:
Yes, absolutely. So just a little bit. If you're not familiar with, I guess, my title is product designer, you might also hear UX designer or user experienced designer used somewhat interchangeably. And what that means is that I work with our wonderful product managers and our engineers and our content experience folks. And my job is to understand deeply what is the experience, the current experience like for our customers.

Austin Guevara:
What are some of the challenges that they are facing and then think holistically about how do we go about solving that problem. That stems everywhere from what is the set of concepts that we present in Salesforce. But it also comes down to, all right, what do the actual, what do the things look like, what does it feel like to build a Flow for example.

Austin Guevara:
And so if we're working on a new feature, and let's say that that feature is related to how you manage your record triggered Flows, for example. And this is a real example because J. and I talked about this recently. In order to understand those problems in order to really empathize with what challenges people are encountering, I need to talk to people.

Austin Guevara:
And since I can't actually live someone else's experience, the only way to do that is to ask them questions and understand their experiences. So J., and I have talked many times about... Love to come to you as someone who is both experienced as an admin yourself, but also who knows and talks to a lot of other admins to understand what are the real world challenges.

J.:
Yeah. To take a step back and kind of make this really explicitly clear to anyone who's listening. If we take a look at Flow Builder for example, Flow Builder didn't always look and feel the way that it looks and feels today. When I started as an admin, blushingly I have to confess it's been about 10 years now, since I started using the Salesforce platform, we had what was called, I believe Cloud Flow Designer.

J.:
And even that was not the first iteration of Flow Builder. To my understanding this predates me. I believe that there was actually an application that you had to download and then you'd create a Flow and you'd upload that Flow. And then you could use the Flow on the platform.

J.:
I could be getting that wrong by the way, because again, that was not my personal experience. But if we take a look at the difference between the Cloud Flow Designer and Flow Builder, which we're using today, the experience is pretty significantly different. The look of it. I like to call the older version Cloud Flow Designer, it felt very much like a program from the eighties, right?

Austin Guevara:
Mm-hmm (affirmative).

J.:
It was just, it was incredibly functional, lots of power behind it, but it didn't look as though it was created with the experience of the user first and foremost in mind. Whereas, when we look at the current Flow Builder, it is much clearer today than it once was how to use it, what you can do with it, how you should interact with it.

J.:
And so anytime that you're trying to modify that look and that feel, you go out and you talk to a number of people. And it just so happens, I'm one of the people internally at Salesforce that you speak with. But who are some other folks that you interact with on a regular basis or that your team would interact with on a regular basis to collect some more feedback, to understand how users interact.

J.:
Right? Because that difference between the two versions of Flow Builder that we're talking about, that's just an example, but it's a really significant difference. And obviously, you didn't make those choices or the team didn't make those choices in a vacuum. So who do you approach? How do you approach them? How often do you approach them? What's your relationship with the audience that is using the stuff that you make?

Austin Guevara:
Yeah. So there's a number of different ways, depending on what point in time that we are going to try to talk to the real people using the thing and understand, all right, how do they go about using it. Of course, as wonderful it is to be able to talk to someone like you J., who is just a Slack message away and who we can spin up a video call at any point in time and just chat about something.

Austin Guevara:
We also really want to talk to customers, to people who are using Flow for their job every day. So there's a few different ways that we might do that. We have a whole Salesforce user research recruiting team. So oftentimes they will actually go through the recruiting process for us. We'll tell them, these are the types of people that we want to talk to because of the, whatever the feature is that we're working on.

Austin Guevara:
And we will get users to be able to talk to that way. Sometimes we send out surveys to ask for feedback. Other times we will send out a self moderated test where you will click through a prototype and be able to like speak aloud about what you're seeing. And in other times we might reach out directly to members in the MVP community who are very, very eager and excited to share their opinions.

J.:
Yeah, absolutely. You brought up prototype, which is something I'm really fond. The interaction that we have are great no matter how we're interacting.

Austin Guevara:
Yeah.

J.:
I think you're a very fun person, but I think the thing I enjoy most is when I actually have a prototype to click through, is we can have a conversation about it as we're doing.

J.:
So can you talk a little bit about your prototype process and as you're working with folks on the product side, and you're developing a prototype, and that starts to become an interactive thing that people can touch and provide feedback on, what tools are you using and how rapidly are you designing?

J.:
How quickly do changes go from an idea, a conversation to product, into a prototype that you get feedback on and then ultimately get deployed. So kind of a few questions bundled together there, but go ahead and take a crack at them.

Austin Guevara:
All right. Yes. I mean, I love talking about prototyping because it's one of my favorite things that I do. And that's one of the reasons that I'm a designer is I love creating something that is sort of like a simulation of what the final thing is going to be, and then figuring out, using that as a way to have a clearer conversation with somebody or to just get a sense for yourself of how this thing is going to work.

Austin Guevara:
And the thing about prototypes, as a word prototype, I think you can describe so many different things. For me, and maybe the thing that comes to mind for you as well is something that looks a lot like the real thing, and maybe even as interactive and that you can click on and get a feel for how it actually works. But prototyping is really something that you use throughout the entire design process.

Austin Guevara:
And it doesn't just have to be something that you would create in really what we call, high fidelity. In other words, looks really close to the final thing. So we do, we spend a lot of time in Figma, which is a design tool, which you can actually start using for free if you wanted to, if you wanted to play around with it. Or maybe even code and HTML, and that will create a really high fidelity prototype.

Austin Guevara:
But typically, if we're doing that level of high fidelity prototype, it means we're pretty far along in the process. And before we've created that prototype, we have many others that are of much quote, "Lower fidelity" that we've created first.

Austin Guevara:
So that could be everything from literally sketching with pencil on a paper, boxes and text that just kind of describes what we're thinking about to maybe some wire frames. Literally think about like pulling up MS Paint or PowerPoint and drawing some boxes. But what I love about that is it's as much as there's this specific skillset of using these, of using HTML or higher fidelity tools, anybody can draw a picture on a paper as a way to help communicate with other people.

J.:
If I can interject here for just a second.

Austin Guevara:
Yes.

J.:
What I like about what I'm hearing, and what I think is particularly relevant or valuable for the admin community, is you a professional designer who makes UX changes and UI changes to a tool that is used by millions of customers around the world, you're talking about getting a piece of paper and just sketching some stuff down or throwing some stuff together in PowerPoint or in MS Paint.

J.:
The reason that I like that you're talking about this is I'm a huge fan of the design phase of any kind of Salesforce administration work. Right? Which means oftentimes when I'm advising folks in the Pathfinder program where I mentor or elsewhere, I'm often talking about closing the computer for a little while.

Austin Guevara:
Yeah.

J.:
And just going over to a whiteboard or opening up a journal or whatever you have in front of you, and really starting to kind of sketch out your ideas, whether that is the data model of the thing that you're trying to build, whether it's the screens that you'd like on a Flow, whether it's the lightning page that you would like to have for a record and spend some time with that design first. And in fact, the thing that I'm kind of like a broken record with this. I'll tell people to go and sketch your first idea, show it to someone, take all the feedback that they give you and then your first sketch away.

Austin Guevara:
Yeah.

J.:
Start a second sketch fresh from that feedback. Right?

Austin Guevara:
Yes.

J.:
And it sounds to my ears, Austin, that you're talking about something very similar here, right? Where we don't need something that is what you're calling high fidelity, or for admins listening out there, I would just say, you don't need something that's incredibly fancy or complicated to convey the initial ideas of your design. And does that sound right to you?

Austin Guevara:
Yes. What I love about what you said there is that you have-. I guess, I think of sketching on paper as a really cheap way to get your ideas down. And I love what you said about take it to somebody, show it to them, get feedback and throw that away. Because the best thing about creating a cheap prototype or a cheap just design, quick way to get your ideas out is that you didn't put a ton of time into it. And ultimately, the goal of it is not to be the solution in itself. The goal is to help you get more information that is going to help you get to a better solution. So yeah, that's a great way of describing it.

J.:
Awesome. So we've got this idea of coming to a better solution, iterating, moving from a low fidelity to a high fidelity solution, prototyping. At what point in your process do you or your team members say, "Okay, I'm going to let this fly and let's deploy."

Austin Guevara:
Yeah. I mean, we try to work with the different roles that we collaborate with in a more agile fashion. Which means we try to avoid the typical waterfall approach of, "All right, I'm the designer. I'm going to come up with what the design looks like, and then I'm going to send it off to the engineers to go build." Ideally, we are involving engineers throughout that entire process.

Austin Guevara:
Not only to be able to kind of check what we are trying to do technic, but also because they're great ideators and they have a lot of wonderful ideas about how we can address problems. So we work closely with them. And I guess, to answer your question, sometimes it's hard to say exactly when things are quote, "Done" because you kind of continue to work on them. And so we know that at Salesforce, we have our three releases a year.

Austin Guevara:
And so over each of those release periods, you can kind of think about each four month period as like a cycle. And so near the very beginning of that cycle is when we are more open-endedly trying to think about what is the specific problem that we're trying to solve. And that's when we're going through with our sketches and trying to get our ideas out there and try to refine to a more specific, this is the feature that we are trying to address.

Austin Guevara:
So then over the course of, let's say a six weeks, we're refining down to a more specific, "Here's the designs. Here's what this feature could look like." Maybe a prototype that shows like this is what the interaction will look like. And then at that point, we are working with engineers then to break that down to figure out, all right, how much effort is this going to take.

Austin Guevara:
How much is it going to take to develop this? And then we're working with them side by side as they are working on that, to help answer questions as they come up. So that kind of answered your question, that kind of didn't. There's no real end. Because the other thing is even after the release goes out, there's very few things or very few features that I've worked on where it goes out and then we're done with it. It's typically something that we're continuously evolving.

J.:
Let me ask-. Actually I want to interject on that because.

Austin Guevara:
Yes.

J.:
It's a question that I've had that I've been interested in across all of our products. And I don't think I've ever actually really asked the question. You said that most things aren't ever finished, you're always tweaking and enhancing them, has there ever been anything that you've been working on where it's just been, "Okay, yes, that's done. Let's step away. And let's focus all of our efforts on something else."

Austin Guevara:
It does happen sometimes. I would say at some point we've all experienced this. There's some products where we say, "Hey, there's something new that we believe is going to be the better way to address this problem area going forward." And so at that point, oftentimes that means, hey, this thing that we've iterated on this product we've iterated on for multiple years, we're not going to invest new effort in because we're putting all that new innovation into another area.

J.:
Yeah. So what I'm hearing is outside of things that end up kind of being sunset or going end of life, or we announce another product that may be the future of that same kind of functionality, we really keep tweaking until we decide, all right, cool. There's a better way to do this. Let's put our efforts over there.

Austin Guevara:
Yeah. I think what's interesting about design and something that I've come to terms with the more time I've spent in my career is that there is no such thing as a perfect solution. And so I'm sure that, I mean, I would say the admins are designers, right? They are designing solutions that your end user are going to interact with one way or the other.

Austin Guevara:
And I, as a product designer, often try to... Am stuck in this mindset of, "Oh, I've got to find the right answer, the right way to do this." And what helps me sometimes is realizing there's no yes, there's no black and white about this is the best solution. But with more information and more craft, you can create a better solution that most optimally addresses the problem that you're trying to solve. So that, I think if you think about things that you keep iterating on, that's why, because we keep finding ways to improve things.

J.:
I am really glad that you mentioned that because one of the things that we really try and focus on with our admins, there are a lot of skills that we talk about is the Salesforce admins. There's a bucket of skills that we think are really, really important. There are core responsibilities that you have as a Salesforce admin that correlate to those skills.

J.:
But one of the things that we really emphasize in the audience relations team or the admin evangelism team is continuously going back to your users, riding side by side with them, or visiting them where they're working and kind of understand their day to day, observing them, seeing how they interact with the applications that you've configured or developed on the platform. And then basically take notes, right? A lot of the recommendations that we make, as we're talking with admins that are out there in the awesome admin community, we talk about you don't have to ask any leading questions.

J.:
If you just sit next to somebody and you witness how they're interacting with the thing that you've put together, if you've got a learner's mindset very often, you'll start to observe things that need to be tweaked. And need might be the wrong word, maybe it's things that could be tweaked, right? Are we able to eliminate a click? Are we able to highlight or bring into focus, something on the screen that has been previously overlooked?

J.:
And it sounds to me like we're kind of saying the same thing there. And I really enjoy that because I agree with you. Not only do we have a new certification for user experience, design, but I think that we've been doing this as admins for a very long time from page layouts to record pages to the way that we even assemble a report or a list view, the way that these things look and feel. Even if they're within a certain visual vocabulary, they still have impact.

J.:
And the choices that we make are never really finished. And I've found in my experience as an admin, that it was very similar, right? I'd have a release schedule, maybe once a month, we would have things that we were collecting from the business that needed to be implemented. But we'd also be thinking about those things that they needed a little bit more attention and Finesse because people are using them every day and they're observing things that cause them friction or cause them displeasure.

Austin Guevara:
Yes. There's plenty of that. And I guess, I have a few thoughts or words of advice. I love the, going to where people are using the thing and observing them using it is one of the best ways you could possibly learn about how to make things better.

Austin Guevara:
And something else you might try that is similar to that is you can sit down with them and say, "Pretend like you are teaching me how to do this."

J.:
Yeah.

Austin Guevara:
"And just speak out loud through what are you doing and why are you doing it? And I might jump in with questions to ask why you're doing something." That way you cannot only see how they're doing it, but also understand their thought process behind it.

J.:
Well, would you agree as you're doing that, that it's important to just focus your questions around the purpose of the action that the user is taking without trying to lead them to a solution that you think is the most appropriate?

Austin Guevara:
Absolutely. But that's definitely one of the biggest skills related to, I guess, doing user research. That definitely takes some practice. But as much as possible, not structuring leading questions. For example, instead of asking, "Why was that difficult for you?"

Austin Guevara:
Right? You might ask something like, "How would you describe your experience with that?"

J.:
Right.

Austin Guevara:
So thinking about the neutral language that doesn't lead them to, oh, something that is definitely negative or something that is positive, but just, "How did you experience that?"

J.:
Yeah. So on that note, right? What I'm hearing is if I ask somebody, "How difficult did you find that?" What's being emphasized, there is difficulty. And in fact, the way that the question is structured, there is no room to give an alternate answer within the confines of the question, right?

J.:
I have to tell you how difficult something was. I can tell you that it wasn't very difficult, but you're still getting a difficulty answer as opposed to, "How would you describe that experience?"

Austin Guevara:
Right.

J.:
I am now free to use difficult, I can use easy. I could use other words that the designer may not have thought of at.

Austin Guevara:
That is absolutely true. And something else, anytime I'm opening up a conversation, either an interview or contextual sort of study where I'm watching somebody as they do something, I always try to cue them with, "Tell me you're very honest and open feedback? There's no hard feelings here. I'm not testing you. Whatever you have to say is valuable."

Austin Guevara:
Because I think people tend to sometimes be overly nice. They might soften their actual experience because we work with a lot of, which is great, but sometimes what you really need is the honesty. And to be able to take that. And not take it personally, but just see it as an opportunity to make the thing that you are working on even better is will take you really far.

J.:
I'd say also in my experience as I'm going through that same encouraging folks to be as honest about their experience as possible, I have found in my own personal life, sometimes I also have to remind myself to take what folks are saying with some grace, right?

Austin Guevara:
Yeah.

J.:
Because as you are working with users, even a passing comment, "Ah, I hate this page," right?

Austin Guevara:
Yeah.

J.:
Or, "Whenever I try and save this, it sucks." Right?

Austin Guevara:
Yeah.

J.:
That kind of language, if you're not prepared for it, or if you don't remind yourself in advance, if you're a person like I am, I am a sensitive flower and my feelings will get hurt unless I remind myself, hey, they aren't directing this toward your value as a designer or your value as an admin.

J.:
Instead, this is just honestly how they feel about the thing that's in front of them. And I find myself having to armor up a little bit it sometimes and saying, "It's going to be cool. Even if it's bad, it's going to be cool." Because that's going to give you the feedback you need to make it better for everyone.

Austin Guevara:
Yeah, absolutely. I think it's really just sort of a mental shift. If you can position your minds that what I am getting here is data. I am collecting data. It's not a personal attack on my abilities or the thing that created.

J.:
I love that. So we're nearing the end here. I would like to know from you, Austin.

Austin Guevara:
Yes.

J.:
What do you think are admins out there, what nugget should they take away from you, a designer about their day to day work? Is there any last word of an advice, skills that they should pay attention to, resources that you enjoy? It's a broad bucket. You can fill it the way that you want. What's the wisdom that you pass on here at the end of our conversation?

Austin Guevara:
There are so many things I could say, but there are a few things that come to mind. If you are interested in learning more about the topic of human centered design, which really can be implied in so many areas. There's a book called, The Design of Everyday Things, which is a great resource that is sort of the Bible on understanding that whole way of thinking about, of creating things. There is also the Salesforce UX designers certification. And of course, a company with that is an incredible trail mix that has a ton of resources that of course are very Salesforce specific. So I think-.

J.:
Which we will link to in the blog post associated with this podcast.

Austin Guevara:
Go click it now and explore it. Yeah. And also, I was going to share, there is a talk from I believe is a Trailhead DX from a couple years ago from one of my colleagues that is basically applying the design thinking process to creating a homepage.

J.:
Oh.

Austin Guevara:
And so it's not for Flow specifically, even though I like to, I'm kind of biased towards thinking about things related to Flow, but it's a great way of, hey, how might I take some of these concepts and apply it to something that I am working on in the near future.

J.:
Awesome. I've got one last question that I want to ask you.

Austin Guevara:
Yes.

J.:
Because I want to end it just on a tone of controversy.

Austin Guevara:
Oh good.

J.:
Do you prefer Freeform or Autolayout?

Austin Guevara:
Oh, this is a great question. I'm so glad that you asked. If I'm going to pick something, I would have to pick Autolayout. And let me explain.

J.:
Wow.

Austin Guevara:
Let me explain a little bit. So Autolayout is something that the Flow team has worked on not only as what it might appear initially, which is to take my Flow, organize it nicely, not make me think about how I'm connecting things, which is a great advantage, but it also is pretty powerful for keyboard and screen users, because now they have a procedural way to navigate through an entire Flow and understand how things are ordered and create things in a logical way.

Austin Guevara:
That's one of the reasons I love Autolayout so much. And also because there's a lot of more love that we are giving to Autolayout. We said that things are always iterating. There's more to be added to what Autolayout has to offer. So yeah, I'm very excited about some of that stuff that we are working on, but I hope you can see why Autolayout's so great.

J.:
My preference for a long time has been Freeform, but in talking with you today, I've learned that the accessibility features of Autolayout are really cool. And I've seen, I follow a lot of designers on Twitter, I've seen a lot of conversations around accessibility, especially recently.

Austin Guevara:
Yeah.

J.:
And I'm newer to that space, so I can't put my finger exactly on why. It may have been a conversation that's been happening for a very long time. But I love the fact that it's something that you are taking into account as the designer. I've actually worked at organizations in the past where some of the Salesforce developers that I've worked with have been vision impaired. And they were using screen readers all of the time to write their or code and interact with things, which is pretty fantastic.

Austin Guevara:
Yeah. What I love is that it's, when you focus on creating an experience that is inclusive and that is a great experience for everyone, for example, for those who are reliant on a screen reader to do most of their work, you end up creating something that's great for every one and even better than it would've been otherwise. So I love taking that lens anytime I'm approaching a design problem.

J.:
That is the end. That's the note we're going to end on. Austin Guevara, senior product designer for Flow Builder. Thank you so much for joining us today. Admins, this has been a blast. And beware Austin, just as you come calling for me sometime, I may call you again and ask you to join me for a conversation here on the Admins podcast.

Austin Guevara:
Thanks, J..

J.:
If you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find more resources, including all the links we mentioned in this episode, as well as a full transcript. You can say up to date with us on social. We are at Salesforce admins no I on Twitter. J. is at J. underscore, underscore MDT. Austin is at Austin Guevara. Stay safe, stay awesome, and stay tuned for the next episode. We'll see you in the cloud.