Season 2, Episode 16 podcast interview with Kevin White, Senior Program Architect at #Salesforce is now out!
This was SUCH a treat! We talked about so many topics, including
– what it’s like to work for ‘The Mothership’
– career advice and raising profile whether in an end-customer environment or with a consulting partner
– how to find your niche on the broad Salesforce suite of products
– interview questions to ask the interviewers
– the Architect mindset (Am recalling Melissa Shepard‘s session at CzechDreamin and London’s Calling Ltd!)
– mistakes partners frequently make
– V2MOM and why the first V is so important!
Wow – this is jam packed with so much information.
You. Do. Not. Want. To. Miss. This.
Listen on Spotify
#OnThePeiroll
Transcript
Pei Mun Lim 0:04
Hello, and welcome to another episode of OnThePeiroll, my podcast where I talk to great guests about topics such as leadership, project delivery, Salesforce consulting, and anything and everything in between. In this particular episode, I get to speak to Kevin White, who’s a Solutions Architect at Salesforce. And we talk about what it means to be an architect, the definition of one, what are the key skills and attributes. An architect needs to have, for example, big picture thinking was a very key trait, the ability to go macro and zoom out and be able to see how things fit with each other. And I found this really interesting, because I also have an architect brain, I think, one time of my life, I may have stepped into the past of a niche and a specialist instead of a generalist like a project manager. But it doesn’t mean that just because I’m a pm, I can’t enjoy things like this as well. So I really hope that you enjoyed this conversation as much as I did, making it.
Hello, good morning, Kevin, thank you so much for coming on my podcast, it’s called OnThePeiroll. How are you feeling today?
Kevin 1:34
I’m feeling very well. And thank you very much for having me.
Pei Mun Lim 1:37
I’m looking forward to this conversation very much. Now. We’ve worked together for a bit, and we’ve remained friends after our stint at Capgemini. But I’m actually we were doing one project together. And I remember you were telling me an anecdote from a story from when you were working before you were talking about some crisis. I’m just trying to remember now about having to cut equipment, and you couldn’t, I don’t know whether you’ll get to that story. But I’m trying to remember that. What I wanted to get to was, it’d be great for you to tell me the story of your journey from where you were, to where you are today. And if you can also maybe share some of the learnings about how you made the decision to move, let’s say from role to role, and led you to where you are as a senior architect at Salesforce.
Kevin 2:37
Sure. Okay. Should we go right back to the beginning?
Pei Mun Lim 2:40
How does that stack up to you to you?
Kevin 2:42
Lovely, let’s do that. So I suppose going back to my education, I didn’t actually want to work in it necessarily. So my dad was in it. And that seemed to me to be from what I could see a bit of a boring job without much challenge. And I didn’t seem to be the thing for me. So when I was at school growing up, I wanted to be a sports journalist. And that was always the goal for me. I did do it at a level. So in the UK, that’s when you’re 16 to 18. So I did it because it was something that I was good at. So I thought it was sensible to do that. But I also did English at the same time moving into the into the journalism sphere. And then when I made a choice about university, it was to go and do a degree in English in media studies. So absolutely nothing to do with it at all. And at that stage, as far as I was aware, that was going to be my career path. But as often happens, the choices you make when you are 18, or 19 don’t necessarily end up being choices that you’ve that you look back on and say they were the right things. So I did my degree, I finished my degree. After I’d done that I went traveling for a year. And then it was a case of finding a job. And at the time, the things that mattered to me for a job were not necessarily what I have a long and fruitful career. It was more about where I could live and how comfortably I could live. So I got a job in London. It wasn’t anything to do with journalism. It wasn’t anything to do with it. In fact, it was much more a administrative type of job. But But I did that job. And to answer your question around roles and how things happen, and this was how I ended up getting into it. So I took this job, and I was what I was 20 to 23. And within a year it turned out the agency I was working for it was it was a publicly funded organization was going to was going to stop being funded. So it was going to close down. And the organization at the time made a decision where they said well, we’re going to be staying in business for the next year, year and a half and what we do to help our employees is all of the budget that we were going to spend on recruitment, etc, we’re going to put into training. So why don’t you come to us? And why don’t you give us a proposal as to what training you’d like to go on, in order to be able to get your next job, which I think was quite a nice thing to do. So at the time, I didn’t know quite what I was going to do. So I ended up doing a project management qualification. And at that stage, it was printed, too. So it’s kind of a bit old hat now in terms of what we do in it, and in modern projects, but that was kind of the industry standard. So I got that qualification. And then, with that qualification, I was able to go and get a job into a startup company who were doing things in it. So they were like a support services type organization. But again, to me at the time, I’m not sure how much thought I gave it beyond, they can offer me a job. And it makes use of this qualification I’ve just gained. And I still don’t think at that stage, it seemed to be the thing for me, it just happened to be where I go next. But within that company, that was where I got exposed to a lot of things. So I got exposed to IP telephony, I got exposed to building customer development solutions. And then finally, I got exposed to CRM. So that was where I started working with Microsoft Dynamics as it was at the time. And we did quite a lot of work within the financial services sector. So that was something that was quite interesting to me. And I spent five, challenging, but very fruitful years with that company. Because we grew, we were about 20 When I joined, and we were 120 when I left. But the reason I left was because that company got sold. So that company got sold. And at that stage, I was looking at it saying well, what do I want to do next? I knew I wanted to stay within financial services, because I built up a knowledge set about financial services. And I felt that was especially isn’t I could offer. And so I had to look for jobs within financial services. And at that stage, a job came up to work within a company called mg investments who were an asset manager. And they were just starting to implement Salesforce. Now at the time, I didn’t know anything about Salesforce beyond what it was in the fact that it was a CRM system. But I got introduced to mg. And the first thing they did was they sent me on an admin tour one course in my first week, so I didn’t even meet anyone in the business straight on the admin to at one. And that was really how I got into Salesforce. So I spent three and a half years, I think it was at MMG, getting really hands on with the platform. So I think when you work for an end user, it is a lot more hands on, and you tend to do a lot more different roles. So I was doing a hell of a lot of different things, including getting hands on with the platform. And at the end of my time there, I was then thinking, well, I quite like Salesforce, I like it as a product. I like the culture, I like the community. So I’d quite like to continue with this. And I have to say that was the first time probably in my career that I really thought I’ve got a track here. And I’ve got a track here that I want to follow. So at that stage, it was what do I do next, I wanted to get some more experience outside of financial services, but also in different side projects. And that was when the Capgemini job happened. So I joined Capgemini work with great people like you and many of us that we know that we mutually know. And I spent five years there doing a variety of different architecture roles, eventually leading the architecture team within the UK. And after that, that led me to Salesforce, I always wanted to go and work for the mothership, too. So yeah, that was how I ended up working at Salesforce and the weird, winding journey that got me that.
Pei Mun Lim 8:56
Oh, that’s, that’s really, really interesting, because that touches on probably one of the questions that you hear a lot, which is how do I get a job at Salesforce? Is it for everyone? What? So you’ve been there? close to two years now, what are your thoughts? And how are you? How do you feel about, you know, working in the mothership.
Kevin 9:22
So it’s been great so far, I think the things that you hope are true when you sort of see it from the outside, like the culture and the working environment and the challenge. It’s all there. So that’s good. And I think it’s a very rewarding place to work, but also a place that’s changing so quickly. I mean, Salesforce is now I think, 74,000 people worldwide, and 20,000 of those people join since the start of the pandemic. So the size of the growth and the speed of the growth means that there’s lots of interesting opportunities. And I think in terms of working for Salesforce Here’s the other thing that I was surprised that I don’t know why we’re surprised at this. But a lot of people who work for Salesforce don’t necessarily come from a Salesforce background. So a lot of them might have been working for a competitor in another software business or working for a partner doing something different. So maybe they’re a partner of Salesforce, but they weren’t working in Salesforce. And I think in a way, that’s, that’s good, because it brings a diversity of thought, a diversity of background into the organization, and it helps the organization to be more productive, and to come up with creative ideas. In terms of your question about, is it for everyone? I think as with any job, does what’s on offer align with your values? does it align with what you want from your career? The constant I can say is, it’s a great place to work. And I there is a genuine culture of respect, and the need for you as an individual to feel like you’re fulfilled, which is always a good starting point for any company. But I suppose if it’s the right fit for you, I think again, it comes down to does the job role? And does the manager and does the goals of your manager align to what it is you want to do? And that, for me is always the key question.
Pei Mun Lim 11:16
Interesting. Now, when you got started with your IT journey, you talked about Microsoft Dynamics, which is also where I came from. And at that time, it felt easy to put your arms around it was marketing, sales and service meeting at its core of CRM. But now when you look at how Salesforce has grown in terms of its acquisitions, in terms of its breadth of suite of products, how can someone from the outside looking in? How can they consider a journey, a career within Salesforce without feeling thoroughly overwhelmed. So for example, if I, I get on trailhead, and I see that marked modules that are to learn everything, I can imagine that for someone new, that cup can feel quite overwhelming. So what would you say to someone who’s just looking at it in considering a career?
Kevin 12:15
So I think first of all, it’s it’s, as you say, it’s understanding what the Salesforce platform actually is. So I think, if you join the ecosystem, 10 years ago, Salesforce was a CRM and in fact, it didn’t even have marketing at that stage. So it was predominantly a sales platform, Service Cloud was was there, but it was still quite new, a marketing didn’t even exist. So at that stage, when you’re looking at a career in Salesforce, it’s a fairly clear path about what it is you need to learn, you need to learn about contacts and accounts and Opportunity Management. And that was kind of fairly clear. And since then, it’s completely different. And as you say, the acquisitions but also some of the some of the native developments on the platform like Field Services, an example. They bring a whole different angle to what is possible with the platform. So first of all, I think it’s about understanding what is the platform, and what are its different parts. And the way I’d recommend you start is that there is a, there is an image which which many people will have seen, it’s all over trailhead, it’s all over a lot of Salesforce sales material, over the 360 customer wheel. And on that wheel, you have a list of products, which are sometimes expressed as capabilities like sales or service or commerce. And you can see all of the different products that Salesforce sell to the market. First of all, I would say learn about what those individual products are just at a high level, make sure you could you’re comfortable with describing what it is they do. And pick an area you’re interested in, pick an area that you feel like you want to learn more about. And make sure it’s something you want to do. So don’t do it just because you have experience of it or because you don’t have experience of it. Look at something that you want to do. And then dive into that. The good news about working within Salesforce is there is so much opportunity from a from a jobs perspective and from a career perspective, that I think it’d be pretty difficult to look at the wheel, pick one of those items and make the wrong choice, you will make a choice that will start you off, you can always move off those products and you can learn more. But it’s very unlikely I think that you make the wrong choice. So look at the wheel, understand how the products work, and then start to dive into one of those products so that you can understand it in deeper detail.
Pei Mun Lim 14:47
Okay, so let’s talk about the consulting world and mainly because that’s where you and I come from, and it offers a breadth of projects and opportunities to do things that you wouldn’t necessarily do So what that also means is that unless the partner specializes in something to financial services, or manufacturing or legal, you’re basically at the whim of whatever project lands, you know, that gets operating opportunity. That’s one close. How then so I do get asked this by lots of people, when I, you know, is if I work in a consulting partner, how do I is different with Capgemini? Because you can specialize, you can say I want, you know, I want to focus on these larger projects, but for the smaller partners, somebody goes in, and then they get lumbered with CPQ projects, and that’s not what they enjoy. How do they find out about what, what else is out there that might align with one of the items on wheels that they might like, without having to join a partner to find out what they do first? Any thoughts or advice about that?
Kevin 16:04
So it’s a difficult one, because the way that personally I’ve felt learning the best is by doing these things. And obviously, if you’re doing these things as part of your day to day work, you spend eight, nine hours a day doing these things, then of course, you will learn it and you will also learn it in practice. So you will learn it because the customer is asking you, How do I build a product? How do I build a cart in CPQ, and you are having to learn these things and give advice to the customer. So doing it in your job, I think is so important, because it means you can get hands on with the product. And it also means you can understand the practicalities of implementing it. So yes, there is Trailhead Yes, there is the theory of how it works. But what actually happens when you speak to a customer who has bad data quality or gray areas about how the product works, or maybe they’ve bought the product, but they don’t quite understand it. And by trying to answer those questions, you will always I feel become the most knowledgeable about a product. So it’s not quite helping answer your question. But I think doing it for your day job is so important to get that level of knowledge that you need. If you’re not doing it in your day job, then you have to decide, what do you want to what do you want to learn about because as you say, the, it’s so wide. So you have to try and stay at least close to what you know. So for example, you’re doing a Service Cloud project. But you really want to learn more about commerce cloud, for example. Well, they’re not actually that close, because commerce carries a different platform. So maybe if you’re doing a Sales Cloud project, and you want to learn about something fairly quickly, think about going into service cloud or field service where it’s on the same Salesforce platform. And again, it comes down to I think, a number of areas. So the great thing about the community is there are lots and lots of blogs, and vlogs and material out there for you to really understand how these products work. So I think the key thing for me as well is look at Trailhead use Trailhead. But don’t rely just on trailhead, I think looking at some of the MVP networks, and the people who contribute regularly on social media. They provide a lot of content, which I think really helps you with the practical elements of it. So they will have a blog out there, where there’s nothing like it on Trailhead that really describes how and why something works in the real world. I think when you’re trying to increase your skill set, don’t just look at Trailhead. Also look at the community because they will help you. But I suppose ultimately, to answer the question about I want to do something different. I think at some stage in your career, you have to make a decision about if I want to do this thing. And my job doesn’t allow me to how can I go and do it? Is there a conversation I can have within my company to say, I really want to do this, but you don’t have any projects. So what can I do? And see if there is perhaps a capability you could take on and you could generate yourself that’s a possibility. Or the other way is unfortunately, you might have to leave the organization. And this is where it comes down to a decision. Is your need to go and do something slightly different on the technology so great that it’s worth moving jobs for? Or is it more an interest area that you could tackle in your spare time or potentially go to some user groups and talk to others about so you understand it more? At some stage you have to make that decision? And it comes down to your personal preference and what drives you most? Is it staying where you are and continuing to build your reputation? Or is it working on this other product which isn’t possible in my current organization? So I need to find it no organization that will allow me to develop those skills.
Pei Mun Lim 20:04
Amazing. Thank you for that. So I interviewed mold, who is our both our colleagues, and he came also from an end user environment before, before joining cat, can you talk a little bit about the two roles that you had one as an end user doing, you know, putting on many, many hats. And then, you know, the varied role that the consulting life brings? How is that different in when someone’s thinking about entering the ecosystem, and I get asked this to end user or consulting. So because most, most of my experience have been in consulting, except for a short stint an end user. So I’m more, you know, I lean more towards one direction. So I would like to hear your thoughts about your experience.
Kevin 20:56
Okay. In terms of an end user, so if you think about what what you get in End User, so you get the potential to get heavily involved in many aspects. So as you say that the many hats things, so you could be the developer, you could be the architect, you could be the lead tester. For one story, you could do all of those things. So you start to get an understanding about how some of the process flow would work and what the different inputs are. So I think that’s quite useful as a skill to have. You also get close to the business users, which I think is something that is important. So you really get to understand how that change you made to this particular app has gone down with the users. And you can also learn from that what it means, from a documentation perspective, how did you communicate the change? How did you sell the change, because you can really start to see when you make that change from what you built, what happened in the business, because the business users might be sitting three seats down from you. So I think that level of exposure to the impact you make is very valuable. And finally, the other thing about end users is if you have a number of different Salesforce products, and if you are able to create a success story for this
used Salesforce in a particularly innovative way, or it has solve your particular business problem, you can stay close to your account exec or your customer success manager. And they will also be looking for the success stories. So you have an opportunity, I think, potentially more as an end user, to work with your Salesforce contacts, to create these success stories, and potentially raise your profile in the ecosystem. So I think that’s the end user side. On a partner side, I think some of the benefits of working in a partner. So the variety of projects, so you will work on many different types of projects. And I don’t necessarily mean different clouds, you might work on the same cloud, but no two projects will be the same, right. So you will have small projects that only have a 12 week timescale, you will have huge projects with 50 developers that take three years. And by getting exposed to the different types of projects, you will start to understand some of the constants, some of the hygiene elements that you must have in every project, and also some of the differences. So how do you phase functionality across a global business, for example, with 1000s of users and different needs? And how do you make the decisions about what you do first. And that type of experience, I think is really important. Whatever you do, so that’s, that’s one thing from it from a partner perspective, you’ll also earn your stripes. So partners need certifications, and they need them to be able to maintain their partner status with Salesforce. So they are, if you think about it, they are invested in you to get those sets. So that’s why often people who work for partners will be mandated or KPI to do two sets a year. That’s, that’s because of the partner status. And and then I think finally, you get more of a, a wider pool of Salesforce experts to work with. So if you have a practice of one or 200 people for a large GSI in the UK, there’s probably another few of the practices of that size across Europe and across the states and across APAC, and you have a chance to connect and network with these people. And you learn from them, right? You can be a sponge, and you can learn from lots of other experts and other people who work within the industry. I think that’s a benefit of the partner. And I still go back to what I said earlier, I still think the most important consideration is does the role will align with your values and aims. So do you feel like the choice that you make will support your own aspirations? That for me is the key question so Have your eyes wide open, understand what this end user can offer, understand what this partner can offer? And just do a check, does it fit with what you actually want to get from your next career step. And the other thing that I would also encourage people to do, this is a bit more difficult, but it’s a great interview question. Do you understand the importance of Salesforce to the organization you are joining? And I think that’s a really important question both for end users and for partners. So on the end user side, it will give you a sense of what actually did they just buy 10 licenses, and they’re Experimenting a bit with this. And they need me to come in as a jack of all trades admin, just to maintain users? In which case that doesn’t sound very exciting. So how can you ask the questions like, well, how many licenses do we have in our role? And how many users are active? And do we have any statistics already about adoption, if it’s if it’s a brownfield site, so you can start to build a picture in your head as to where is the opportunity here?
On the partner side, it’s understanding how important Salesforce is in the broader context of the organization. So pretty much every si now large or small, will have a Salesforce practice. If you’re going to a global systems integrator, the question is more well, is Salesforce important to this organization? So think about questions like, How have you grown recently, what’s your year on year growth, the like, and the reason that’s important is because if you consider Salesforce is growing, somewhere between 20 to 30%, year on year, if your practice is only growing 10% year, on year, or 5%. year on year, you’re actually losing market share. So the way that to maintain your market share is to grow at the same rate as Salesforce, right? So I think being able to ask those questions, and just get a sense of what the organization’s goals with Salesforce is, will help you to understand how important Salesforce is to the organization. And I think that’s important as well, because I think particularly in the partner world, they’ll often offer you jobs, which at the surface level appear to be the same, you’ll be an architect or a developer, and you’ll be working on this project, and we’ll pay you this amount of money, and you’ll get to do sets and we have training programs, you can order these things, they sometimes appear quite generic when you’re looking at them. So it’s really important in your interview process, to ask questions like, Have you been growing recently? What is the growth targets to really start to understand what the organization can offer you in terms of your own career growth?
Pei Mun Lim 27:45
That is such an important question to ask. But let’s flip it around a little bit. At the moment, as you say, because of the growth rate of Salesforce, there is a big cry for good talent. So what we’re seeing in the industry is you get the more senior people who move around consulting partners. And then you’ve got this whole raft of people wanting to join, and you know, things like that falls, refugee falls, and so on, so forth. And how Salesforce is funding and investing in getting new talent into the industry. However, what I see, and I think you’ve seen it as well, is that a lot of people want resources who have experience. And if you have a one year experience, or a year and a half you are, you know, property. But if you’re new, just go to trailhead, and you’ve got your certification, but you don’t have that experience and you want to you like coding, you know, you’ve joined the RAD program for women, for example, you really enjoy it, how do you get foot into the career path of being a technical architect, if you’re brand new.
Kevin 29:08
So if you’re brand new, the important thing is to put yourself in the shoes of your interviewer. So you are going to interview for a job. Maybe they’re looking for experience, or they are hoping you’ll give them some experience. And you don’t necessarily have the track record on your CV, perhaps you’ve come in from a different industry. And they will be wanting to ask you about that. So you put yourself in their shoes. What is it really they’re asking? They’re not necessarily asking for you to prove that you have two years of being a developer and a very similar sized organization and you developed 500 story points and you wrote this many lines of code and your time there. They’re not necessarily asking for that what they’re asking for and they talk about experience is doing You have practical experience of how to work on the platform? And if you think that’s the question, then you’ve got various different ways to answer. So to give yourself the experience of working practically on the platform, that’s a different question. So that could be something where you do pro bono work. So you work with a charity, and there are many that need help. Go into the salesforce.org website, there’ll be plenty of opportunities there. They will need help with people who can get hands on and you will be able to start building up a portfolio. In addition to that, I would say, don’t be shy on doing work on a on a developer role on spinning up developer org, and building out some concepts. So you can prove to your interviewer how it is you have practically worked on the project and on the solution. So few developer can you show them some batch Apex that you’ve written? Can you show them some, some some asynchronous code which causes a curable method? There’s various different things you can do, just within a developer. Org to prove that you have practical hands on knowledge. And for me, that’s really the question. I don’t think any employer would be hugely enthusiastic to take someone on who’s done a few Trailhead badges and gone home and Salesforce consultant. So show them that you’re not showing them that you have done the trailhead badges. And that’s a good level set. But talk them through and show them on an org what you’ve built out, you understand how to build objects, you understand the difference between a process builder and a flow and when you should use which these are all of the questions when people talk about experience. The interviewee should be trying to answer.
Pei Mun Lim 31:47
Okay, thank you. One of the things that I recall from our time together was that you were also very passionate about helping people understand that you don’t have to be a developer to be a law architect, and that there is a past from a functional side as well. Can you talk a little bit about why you feel that that’s not such an impossible and crazy dream?
Kevin 32:14
Well, I suppose let’s first of all, look at what an architect is. And what is it that an architect does? Now, there are various different types of architects, first of all, so you have solution architects, technical architects, enterprise architects, functional architects, you could have deployment architects, because Salesforce has grown so much what an architect is, does not mean you’re a CTA, right, that’s the first thing for everyone to get straight in their heads. There are various different levels and types of architecture roles, which need different skill sets my view of what a good architect is, so it’s somebody who is able to zoom out from a requirement and see a bigger picture. So you get asked to paint the square red. And you can zoom out and say, well, what’s the impact of me painting that square red? And is this actually the right decision? So you are a good citizen of what you do, and you try and make sure that the best interests are made when trying to deliver a solution. You also consider wider trends within and without the industry. So is there anything within my industry that I could reuse, has somebody in the industry done something that is useful to us that perhaps our business doesn’t know about? So again, I’m assuming outpoint, you want to also have your ear to the ground to listen to what other people in industry are doing, to see if there’s anything that you can apply in your business that no one else has thought about? You also want to be able to apply methodologies. So I think one of the key roles of an architect is to deliver increased rigor. So you want to be able to use standard it methodologies or industry methodologies, that, for example, help you make better decisions. What is the decision making process that we have on this program? And how do we record these results so that we are aware of why we made these decisions as a simple example. And then you also need to be aware of the way the technology is moving. So are there things coming up in the Salesforce roadmap or in the AWS roadmap for example, that could be really interesting to us a and could also be affect what we do today. So should we actually invest the next three Sprint’s building this or should we just delay this feature until June when we can get everything that we need? And it won’t take us three Sprint’s because it’s available in a particular product. So that’s important as well. And then finally, can you justify your decisions that for me is the key thing. Particularly within it like there are various different ways of achieving any goal and it’s rare that they are black and white, right and wrong. There are so many different there variables and factors around how you make that decision that you need to be in a position to justify why you make those decisions. So you need to be able to stand behind what you’ve done. And often, that’s by just simply applying the YY concept. So ask yourself, why three times. And if you can justify that to yourself, then you could justify it to other stakeholders. And, and of course, like anything, you will document that, for posterity sake. So that, for me is what a good architect is. I don’t believe that anything that I’ve said, needs you to be able to write the best code in the world, or read the best code in the world, at least not to start with a lot of that type of skill set, which is more on a kind of enterprise architecture type level. from a functional perspective, you will already be building up some of these things. So for example, you will be very aware of the Salesforce roadmap, you will want to know about the latest features that are coming out to avoid you having to build things. That’s something that functional consultant will quite often be on top of already. The next one around the wider trends within the industry. Again, there is no reason why is it functional consultant, particularly if your industry is specialized, that you shouldn’t already be thinking about these things. So I think moving from this functional space into the architecture space is definitely possible. And given the breadth of architecture roles there are that are out there. Just remember, you don’t have to be a CTA to be a Salesforce architect. Great if you can be that there are two sides of that CTA pyramid. One is application architect. One is system architect. And there are plenty of people in the ecosystem work on all the way up the application architecture side. And they’ve decided not to pursue the system architect one because they didn’t want that for them. And they’re they’re doing really well in their careers as effectively an application architect, working within the business, doing some of the things that I’ve described.
Pei Mun Lim 37:04
If we look at what’s is promoted, so what you’re sharing is very logical, but it doesn’t come across so much from maybe Salesforce needs to do a little bit better marketing around that side of things. But what I see and what a lot of people see is that the CTA is elevated. And that is where, you know, if you say you want to be an architect, everyone will go right. So you’re going to go for the CTA track, you’re the Barefoot board, etc, etc. And you can feel quite overwhelming to a lot of people. So it’s fantastic that you made that explanation. And that’s something that we can use to raise visibility, that it’s not just one track. The whole raft of architect roles. I think Gemma blezard talked about the different roles and how they equate to a party planner, the door, the door man and a DJ, I think she said was a Data Architect, expect this, it was really interesting to explain that to people. So appreciate that. Thank you very much. So it sounds like a lot of people keep asking you, when am I an architect when, at what stage in my career? So if you look at an all consultancies, you start from just being a regular developer, and then Oh, my God become a team lead, and then senior Dev? And at what point? Can they consider themselves a technical architect? Whether or not there’s a sea in front of that? Obviously, that’s a different question. But how do they build up so you shared a lot of that already. But there’s, there’s that which is the soft skills in the learning and awareness. But there’s also the formal type within companies within partners that says, You’re a senior developer, and now your technical architect. And if that’s something they want to advocate for themselves, how do they go about doing that?
Kevin 39:01
So we talked a bit about some of the skills of an architect just before so the fact that you can zoom out the fact that you can look at the wider trends that you can look to the future in your decision, etc. So that’s some of what they need to do as an architect, as a developer or a functional consultant on the platform, your lens is very different. So you are working on the lowest level of work unit, which is usually a user story, and you are specifically requested to zoom in on a problem right? Here is the story, you need to go and solve this on the platform. And as you solve it on the platform, you will be intimately aware of how that change impacts the user or the platform. So you’ll be thinking about the number of transactions that your change creates. You’ll be thinking about what it is to the UI you will be thinking about what it is to reporting so at a feature level you will be drilled in very low. You will also be working in an environment where a lot of the disease In the enterprise type decisions, should we integrate with this platform? What capabilities should we using Salesforce versus what should we keep in SAP, for example, those decisions will probably be made elsewhere. So you might not be exposed to those. And but one thing you will be good at is you will be good at componentize in what you do. So you will be componentized them. And you’ll be thinking about how you can package those items for ease of maintenance and ease of reuse. So that’s kind of a level you’re going to be working out there. The key difference for me is it is that level. So you are zoomed in on something as a developer or functional consultant. And as an architect, you need to be zoomed out, and looking at the picture less from a detail level, and more from a overall kind of capabilities and framework perspective to say, Are we moving in the right direction? Do we have the right parts joining up with each other, and that was retrieved from a technical architect. So whilst you might be more in the code, and you will be an Enterprise Architect, you need to start to think about well, what is the impact of all of this code on the contact object? And is there a framework I can use measures I can take to be able to understand what the overall execution time is? And if there’s any risk areas within my project? How do I bring that in? from a quality perspective? Do I use peer programming? Do I use static code analysis tools? So there’s various things from a TA perspective that you will have to zoom out on to make sure that you have some of those standards methods that I talked about in place? And that the key thing for me is to are you an architect or not? Or? Or how do I know I even want to be an architect, right? I think the other important thing is
developers and functional custodians are specialisms in their own right, we shouldn’t think that, because you are one of those things, the only next step for you is logically to be an architect, because that doesn’t need to be the case, right? You need really strong experienced development leaders on the platform, as you do with the functional consultants. So don’t feel like you must be an architect. Just because that seems to be sort of the way that it’s marketed sometimes from a, this is how you move your career up. You don’t need to do those things. But if you want to try and find out whether you should, then, for me, think like an architect. So zoom out a bit. And check your understanding to see if you really understand how the wider architecture fits together. Why am I building this in this way? What impact will it have downstream, maybe on things I’m not building on or even thinking about, but start to think like an architect so you can understand your impact. And at the same time, understand how architectures are put together, I think that’s one thing you can do. And you can also learn from the architects that you work with. So instead of just seeing it as a, as a quality gate, or handover point where an architect gives you a design, ask them why they did it that way, and what some of the decision points were that they went through to be able to get here. So you can start to understand, as an architect zooms out, what are some of the considerations they need to make? And think to yourself? Would I want to be doing that? Is that level, good enough for me? Or do I want to go back into the detail. And then finally, try it yourself. So even just through a rough sketch of how you think something might look from a slightly higher level than they used to working with, put it together, talk it through with one of your architect colleagues, because, first of all, I’m sure they’ll be happy to help. But second of all, having that challenge from somebody who is working at a lower level on the platform, is always great for an architect, because you are the junction point between exactly what happens at the transaction level on the platform, and their designs. So anything you can put together to say, well, I know this level, and I’m trying to learn about this level. So here’s where I think the matchup is really is a really good thing. And the one thing I would say about making the move, if you do decide to become an architect, remember that you’re now operating at a different level of detail. One of the traps that you can fall into if you’re used to operating at a bits and bytes level at a code level within the platform. Then whenever you speak to other people, like your stakeholders or your project manager or your customer, you tend to talk about level. So you talk about very detailed, technical or specific product items that really those people don’t particularly care about. They are interested much more in the high level. So the fact that you have that knowledge and you know intimately how the platform works is great. But it’s the sort of thing that as an architect, you keep in your back pocket, and you only ever bring it out if needed. The key step change you need to make to become an architect. You need to be able to abstract the detail and you You need to be able to simplify the way you talk about it. So people understand. As a developer, your key goal is to build that user story, build it, well build it efficiently, make sure it works. As an architect, one of your key challenges is making sure people understand what you’ve done, why. And if you talk to technically, or you dive into detail that isn’t necessary, people won’t understand. And then you haven’t achieved what you needed to do. Even if your design was good. The people don’t understand it, then you haven’t necessarily succeeded in in the role of an architect.
Pei Mun Lim 45:38
Sounds like it’s communication as well, in understanding how to pitch your message across at the right level. So this segues quite nicely, maybe not into your question that I wanted to delve in now that you’re at Salesforce. Sounds like you probably interact with more partners and more clients than you were at tap. What are the kinds of things that you see partners do that you will common mistakes that they do that you think more partners should be aware of insights, that those issues in terms of implementing enterprise wide type projects?
Kevin 46:26
So I think one of one of the challenges, this is a really difficult one to overcome. But I think knowing it’s there is important. So I think first of all, you have to as a partner, you really have to use the Salesforce relationships as much as you can, and really understand why did the AE sell this, this software to the customer, and what was their thinking, in the in that software sales journey, there would have been various demos, there will have been various decks produced that describe why this is a good fit. And the customer will have made a decision based on that. One of the mistakes that partners can make is they come in with their own view on what should be done. And actually, the people who signed the checks are not working on the project, they’re probably sat in a boardroom somewhere. And they don’t want to be surprised by what you have implemented, being completely different to the sales journey that they went on, and that they signed off on. So the important thing is to make sure you’re completely aware of why and and what the reasons were that they bought Salesforce, so that you can try and bring that into what you do. That’s not to say you can’t challenge that initial view. Because often when the rubber hits the road, and you get into the detail, you realize some of those things might not work. But be aware of it. Because they were when you if you spend six months heads down developing a project, and you decide you’re going to display, you’re going to demo this to the board, two weeks before you go live, at least acknowledge if you’ve had to change things, why you’ve done that, so that they can see the journey that you’ve been on and the learnings that you’ve taken from the business, I think that’s really important.
Unknown Speaker 48:13
And the other thing is even more difficult to try and to try and resolve but
Kevin 48:20
often the maturity of the customer, and how well they can work to your methodology is different to how you hope it will be. So if you think about a partner, a partner, deliver Salesforce projects every day of the year, right, that’s, that’s why they exist. So they will have tried interesting methodologies, and ways of working like Agile and Scrum. And they’ll be very used to working with user stories and JIRA and looking at burndown charts. Quite often, a lot of organizations do not work like that internally. So you’re very aware of the culture clash, there can be between an internal project management team and your project management team, which means you might be coming at things in a completely different point of view. And I think one, one thing you can do, which in my opinion is never wasted time, is before you start the project, spend two or three days, sitting in a we’re in a workshop together with leadership teams from both sides. And just make sure you really understand each other about how this thing is going to work. I think one of the best ways to do it, is you. If you’re in charge of the methodology, you present the methodology back to the customers team. On day one, you say this is exactly how we’re going to work. And then on day two, you get them to present it back to you. And you can then start to see did they understand that really? Are there any gaps in the way that they need to do things that we need to adjust our methodology for? Because I think the worst thing is, you’ve landed a big team of developers. You’re ready to go you’re itching to get started and developers do points to the team. But if the methodology is misaligned, you’ll never agree on what progress is on whether things are good or bad. And it turns into a kind of, he said, she said, type project. And that’s not going to be good for anyone. So I think aligning on that methodology from the start, and being very honest with each other about what you do and don’t understand about how each other works, is a really good starting point.
Pei Mun Lim 50:24
Thank you. Let’s pivot slightly. Earlier on, you talked about the fact that you’re now that you’ve moved on to a from end user to a consulting role, and then now at Salesforce, and you get exposed to so many projects, and then you get to see what are the constants and what basic hygiene that needs to be there in order for a project to be successful. So for the companies who are embarking, or at the start of the Salesforce journey, either, you know, from small, medium, or more enterprise wide global rollout, one of the key things that you think need to be in place the key hygiene factors that you spoke about earlier, that if you, you know, stepping to a situation, you think, Oh, they don’t have you know, this item, we’re going to be in for quite a rocky ride, what what are some of the key hygiene factors in your point of view.
Kevin 51:24
So I think the key thing to start with, and I know it’s quite high level, but for me, it’s having a vision that everyone understands and is aligned behind. Because what you what you want, you want to empower your team who’s delivering the projects, to be able to make decisions within the context of the project. But to align it to an overall goal. Often the challenge you will have, if you don’t have a clear vision, and you don’t have a clear sense of where you’re trying to get to, is you end up in paralysis within the project team, because they can’t make decisions, because they don’t know what they’re aiming for. So they can’t make those decisions. That means they have to escalate that to more senior people. But if they don’t have the vision, then senior person one, she might make a decision different to senior person to because they’re not aligned behind the vision either. So being able to have that vision to say, what does this project achieve? How does this align with what we’re trying to do as a business and having some very clear principles that everyone must follow? I think it’s so important. There’s many times that I would sit in an Architecture Board. And there’s a decision that’s raised. But without those principles, and those, those clear goals in mind, it’s so difficult to make a decision. Because you look at it, you say, well, there are three different ways of doing this. And I can’t tell you for sure that any one of those is fundamentally wrong. They’re different, and they have a different impact. But if I don’t know what the vision is that you’re trying to get to, I can’t tell you which one is right. And that just means the decision doesn’t get made, or it gets made, unfortunately, without the best interest in mind, because you don’t know what those interests are. So for me, it’s that vision, it’s that vision, and from that vision, a set of principles that will help the customer. I don’t know if you’ve discussed the v2 Mom process before, but often at Salesforce, we do a v2 mom for our customers. So I know that to us as an internal tool for us to set our own objectives and the company sets objectives. But we do it for the customer as well. And sometimes it’s that V to mom, and having that established, which can help all of the teams to have that reference point to to make the right decisions.
Pei Mun Lim 53:45
So no, I’ve not discussed that in any of my podcasts before. Can you just give a brief overview of how that’s done at Salesforce? And how do you do that with your clients.
Kevin 53:56
So in terms of at Salesforce, so the v2 Mom, it stands for vision, values, methods, obstacles and measures. And it’s five different categories of information if you like that you start from the top and you work your way down. This this came to be it was it was from Benioff originally who brought it into Salesforce from the very start. And the way that this works is every year Salesforce publishes its corporate b2b month, starting with with Mark and Brett and the and the senior leadership level, and then everyone else has been two months is down. So the next level of management, create theirs and then the next, the next the next. So there should be a clear theme running through all of these v two months, all the way to the company goals. And the v2 ones are public. The company one is collaborated on by various members of staff it’s posted on Slack is a draft and people can come in and ask for changes to that’s how it works within Salesforce. from a customer perspective. It’s a similar thing. You start the project, you go through your vision In values, methods, obstacles and measures. And for me, I think it’s a great document to align people, you will have stakeholders that have come to this project differently. Some will be very aware of what’s going on, some will have come in for a very tactical reason, like, I need a tester, the tester and a testing team to be able to support me, well, if you don’t know why we’re here, it’s very difficult for you to test the right things. So having that v2 Mom at the start and using it as a reference point, is useful for all of the stakeholders within your
Pei Mun Lim 55:33
project. So that’s really interesting. What you’re advocating then is in order for, to make sure that a project is successful, is to have that right upfront. However, for a lot of partners, it feels like we get introduced at quite a late stage, that decisions have already been made to get the number of licenses to for whichever cloud, they’ve already had the demos with AES and have had some idea of what they’re going to get. So it’s not something that we can do, or do you think that it’s worth doing it at that point anyway, to make sure that we are on the right path? What happens if we do that? I don’t know if you’re allowed to answer this bit. And it sounds like the decision they made earlier might not be the kind of decision they would make. Now, having gone through that process, what what do you think is likely to happen given that the A’s at Salesforce will probably have gone through that, and should be should have the kind of integrity enough to make sure that they’re selling the right solution? Even if they don’t do that beechmont exercise for the clients? What are your thoughts? Well,
Unknown Speaker 56:45
so the VT mon is a live document, it doesn’t get created the start and it lives forever, it changes. So you can change it, anytime you feel is relevant. If it doesn’t exist, create one, if it does exist, revisit it, say our assumptions correct about how this thing was going to work. Have we now learned things, six months in that we just didn’t know at the start. And let’s be bold enough to change, bold enough to acknowledge those things be initiated from a partner or from the customer themselves, so that you have the latest and greatest version of that. So I think it’s absolutely right for the partners to to challenge and to make sure that the vision is still correct. And for the customer to be brave enough to say, we’ve learned things that make us change how we thought originally. And that’s okay. That’s just the learning journey. And how you evolve as an organization, particularly in the middle of a digital transformation, right, you’re going to learn things about yourself, you’re going to learn things about your teams about your data that you didn’t know. And when you learn those things, be bold enough to make that change in your original vision.
Pei Mun Lim 57:49
So while we’re entering into a territory that I’m really interested in, but I’m very mindful of the time. If you’re short in time, then we can continue at part two. But if you’ve got another 510 minutes, fantastic. Okay. So this is one of the things that I talk about a lot, because I run projects. And one things that I feel is that when we get introduced to the client, a lot of the sales have already been done, let’s say I’ve not been involved in the pre sales and a bid process even. And then we go into a client and we find that either Did you know The Project maturity levels isn’t quite there, or that running an exercise like, you know, the v2 Mom would really crystallize some of the challenges that they’re going to have either the fact that they don’t have a vision, or you know that there are things that need deeper thought before we actually kickstart the project. However, as a partner, when we go with it is really I’m going to start the engine now, whether the wheels are on a kind of got to go in so what I normally talk about is sometimes we as a partner going into putting product, we can’t make that change, we can’t help the client get to their level of clarity to be bold enough to question about the direction that we’re going now because we are already you should already be starting because you know, it’s a bit statement work has been signed, and we’ve got a team waiting and raring to go. So what I normally tell people, when you’re in that situation, our job, really, at that point is to implement the best that we can. What else can we do because it feels like we’re not the right people, the team and the right time to actually bring that on board. At that point. What are your thoughts around that?
Kevin 1:00:00
So I think delivery organizations within within partners, I think there’s something they can do, which helps, which is coming to the table with a list of standard assumptions, or dependencies that they’ve worked with on every project. So, again, so it will be quite mechanical, we assume that you have a code repository that we can access, we assume that all of your workstations are able to run Salesforce, and that you are able to run the lightning console with a particular spec. So there are a set of standard assumptions, which most likely won’t have been covered within the sales process. But they’re still really important, because if they’re not validated, then the project will fail. At some stage, there will be a big road bump, when you all of a sudden realize we don’t have these things. And it’s either stopping your delivery progress, or worse, stopping the solution operating correctly. So having that list of standard assumptions and dependencies that you can bring in and say to the customer, look, our priority right now is to get working for you. But I want us to spend, even if it’s just some offline time, half an hour a week, just going through each of these, maybe it’s part of our standard governance, when we have a governance meeting, just to make sure that these things are all in place. And then you could potentially pick up some things that could trip you up later on. So I think that’s important. The other thing I would advise is, don’t think you personally is a delivery team have to do these things. So look at who is working within the organization within the organization’s partners, and understand what’s on offer. So a good example is, if you if you’re a premier success customer with Salesforce, you get access to a customer success manager within the customer success group. So that’s the group that I work with. There are a series of standard methodologies that help to do things like assess your your organization’s maturity when working with Salesforce. And this is something that you can request as part of your premier success package from your CSM, to do what’s called a contest assessment. And they will do a five point assessment as to how mature the customer is. And part of that might include looking at the vision and understanding is the vision in place in is it clear? Now what might end up happening is the answer that comes back from that is no which isn’t in place, or no, it’s not clear, well, delivery team, there’s a risk for your project, raise it, put it as read, and be very clear that this could hinder you. But you have done it in a way that has engaged Salesforce, it’s engage the customer, because they would have had to have gone through that exercise. So anything you now say, will be I think will be given more credibility and seen less negatively because you’ve gone about it in a certain way. And you’ve shown you have a method and you’ve shown you want to get a second opinion. So it’s not just you know, as could happen, right? You’ve not delivered on your story point for the sprint, you’re saying is because there’s no vision, you couldn’t make decisions quickly enough. But as a delivery team that might be seen as you’re making excuses, because you didn’t deliver your story points. Okay, well have the more mature conversation, don’t have the conversation at the time where you’re telling them why you didn’t hit the burndown target, have the conversation earlier, have the conversation as part of weekly governance. So I think it’s about In summary, coming to the project with a list of standards that you expect, and making sure that you build in time to work through those. And it’s also using the customer and the partners to their fullest extent, to be able to drive out some of these things if you can’t do it yourself.
Pei Mun Lim 1:03:48
Outstanding. I think I got a lot more out of this podcast than I expected beginning. So again, thank you for a little bit over I want to thank you for the time that you’re taking to talk to me about all of this and I think it’d be really, really helpful to anyone thinking about getting on the architect track into the wonderful world of Salesforce. So I appreciate your taking the time to talk to me.
Kevin 1:04:15
Your Pleasure. Thank you for having me.