Essential Soft Skills for the Salesforce Architect

Hello, and welcome to another X Force Data Summit presentation. Today, have Steve Baines, who's the CEO and founder of Forsivity, a consultancy in Manchester, New Hampshire. And Steve's gonna tell us about, some essential soft skills to become an exceptional architect.

So here's Steve.

I am Steve. Yeah. Thank you very much. So, you know, this is playing in the morning in the Eastern time zone, but, you know, good morning, good afternoon, and good evening to actually, a few folks in Australia might be listening to this also. I know it's the middle of the night, so have a cup of tea or a cup of coffee like myself, and, you know, I hope you enjoy it.

So this is essential soft skills to become an exceptional architect.

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. But what really makes people exceptional architects is the ability to deal with the more human side of projects and those soft skills that you don't necessarily teach you in school and it's something that maybe you just have you know, learn through experience. So this talk today will be about those soft skills.

So quick introduction about myself, I am the CEO of Forsivity, we're a Salesforce system integration partner and ISV partner. We're based in Manchester, New Hampshire, which is just Northern Boston. This is why 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. 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 twenty eighteen. I took my CTA review board in Atlanta.

I got my first Salesforce certification in twenty fourteen, but I've been in the Salesforce ecosystem since two thousand and four. First as a customer and then as a partner. So I always tell people that I've been on Salesforce since version four of the API and we're on version forty nine, I think, right now. So that is definitely showing my age. I'm the co organizer of Northeast Dreaming, is a Salesforce user conference, which I'm sure you've heard of many Dreaming events throughout the world now. It 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 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. 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 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 pulling the audience to ask them who would consider themselves to be an architect.

And this is where I typically get just a few amount of hands put up in the air. And then I'll ask you something, do you consider yourself to be an admin or are you a developer or an admin or a 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 ask that is because our perception of ourselves as architect I think is much different than a lot of us think and my hope is that this kind of 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 ten years that the show was on is that whenever George would meet somebody, typically a woman, she asked what he did, 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 to women so he could, know, they'd go on a date with him 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.

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? Oh you came to see me, I work in the building. What do you do?

I'm an architect. Oh. I'm an architect.

You designed any buildings in New York? Have you seen the, new addition to the Guggenheim? You did that? Yep.

Yep. It didn't take very long either. What about architect, Steven? He's into architecture. Hey. Just like you pretend to be.

Let me be the architect. I can do it. Look.

Why couldn't you make me an architect?

You know I always wanted to pretend that I was an architect. I'm a I'm an architect.

Really? Okay.

Well, what are you designing?

Railroads.

Thought engineers do that. They can. You.

Very knowledgeable.

I'm, I'm also an architect.

You're an architect?

I'm not.

I I can discuss other things, you know.

Architecture?

Nothing is higher than architect. I suppose you could be an architect.

Well, isn't an architect just an art school dropout with a tilty desk and a big ruler? It's called the t square.

Okay. So you can see that there was many scenes with them referring themselves to an architect. So it was a ten year running joke in Seinfeld. Obviously I put this in as a joke, but also to kind of reinforce the fact that there is a little bit of a mystique around the title of being an architect.

And my goal really today is to remove that kind of mystical aspect of an architect and really help you all come to the realization that we are all architects and we do architectural work every single day, we just may not be called architects.

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 plushie root there who was introduced last year 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.

Of course, you know that the application architect is much more builder focused or configurator focused, declaratively focused, whereas a system architect is much more technical focus.

Now the thing that I'll always point out to folks whenever giving this talk is that you don't necessarily have to be a developer to be an architect and 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. That is the whole notion about being an architect is really having a good understanding of what the possibilities are. It's like, you 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.

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

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

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 handing it yourself to do that work. This kind of goes back to the whole notion that we are all architects, we just function in different capacities depending on the size company we're in or the size team that we work on or project working on. A lot of architects are master of many things and sometimes they're just master of some things.

You do not have to have super wide knowledge or super deep knowledge across 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, you know, allow you to really focus on areas that matter most to you or matter most to your company or matter most to your team. 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 art, say that over and over again, when I chat with people about their journey to CTA, 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 spend some time working as a developer for the next couple of years before he goes and gets a CTA. And it's all goes back to that notion that you have to be a developer. And I actually said, you really don't need to do that. You can really drive towards being that CTA, still get a little coding experience, know, 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.

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 5D 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, what are we trying to solve? What are your business requirements? And the stakeholders will tell you what they want and often say, you know, 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.

Should we do that? Or should we do it a different way? Should we do it at all? You know, this is where 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. Decoding might not be coding. I can share 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 fairly large scale. There's not a single line of code that's been written in that solution. It was a one hundred percent declarative solution.

