[00:00:00] Hello and welcome to another X-Force Data Summit presentation. We have Steve Baines. He’s CEO and founder of Forcivity, a consultancy in Manchester, New Hampshire. Steve's going to tell us about some essential soft skills to become an exceptional architect. So you're Steve. I am Steve. Yeah. Thank you very much.
[00:00:34] So, you know, this is playing in the morning and the Eastern Time Zone, but you know, good morning, good afternoon. And good evening to everyone. Actually a few folks in Australia might be listening to this. So, have a cup of tea or a cup of coffee like myself, and, I hope you enjoy it.
[00:00:56] So this is essential soft skills to become an exceptional architect. Now, for those of you that know me, they know, you know, that I spend a lot of time talking about soft skills. Hard skills are something that Salesforce has really done a great job of giving us materials and mechanisms to learn that and, you know, take those exams and become very skilled up from a hard skill perspective.
[00:01:20] But what really makes people exceptional architects is the ability to deal with the more human side of projects and those soft skills that they don't necessarily teach them in school. And it's something that maybe you just have to learn through experience. So this talk today will be about those soft skills.
[00:01:38] So a quick introduction about myself. I am the CEO of Forcivity. We're a Salesforce system integration partner. We're based in Manchester, New Hampshire, which is just north of Boston. This is where I always joke that New Hampshire actually is part of the United States. It's not part of Canada, for those of you who don't know where it is. But of course, our claim to fame is the presidential primary.
[00:02:00] We also have a city that has the only triangle-shaped manholes in the whole country. So a little fun fact about New Hampshire. I'm a certified technical architect. I became a Salesforce CTA in September of 2018. I took my CTO review board in Atlanta. I got my first Salesforce certification in 2014, but I've been in the Salesforce ecosystem since 2004. First as a customer, and then as a partner.
[00:02:25] So I always tell people that I've been on Salesforce since version four of the API. And, we're on version 49, I think, right now. So that is definitely showing my age. I'm the core organizer of Northeast Dreaming, which is a Salesforce user conference, which I'm sure you've heard of many Dreaming events
[00:02:42] throughout the world. Now I used to be just a few in the United States. Unfortunately, many of them are being postponed because of the situation we're in right now. But, you know, very proud to be part of that team. We've had two events so far and we're looking forward to our next one. I am the host of CTA Office Hours.
[00:02:58] That's a monthly event that I put on. It's very similar to going to office hours at school or your college professor. It's an opportunity for you to just chat with the CTA. And I have other CTAs join me from time to time. And it's really just an open dialogue to have folks, pose interesting questions or challenges, and we all try to help them solve those.
[00:03:19] And sometimes it's just a discussion about Salesforce things in general. So if this was an in-person event, what I would be doing right now is I would be polling the audience to ask them, who would consider themselves to be an architect. And this is where I typically get just a few, I'm not a hands put up in the air.
[00:03:39] And then I'll ask yourself, you know, when do you consider yourself to be an admin or are you a developer or an admin or builder, like really just kind of get a sense of where you think you are and what you would refer to yourself as. The reason I asked that is because our perception of ourselves as architects, I think, is much different than a lot of us think.
[00:03:59] And my hope is that at this time rotation kind of, it takes you through that journey to realize that we actually are all architects. We may not just have it in our title. So first things first, this is my favorite architect. And for those of you who may or may not get the reference, this is George Costanza and he was a major character in the sitcom series, Seinfeld, and the running joke throughout the 10 years that the show was on is that whenever George would meet somebody, typically a woman, she asked what he did.
[00:04:32] He had always joked that he was an architect. Of course, it was a bit of a joke and he was trying to make himself seem a little bit more important, in this case, the women. So he could, you know, they'd go on a date with them, but, I simply show this as a joke, but also to kind of talk a little bit about this whole notion of architects being this elevated kind of mystical position a bit.
[00:04:53] So for those of you who have not actually seen George in action, here he is. If I see her, what do I say that I'm doing here in the building? You came to see me. I work in the building. What do you do? I'm an architect. I'm an architect. Have you designed any buildings in New York? Have you seen the new addition to the Guggenheim?
[00:05:18] It didn't take very long either. What about architects? Steven? He's into architecture. Hey, just like you pretend to be.
[00:05:29] Let me be the architect. I can do it. Why couldn't you make me an architect? You know, I always wanted to pretend that I was an architect. I'm an architect,
[00:05:48] railroads, engineers, do that. They can. Very knowledgeable. I'm a, I'm also an architect. You're an architect. I'm not. I can discuss other things. You know, architecture. Nothing is higher than an architect. I suppose you could be an architect. Isn't an architect, just an art school dropout with a tilting desk and a big ruler.
[00:06:20] It's called a T square. Okay. So you can see that that was many scenes with him referring to himself as an architect. So it was, it was a 10 year running joke in Seinfeld. Obviously I put this in as a joke, but well, also reinforce the fact that there is a little bit of a mystical around the title of being an architect.
[00:06:38] And my goal really today is to, is to remove that, that kind of mystical aspect of an architect, and really help you all come to the realization that we are all architects and we, we do architecture work. Every single day. We just may not be called architects.
[00:06:57] So let's flip over to the architect journey itself. I'm sure many of you have seen this triangle before. you know, you've got the newest Salesforce plushy route there who was introduced last year at Trailhead DX, but this is the architect pyramid. Each of those areas are what are referred to as, you know, domain certifications or domain expertise.
[00:07:17] Of course, you know, that the application architect is much more builder focused or configurator focused, declaratively focused. Whereas the system architect is much more technical focus. Now, the thing that I will always point out to folks when I'm ever giving this talk, is that. You don't necessarily have to be a developer to be an architect.
[00:07:36] And I would say, I would actually say that you don't have to be a developer to be an architect. This is one of the common misconceptions about being a CTA or just an architect, in general, is that you have to have really, really strong coding chops. It's not necessarily that you need to be a super-strong coder, but it's more about, you just have to have an understanding of what the possibilities are with Salesforce technologies when it comes to coded solutions versus declarative solutions.
[00:08:01] That is the whole notion about being an architect is really having a good understanding of what the possibilities are. It's like, you know, you don't necessarily have to know how to do every single thing in the Salesforce ecosystem, but you just have to know that they're possible and that you can design a solution and then perhaps hand it off to a solution architect or a developer.
[00:08:22] I grew up as a developer. I don't really write code that much anymore, though, so, but I still continue to function as an architect. And the reason I can do that is because I have an understanding of, you know, code, what's possible with code. It's not even about how to write a class or how to write a trigger.
[00:08:38] It's simply about, I know that things can be done with code, or I know that when customers are asking for certain requirements that can't be done declaratively, that I can go to a coded solution and do that. So, if there's anything you hear me say consistently throughout this talk is that you do not have to be a developer in order to be an architect.
[00:08:58] Some of the things that you do have to think about though, is that this is really about being business-minded. It's thinking about how these solutions will satisfy your business users’ requirements. You do have to have a level of, you know, technically adept. So you still do have to understand what's possible on the Salesforce platform, but it's really about being that Jack and Jill of all trades.
[00:09:23] It's having that mastery at a level that you can discuss solutions and different approaches and best practices and design that solution. And then, in turn, hand it to somebody. And oftentimes you may be handling it yourself to do that work. This kind of goes back to the whole notion that we are all architects.
[00:09:41] We just function in different capacities, depending on besides the company we're in or the size team that we work on. A lot of architects are master of many things, and sometimes there are some things do not have to have super wide knowledge or super deep knowledge across.
[00:10:00] Everything related to Salesforce, you can be a master architect in e-commerce or marketing cloud or integration. You can serve specialize in architecture. And that's really the intent of this certification pyramid is to allow you to really focus on areas that matter most to you or matter most to your company or matter most to your team.
[00:10:22] You don't necessarily have to achieve every single certification on this pyramid. Again, you do not need to be a developer to be an architect. I say that over and over again. When I chat with people about their journey to CTA I'm, I'm chatting to a gentleman right now and he was actually asking me if he should. Take a step back in his career and actually spent some time working as a developer for the next couple of years before he goes and gets a CTA.
[00:10:47] And it all goes back to that notion that you have to be a developer. And I actually said, and you really don't need to do that. You can really drive towards being that CTA. Still get a little coding experience. You'll learn your chops a little bit, but it's definitely not necessary to really deviate for a couple of years and become a super-strong developer just to achieve becoming a certified technical architect.
[00:11:07] All right. So let's talk about what architects proverbially do. So these are more hard skills. So this is what's referred to as the five D approach. You may have heard this before. So when we are working on a project, the first thing we'll do is we'll do discovery, and we'll go out and say, Hey, tell me a little bit about this problem.
[00:11:28] What are we trying to solve? What are your business requirements? And the stakeholders will tell you what they want. “They often say, Can you do this? And then we actually, you know, define what we're going to do. This is where we tell the stakeholders what we think they need to do. Now us as architects, this is where we look at the solutions and say, my business users are asking me for this, or they've already come to me with a solution.
[00:11:56] Should we do that? Or should we do it a different way? Should we do it at all? You know, this is where we, you know, we put that business cap on and really start thinking about this from a business perspective, is this really the best solution? Or are there different ways we can go about this. Then we go into design mode, we're building the coding might not be coding.
[00:12:16] I can get, share a most recent example with you that I worked with one of our customers to develop a COVID solution for them. And it's been deployed at a fairly large scale. There's not a single line of code that's been written in that solution. It was a 100% declarative solution. So yeah, again kind of reinforces the fact that you don't have to be a developer to be an architect.
[00:12:37] You can really think about what's the best fit solution, time to market your budget, the users that you're working with. And just really what the requirements are. Of course, there's lots of things you can build with code, but sometimes code is just too much. You know, there really is elegance and simplicity.
[00:12:53] In this case, building everything declaratively was the simplest approach and it actually turned out to be the most effective approach. Now, as part of that five D approach, of course, the fourth stage is development. And again, not necessarily that you're right now, you're developing development can mean a lot of different things, especially with tools like Flow right now, where you can build really powerful, automated solutions without writing any code.
[00:13:18] And then last but not least, you go into deployment mode. And of course, there's lots of ways you can go about doing that. This is definitely outside the scope of this talk, but. You know, continuous development and dev ops as a whole, as a burgeoning industry in the Salesforce space. And there are many, many options available to you.
[00:13:35] But at the end of the day, the whole notion of getting your builds from a pre-production environment into production environment is typically your last step.
[00:13:48] So our solutions, you know, really what should they be? You know, we supposed to, we're supposed to design and build robust solutions. And what that means is that it's something that's got to work, you know, it's gotta be, it's gotta be sturdy. It can't be a house of cards. It's gotta be something that your customers can rely on.
[00:14:05] We also have to think about the concept of retry. It's really about. You have to design solutions for when things will go wrong. It's not about if things will go wrong. It's about when they'll go wrong. As an example, if you design an integration between the ERP system and Salesforce. Eventually, there's going to be a problem with that.
[00:14:25] You're going to have bad data. There's going to be a transmission error, maybe login credentials go bad, something will go wrong. How do you handle that? How do you design that into a solution? So your users can retry that transaction or the code. We try that it's actually. Then, of course, our solutions have to be replicable because we have to be able to do them over and over again.
[00:14:48] And again, it goes back to being robust and being reliable. But you know, these still really all focus on hard skills. It's all about designing solutions. This is very, very technology-focused. Let's talk about why we're really here. And this is about acting and thinking like an architect. Now, you notice I wrote up at the top, I am an architect, but I put “am an” in parentheses for a reason.
[00:15:17] I wrote it that way is we're an architect is actually a noun, but it also can be a verb. So an architect is a person who's responsible for inventing or realizing a particular idea or project. So when I say, Hey, are you an architect? This is what we all immediately think of. It's like, I'm not an architect, I'm a developer, I'm an admin.
[00:15:38] But when you use the phrase, I architect, totally different meeting. Now we're talking about the verb. We design things and we make things. This is where we all can now start to bridge the gap of, Hmm. Maybe I actually am an architect because I'm designing little micro solutions, micro scenarios or microservices.
[00:15:58] It really is architecture. It doesn't necessarily have to be this grand scheme, grandiose type of design, and solution that we're putting together. It really can be at a micro-scale. So, another video here, this one is a quick, a quick video as well, but the backstory to this is years ago, I used to work in plumbing and heating wholesale.
[00:16:19] Yeah. And there was a time when, I was the buyer for Kohler plumbing products, and this happened to be a commercial that came out at the time. So yeah, it kind of resonated with me because I found a really, really interesting way to weave it into the story about being an architect. I'm gonna go ahead and play it.
[00:16:37] And then I'm just going to talk a little bit about it. And, just kind of frame it in the way that Salesforce architects can kind of apply this to some of their real world experiences. This is a classic or design
[00:16:47] Design a house. All right. What was that you know, for also for those of you who maybe couldn't quite hear that really, what she did is they sat down at the desk and he's showing off all of these great things that he's designed with his firm. And he says, what can I do for you? And she slams the faucet on the table and says, Build a house around that.
[00:17:38] So what do we call that in art, in architectural worlds, you guessed it that's requirement gathering right there. So that was her requirement. Build a house around this faucet. Believe it or not, I'm standing in the house right now that I tell people all the time that I actually built it around a pool table.
[00:17:57] You know, way back years ago, when we were living in our old house, I really started getting into playing pool and I wanted to have a pool table. At the same time we decided to build a house. And I built my game room specifically around being able to house a certain size pool table. It fits perfectly. We don't have to use little sticks or anything.
[00:18:16] So that was really my version of the Kohler faucet. But, you know, it's like, it's like, no. So sometimes do you really see kind of users and be like, what, what are you talking about here? I mean, because really what you're, what you have here is she's your stakeholder. And it's up to us as architects to really look at our stakeholders and be like, okay.
[00:18:39] I was just given a really vague requirement. How can I go about extracting the right level of detail from her to make sure that she's happy with what I designed for her, you know? And the kind of the way that she's looking at it, she's like, she's just kind of given this look like, I wouldn't be thinking about that.
[00:18:56] How do you like them apples? And he's like, Challenge accepted. I can do that. So this is really where we now start talking about the art of being an architect.
[00:19:08] So let's get into it. Let's start talking about some of these soft skills. First and foremost. It's obvious. The skill of talking. For those of you that know me. You know that I have no problem talking. I can talk and talk and talk until the cows come home, but what's equally as important to talking. Is listening, Talking, listening together.
[00:19:29] It becomes what we all call communicating. But it's important to be able to know when to say yes. And when to say no. On the surface, it sounds like those would be really easy things to do. But the reality is, is sometimes they're really challenging when you've got, you know, a business user that's coming to us as I really, really want this, or this is how you're going to do this.
[00:19:53] Sometimes it's really difficult to say no to them. It's like, how do you help them through that? When you know, it's not the right solution or, you know, there's a different solution that will do it better or faster or cheaper, or just because you've got somebody else who's given you a requirement that's completely contrary to what this user is saying.
[00:20:08] Well, this is where it becomes less about science, less about hard skills, and more about the art of being an architect. So let's talk about the art of listening. There's a hyperlink on this slide here, which I highly encourage people to check out. I reference it quite a bit and it talks about the principles of listening.
[00:20:27] Listening is a skill listening to is, is very different than hearing. and I, you know, part of becoming an architect and for those of you who were thinking about going for the CTO review board, one of the skills that's emphasized immensely as part of preparing for that is your ability to communicate. Not only to verbally communicate but also to listen.
[00:20:46] that's really one of the things that they'll look for, and this is just like being in front of a customer and being able to convey to them your solution that you've come up with. So what's the first thing you have to do in order to listen. It goes without saying. You have to stop talking. Of course, if you're talking and you know, the person's not going to talk or you're truly not listening they're so you've got to stop talking.
[00:21:08] You've got to prepare yourself to listen. Now, what do I mean by that? It's simply not looking at somebody and be like, all right, go ahead and talk and listening. It's a frame of mind. It's relaxing your body. It's really opening your ears and opening your mind to what they're saying and being ready to receive it and absorb it and being able to react thoughtfully to what they're saying to you. Do things to put your speaker at ease.
[00:21:32] Oftentimes when we're in there and we're where we're dealing with customers and we're gathering requirements. Sometimes there's a little, you know, they're a little bit uncomfortable with it because they're not quite sure what this project is, why are you asking me these questions? Why are you asking me about my job and how I do things?
[00:21:51] Like, are you getting rid of me? Am I getting fired? Are you automating me out of a job? They're wondering all these things. So do things to put them at ease. Remove distractions. This is something that I insist on with my team. If you are in with a customer, the one thing you should not have anywhere in sight is your cell phone.
[00:22:09] Turn it upside down. So you can't see it, put it in your pocket, remove the distraction because when you become distracted with other things, you're telling that customer that they are less important to whatever just occurred. I have been in meetings with the CEO of the company with my boss and I've literally been mid-sentence about making a $250,000 investment in an ERP package and his, his Southwest app dinged to him while I was talking to, he literally got up and went over to check because he thought he was going to get a good fare from Southwest airlines.
[00:22:42] Huge distraction. Really changed my opinion and how I viewed him. And it was very, I felt it was very disrespectful because it told me that to him getting $50 off, off of his Southwest Airlines, airfare was much more important to him than everything that I had worked so hard on. So remove those distractions and really make your user feel like they're the most important person in the world right now.
[00:23:08] Empathize with them. You know, understand that technology solutions have a huge human aspect to it. It's not just about sitting down and configuring Salesforce. There are people behind those screens, behind those keyboards that are making things happen. And when we make technology changes, you are impacting people's lives.
[00:23:27] Some people react very emotionally to technology change, and we have to be sensitive to that. Be patient with them. Sometimes users may not understand what you're talking about. They may not understand the application or the landscape as well as you do. So really be patient with them and let them verbalize themselves, take it in, try not to react negatively, and really absorb what they're saying to you and help them work it out, help them communicate with you, help them talk to you.
[00:23:55] Avoid personal prejudice for sure. So be open-minded. So don't walk in with preconceived notions when you're listening to somebody. Allow their opinions to seep in and consider without bias and really use that information objectively when you're coming up with a solution. Listen to their tone. Listen to how they're actually talking to you.
[00:24:16] You know, do they have, you know, a bit of an attitude in their voice, or are they getting quiet? You know, that really can help you understand what's truly occurring with this particular customer. You know, why are they acting that way? Are they acting angry? Is there, is there a bit of an attitude?
[00:24:34] You know, I'm smarter than you. you know, it's, so it's really important to kind of pick up on that tone. And I also will say body language to really understand what they're actually feeling. Don't just listen to the words, listen for ideas. Listen to what they're actually saying. Again, this is the whole idea of truly listening and letting it come in.
[00:24:53] You'd be amazed at the gems that you're going to get while talking to business users. Forget about talking to executives and directors, and just kind of saying, go forth and do this. It's more about when you start talking to those lines of business users, but people are actually dealing with markets, amazingly, the gems of information that you can get from them.
[00:25:11] And of course the nonverbal communication is key. I always joke that I received probably my biggest dose of nonverbal communication when I had a customer actually throw a clipboard at me, believe it or not, he literally flung a clipboard at me. it certainly wasn't verbal communication, but it was physical communication for sure.
[00:25:32]Turns out that it had nothing to do with me. But, you know, I joked that it was really, you know, you've got to really pay attention to the subtleties and sometimes people may shift with their bodies, you know, even writing with the, with everybody being in, you know, COVID quarantine, they're doing things over video conferences now, and you lose that sense of communication and it's really a challenge for sure.
[00:25:54] It's like, how do you maintain that? I really get a, you get a sense of. You know how people are feeling or did they shift in their chair? Are they rolling their eyes at a crossing their arms like this? You know, that's always a telltale sign that there's not too Jasmine what's going on. So I actually have ref you know, retitled this whole slide and I really call it the art of shutting up.
[00:26:13] Cause that's really what it's about is just zipping it and listening, shutting up, stop talking. I always ask people I'm like, are you really listening or are you just waiting for your turn to talk? So these are really the soft skills now that we have to think about. So it's not about waiting for somebody to stop, and then you just immediately chime in because you were telling them like, Oh, you know what?
[00:26:37] You really didn't listen. You didn't really hear what I just said to you. You were really just waiting to respond because first of all, your response was instantaneous. And second of all, you were smallest, really had nothing to do with what I just said to you. So you definitely want to convey the fact that you are truly lessening or something, not just waiting for your turn to chime in.
[00:26:53] Knowing how to do something versus knowing what to do. Now, here's an example that I always use. Years ago when I worked in the plumbing heating industry, I was out at a job site and it was two buildings that had to be connected by a bunch of pipes to run. The heating system was over here were some units over here and they have to run a cooler water onto the ground.
[00:27:14] Well, the guys had reached the point where all of these lines weren't fitting in the conduit. And the architect happened to come out and they basically got into an argument because the architect said, I designed this on paper and these should all fit in a pipe. No problem. And the guys, the field guys were like, they don't fit.
[00:27:31] And here all the reasons why it's not going to fit. And that really is, you know, it's, it's kind of a subtle difference between being an architect and knowing. What to do versus knowing how to do something. The architect knew that you had to get pipes from here to here through an underground conduit and a tenant shrunk conduit.
[00:27:49] But he didn't really necessarily know all the tricks about how to do that. And what happens if the pipes are crooked and they get stuck or they just don't fit, he doesn't have that type of knowledge. And that really is a subtle difference between being an architect and knowing what to do versus handing it off to somebody else and say, here, go execute my solution.
[00:28:07] Now you do have to know how to talk. Communication is key, but what's as important to know how to talk. Knowing how to get people to talk to you. Being able to extract information out to users is really difficult. It can be a challenge, and sometimes people will clam up. For those of you who have seen office space with the two Bobs, you know, you know that when you're getting visited by the two Bobs, you're not going to say anything.
[00:28:31] You're just going to sit there and answer with one-word answers. Users may get the same way they may have, you know, they may really be questioning your motives. Like, why are you doing this again? Go back to next. Alright. I was like, are you automating me out of a job? Or why are you changing this?
[00:28:51] You want to make sure that you tailor your message to your audience. Don't treat everybody the same way, you know, really kind of hone your message, hone your approach. Hone your words, hone your attitude, everything to who it is that you're talking to.
[00:29:03] Some folks like really direct talk, other folks like, you know, kind of softer approach, you know, the softer side of being an architect, for sure. So really understand your audience and understand their motivations and understand how you can get through to them and effectively communicate with them and in turn, get them to communicate with you.
[00:29:24] My favorite soft skill of all is "begin with the end in mind." So for those of you who are Stephen Covey fans, you know that this is one of the seven habits. I always start with an empty mind. I always ask again, what are we trying to achieve here? What are our objectives? What's important to you to take it down to a micro scenario?
[00:29:43] It's like, what do you need on that report? What do you need to see for fields? And let me work backwards from that to make sure that I build the right object structure for you. Build the right workflow? So the data will get in front of you start with the end of mine and then work backwards from there.
[00:29:58] It’s amazing when you know what you want it to be, how many different design decisions you make leading up to that point, as opposed to starting at the beginning and working toward the end, and then suddenly realizing that you don't necessarily have everything that you need in order to truly obtain, you know, that objective that the user's looking for.
[00:30:14] Don't forget about the difference between, can we do this versus should we do this? This is where being an architect is so essential users may say, I want you to do this and I want you to do it this way. Can you do that? And of course, 99 times out of a hundred, with Salesforce, the answer to that question is, yeah, we can do that.
[00:30:36] But as architects, we should say, should we do this or should we do it this way? Or should we do it that way? This is where us knowing what to do, knowing what's possible really makes us exceptional architects. It doesn't necessarily mean that we have to know how to write that code or know how to integrate with that system.
[00:30:56] But we know that yes, some integration is needed or some automated. We needed to do that. That right. There is an essential skill for an architect. Be sure to recognize obstacles and roadblocks. For sure. So I said earlier technology has become so easy that we really spend very little time, at least in working on technology.
[00:31:15] It's more about everything leading up to that. It's the people in process. So if we remember back to this person, right, it's like, is she a roadblock? Is she in ops? Where's she going to be? That's going to help you, you know, and it's really now, okay. It's like, No, no architects, like, no, not everybody's jovial, like, so this is where we have to really get creative with everybody there, because even we may get architects that, you know, may not have expertise in certain areas.
[00:31:45] So it's up to us as business users to be able to provide the resources to our users. So, you know what, I'm not sure about that, but let me go find out, let me go find the answers for you. All right. So let's talk about the typical project.
[00:32:01] Now if I took a pie chart and I divided the project up into multiple pieces here, I would say today, because technology has become so easy. We only spend roughly 10% of our time with actual fingers on the keyboard, touching with technology. The other 20% is working on process. I mean, how to do things, changing, how to do things.
[00:32:24] How do we get data from here to there? We spend the vast majority of our time working with people. At the end of the day, we are working on people projects. We're not working on technology projects. I'll give you a great example. My physician retired last year. He retired because his hospital was implementing a new EMR system.
[00:32:49] He wanted nothing to do with it. He had gone through it 10 years ago. And said, you know what? I am not doing that anymore. I have no interest in changing my world, my technology world. You're going to tell me no it's differently. Ask my patients differently. I'm not doing that. So he literally retired because of a technology project.
[00:33:09] He was a fantastic physician. He was a great loss to the hospital. You know, I miss having him as my doctor, but as you can see at the end of the day, this really becomes about people. It's not about technology. We really are human behaviors here at the end of the day. That's really what we're focused on is how do I help this person through this change?
[00:33:28] How do I help this group or this company through this? It's really not about how do I make Salesforce do this. A lot of us can do that. Many people can do that, but it's more about how do I get these users to adopt what's just been built, even though they've been very verbal with me that they don't like it because they have to change how they do things or now they spend half of their day doing extra work or they have to come in earlier or at different times because things are done differently now.
[00:33:56] So what do we actually do? I hear a lot of verbs here about what architects actually do. Here's what we do. You can say like, Oh, you're right code. Yeah. Create data diagrams. You create fields. That's not what we do, we guess. We have to sit there and guess it's like, okay, what did they mean by that? Or sometimes you just have to extract information and you just don't get clear information from your customers.
[00:34:20] It's like, you got to yank it out of them. You've got to empathize with them. You're going to put yourself in their shoes. I've had business users become quite upset. I've had some cry because of changes that were happening. Because they were, you don't have to an outsider those changes felt very simple and very small.
[00:34:38] And the reality is, is that it was rocking their world. It was such a drastic change to their world and it was extremely disruptive and it was very upsetting to them. We have to help our users envision the end goal here. I mean, we have to evangelize the solutions that we're creating. We have to paint that picture.
[00:34:56] We have to say, okay, everybody, here's what we're doing. And here's why you should get excited about it. This has nothing to do with writing code. This has nothing to do with touching Salesforce. Again, it's about those softer skills. It's about getting folks on board with your vision and where you're with your design.
[00:35:12] We have to enable them to be successful. So it's not just simply be like, here you go. Here's the solution. It's about, here's the solution. Here's how you can be successful with it. Let me show you, let me educate you on what's. What's happened here. Let me tell you why we've done what we've done. It's not simply about here
[00:35:30] we did this, use this. We have to evaluate, we have to really make decisions. We have to evaluate multiple different variables, multiple different choices, and really come up with the best solution. When I went before the CTA review board, one of the things that they told me when I was preparing is that when you present your solution to the judges, it's not about picking the right solution.
[00:35:50] It's about picking a solution and being able to stand behind it. You have many choices that you can evaluate. There are many ways to do the same thing in Salesforce. So it's about evaluating all the variables that matter to you. And you'll have time budget, skill sets, team size. All of those things is okay, this is the best solution for this scenario.
[00:36:09] Sometimes we have to coerce, people sometimes just say, listen, this is going to happen. Or we have to kind of force them down a road because there are other things and other decisions that have been made that maybe this person's not privy to, or it's not part of the conversation, but you kind of have to force them a certain way.
[00:36:24] Sometimes you get to put your arm around them and just counsel them through, you know, and say, Hey, listen, this is why we're doing it. And it's really just kind of starting to become their advocate and helping them through a situation. And you'd have to console them sometimes and say, Hey, you know, it's going to be okay.
[00:36:41] You know, there's a lot of good reasons why we're doing this and you know, me and my team are going to be right there with you through this. So it really will be okay. You've got to facilitate conversations for sure. Because sometimes decisions are not all black and white. They're not straightforward.
[00:36:56] So you've got to play that facilitator, you know, you've got to play ringmaster, you've got to stand in front of a room and be like, okay, I hear you. But what about this? Or have you thought about it this way? You know, reframe that question back to them. it's certainly as an art for sure. There are certainly trail heads out there as well to talk about a lot of these soft skills.
[00:37:14]But what we actually have to do is we have to defend, sometimes we just have to defend our solution and say, this is what we're going to do. This is how we're going to go about it. It's almost like getting your, your dissertation or your Ph.D. for Salesforce is you've got to put something out there, and then you've got to defend it.
[00:37:31] You know, because not everybody's going to believe in it. So you've got to have some reasons, you know, some facts as to why we're choosing this way. Again, it's not about doing it right or wrong. It's about, I've got eight different choices here, which one is the best way to go about doing this? At the end of the day, I refer to this collectively as what's called being a corporate therapist.
[00:37:50] Because that's really what we are. We're human behaviors. We are really talking about dealing with people in process. It happens to be done in the context of a technology project, but we actually are corporate therapists. So I would ask you all now. Are you an architect? You know, would you, would you now consider yourself to be an architect because architects, what they do is they develop ideas.
[00:38:15] They design projects, they make things. They design things like, see, everybody's an architect now we're all architects. You just didn't know it yet. So my hope is that this talk has helped you come to that realization that we all architect in every aspect of our jobs, every single day, we just may not be called an architect.
[00:38:36] There are some great resources out there on Trailhead about public speaking and storytelling. Some things that are really core to who I am and how I operate. My very first course in college, was a public speaking course, within the first five minutes, my professor said to the whole class that this will be the most important class that you take in your life.
[00:38:59] And he was a hundred percent correct. I didn't know it at the time, but looking back on everything that I learned in that class, it was immensely valuable and I've carried those skills with, with me throughout my entire life. I would highly recommend that one Trailhead right there. You can look for it specifically by that name.
[00:39:16] It'll pop right up. And of course, at anything around storytelling, communication will certainly help you become or become an even better exceptional architect. And thank you very much. Thanks, Steve. I had a couple questions, maybe observations. I mean, I, I mean, you're, you're, you're really emphasizing, you know, that you don't have to be a developer.
[00:39:40] I would even go another step further and say that sometimes being a developer might trip you up in the Salesforce ecosystem because if you're too eager to write code to fix it, problem. Hmm. You have to think twice, you have to, I think you have to think twice in the Salesforce platform before you decide you have to write code. You absolutely do.
[00:40:00] I mean, cause you find it. You can, of course, you can solve most things with code. But coding is not always the best solution. Will it do exactly what you want it to do? Sure. But do they have the staff to support it? Do you have the ability to test every single scenario? Do you have the time to write that?
[00:40:16] You know, who's going to take care of this once you're gone. I mean, so there's, there's so many reasons that go into whether or not you should code or not code. you know, do you have all these testing requirements? You know, so it's, it's easy to simply default to that and say, I'll just code this, get out of my way and code it.
[00:40:33] It may not be the best solution for customers, though. Yeah, I agree. Well, thank you very much. I think it was a great presentation and I think that one of my questions is going to be, are there Trailheads for those soft skills, but you outlined them? Yes. I think that's one of the great things about the Salesforce platform in there and Trailhead and, and the idea and trying to make it administrator.
[00:40:57] If you want to learn those skills, you can in this spot. Absolutely. And anybody can do it. Doesn't matter what point of their career. And they're on. These are, these are skills that are applicable to everybody, whether you're just starting out or you've been at it for 30 years.
[00:41:11] Great. Thanks again, Steve. Great presentation. Thank you. Bye-bye.