In this week’s episode, we’re joined by Julian Joseph, a lead Salesforce DevOps Engineer.
Through the episode, we hear about how Julian found his way into the Salesforce space, initially working as an Administrator before gravitating towards QA and testing roles. Julian explains some of the nuances to Salesforce testing and explains how his passion for automation eventually led him from testing into DevOps and whether this is a jump that many people make.
DevOps is often seen as technical, so Julian explains the skill sets required to work in this space, and shares some advice as to why non-technical Salesforce professionals may benefit from learning scripting.
Julian talks us through how he has approached his recent job search, how he automates certain tasks, the kind of questions he asked in an interview to assess culture fit, and some recent additions to his LinkedIn profile and resume that make an impact with potential hiring managers.
We hope you enjoy the episode and make sure you follow Julian on LinkedIn and his other social media accounts!
Ben:
Julian, welcome to the show.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Thank you. Glad to be here!
Ben:
I’m excited to unpick your journey, your career and find out a bit more about you. If you’ve ever listened to any of these episodes before, you’ll know I always like to kind of look backwards and find out a bit more about what got you to this stage of your career as well. So let’s start back at the beginning. And if you could tell me a little bit about kind of early career, what you did before the world of Salesforce, what you wanted to do and really how you found your way into the Salesforce space.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah. So actually going to college, I knew I wanted to be in Engineering, but I found out quickly that at least in the short term, that wouldn’t be the case. I actually flunked out of Electrical Engineering, and so it was an interesting path getting back into tech, getting into Salesforce. For me, that was actually by way of a nonprofit called Liberty in North Korea. After college, I actually taught English in South Korea. And eventually came back to the States, worked for that nonprofit. They were using Salesforce. And thankfully, there was the Vice President of that organisation. He was really, I think, influential in terms of being tech forward with the organisation itself and encouraging staff to kind of go down that path. And I had that tech background and I just got roped in actually into doing a project to do a large data migration into Salesforce. I had no idea what Salesforce was. In fact, I was asked to learn it over a winter break and I just said, yes, not knowing what it was. These are the days before Trailhead. And so I didn’t have a whole lot to go on to even have an image to look at it at that time. I mean, I’m sure they were out there, but I didn’t find it. And so it was really going in, not knowing what it would be at all, but got brought into this project, got trained up by somebody, thankfully, who had done Salesforce in the past. This is in the nonprofit success pack. It was called the starter pack back then. But I got brought into that project, really got interested in just doing things like large data migrations. I never thought it would be something that exciting, but for me, it was like fun to try to figure out how to keep uploading things over and over again until I actually got it right. And that led to a job with a Salesforce partner called Classy, they’re owned by GoFundMe, that was doing tech support and admin support, moved over into test engineering, and then eventually made my way over into Salesforce DevOps.
Ben:
So when you came back from South Korea, had the plan been that you would look eventually to go back into tech or was it literally kind of that whole Admin by chance situation?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Definitely the Admin by chance. And so when I was at that nonprofit, I was actually a donor relations intern, which basically meant I was calling up donors, asking if they want to increase their donation, just checking up on them on a regular basis. And so nothing really tech focused. But my boss at the time, I actually saw that he was, of course, he was the Donor Relations Manager and he was sending out these emails. It was actually fundraising emails. And every day he was having to actually build a new list of emails to send out. He was using spreadsheets and he would actually copy and paste back and forth from a kind of a large spreadsheet with the smaller ones based on people’s donation levels and things like that. And I saw that and I was like, “I think I can do this better”. I can create a formula in Excel. And one thing led to another, I learned,” oh, actually there’s a better way to do this with MailChimp” and “oh, MailChimp can actually integrate with our data”. Of course that’s through Salesforce and eventually I saw all these connections kind of come together and that basically drew me back into tech, just my interest in each of those efficiencies.
Ben:
Yeah, nice. And you mentioned Classy are owned by GoFundMe. Was that through an acquisition or was born out of GoFundMe?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
It was through an acquisition. That was actually after I’d already left Classy. I think it was, I’ll say about two, three years ago now. It makes sense. They have similar visions. GoFundMe is like one of the donor B2C. Classy was more B2B, B2 non-profit really in this case. And yeah, they basically merged their services together and they’re kind of offering a holistic solution.
Ben:
Yeah, nice. I had no idea. So you started in your Salesforce journey as an Admin, but then I can see looking through your profile, you kind of gravitated towards that QA role. What was it about that space that interested you?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
QA for me, and this is a theme throughout my career, it was really a customer centric kind of mindset and move for me from, from role to role. In that case, in particular, it was realizing I’m doing technical support. I’m working with these Admins. I’m of course fixing bugs or at least working with them as they identify bugs and passing those to Developers and helping them implement them in their Salesforce works. And time and time again, we would have a release that had, let’s say, a bug fix or a new feature. And unfortunately, create new bugs and new or missed features and things like that. And so I was realizing, you know, what’s the best thing to do before I was giving it to customers? I’d actually test it on my own. That would save me time. And I was without knowing it, I was actually becoming a Test Engineer, a Quality Engineer by just verifying things before I’d give them to customers. And so that for me just turned into, “hey, why don’t I make this a role?” I also learned, this is something I care about a lot, pay equity, but I also learned that the pay for that role was also double. And so if I’m already doing the role, why don’t I get paid double for it, compared to what I was doing on the tech support side? And I just started going down that path, kind of taking the efficiency of doing the work, but also the efficiency of improving my career.
Ben:
What would you say some of the more challenging aspects of the testing space for Salesforce are? I guess if, because a lot of people might not have, especially if you’re looking at someone that’s delivering a program of work as a manager, may never have experienced Salesforce testing before. What makes it complex or what makes it more challenging than testing other technology?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
So with Salesforce, I’d say there are a number of nuances that you need to be aware of when you’re testing. Probably the core difference between testing some other application and testing Salesforce is that everything exists on this platform in the cloud already with a lot of other applications. You know, eventually they’re going to get to the cloud. They are often like a website or something that can be downloaded or installed and so distributed in that way. But where they’re living isn’t. fully on the cloud all of the time. It isn’t the only place that you can test. Often there’s a way to basically have it locally and test in your local environment. With Salesforce, you’re always working within a Salesforce environment in the cloud. You’re always working in somewhat of like a real space. And that’s both good in some ways because you are getting an environment that’s probably more realistic. But the challenges are you also have a lot of limitations in the environment that you maybe can’t work around the same way you could potentially with other applications locally. And so whether that’s actual Salesforce limits or it’s just the limitation of always needing to take your code and actually move it up into the cloud, deploy it to the cloud before you verify it, before you test it, and actually working in this other environment, that’s something to always think about. Additionally, I think in Salesforce, there’s a lot of automation in the background or efficiencies in the background that Salesforce has put into place for the Admins, but they are going to impact the way you test. And so for example, when I think of like adding a field in Salesforce and you need to test it, it isn’t just the field that you’re thinking about. You’re thinking about the permissions around the field, maybe validation rules, maybe a flow that it’s connected to. And so there’s all these advantages that Salesforce has, but it means that one component is touching a lot of other components in Salesforce. And some of them maybe automatically were created in the background. Like a permission might be created alongside of creating a field. And so somebody who’s doing testing, they need to understand Salesforce enough to know which things are going to be automated in the background. So they need to understand it. I would say like an Admin. And they probably also need some Developer style skills as well. Understanding the way that code is working, how it’s deployed what code is actually living in that environment that you’re testing it. And so all in all, I think it’s a bit broader skill set just out of the box from maybe a Tester in another application.
Ben:
It’s interesting you say that about needing to have the Salesforce platform knowledge because I know like some people on a project they might make their Functional Consultants or their Developers do the testing rather than having like a dedicated Tester and I think you’ve highlighted there like it is a specialized skill. Do you think it’s vital that there is a Tester rather than it just being a responsibility that’s given to someone on a project?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
I would definitely say having somebody with that mindset and that focus is really helpful. I think in terms of having somebody dedicated, I think that depends on the project size. I don’t always think in every situation there needs to be a dedicated Tester. I think that role can be shared. But I think what is more important that there’s somebody really thinking about some of the nitty gritty and thinking about ways to break an application. And so for example, usually you don’t want your Tester to be the same person that is going to be developing that change or making that change. Because the whole point is that there’s like a different brain, a different mind that’s coming at this issue from a different angle and not making any of the assumptions that you made. One of the funny things in testing is sometimes when I’m working with Developers I’ll hear them say, “oh, this is, this is where I tested or you don’t need to test this area”. And for me, that’s actually a lot of signaling of, “okay, that’s exactly where I need to test” because if you’re telling me I didn’t need to test it, you probably didn’t test it, you probably weren’t thinking of ways to break it. But even beyond just knowing where to do it, I think there’s also a special mindset of putting yourself in that customer’s position, thinking with empathy and thinking with what are going to be the real challenges, especially when you’re starting to think about things like accessibility and equity that comes into applications. make and develop something doesn’t mean it’s going to be usable by everyone. And a good Tester is coming at that new feature, that bug fix, and is really thinking about it from a lot of different, wearing a lot of different hats and understanding a lot of different scenarios and personas that person might have and trying to break it and trying to really stress test this change in that way. And so I think having somebody that has that mindset doesn’t always have to be somebody separate, but It’s important to have that somewhat more unique nuance skill set separate from a traditional maybe Tester or traditional Developer Admin.
Ben:
Yeah, it makes a lot of sense when you put it like that, like it’s obvious, that someone that’s built it shouldn’t be the one testing it, but it’s not always the case. So it’s good that you make that clear that it just the reasons for it, I guess. And you’ve obviously moved more into the DevOps space recently. And if I think about the testing candidates that I speak to, whether they’re Salesforce Test Analysts, Test Leads, Test Managers, and they’ve gone through that progression, it’s often they stay down that testing route. And I actually speak to a lot of people that want to transition into, you know, more sometimes more functional roles. And, you know, they might want to become a Salesforce Admin or a Functional Consultant. And I don’t see many in my experience or that I can think of off the top of my head that have gone into the DevOps space from a testing background. Is that an obvious move? Are the skill sets quite well aligned or is your transition fairly unique?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
I think it’s a less common path from what I’ve seen as well. But I think it makes a lot of sense when you come at it from the view of efficiency and specifically automation. And so I started off testing more manually, but over time, with that same mindset of efficiency that I had, I think early on in my career, I kind of kept that going with testing. And for me, what that looked like is getting into automation. And so that meant creating automated tests. That’s a very common path for somebody who starts off manually to go into automation. But additionally, with some of the Salesforce nuances, what I learned is not just learning how to automate tests, but learning how to automate changing settings or changing the Salesforce org environment and being able to create additional environments, additional Salesforce orgs. So representative for scenarios became really important. And so I was learning both of these skills and DevOps really led itself, especially to that configuration, that or creation, thinking about settings and configuration, that piece of it. And so I think that’s where my transition came in, but the UI automation, UI test automation, that piece of it is also, I’d say related to DevOps in that. You probably need to understand the infrastructure that your tests are going to be running in. So whether it’s running in something like AWS or GitHub Actions, CircleCI, some of these tools that do basically DevOps or do kind of CI CD. But one piece of that, one big piece of that is running your tests. Understanding that part of it was also crucial. And so in many ways, I brought some of those skills from the testing, from the automation. they naturally grew into that DevOps skill set.
Ben:
And when people think of DevOps, often they think technical, right? Like it sounds like a technical role, a technical kind of skill set. So how would you explain the different types of skills that go into DevOps from a, you know, functional technical and which are more technical than others?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
I’d say a lot of those tools that you use tend to be on the more technical side and DevOps. And so definitely on that end, I think that’s where the technical piece comes in and I’ll explain that a little bit more in terms of the maybe non-technical side, I think there’s also a lot of people management and this kind of like philosophy of how you do DevOps, which tends to be a set of soft skills. So just starting off talking about that, that piece of it. A lot of times when I’m implementing something with a team, it’s not just thinking about what technology am I implementing, what changes am I making to their, going back to like the environment creation or to how they’re running tests or to validating code and making sure that it meets all the formatting requirements that they decided as a team. Those are some of the technical pieces, but on the human side, there’s this question of like, how do those things get implemented? This idea of change management, and also what is the value of implementing each of those things? And I think a lot of this comes from maybe some stigma around this idea that sometimes DevOps can be slowing a team down. Potentially, ideally it’s like speeding things up, but sometimes to do that, you’re also like helping QA, let’s say, implement higher levels of quality and additional checks and barriers to combining code. to releasing a product and to making sure it meets these different quality checks. And so I think there is some of that question of how do these things get implemented and having to know how to work with a team, how to work with Developers and how to build trust over time. For me, specifically with that flip deck is knowing what order to implement some technical changes in and maybe not rushing things too quickly or to build trust with maybe some lower hanging fruit. some smaller projects before we get to the bigger needs. I think also on the other side of soft skills is maybe some leadership management as well. And so these processes, they’re probably, they might be affecting one team, but often they might be affecting multiple teams. And so knowing how to work with multiple managers or with a Director or some other higher level people in the org to be able to implement some larger process changes, I think it’s also really important. to be able to be a good DevOps Engineer. On the technical side, I talked about some tools earlier like CircleCI, GitHub Actions. There’s some other tools out there as well, like many might’ve heard of Popado, Gearset, AutoRabbit, Flowsome, some tools that are Salesforce specific to DevOps. I’ll tell you one thing that’s nice about Salesforce DevOps is these tools are in this somewhat of a middle ground in terms of not having to be as technical as some traditional DevOps tool and being more familiar to people like Admins, having like a nicer UI, working well with automatically with orgs by just connecting to them rather than having to set up like a whole tooling backend tooling process to get some of these changes to work. And so Salesforce, I’ll say just has that benefit of I’ve seen Admins, for example, switch over to become somebody who does DevOps because there can be a lower technical barrier in some flavors of it. I’ll make one note that tends to be on the org side or the, I should say, the customer side of doing DevOps. There is a smaller but also important partner side of DevOps that’s actually my specialty. And so if you hear things like ISVs, to some degree, the SI partners, these are some just tools to describe different kinds of Salesforce partners, the ones who create and manage packages usually distribute them to customers. That flavour of DevOps actually tends to be still pretty technical because the tooling they’re working with that we’re working with tends to be more CLI based, more typing in commands and not having a pretty nice UI. But at the same time, since it is still within Salesforce, a lot of the skill set still involves knowing a lot of things that an Admin would know as well. And so even on that end, there’s some crossover to this, what can be thought of as less technical, more declarative.
Ben:
Yeah, it’s interesting. There’s obviously a lot that goes into it. AndI think, from a skillset perspective, it’s that kind of unicorn, and he’s the perfect candidate, right? Someone that’s got both skills. But if someone is more on the functional side and wants to become more technical, I hear of scripting a lot in the DevOps space. Like, can you explain what scripting is? And is that something that is key to a DevOps role? And if so, how someone could learn to script?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
What I think of scripting and this may not be the textbook definition, but I’ll describe it the way that I know it and the way I think I experienced it. When I think of scripting, I’m usually thinking of procedural commands, so commands that I’m doing in order. And when I say commands, I’m even more specifically talking about what you might be typing into a terminal on your computer. So if you open the terminal app, rather than clicking around, usually what you’re doing is typing in different. actions or typing in different commands, things that you’re telling your computer to do in a way, in a different kind of interface. And so when I think of scripting, I’m usually thinking about doing those different commands, but basically chaining them together into what is typically called a script and then being able to run them in order. And so ideally, basically creating your commands that you want to run in order, in order to perform a set of actions. It might be against your computer. It might be against AWS and Salesforce DevOps world is probably going to be against the Salesforce org or maybe even like a group of Salesforce orgs. And so that’s what I think of a scripting definitely important. And usually you take that skill of scripting and creating a script that might be run locally on your computer. And you kind of take that and you translate it into another tool’s language, which essentially is like the same language, but usually just a little bit more context. So for example, I use GitHub actions a lot. If I want to take a local script that I’ve created on my computer and I want to turn it into a GitHub action, it’s more or less a matter of copying and pasting and then just adding some formatting, some things like adding names to it, adding some just general typical code that would be required for any GitHub action. And then just making some decisions about when I want that, when I want that script to run. And so to get more specific with an example, if I wanted to create a script, that for one Salesforce work, it ran all of the tests in that org. I could write out that command. I could write out that script locally and run it. Or I could say, I’m going to put this into this GitHub action, this CI CD tool. And then every single time a Developer makes a change within GitHub, which is usually where developers are doing their changes or some similar version control tool, every time they make a change, it’s just going to automatically run all those tests. And then that’ll give that developer feedback about if those tests are running. And so that’s an example of one kind of script that could be running for DevOps purposes.
Ben:
So is it something that should be scary to Admins, the concept of scripting?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
I think not. I mean, it’s very similar to writing, I would say a flow. So if you’re familiar with flow or flow, of course, replaced essentially process builder, if you’re familiar with doing those things in order, in a lot of ways, scripting is the same. The difference is instead of like boxes of lines to each other, you’re just writing out texts line by line. And in terms of like learning that, I mean, I’ll just say you can actually learn a lot of scripting on Trailhead. There’s a good number of trails and modules that talk about scripting, specifically scripting with the Salesforce CLI or with Cumulus CI, which is a tool I use at Salesforce DevOps. There’s great modules and trails for both of those. There’s a course just on YouTube, I’ll say, there’s a whole bunch of courses just talking about like what does this look like. And then nowadays, actually something I like to use a lot is using tools like ChatGPT. using some AI conversational tools to do this for me. And so you can even learn and I’ve actually worked with some people to help them learn how to do some basic scripting, just by asking this tool to do it for you. And the kind of reverse engineering app and learning it that way.
Ben:
And if, even if an Admin didn’t want to go down the DevOps route, would scripting be useful in their day-to-day job?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
It definitely could be. And I was using it early on. I mentioned that transition from tech support to quality engineering. Even that early on in my career, I was beginning to dabble in it. And I will say it was intimidating to me at first. I thought, “okay, I’m never going to be able to learn how to do this”. But taking small chunks of it and having some people that support me along the way, I realized it could actually be very useful. In particular, a lot of things that you want to do in Salesforce that can take, let’s say, five, 10, 20 clicks to do, you might be able to translate into a single script. And so for me, that often looked like maybe loading it with a bunch of test data, or maybe making a lot of changes to, let’s say like 10 different contacts to like merge some kind of data between them or reload them or even do more complicated things like create a bunch of settings changes like the state country pick lists or some other larger things. So in Salesforce, some of these actions, they could take 10, 20 clicks. They could, they could take you a while to perform. But if you learn how to do them, if you learn commands, commands essentially do those same things, but usually at a larger scale, often a lot quicker. And then they have the added benefit of you can change it together with the script. and do them all at once or do them with effectively one button press, and so there’s a lot of advantages to being able to learn even some basic things.
Ben:
Yeah, I think that’s really, really good insight and valuable recommendations to people that are watching this because it’s probably not something that everyone thinks about learning if they’re from that kind of more functional admin background. But yeah, like you said, there’s some real power in that. Now I shouldn’t be surprised based on everything you’ve said today, but automation is obviously kind of at your core. And I know having followed a bit about your LinkedIn posts and your job search journey. and you’ve done some automation in that space as well. So can you tell me a little bit about how you approach that and I guess why you do it as well?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, I do automation, so I love to be lazy. I think the best Engineers are lazy Engineers. I say that a little bit in a joking way because, you know, to some extent, that’s not always true, but I think the core idea that I’m trying to get across there is I’m always looking to automate everything that I do, so whether it’s, let’s say, the work I’ve talked about or searching for a job. or even having conversations with people, which is a challenging thing to automate, but not impossible. I’m always looking for those ways to do it in a way that’s also still as authentic as possible because I think there’s sometimes you can take away from automation. There’s a lot of risks. There’s a lot of things that can be lost in terms of authenticity. And so I think trying to keep that as high a bar and a value of mind but along the way, whenever I see myself doing something over and over again, I usually think to myself, “there’s probably a better way to do this, probably easier way”. And I think that’s even a little, a lot of Developers might say something similar, but I’ll say for me, my first thought is I think somebody else has probably done this, so I don’t always like solve a problem by just building an app or building a new tool for myself. That’s not my go-to. It’s usually to actually just go to Google and see, has somebody else done this? That’s helped most recently in my job search because I thought, how can I mass apply to these jobs that I’m seeking? And I thought, “oh, maybe I can look for this”. And sure enough, I found some tools that will do that for me without me having to build it. But yeah, automation to me is really just how I, in a sense, improve my life day to day.
Ben:
Yeah, I love it and I know you’ve spoken about things like tools like Calendly and stuff like that, which I love as well. So yeah, there are some really smooth things out there that just make that day-to-day interaction easier. I guess the risk of automation, especially for something like a job search, is like you are starting with quite a wide funnel because, you know, every, not every company that are advertising a role is actually going to be a company you want to work for. So how do you, because the funnel is large, how do you then, as it kind of starts getting to the more pointy end with regards to like interviews and things like that, how do you assess a company for, do I actually want to work here? Like, you know, is the culture going to be right for me? Are the values right for me? Things like that.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah. I think a piece of that, I just want to make sure I touch on is like when I start funneling or when I start narrowing things down, um, and this might not be right for everybody, but for me, I’d rather be in a place where I’m turning down companies than the other way around. And so I always try to keep that funnel as large as possible for as long as possible. Now my time is limited, other people’s time is limited. And so I can’t always be contacting everybody. But more often than not, I’m always trying to make sure that I have enough contacts and enough companies kind of coming into my funnel. And so for me, specifically, that means like applying to a lot of places at once, maybe even some tooling and things like that. And then later, you know, if I have to say no, I’d rather be in that position to do that. I think traditionally in our job market, we thought of, “oh, it’s more on the recruiter side to say no. They’re getting like a thousand applications to one job. So they’re the ones like weeding out”. I’d rather be on the other side of that where I’ve got a lot of jobs and I’ve got to be weeding out on my end, not them weeding me out. And so I think that means just scaling up. But in terms of like how I begin to funnel those things down, I am a pretty values based person. So obviously once I’ve crossed out reasons like the location, I am, for example, looking for remote. So if it was onsite or hybrid, that’s probably not for me in most cases. Or some of the technical pieces, of course I’m like looking for a different specific roles. But once I’ve gotten down to like the role piece of it, in terms of like funneling the company, I’m really looking at values alignment. And what that looks like is asking. some specific questions about how their values may or may not align to my values. I mentioned pay equity earlier. I definitely ask about equity. And so often in an interview, depending on who I’m talking with, but especially if it’s somebody like a leader of some sort, I’m often asking them questions like, what do you think about pay equity, pay transparency? What do you think would happen if I were to create a pay equity channel and your company’s Slack group, for example? start this conversation. How would you react? How would the leaders react? Some other things about it to me are, I mentioned DEI and accessibility. That’s diversity, equity, inclusion, accessibility. Those different things. Just seeing how the company either invests in those spaces. Do they have groups talking about them internally? What can I hear about those groups? I often, once I get far enough along in the interview process, I’ll often be asking to meet with more people. And so, you know, the company may see the interview process as being done, but on my end, I might want to meet with somebody from one of those groups. I might want to meet with somebody higher up in HR or even like another executive to ask some of these questions if I didn’t get enough information earlier on. And so yeah, to me, weeding out looks like value alignment and determining what that looks like.
Ben:
I think it’s really powerful what you said around like you, it’s important to look after your own interests, right? And I like for me as a recruiter, yes, I don’t want people wasting time, my time, my clients time, your time, everyone’s time. So I understand your concept of having as much in the funnel as possible, because ultimately that will lead to more opportunities that you can say yes or no to further down the line. But in terms of your like how satisfied on average, because you’ve had like 45 interviews, I think you as per your last post. When you are asking questions like the ones you’ve mentioned, how satisfied on average do you think you are with the responses?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, there’s definitely a range. I’ve had some responses that are definitely, they’re not satisfying. And to me, what’s maybe unsatisfying is when, I mean, obviously if there’s not a value alignment, that’s not great, but I also am glad that I got that information early on, doesn’t even always mean like it’s not a good fit at all, but it’s just more information for me to take in as I go through the process, you know, trying to figure out what I’m looking for. But I’ve also had situations where people have been honest and they’ve let me know that it’s something that they’re working on and they give an examples to me, those are more satisfying, even if it’s we’re not good enough in this aspect. But if, for example, if this is my manager giving me some of this information and they say, “hey, we’re not meeting our own expectations or maybe even what your expectations might be. But I want to work on this with you together. This is, if you started that pay equity channel, I think this is the response you’re going to get. Maybe some apprehension or some interest, but maybe some apprehension from some other leaders. And honestly, that’s something I wouldn’t advise doing at least early on. But I want that to be the case. And I want us to work towards that. And I want to figure this out as a company.” To me, having some people to work through this together, to having, seeing that the company is at least open enough to having those conversations, those are important. And I have gotten some of those responses. That’s always a great sign. To me, it’s like, if there is, the most concerning is when there have at times been some language about, you know, this is what we need to work on or excuse me, when there’s been some language about this is what we are working on and it’s going well X, Y, and Z and we’re pretty much done. Like when I hear that we’re done, that’s almost always the biggest concerning piece is because this is just this idea that we’ve kind of checked this box, we’ve finished this discussion, it’s closed. This is what we’ve determined and like the door is closed. Sometimes I’ve heard of it like framed as disagree and commit. I think it’s honestly a misuse of that term, but I can see where it’s coming from. And just this idea of, you know, this is, this is a conversation that we’ve had and we’re, we’re finished with it or we reach this level, we’re satisfied. That level of satisfaction or complacency, that’s been usually when, at least for me, that’s the biggest misaligned.
Ben:
Yeah, I think that the real key message is that like I feel a lot of cut, but both job seekers and hiring managers and companies sometimes feel they need to give the answer that the other person wants to hear because they’re trying to hire right. They want this person there. They’re from a skill set perspective. They’re perfect for the role. But actually, when you get into the kind of values discussion, the transparency is the best policy right always, because it’s just for anyone getting into a role, if they join and it’s completely the opposite of what they were told in the interview or you know, you do start that Slack channel and the response is completely different and the manager always knew that was going to be the case, but just wanted to get you in the position. Like it’s just a waste of everyone’s time. And sometimes, like you said, it’s not what you want to hear, but the way that it’s framed and that this is something we’re working on and, you know, with your support and that might still be a role that you would consider.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, if there’s willingness to have that conversation, to me, that’s the most important thing. And they use the phrase, waste of everybody’s time. And that’s something. that I try to think about whenever I’m moving forward. Like, am I truly wasting somebody else’s time or my time? I’ll say, first of all, to me, generally speaking, just having the conversation is almost never a waste of my time. Maybe if we’ve done like several rounds into it, that might be a different case, but at least in the beginning, especially some initial conversations just to see like what this fit looks like and getting into that nitty gritty, especially if we’re having time. If we’re having these honest discussions about values and going through it, or just other kinds of alignment, to me, that’s important on both ends. But the real waste of time is when there isn’t that transparency that you’re talking about, or there isn’t that honesty about what is going on. And we’re kind of dancing around the things that we don’t want to say. Of course, you’ve got to be professional to a certain degree. But I always try to err on being as open as possible, being as transparent as I possibly can be, encouraging that from the other person in these conversations. And I think that’s the best way we see some alignment. I think also mixing in there, trying to make it a valuable conversation regardless. I want every interview I do to be valuable for both sides. It’s really only a waste if you’re coming into it thinking, this is only gonna be valuable if we get a yes on the next step. That’s almost a pet peeve of mine.
Ben:
Just to clarify what I mean is a waste of time if you’re only telling the person what they want to hear and then they join the role and they find out it was actually completely different. Like I think that’s why it’s so important to be transparent because you know not every role, not every environment, not every company is going to be right. Just as not every potential employee is going to be right for that company. And that’s why I think sometimes you just have to be, even if you know it’s not what the person wants to hear in the interview, you should still put it across, right, and not fear them turning down the job or not fear being turned down for the job because you’re being true to your values. But yeah, just when I see people join a role and they’ve been told one thing and then they get there and it isn’t what they were told, I think that’s when it’s a waste of everyone’s time, right, because you know, you’ve been lied to ultimately through the process and you might have missed out on other opportunities that were a good value alignment. and then you’ve joined a company that was never going to be right for you because the manager was just really keen to get you in the role or you were really keen to find employment and then it just it’s off, you know, it’s not, it’s not the right environment. So that’s what I mean by, yeah, just transparency is always the best policy through an interview process.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
100% agree. Yeah.
Ben:
Now, one thing I preach, I tell a lot of people about is on their profile, it shouldn’t just be a list of tasks, right? You shouldn’t just say what you did and what your day-to-day responsibilities were. I think it’s really important to also highlight achievements. And one thing that I saw on your LinkedIn that I rarely see on anyone’s profile, and sometimes I guess it can be more challenging to present these kind of figures in different roles, but you speak about cost saving. and like a dollar value of how much you have saved a company in a particular role. Why do you do that and how did you come to the calculation?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah. So yeah, thinking about numbers and even like presenting them, that’s actually something that’s really relatively recent on my profile. And I’ll just start off saying I consider it somewhat of an experiment to see how people respond. And I think I’m getting good feedback that it’s positive. So it’s great to know. In terms of figuring that out, to me, that was actually really important. And it didn’t start with, let’s put this on my profile. It was actually in my role. What are the numbers that I think are valued by leadership? Which dollars are almost always a good bet. Yeah, what are those metrics and what are those things that I can show in my role? So that I feel confident that I’m on the right path and that they feel confident that it’s a good decision for me to be doing this role. And in particular, I was actually trying to think of ways of like, specifically, how can I prove out my salary? That’s, you can’t always do that with every role. And I wouldn’t say that’s like always a great strategy. So I just want to put that caveat. But for me, that was just how I came to this thought process of like, how, at least for myself, do I feel confident that, you know, I’m adding enough value and I’m doing it the right way. And so what I looked at was I wanted to get to a dollar amount, but I knew that would be kind of difficult. For example, things I’ve done back when I was doing testing and also somewhat with DevOps. might involve reducing bugs. And bugs could be really valuable in terms of like the cost savings, but they’re really hard to figure out that value. And so for me, I decided to look at some other metrics and the one I came across or the one that I figured out that I could get what was engineering hours saved. And so how much time I was saving people on my team by implementing processes with this automation. And yeah, I just started to do different estimates with projects. And so I looked at those projects that I was doing and either tried to figure out some of my own guesses more often than not, I would actually ask some of the people on the team or, you know, you’re doing this process and this new process that I’ve implemented takes an hour, how long has it taken you before? Was it like 10 hours, 20, whatnot, and try to get, you know, ask a few people, get some more information, get an average. And then I also went and checked in with our VP of Engineering, and I actually asked her, like, what is one engineering hour? A lot of people can probably also just calculate this, but I just wanted to take a metric that I was seeing leadership already use just to give it a little bit more validity. And really, all I did was just multiply those two things together. And so that half a million number that I came up with savings was just looking at every project. Let’s say it was like six or seven different projects, again, getting estimates for a number of hours saved and then just multiplying them by whatever one engineering hour saved, which I think in this case, I used the number $125. And so just $125 times however many hours got me to that number. And then from there, obviously, when I went to the job search process, I started to think, “hey, I’ve already done this work of getting some good valuable metrics, why don’t I just use these in the same way?” And so just transfer it on over. The same internal stuff I was using at my company to calculate my own savings. I just looked and was able to track that out.
Ben:
Yeah, I mean, I love it. And I think it’s going to be different from every for everyone. And in terms of the different role they have, but just looking at the way you think about it, like, anyone, anyone can kind of transfer that into their role and look for ways that they can kind of articulate the value that they’ve provided and not just list tasks. I think that’s the key message for me from that. And I think you’ve done it the right way and that you do articulate it as an estimate. You know, it’s not you’re not saying this is exactly the dollar amount. And also if ever you’re questioned in an interview, you can quite clearly explain how you came to that figure. And I think that’s also really important, right? People shouldn’t just be putting figures on their CV that they can’t kind of back up with the theory behind it.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, no, I totally agree. I actually have these same conversations with friends who are applying and going through this process of updating their resume. And that’s exactly what I tell them. It’s put some metrics on there, but if they are estimates, I mean, be clear that they’re estimates and also be ready to back that up, but still go through the process of doing it. And sometimes I’ve noticed that it can be difficult to Try to figure out, “oh, like maybe especially like two jobs ago, what were some of these numbers, what was my savings”, like things like that. I always recommend, you know, get a rough estimate, make it reasonable. If you can talk to anybody from that past company and just like throw that number past them, does that seem about right that we were doing? And try to, I usually try to be a little bit more conservative with it as well. If you’re unsure and, you know, ratchet it down a little bit. But yeah, be able to justify it, just be able to explain it. That’s like the bar in terms of whether or not you put that number on your resume. Can you explain it to me? Can you explain it to somebody in the interview and reasonably justify it? Because regardless, even the metrics that you see in an all-hands meeting, a lot of times those are estimates as well. So everybody is guessing to a certain degree. Of course, there are probably a lot more scientific ways. There might be a whole scientific process, but it’s not. To some degree, it’s still just an estimate. And the whole idea is like, can you explain that well? Do you have good justification? And so take that same approach when you’re adding those things to your resume.
Ben:
Definitely, I love it. So if anyone’s listening and they want to reach out, pick your brains on any topic that we’ve discussed today. Where’s the best place to find you?
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, LinkedIn is always a great place. So you can just type in my name, Julian Joseph. And I bet if you add the word Salesforce or DevOps or both of them, I’ll probably be, hopefully be one of the first ones to pop up. You’ll see a lot of emojis and you’ll know you’re on the right person. Besides that, I’ve got a Linktree, Linktree/Julian Joseph. And that can link you to all of my other social media, my website. Actually, I’m particularly proud of my website, I’ll say, because I didn’t design it, my friend did. She did a great job of making it minimalist and cool, but it’s actually using Salesforce Experience Cloud. And so yeah, that’s on my link tree, and you can see what that looks like. It has some of those figures and numbers, as well as other projects I’ve worked on.
Ben:
Brilliant, well thank you so much, I’ve really enjoyed the chat.
Julian Joseph (he/him) ☁️🤘🏽🌈✝️🍕:
Yeah, same here. Thank you
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.