So again, kind of reinforces the fact that you don't have to be a developer to be an architect. 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. 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 5D approach, of course, the fourth stage is develop. And again, not necessarily that 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.

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 DevOps as a whole is a burgeoning industry in the Salesforce space.

And there are many, many options available to you. But at the end of the day, the whole notion of getting your build from a pre production environment into a production environment is typically your last step.

So our solutions, you know, really what should they be?

You know, we are 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 sturdy, it can't be a house of cards. It's gotta be something that your customers can rely on.

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 an ERP system and Salesforce, eventually there's going to be a problem with that.

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 solutions so your users can retry that transaction or the code retry that action?

And of course our solutions have to be replicatable means we have to be able to do them over and over again. 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.

Reason I wrote it that way is word 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.

But when you use the phrase I architect, totally different meaning now. 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 maybe I actually am an architect because I'm designing little microsolutions or microsenarios or microservices. There really is architecture. It doesn't necessarily have to be this grand scheme, grandiose type of design solution that we're putting together. It really can be at a microscale.

So other video here, this one is a quick video as well, but the backstory to this is years ago I used to work in plumbing and heating wholesale and there was a time when I was the buyer for Kohler Plumbing Products and this was happened to be a commercial that came out at the time.

So it kinda resonated with me because I 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 and then I'm just gonna talk a little bit about it and, you know, 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 classical design we did in Milan. It's a postmodern residence. Designed one five prestigious awards. Husky headquarters in Kyoto. To see our architecture, you don't want to call the new world. So what can I do for you?

Design a house around this.

Alright.

What was that?

You know, so 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.

So what do we call that in architectural worlds? You guessed it. That's requirements 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.

You know, way back years ago when we were living in our old house, I really started to get into playing pool and I wanted to have a pool table. 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.

So that was really my version of the Kohler faucet.

But you know, it's like, so sometimes do you really sit in front of users and be like, what? What are you talking about here? I mean, because really 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, 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, what do you think about that? How do you like them apples? And he's like, challenge accepted, I can do that. So this is where we now start talking about the art of being an architect.

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 till the cows come home, but what's equally as important to talking is listening. Talking and listening together becomes what we all call communicating but it's important to be able to know when to say yes and when to no.

Now on the surface, it sounds like those would be really easy things to do but the reality is sometimes they're really challenging. When you've got, you know, business user that's coming to you and says, really, really want this or this is how you're going to do this, 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 saying.

But 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. Listening is a skill, listening is very different than hearing and I, you know, part of becoming an architect and for those of you who are thinking about going for the CTA 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. 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?

Goes without saying, you have to stop talking.

Of course, if you're talking and the other person's not going to talk or you're truly not listening there, so you've got to stop talking.

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, I'm 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.

Oftentimes when we're in there, 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, 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 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.

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 are telling that customer that they are less important to whatever just occurred and I have been in meetings with a CEO of the company with my boss and I've literally been mid sentence about making a two hundred and fifty thousand dollars investment in an ERP package and his Southwest app dinged to him while I was talking. He literally got up and went over to check he thought he was gonna get a good fare from Southwest Airlines. Huge distraction, really changed my opinion in how I viewed him and it was very disrespectful because it told me that, you know, him getting fifty dollars off of his Southwest Airlines airfare was much more important to him than everything that I had worked so **** **. So remove those distractions and really make your user feel like they're the most important person in the world right now.

Empathize with them, you know, 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. 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.

Avoid personal prejudice for sure, so be open minded. So don't walk in there with preconceived notions when you're listening to somebody.

Allow their opinion to seep in and consider it 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. You know, do they have, you know, a bit of a attitude in their voice or are they getting quiet? You know, that really can, you know, help you understand what's truly occurring with this particular customer. You know, why are they acting that way? Are they acting angry? You know, is there a bit of an attitude or is it like, know, I'm smarter than you. You know, 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 to come in. You'd be amazed at the gems that you're gonna get out of 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 line of business users, the people who are actually doing the work, it's amazingly the gems of information that you'll get from them.

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. It turns out that it had nothing to do with me, but I joked that it was really, you you've got to really pay attention to the subtleties and sometimes people may shift with their bodies.

You know, right now with everybody being in COVID quarantine, doing things over video conferences now is you lose that sense of communication and it's really a challenge for sure. It's like, how do you maintain that and really get a sense of how people are feeling or do they shift in their chair? Are they rolling their eyes? Are they crossing their arms like this?

You know, that's always a telltale sign, but there's not to jazz what's going on.

So I actually have re titled this whole slide and I really call it The Art of Shutting Up because 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 are telling them like, oh, you know what? 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, your response really had nothing to do with what I just said to you. So you definitely wanna convey the fact that you are truly listening or something, not just waiting for your turn to chime in.

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 and 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, there were some units over here and they have to run coolant hot water onto the ground. Well, 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 the pipe, no problem.

