In today’s episode we’re joined by Kristian Jørgensen, Salesforce Solution Architect and the author of the Salesforce End-to-End Implementation Handbook. We discuss Kristian’s early career and the various roles he held before finding his way into the IT industry and building a Salesforce career. He shares his first exposure to Salesforce, why he decided to move into a Salesforce role full-time, and how he progressed from Functional Consultant to Solution Architect.
Kristian explains what he noticed about Salesforce projects that led him to write the End-to-End Implementation Handbook, what some of the key upfront decisions are that can impact a Salesforce project success, how a company goes about estimating ROI on a Salesforce project, and what factors influence the decision around project delivery models. Finally, Kristian explains what a Salesforce Centre of Excellence is, how BAU should really be viewed, and shares some tips for companies transitioning out of project mode.
You can find Kristian on LinkedIn here:
https://www.linkedin.com/in/kristianjorgensen/
Purchase a copy of the Salesforce End-to-End Implementation Handbook here:
https://www.amazon.com/Salesforce-End-End-Implementation-Handbook-ebook/dp/B0BHT8YMYR/
We hope you enjoy the episode!
Ben:
Kristian, thank you so much for joining me.
Kristian Margaryan Jørgensen:
Thank you so much for having me.
Ben:
My pleasure. So I’ve seen a lot of things about your book recently, lots of people are reading it, so I’m really excited to unpick some of that and tell our audience a bit more about what they can find in the book if they pick it up, which I’m sure they will. But before we get there, let’s dig a bit deeper around your career and find out how you ended up in the Salesforce ecosystem and writing a book. But tell me a bit about your early career and the types of roles you held before Salesforce?
Kristian Margaryan Jørgensen:
Yeah, absolutely. Because Salesforce, it’s not something I did straight out of university, actually, I started out in sales. I worked at Carlsberg, a Danish brewery in an Inside Sales role. And later at Innocent Drinks, selling smoothies, first at store level, and later as a Key Account Manager. managing relationships when negotiating annual joint business plans with the headquarters of convenience chains and gas stations like 7-Eleven and this was well back in 2006, 2010 something around that era if you can put it that way. A bit later. I gradually found out, I became aware that I really enjoyed the analytical side of business and so held various roles such as a Sales Analyst for a watch company and a Channel Manager role at a roadside assistance company, supporting sales and customer service directors with insights and recommendations about their operations.
Ben:
So how were you gathering those insights? What were you using to put that all together?
Kristian Margaryan Jørgensen:
Yeah, absolutely. So whatever data I could get my hands on really, right, related to the business. So it could be CRMs or if there wasn’t a CRM, then whatever spreadsheet that were lying around capturing activity, typically finance or ERP system also. And then it would be about blending it all together. I taught myself Power BI to some extent and built models in that to report both to the business and the users or employees so they could see how their performance was, but also management reporting for budgeting reasons and seeing how we’re tracking there.
Kristian Margaryan Jørgensen:
It was great fun.
Ben:
Yeah, we’re doing a big project at the moment around salary surveys. And I think to be in that world of data, you just have to have a completely different mind to the one that I have, because it’s just all numbers to me and trying to make sense of it is challenging. But when you can actually see trends and spot them and obviously use a platform to help you do that, like it’s so powerful.
Kristian Margaryan Jørgensen:
Absolutely. Yeah, yeah.
Ben:
So when you were in sales, when you go back to the early days working for Carlsberg and Innocent, were you using CRM? So were you aware of like Salesforce at that time?
Kristian Margaryan Jørgensen:
Not at that time. At Innocent there was a system, I remember it was called Demantra based on Oracle, but it was mostly for sales forecasting, not so much capturing the activity or the CRM aspects. I think we just used spreadsheets to be honest. Then later it was acquired by Coca-Cola and I’m sure they’ve matured in the operations since. But it was a startup and I was part of the launch into the Danish market. So yeah, it was a good startup feel also seeing how that grew.
Ben:
Did you ever in the earlier days see yourself ever working in IT? Like did you anticipate that at all?
Kristian Margaryan Jørgensen:
No, great question. I think about it sometimes these days because I really love my job and the role as a Solution Architect and what I’m doing. And I really wish I knew it existed when starting out because then I would have pursued it much earlier, right? But it never occurred to me in the early days. It was all about becoming a more senior salesperson and doing more types of different aspects of sales. And yeah, then gradually transitioning to the more analytical side, which is in my nature, but I just didn’t realize it early on.
Ben:
It’s interesting you say that if you wish you’d have found it earlier, because I think sometimes like, yeah, it’s easy to say, wouldn’t it be great if I could have just gone into Salesforce, but then you lose some of the appreciation for the, like a lot of the skills that you probably picked up in a sales role that, that actually benefit you today when you’re negotiating with a client or even just putting yourself in the salesperson’s shoes to understand the impact of the solution you’re designing.
Kristian Margaryan Jørgensen:
Absolutely. So I don’t think I would be the Solution Architect that I am today if I hadn’t had those roles. So I guess it’s a, I don’t know, you can’t have it both ways, right?
Ben:
That’s right. So how did Salesforce come to your attention?
Kristian Margaryan Jørgensen:
Yeah, so it was when I was at that company as a Channel Manager at the Roadside Assistance company, where I first came into contact with Salesforce. The company was doing a major program to both replace the backend billing platform, which was an old legacy billing platform, and also the on-prem CRM. with Salesforce. So it was a company that I first got in touch with Salesforce and an implementation partner.
Ben:
And what was your role through that programme?
Kristian Margaryan Jørgensen:
I was a Business SME representative. So explaining to the project how we worked in sales and in customer service, what the processes were. So that was part of the project as it went on. And then later I was part of a training, the staff, both sales and customer service. I think we were about 130 or 50 business users. And then was a super user, something like that to support. And yeah, obviously doing a bunch of dashboards and reports in Salesforce and also extracting or connecting with Power BI to do the more consolidated management reporting.
Ben:
So did that light a fire within? Like did you get that exposure, get that like a look under the bonnet at Salesforce and think, right, this is what I’ve now found what I want to do?
Kristian Margaryan Jørgensen:
Yeah. So funnily enough, it wasn’t really when I got the feel for, “oh, I want to do Salesforce projects”, but I definitely got a, you know, an appetite for Salesforce, seeing how smooth and slick it was mostly from the reporting and the insights you could do and how quickly you could do that compared to the old on-prem CRM. So it wasn’t really until I went to work at another company before getting into that company I worked as a Financial Controller. So having done sales, analytics and finance, that role was more about management reporting and again supporting sales with insights. And we also had Salesforce there. So I looked after that from a Nordic perspective. And then after that, I joined Capgemini for about four years. So that was when I made the switch to the consulting side.
Ben:
And that was into a Functional consulting role initially?
Kristian Margaryan Jørgensen:
Yeah, yeah, exactly. And then quite quickly I found, “yes, I do enjoy looking at, let’s say. one smaller aspect or a user story, but I really enjoy looking at the big picture, how does it fit into the oral process? What’s a company ultimately trying to achieve and how does it connect to other systems and what’s a downstream process after this little bit that I’m looking at?” So I quite early on articulated to my manager who was supportive that was what I wanted to pursue, that type of role. And he said there is something for a Solution Architect and yeah then I was really just enabled and empowered to pursue that and got a great mentor.
Ben:
I was going to say what helped you get there quickly, but the mentor you said was key, right? So what kind of things did they do that helped you get? Because you progressed quite quickly into a Solution Architect role. If you look at your start to like from a Functional Consultant into that, and a lot of people want to do the same, you know, want to make that step up, but it can be a challenging step up, especially also if you’ve not got that broad IT background, I guess.
Kristian Margaryan Jørgensen:
Yeah, no, absolutely. So I think the first thing is to voice it. Because if you don’t ask for it, if you don’t let people know that you’re interested in it, then you won’t get the support that you need, right? And I think it’s important to not think about either I’m a Functional Consultant or I’m a Solution Architect. There is a transition, right? And you are even as a Functional Consultant, you’re still a Solution Architect, but just within a smaller domain or part of the project or engagement that you’re working on. So don’t put yourself down if you don’t have the title or the badge. And then, yeah, I think a mentor, so it could be a senior person at the company working at, or of course use the, the Ohana, the Salesforce ecosystem, which is full of people who are there and want to, to help. And then I think you really need to do the work in terms of studying and of course applying what you’re studying in your day to day work, but you also really do need to study. And I think that was. the part that I really worked on hard because I don’t have that IT background. So I really wanted to get the different architect domain knowledge. So I did a bunch of that. Also discussed a lot with my mentor, the different parts, because I wanted to have that as sort of my IT background, and then I could focus more on the functional side, which I excelled at.
Ben:
Yeah, nice. And obviously, we’ll touch on the book because, like, it’s the Salesforce implementation handbook, right? So what did you see on projects that made you think, right, we need to kind of document this and point people in the right direction?
Kristian Margaryan Jørgensen:
So I think needless to say all projects are different. Yet I still think there are similarities and things you see over and over again in terms of how they’re set up. It’s you can compare it to like design patterns for Salesforce solutions. I know you had the last man on recently who wrote the anti patterns book. And so it’s really a book for what works well and what doesn’t. And I guess what prompted me was many projects I’ve been part of and seem to be set up in seemingly random ways. And I wanted to capture this. what I thought was a framework for how projects could be set up, minding that there are differences and you could have different delivery methodologies and there’s not always a right way for everything, right?
Ben:
When you say they’re set up randomly, like do you find that typically that’s because, like are you talking in an implementation consultant’s sense or are you talking like on a customer site who might never have done Salesforce before, so they’re setting the project up in a way that, you know, they’ve delivered an SAP project before or anything else within their IT stats?
Kristian Margaryan Jørgensen:
Yeah, so all of the above really, right? So it may be that, let’s say from the implementation partner side, if they are, let’s say, in charge of proposing and leading how to set up the project and how to deliver it, then it may be that the project manager from the implementation partner hasn’t done a Salesforce project before, but they’ve done CMS or EOP or custom development, which is radically different from how you could and should go about a Salesforce implementation. Because essentially you already have a SaaS product out of the box that you need to modify and tweak to fit the processes of the company. On the other hand, you have the customer which also may have experience with different types of projects or none, because it really comes down to the people that are allocated to the project from the customer side. So it depends on their experience. Sometimes they may have worked with Salesforce before as users, or some of them may have been part of implementing it and other companies, but sometimes they have none of those, right? And some of them have no experience with agile delivery methodologies. And so you have this, not clash, but you need this group of people to come together. And it’s just, as you can imagine, it turns out many different ways, right?
Ben:
So if you’ve said there’s a framework best practice, I guess like in an ideal world of everything enables a company to set up a project in a certain way. What does that look like? Like what and I guess there’s still no guarantee of success with anything right because things change along the way but like if you were to put your hat on the fact that if we do it this way, there’ll be success. What does that look like?
Kristian Margaryan Jørgensen:
Sure. And I’m really working with my imposter syndrome here, calling it best practice and a framework, but let’s go for it, right? So I’d say before starting a project, it’s crucial to have an organization, create a clear vision for the Salesforce project, right? It needs to be based and tied to the overall company strategy that is leading the organization to implement Salesforce. Because if you don’t have that, then it’s just an island and there’s no clear why, essentially, right? So if you know this, then aligning your organization internally before the project, it really makes everything so much easier as you progress. So vision, the why. Then secondly, it’s about defining the nature of what business capabilities you want your Salesforce implementation to support. So that’s the what. And then it’s about the how, how to deliver right, both development wise, delivery methodologies to consider. and then critically the change management, communication and rollout strategy. So you don’t need to know all of this in detail before you start up your project, but you need to consider it and have an opinion about it as an organization, because you will be talking about your implementation partner if you go with an implementation partner. And if you are clueless as an organization, then implementation partners want what’s best, but they should be having qualified conversations with you as an organization about where to go and what direction, right?
Ben:
Who is responsible for change management? Then like if there’s a partner and a customer, where does that fall?
Kristian Margaryan Jørgensen:
Good question. So I’d say ultimately the organization, the company is accountable for it because at the end of the day, they’re investing in Salesforce in the implementation. So if it doesn’t work out, then it’s on them, right? That being said, it can and often is something where the the intricacies, the consulting, the advising, and also some of the, let’s say, the communication bits and bobs and the different training programs and all of the gears of the actual change management is sometimes something that is used for implementation partners to support with.
Ben:
Yeah, it’s interesting because I think if you look at like the, like, I’m not talking big end of town, like the Capgemini, Accenture, Deloitte, because they will have change practices, right? But if you look at some of the smaller partners, when they’re growing, often that they change management isn’t something they have within their team. You know, they have, they might have a couple of founders and then a delivery team, a couple of salespeople, but change management doesn’t necessarily come in until you get into that larger end of town, but then. A lot of smaller projects probably think, you know, change management isn’t, we just need the system built and then we’ll start using it, but that’s probably where a lot of them are going wrong.
Kristian Margaryan Jørgensen:
That’s dangerous, right? Yeah, and I would say, if you look at some of the boutique Salesforce consultancies, not doing a promotion here, but wait where I am, which is part of IBM, has a dedicated change management practice. And I think you’re seeing that more and more that if it’s not part of the company, the implementation partners, then they will work and have partnerships with dedicated change management agencies which also exist in the ecosystem.
Ben:
Well, one thing I’ve always wondered, especially coming, obviously, in the sales space myself, you’re coming from the sales background, like, obviously, every company are conscious of ROI and understanding the impact that something is going to have, any investment is going to have on the business. How can a company track that upfront? Like, when a business is putting a business case together, someone’s responsible for that. Obviously, the CFO, the CEO, they want answers around,
Kristian Margaryan Jørgensen:
Yeah.
Ben:
We understand why we’re doing this, but like really why? Like what’s the outcome after go live? How does the company track that?
Kristian Margaryan Jørgensen:
No great question. So I think at its core, as you say, it’s about being able to answer two questions for those two key stakeholders, right? What investment are you looking for? And what will we gain as a company or organization for that investment? So to answer those questions, you need to estimate both upfront. So the business impact either what uplift in revenue or what increase in efficiency you can expect the Salesforce implementation to deliver. And then there’s a cost of the implementation. So that’s a total cost associated with both implementing, change management, rollout and license costs. And here you need to make sure to deduct any legacy system costs that you are retiring and won’t be needing, right? So you will likely have some savings. And after you do all that, then it’s just the calculations, right? The payback time, how many months until the business impact outweighs the cost of implementation, and then you have the ROI, return on investment, over some investment horizon, typically three or five years.
Ben:
And you mentioned when you were with the roadside assistance company you were involved in a project, you were on the business side as an SME Do you see that being the best blend of rather than the company just outsourcing the project to a partner and saying “right you deliver it on X day” and we’ll take it over from there, does the business have to have reps on the project and if so, how does like what’s the best way to structure that?
Kristian Margaryan Jørgensen:
Yeah. So yeah, at that project there was an implementation partner and I was a representative from the business and I’d say it’s absolutely key. I wasn’t the only one. There were others, but you can’t outsource it 100% because then you really risk if you’re not involving users or people from the business, you, there’s a major risk, right? That you’re not building what’s actually needed. If you don’t show what you’re building regularly, there’s a risk that you’re building the wrong thing, or it’s a beautiful solution, but it’s not really what was needed. And so, yeah, you absolutely need to have people from the business, so to say, some future target users.
Ben:
And is that like you free up their time completely? So like when you were on that project, were you 100% dedicated to the project or were you like splitting your time between your normal deliverables?
Kristian Margaryan Jørgensen:
Yeah. Jeez, this was almost 10 years ago, right? I think it was like a 30 or 40% allocation, something like that, for let’s say the preparation phase, the discovery or whatever it was called for that project, right? So not throughout the year, year and a half, or how long the development went on, but something like that. And I think it’s a good point, right? Because when we talk delivery methodologies, When you have the waterfall bit, then you have some people be part of the discovery or definition of the requirements, that’s all done in one phase, right? That would require a huge allocation of people from the business and IT to be part of them designing it. And then you may go into development mode where you don’t have any interaction if we’re talking pure waterfall here, right? Any interaction with the business or future end users. But then that also means they don’t have to be part of the and freeze up time, which may look like it’s an attractive option, just from a pure resource perspective, but you can imagine the risk that then entails. Whereas if we’re more on the pure agile side, then you need someone from the business, typically called the product owner, to be fully allocated or have a very high allocation because they will both be looking at the roadmap, the future, but then also doing user story refinement and validating when stories are developed and demoing in to the wider stakeholders. And that takes a lot of resources, right? And so sometimes it’s something in the middle that’s more attractive, like a hybrid model.
Ben:
When is one option better than the other? Because, we hear of ‘wagile’ and all these things. To me, like, I used to be an SAP recruiter, and this was going back like 10 years, but everything then seemed to be waterfall. And then I’d hear about these projects that were like five years long. Like, there was one in the UK at a big supermarket and it was like a five-year program of work that was like a billion dollars, and it was just a massive failure. So to me, like the way that Salesforce, like quick delivery, like showcasing, show, like, because things can be built quickly, that seems to make a lot more sense to me, Agile, but like, are there times where actually waterfall does suit Salesforce?
Kristian Margaryan Jørgensen:
Yeah, sounds painful. Absolutely. And I think there are some general guidelines for when what delivery methodology works best. So maybe we can just quickly talk about those and then get into some examples or if that’s all right. So I think generally waterfall is preferred if the scope is clearly defined, known, there’s a strict budget and timeline to be met. Typically, this is the case for regulatory requirements, if there is some law that is being implemented and you need to have that in place in your systems in some shape or form. Also integrations are typically best delivered in a waterfall manner, as you need two parties to be available at the same time to design, develop and test. Agile, many variations I’ve seen work great is when there is an experienced and empowered product owner, right? It is really a senior role because in the true sense of the meeting, they have the authority to make decisions around a participation and product roadmap and features, obviously based on great interactions with the wider business stakeholders, but they will ultimately be the ones deciding. So clearly defined roles and responsibilities and ways of working, clear development process. So those are the things that work great for Agile. And then coming back to when to choose what. So sometimes you will have, you both want parts of one and the other, and then you have to find what is a good hybrid model that works best for your organization. And I’m a big fan of having regular check-ins and involvement with the business. So you make sure what you’re developing is actually in line with that. But sometimes you have to accept that you may not be able to release something until you have enough capabilities so that you can effectively retire a system that you’re replacing or there may be other considerations into play. Because sometimes an organization isn’t only doing Salesforce, they may have SAP for HANA migration or something else right so you can’t always just decide even though this is what you would want to do right
Ben:
Can you sometimes walk into a customer and just by the way that they are, tell how a certain methodology isn’t going to work for them, even before you’ve gone deep into a project, maybe the business maturity or maybe they’re just too prehistoric with the way that they do things and you think, right, Agile isn’t going to work in this environment.
Kristian Margaryan Jørgensen:
That’s a good question. So I think it’s important to remember that maturity is also something that changes throughout a Salesforce implementation project. So even though they may not appear to be, let’s say digitally mature or methodology mature, if they have the mindset and the willingness and the let’s say self-reflection that their organization isn’t, but they want to get there, then you can go together and have conversations about, okay, let’s do it in the more agile way or trend towards it but it needs to be an aligned and agreed upon approach upfront. It’s something that we will encourage but it’s not always something that is appreciated or wanted. But this mentality of moving the maturity of an organization as you do the Salesforce project is really key because that is something that they will benefit from also in other aspects of their business.
Ben:
Yeah, makes sense. So obviously we’ve talked projects and now if we touch on BAU and that transition from a project to BAU, what are some of the tips you have or things you’ve seen work well for companies that are about to ultimately kind of take ownership of a platform that’s been built by a partner?
Kristian Margaryan Jørgensen:
Yeah. So I think the end of a project, the transition to business as usual is usually underestimated by organizations because it really should be considered a transition to continuous improvement after an initial release or rollout. Because users will typically have a ton of feedback or changes they would like to have made or new features. When they see the system, they will be inspired to do other things. Management may have new opportunities they’d like to pursue or capabilities they want to have Salesforce support. Could be extending an implementation with e-commerce or field service capabilities or many of the other things that the platform can do right. And all of this means that you need to be able to adapt to these changing circumstances and priorities even after the initial release. And for that, you need both technical and a business setup to handle that. And that’s where DevOps comes in, right? Both in the technical CICD sense, but also the mentality of still having people allocated and or working with an implementation partner to, to facilitate that set up, right. And then there’s data, right? Cause that’s what you get out of the platform, out of users using it, interacting with customers to be able to really reap the benefits of all that data and use it for other things, automations or AI as everybody’s talking about. You really need to be on top of that and continuously manage and govern it. So I think instead of thinking of its transition to PAE, yes, there is something around user management, provisioning and support in that sense, but there’s a bigger sense of, you know, if you invest in Salesforce, you should continue to do so because you will see gains from it.
Ben:
Yeah that makes a lot of sense and I think historically, you know, we speak to people and they, you know, when they’re considering a role, they’re like, I don’t want to just be bogged down in BAU and that’s the way that you explain it is actually how they should think about it as well, right? It doesn’t mean that there’s not enhancements and continual investment and improvement in the platform. It’s on that person also to get the most out of Salesforce, not just the business of hiring someone into a support role like that person can make it what they want to.
Kristian Margaryan Jørgensen:
And if I may just say, if they are able to articulate the value of a new feature or change request in a business sense, like we talked about when we talked the business case, when seeking investment, that also applies to if you’re talking about a user story or a feature or something like that, right? If you are able to articulate it, it’s more likely that you will get the business or management to sign off on it. That is, if you don’t have a dedicated, empowered product owner who is able to make those decisions themselves, right?
Ben:
Yeah, makes sense. I know in the US and Europe, the Salesforce Centre of Excellence has been around for a while. We’re seeing a few bigger companies here now starting to implement them and I think I’ve always seen it as something that’s like a big enterprise customer might have a Centre of Excellence where they have a huge Salesforce team. What actually makes up a Centre of Excellence and who could have a Centre of Excellence? What makes it different from just a Salesforce team?
Kristian Margaryan Jørgensen:
Yeah, yeah, good question. So I think it’s also one of the, let’s say… watered down terms or it’s used in many different ways. So it can come in many different shapes, but essentially a Centre of Excellence is more of a management philosophy rather than a formal management structure. So it may seem a bit fluffy like that, but the goal of the COE should be to empower and enable teams to deliver value in the most efficient manner, so it could be with reusable assets, having development guidelines, different ways for how do we integrate if we have this pattern, tooling, change management processes, all of these things should be consolidated so it can be reused and applied. So many different aspects as you can tell, both business and technical, and typically you have a number of forums that are related to the COE like a design authority to do technical design review for stuff before it goes into development. And then a data governance board, which typically needs to span across systems as things are integrated. So more of a philosophy, and it may be that an organization has ‘this is our COE’, where the Salesforce team sits within it, but you can also have a more loose structure where people are partially allocated to the COE for the different forums they’re part of.
Ben:
So when you say about continuing innovation and ongoing enhancements of the platform, like a COE wouldn’t just be across that, it would be across projects, like if it’s got that design authority within it, anything that touches Salesforce would run through the COE?
Kristian Margaryan Jørgensen:
Yeah, or at least through the design authority. Absolutely. Yeah. And you know, there is a threshold for what type of stuff needs to go through the design authority. And that’s typically decided when setting up the design authority framework at a company. Because it may not be that each little tweak to a report or some pure UI changes. Maybe that doesn’t need to go through, but any complex automations or code or integrations or security changes, stuff like that typically should go through.
Ben:
Yeah, I guess so even a company without a big team still need to be thinking about these decisions, whether or not they’re going to formalize a COE or like these are all decisions that a hiring manager, a team leader of Salesforce people should be encouraging these kind of practices and the ways of thinking and the ways of working should all be, whether or not it’s in a structured environment or not. That’s kind of the end goal for everyone, right?
Kristian Margaryan Jørgensen:
Yeah, absolutely. Also, I mean, it’s like one thing is those forums, the design authority and data governance board. But with all the reusable assets, it’s comparable to having a knowledge base in Salesforce, right? It will make things so much easier if you don’t have to invent things every time for a new project or a new rollout or a new whatever it may be. Right. So it will make your life easier in the end.
Ben:
Sure. So finally on the book, is it for enterprise customers and could smaller businesses get value from the book, implementation consultants as well, what’s your target market?
Kristian Margaryan Jørgensen:
Yeah. So it is for, let’s say companies that are about to, or are already implementing Salesforce, regardless of what states they’re in. And it is for any type of role within a company that has something to do with Salesforce that is curious to see ‘where does my role fit within the larger Salesforce program’, right? So it could be people in roles as Product Owners, Architects, Project Managers, or Developers, QA specialists, you name it, right? Change Managers. It is probably more for medium or larger enterprises, not so much for one person companies. Maybe they will also get something out of it, but typically Salesforce doesn’t play that major role within the company.
Ben:
I guess finally, if anyone’s listened and wants to pick your brains, ask some questions, where’s the best place to find you?
Kristian Margaryan Jørgensen:
Yeah, LinkedIn is where I’m mostly present.
Ben:
Awesome. Well, thank you so much. I’m excited to get this out and get some feedback from some of our listeners around the book as well. So, yeah, and hopefully some people will take you up on that offer to answer some questions as well.
Kristian Margaryan Jørgensen:
Absolutely.
Ben:
Thank you.
Kristian Margaryan Jørgensen:
No, thank you so much.
Ben:
Awesome, that was great.
You can visit our Salesforce jobs page for up to date opportunities. If you’d like to become involved in the Talent Hub Talk podcast as a guest, we’d love to hear from you.