And the guys, the field guys were like, don't fit and here are all the reasons why it's not gonna fit. And that really is, you know, 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, a tenant run conduit, 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 the 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 now.

You do have to know how to talk, communication is key, but what's as important to knowing how to talk, knowing how to get people to talk to you. Being able to extract information out of 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, you're just going to sit there and answer with one word answers.

Business users may get the same way. They may have, you know, they may really be questioning your motives of like, why are you doing this? Again, go back to next, it's like, are you automating me out of a job or why are you changing this? It's, we've always done it this way. It works great this way.

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

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 the end in mind.

I always ask, okay, what are we trying to achieve here? What are our objectives? What's important to you? Take it down to a micro scenario. 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 or I build the right workflow so the data will get in front of you. Start with the end of mind and then work backwards from there. It's amazing when you know what you want 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, objective that the user is looking for.

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, ninety nine times out of a hundred with Salesforce, the answer to that question is, yeah, we can do that. 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, but we know that yes, an integration is needed or some automated will be 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 working on technology. It's more about everything leading up to that. It's the people and process.

So if we remember back to this person, it's like, is she a roadblock? Is she an ops? Or is she somebody that's gonna help you? You know, and it's really now, okay, it's like, not all architects are like, not everybody's jovial like, like, work.

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.

So it's up to us as business users to be able to provide the resources to our users to say, you know what, I'm not sure about that, but let me go find out. Let me go find the answers for you.

Alright. So let's talk about the typical project.

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 ten percent of our time with actual fingers on keyboard touching the technology.

The other twenty percent is working on process, how to do things, changing how to do things, 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. He wanted nothing to do with it. He had gone through it ten years ago. He 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 notes differently, how to triage my patients differently. I'm not doing that.

So he literally retired because of a technology project. 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 has really becomes about people.

It's not about technology. We really are human behaviorists 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? How do I help this group or this company through this change?

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

So what do we actually do?

Now I hear a lot of verbs here about what architects actually do. Here's what we do. You could say like, well, you write code, you 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, you just don't get clear information from your customers. It's like you gotta yank it out of them. You've got to empathize with them.

You're gonna 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 know, to an outsider, those changes felt very simple and very small and the reality 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. We have to evangelize the solutions that we're creating. We have to paint that picture. 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 with your design.

We have to enable them to be successful. So it's not just simply by 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 happened here. Let me tell you why we've done what we've done. It's not simply about here we did this, use this. We have to evaluate, we have to really make decisions, we have to evaluate multiple different variables and 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 a right solution, it's about picking a solution and being able to stand behind it. I have, 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, your time, budget, skill sets, team size, all of those things that say, okay, this is the best solution for this scenario.

Sometimes we have to coerce people. Sometimes they say, listen, this is going 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 pertinent to the conversation, but you kind of have to force them a certain way.

Sometimes you gotta 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.

You would have to console them sometimes and say, Hey, you know, it's gonna be okay. You know, there's a lot of good reasons why we're doing this and you know, me and my team are gonna 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.

So you've got to play that facilitator, you know, you've got to play ringmaster. You've to stand in front of 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 certainly is an art for sure.

There are certainly trailheads out there as well that talk about a lot of these soft skills.

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 go about it. It's almost like getting your dissertation or your PhD for Salesforce is you've got to put something out there and then you've got to defend it, You know, because not everybody's gonna 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, because that's really what we are. We're human behaviorists. We are really talking about dealing with people and 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, you know, are you an architect? Would now consider yourself to be an architect? Because architects, what they do is they develop ideas, they design projects, they make things, they design things. Like see, everybody is 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.

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.

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 me throughout my entire life. I would highly recommend that one trailhead right there. You can look for it specifically by that name, it'll pop right up. And of course anything around storytelling and 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, you're really emphasizing, you know, that you don't have to be a developer. 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 a problem, you have to think twice. I think you have to think twice in the Salesforce platform before you decide you have to write code.

You absolutely do. Mean, because you're finding 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 staff to support it? Do you have the ability to test every single scenario? Do you have the time to write that?

You know, you know, who's going to take care of this once you're gone? I mean, 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 easy to simply default to that and say, yeah, I'll just code this, get out of my way and code it. It may not be the best solution for your customers though.

Yeah, I agree. Well, thank you very much.

I think it was a great presentation and I think that Thank you.

One of my questions is gonna 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 and Trailhead and trying to make a administrator the self that if you wanna learn those skills, can in this spot.

Absolutely, and anybody can do it. It doesn't matter what point of their career they're in. These are skills that are applicable to everybody, whether you're just starting out or you've been at it for thirty years.

Great, thanks again, Steve. Great presentation.

Thank you. Bye bye.

‍