14th #OnThePeiroll #podcast with Richard Clark now out!
I really had a lot of fun on this one; QA and testing is in my blood, I think.
Testers get a raw deal.
Devs dislike them because they point out problems in their code.
Functional consultants detest them because they identify design gaps.
But don’t forget – they are there to ensure quality.
What’s quality?
It is not perfection.
It’s delivering a solution to SPEC.
A really good QA will know the difference, and will ensure that the delivery of product is of a high standard.
Regardless of whether testing is manual or automated, QA is critical in the success of a project or product.
Underestimating its importance will spell your doom… oom… oom… <echo accompanied with a dramatic flourish of the arm> 🦹🏻♀️
So don’t!
Anyway, that set me off on a riff… just listen to the podcast (link 👇🏻)
We talk about so many things in the #Salesforce, but obviously focused on testing, projects and implementation.
I hope it’s as fun to listen as it is to was to make it!
Enjoy!
#OnThePeiroll
Transcript
Pei Mun Lim 00:27
Okay, hello, Richard, welcome to my podcast OnThePeiroll. How are you today?
Richard 00:36
Hi Pei. I’m good. Thanks yourself.
Pei Mun Lim 00:38
I’m very good. I’m quite excited about this. We’ve not spoken for a while, even though we’ve worked together at make positive where where we know where we first met and then asynchronously at Capgemini,
Richard 00:55
which was yes, I forgotten that. baton change that wasn’t that
Pei Mun Lim 01:02
was you are now CTO of provar.
Richard 01:06
Not quite. I’m the Chief Technology Innovation Officer now. So that was a change back in February.
Pei Mun Lim 01:13
Okay, I will ask you about that in a minute in more in a few minutes. But I think just looking at your career history on LinkedIn is very long, and very prestigious, in a way when I’m eyeballing it, I would like it, if you can just narrate to us the story of how you get to where you are today.
Richard 01:39
Wow, that is a long story. I began at the beginning, which is writing games as a teenager, back in the 80s. On home computers. The days when you had to, if you wanted to sending a listing, you had to type out the typewriter, if you didn’t have a printer, most 3d printers then. And if you wanted to install the game, you found you took it from magazine, you typed in all the code. And you hopefully got it to work so that I probably learned debugging before I learned coding in many ways. Because before I learned to code, I learned to debug someone else’s. So that was quite an interesting thing. Fast forward through Computer Science University didn’t know much about programming there, unfortunately, but learn things data modeling aspects, networks, columns, that sort of thing. And early access to email with Janet at the university computer networks back in the late 80s, early 90s. So we used an email about 10 years before everyone else didn’t know it’s called email then. So went through quite a number of companies. I’ve had a lot of work where working with software houses, consulting companies. So I’ve worked with lots and lots of big name brands, mainly in the UK. And through that experience, a lot of the times what I implemented was a CRM, but I didn’t know it was called a CRM at the time, it was called prospecting, where it was called a customer registration system, and had no idea never even heard the acronym serum until many years later. And then around 2007, I was fortunate to be invited to join a startup, which to friends that formed. And the idea was to be the next sales force. That was the plan. So we can do product development products always been at my heart, we’re going to develop our own products, not for CRM, but to rival that and went through a number of ideas. But we quickly needed to raise some money. So we started doing Atlassian implementations for customers. So we’re doing complex interior type systems are people writing plugins for that we thought that was going to be our that was gonna be our moment then. And then we did a Salesforce project with the implementation project for customer Chelmsford. And out of that, it was at the time when Apex first hit the scene, suddenly, no more es controls, it will always country’s worst at around, but we’re trying to get away from them. And we started I started getting good both the Salesforce ISV team about building applications on the platform, as well as my first app exchange app there. And that company was Brightgen, who we all know today, as a UK plastic partner. I was fortunate there to recruit a very talented individual who scraped past my Java Enterprise Edition exam, Cookie Bowden, and said to him, or do some certifications, get on the forums, get yourself known, free marketing. And he took that and went for it in spades, as we say. So he’s completely dominated and been a huge contributor to the ecosystem. And I’ve been a bit of a journeyman as you say, going through various companies working at various end customers, again, implementing Salesforce, helping customers build products on Salesforce, and lots of applications. And that includes both the larger global system integrators like Capgemini and other smaller partners like make positive you mentioned as well. ultimately lead me to a path in 2030 To make positive when I met a guy called Gary waters and pulled off key, who had an idea around a map, they wanted to build for testing, based on their experience at the company they were at. And it was quite an early experience. They asked my advice, and I said, Okay, if you build it, you don’t want to build an ID. So use Eclipse because Forster comm ID was using Eclipse. If you’re going to test Salesforce, don’t use the UI. So looking at us, and this UI keeps changing these locators I, I do something then the page changes and it’s broken. Why is that? They explain why. So say this is in good metadata and this metadata API. And that got the ball rolling with the guys that provide in 2014, make positive and finished incubating the project. And the guys ready for launch on their own companies provar and take some resources out in gown in India as well. And then I sort of looped back with those guys. I was a customer twice. And then in 2017, I was between roles contracting. It was after dreamforce. And Gareth phoned me up, I just come back from accepting a job as a developer somewhere doing lightning component development. And Garrett said to me how Fletcher improver and that’s where I am today.
Pei Mun Lim 06:18
Oh, that’s quite a interesting journey. It sounds like product development and getting your hands dirty has been what driven you, if I look at the kind of roles that you’ve picked up? Is that still something you’re doing? Are you still coding at your level? So
Richard 06:38
yes, and no. So I’m actually working on a new product for prover at the moment. And it’s no secret, it’s in the test management space. So it’s the ability to have the history of all your test executions, but actually also plan what you’re going to test, we’re going to test it. And the purpose of doing that is then you’ll be able to measure and talk about the outcomes and make sure you’re checking your test results against what you plan to test rather than just say it worked. Yeah, that worked. But that was that what we were supposed to test quite important. And are building that declaratively. Myself, because they will understand it’s quicker to do that in prototype, but we’ll use mocking up tools. But actually using an old colleague of ours, who’s now joined us, Kemal. He’s going to be doing the web components. So today I was doing the design. So those are WC components.
Pei Mun Lim 07:29
Okay, can we just take one step back? So for any of our listeners who are not familiar with provar, can you just share a little bit about what what what the flagship products are and what the other products that you’ve just been talking about?
Richard 07:45
So provar is the first and only testing product built for Salesforce, we’ve been successful enough that people just like to try and imitate what we do. And what provar solves is the problem that with Salesforce, you have three releases per year, that a mandatory, you can’t stay on Salesforce, you know, spring 20, you have to upgrade, there’s no, there’s no holding back option. So customers are forced into a three times year change cycle. The other thing customers experience is that generally Salesforce projects are very agile. And we’ll talk more about agile, I’m sure in a few minutes, because it’s probably our favorite topic. And that means there’s lots of change happening. And when your Salesforce was just used by your sales team, or just your customer service team, the impact of a bug was probably not a big financial risk. But now we have websites running on Provo, we have e commerce application. So I don’t bring prep, I wrangled Salesforce with e commerce applications. So what provar does, in essence is allow people to build test suites using a declarative approach. So point and click to build both UI and API tests. You can test your end to end business processes. And then you can choose how you want to run those. So I run the run that every time I make a change, do you want to run that every time I do a deployment? Or do I just want to run that every day to make sure there’s no bugs in production that our business processes are working?
Pei Mun Lim 09:09
Seeing that sounds quite comprehensive. What kind of so when when when I was working with positive, we were looking at rolling that out for one of my clients. That was a project in flight. And there were a few reasons why we didn’t take it on. One of which was obviously budget. It wasn’t something that client had been prepared for. Because it the cost of is different in that for that particular project. We had scoped to have a manual tester as an example. But we found what we found was we had underestimated the amount of testing that had to be done. And every release, just made a bit more difficult. So we looked at provar. And one reasons why we found that it wasn’t suitable at that time was one was budget. In number two, there was a lot of change that was going on. So can you share some thoughts about where provar is suitable for organizations at which step of their journey in in terms of coming on board Salesforce and utilizing it within their roadmap?
Richard 10:37
Okay. Firstly, your example is not unique is probably the majority, probably over 90% of projects do that people underestimate testing, they leave testing to the end is the first thing to get squeezed. Or we’ve all done projects where what we do for testing, we call it UAT. And we hand over the implementation the sandbox straight over to the customer, and say you test it. And we don’t help them. Sometimes we help them to test scripts, we tell them what they need to test, but they don’t know what we’ve already tested. So that’s that’s been a problem in the past. So how provar can help customers most is, when you’re doing a Greenfield Salesforce implementation, you usually have a very high engagement, the business people are very interested in what you’re doing, and you may be doing it quite interactively. They’re very true agile. When I started in Salesforce, we were doing everything in production, we didn’t always have a sandbox, that wasn’t an option. And so we were building as we went on a daily workshop basis, and people were then able to use the system then and there. And it was truly agile that days after our licenses arrived, people were entering real data into production, then, of course, what happens is you start getting a change request, as you said, that change questioning or take me three days. But those three days might affect the lead object might affect your marketing automation might stop the validation rule firing. So suddenly, you need to think about the impact on everything else. And that’s the payback of probates, that would work called a regression gap. So people always plan for what they have to do, they don’t always size what they need to test. So companies will benefit and get a very quick return on their investment in think tools like provar, if they can plan ahead and know what they need to do. The other important thing, few is manual tester. manual testers are excellent at one thing, or especially one thing, they’re excellent at exploratory testing. They’re excellent at finding things that the developer didn’t think of the architect didn’t think of the business analyst and think of the customer didn’t think of, they find gaps. That’s what their real skill is a good manual tester. So make them do any kind of go to this page, fill out these seven fields, and hit return is a waste of their skills. You can automate all that boring stuff, you don’t want to make 100%, you automate the boring things, repetitive tasks, the things that have to work. And then you let your manual testers focus on the what if scenarios. So if I hit cancel halfway through this, will it save it? What if I don’t enter that line? item? What’s gonna happen? What if I change the status that order? What if I set the opportunity to close lost, at the second stage, not the last stage. And that’s what exploratory testing is good at to do and actually will always continue?
Pei Mun Lim 13:17
Let’s see. So when, if someone’s looking at a project, then or to begin, using Salesforce in the organization, is what I’m hearing. Test Automation is something that you would only use for regression testing, and therefore after go live, and during your three yearly release, or is there room for it within a larger Transformation Program,
Richard 13:52
you definitely want to be sick, think of it as early as you can, so that the difficult point is at what point that project, do you have a stable enough development, that it’s worth investing your time in automating the tests, and the traditional way of automating test was with code. So when you consider a tool at Salesforce, you can have a bunch of functional consultants or admins making changes, creating flows, creating page layouts, dynamic forms, lots of great work, they can do process builder, whatever. And then you employ a developer a high cost resource to test it worked doesn’t make sense. There’s no payoff of doing that. So what’s really important is to use a tool, which is also declarative, that may be that admin or that functional consultant can also use to create tests as they go. Because as you know, we write unit tests for Apex code, but we don’t write unit tests for a flow or a process or for foundation rule. using tools like provar. If you identify that point where you have your baseline, maybe your MVP, which may not be your release candidate, your first release candidate, but your MVP, then you can start building those tests successfully. The other thing you can do is you don’t have to start with UI testing. So using the Salesforce API, it’s very quick, immediate, you can create tests at the API level. So what I mean by that is for every data table every s object in Salesforce, there’s automatically an API that can be used to create, read, update, or delete records. And using the toilet provar. Within seconds, you can create a test mimics that, take some test data, fire it in and check the results. So you can definitely use that from the start. The second point about the value of it is for using every day. So regression is certainly one task. But the way you build your regression backup is by building your system tests up. Throughout the process, we refer to earlier with our new test manager product is about making sure that we also record at the start of the project, what your test strategy is, what your test plan is, what are the things that need to be tested? Because understanding what to test is probably what most of our customers suffer from most, is they don’t understand what needs to be tested. And some testers don’t understand Salesforce, they’re testing the wrong thing they’re testing does a ListView work? If I search this view, does it find a record? You don’t need to test that Salesforce will be tested that you need to test your customizations?
Pei Mun Lim 16:12
So what would the what would the proper strategy be then? If we are looking so let’s let’s pick up a hypothetical situation where you’ve got a client, who’s engaged the partner to implement Sales and Service Cloud and potentially rolling it out globally. And with more integrations with maybe language and currency to think of later on, at what point in how should this organization begin to think about the test automation strategy for such a big implementation,
Richard 16:53
I think should think about it in the definition stage of your project, you should definitely read it, for instance, resources need tools you want to use, and adjust. If anyone’s thinking of, say, employing tests that are developed through testing, please talk to provar. Okay, at that point, there’s always an ROI to pay back. As soon as you’re thinking about employing a developer to do test. The larger projects for sure, it’s easy to see that you need to do test automation, there’s a business value a business risk economically attached to that. For smaller projects, if you’re going to do a Greenfield, Salesforce implementation or a nonprofit implementation, 10 users, it clearly doesn’t make sense if you’ve got 10 users to be doing test automation. And this something is so critical that you need the business value. And in that case, it may not be UI testing, you just need to have some API’s that are running and you can probably script that using Data Loader and a few tools. So testings always required. Whether you need prover or not is a is a trade off between the cost the product and make sure you get that payback within the acceptable timeframe.
Pei Mun Lim 17:58
Okay, sounds like something that is Mr. Su Su mentioned, where budget and timeline is consented to things that get missed Moses testing and project management. So I tend to have no so conversations with the clients quite a bit. In terms of let’s just go back to your the path that you’ve taken on your career journey. And it looks as if you have staked quite a lot in the contracting side of things as opposed to on permanent with with an organization. Is there a reason for that?
Richard 18:39
That’s a great question I didn’t realize I had I mean, I spent probably seven years at the first company I was at in Colchester, going from a junior developer to the software manager. I then went contracting pretty much through the whole of the 1990s was a great time in the UK for contractors, it was a tax efficient way of turning 30,000 pounds a year into about 28,000 pounds in your pocket. for the right reasons, a lot of those tax evasion avoidance, which is the which is the legal version, or those tax schemes are now largely God and we have ir 35 the demon so the reason I’m not contract anymore, if that if it plays a big part in that the reason I was contracting, it was because of that dynamic nature of Actually, I choose what projects I work on. When your listeners viewers, maybe we’re from system integrators, you don’t always get a choice. So you may be sent somewhere you don’t want to go We both know that experience. And you may be there three months, and it’s not the job you thought you’re going to be doing. And while you’re adding value for that customer and you’re adding value on that account, it may not be the most interests you so be in a contract for me gave me that opportunity of going in somewhere without worrying about what the project was. I’ll start the project deliver everything I need to do in six months, maybe 12 months maybe extend but if I was then finding there was no challenge left or project wasn’t available. I was very comfortable moving on or taking a break when he did.
Pei Mun Lim 20:05
So here’s a question that I think about quite a bit. One of which is when you’re working with a partner or GSI, you have the benefit of a standardized ways of working. Most of the time that standard is of a reasonable level, there’s best practices around what you can do what you should do around security, and so on so forth when you are contracting. And you might be contracting as a staff augmentation for the partner, or directly with the client, you don’t have that. And you are basically in with whoever things best were being a specific thing is going to do in your experience, how often do you see projects that are run well, along with the methodology, the development and the testing, and providing a robust solution? bearss. So we know a lot of organizations, they’ve got internal landscape and politics around how change is managed. Where those sorts of environments and situations don’t result in the kind of quality system that you hope to achieve?
Richard 21:28
And that’s a very difficult question. So if I take the last consulting engagement I had was for a UK satellite telco company, and they were going through a digital transformation internally. So they had a monopoly, their monopoly was being eroded by new players in the market. And they’re having to change their business. But they invested in a team to educate around things like six sigma, to educate people about Pro. They paid a scrum coach or several Scrum coaches, who I was fortunate to work with. And those people were really, really important in educating the end users that the, you know, there’s real people who really use the system, usually sales operations in most companies, I’ve worked at the people that really understand everything works, and understand what the exceptions are, and what’s normal. The challenge, there’s always been the senior managers, and why should I pay for that? Why do I need to do it that way of getting the engagement level. So it is very, very difficult at those end customers where you don’t have that champion of that digital transformation. And at that, at that location, we were working alongside some large GSI guys who were doing that. And they were perceived to be slower than I was coming in with my own team of five, we were doing things. And in fact, we had some comments that the business were a bit worried because we kept delivering on time. And they’re like, we’re not used to this, that’s not supposed to happen, especially delayed, that’s what normally happens. I’ve got time today for the release date, you gave me release date. So I put the holiday knowing would definitely not be that day like Well, that’s not the way I work. I might have shipped 100% where you wanted but I’d rather ship 90% working, then make you wait longer. That’s the point of Agile gives you something working now that’s complete. And then you can have the rest later anyway. So there is definitely trade off. I think also be very careful about this. But not all of those large size or even smaller size do have all those right ways of working. I agree. And some of that can be down to whether there are boutique that have specialized in that one product, they’ve got very lean processes. Or maybe it’s the same process, whether you’re doing SAP or Salesforce, or workday, or ServiceNow. So they can be trouble with things like that. And I went on some early projects back in the early 2010. I think it was 2011. And it was a partner who was mainly a sap partner. And they planned a two year Salesforce implementation in Netherlands. And we were like, how’s it two years and I was actually on the governance for that. I said, This is crazy. Why is it taken two years to do this, but they had a process, it was almost stsadm, they had a process, they had a methodology they were following. But obviously what it was going to deliver at the end of that two years was gonna be out of date. selfless moves too quick. You can’t make technology decisions in a waterfall manner two years in advance, because you’re dead in the water if you do that.
Pei Mun Lim 24:23
So this segues really nicely into methodology that we talked about. So I’ll let me put my stamp forward and then we can have a discussion about it. My point of view is that agile works a lot better with a product company. Or if your internal in the way that you’ve talked about, you’ve got your team and you’re delivering internally versus them engaging a partner. Whereas if you are engaging in partner it can’t quite be agile. Big Because then there is accountability issues and that sort of thing is, how do you how do you see things?
Richard 25:07
Yeah, I totally agree. I think the trouble is, agile is about the ability to change things and deliver something early. And that’s that’s what we talked about ready. But with customers when you’ve got contractual relationship, no, this is what you agreed, this is what we suddenly signed off for this amount of money by this date, so there’s no flexibility, but they need flexibility, this whole reason you do things agile, because their business will change needs to do to new things, when you start to change that once that documents issued any changes to that have an impact, you can’t just swap things out for free, you can’t take out five points and put five points in. Because there’s thinking time, there’s design, there’s all the other points that could be done. And I think that’s been a misrepresentation of agile, that is so easy to lock things out. When you’re a product company, you’re not working off that scope, what you’re working off is a backlog of changes. And you’ve got product managers prioritizing and shifting things in that backlog. So what we’re really changing when we do President provar is removing things up and down that backlog, we don’t change what’s in sprint, because that’s been committed to this would have been designed, we could affect what happens in the sprint plus one. But businesses that tend to be it needs to be now it needs to be my way or the highway. So it can be very, very challenging. And I do feel, you know, I wouldn’t want to go back to consulting for that reason, it would be a challenge to go back and have to remember that you can’t do that.
Pei Mun Lim 26:33
Okay, I’ve got a really, I’d like to ask a question that’s been on my mind. Now, when you talk about product development and agile, what about technical debt? When you so when. So I know of one consulting client who had gone full agile, but they went in it with the eyes wide open, they wanted to learn the journey was what they wanted the journey of discovery and learning, plus the final product, not just the final product. So I believe what happened was they got to the end, they got what they wanted, I can’t remember how long that project was, and what it wasn’t my project. But there was a very candid conversation about if we had designed it, what we wanted upfront, which they didn’t know at that point in time, the cost would have been less than half. And they wouldn’t have had the amount of technical debt of all the changes that they took. And so that was quite interesting that they came away with that point of view. However, from a product delivery point of view, how do you deal with with technical debt of the changes? Do you? Do you refracted every set date, say, let’s now have a look at what we’ve accumulated? And let’s look at fixing that? Or how do you manage that? How are things
Richard 28:01
so if I can mention on the first point, so it’s quite interesting because people think agile is somehow cheaper. And I would always say agile is more expensive. Your trading costs against the ability of something early. And the ability of flexibility, that’s what it provides. It is definitely not cheaper. how we handle technical debt is we have to run vulnerability scans in our product on regular basis, we use several third party libraries, we wouldn’t you know, code everything from scratch. We have chrome updates that happen all the time we have Salesforce releases happen all the time, each of those has created technical debt. So we have technical debt that falls into the it must always be part of the next sprint. So there’s always a Chrome Beta version, we’re always working on the technical debt for anything that introduces anything that deprecates we’re always working we actually work we were really working on a must track now winter 22. So we get access long before other Salesforce partners as part of that could monorail. So we’re working winter 22 compatibility at the moment that’s already in our backlog. That’s a commitment we make, we have to have that compatibility, to give customers that promise that guarantee that test they write in Provo will keep running, even if Salesforce changed something from aura to lightning or change the DOM rendering as we say, equal field. But we also have things that are more longer term like Java upgrades that happen more slowly, and long term stable releases every few years. So we just have to plan those in our roadmap. And I always liken it to when we’re doing our release planning is we could follow our bucket or hourglass with sand have lots of little things customers want and a few bugs in here and whatever we have to balance or we can take a few big rocks, put them in the bucket first and we fill up around it with sand. And that’s my preferred way of working is we take those big rocks and we have a trade off between the new features sometimes or resolving or mitigating some technical debt that we can see coming or has already arrived.
Pei Mun Lim 29:56
Okay, that sounds like a good way of doing it. Because my head was, oh my god, how do you do that? So quite nice structure great that you’re doing that. So I know that you’ve got a team out and around. And you’ve got a team here. How do you manage both teams and make sure that it’s as tight as if they were all co located? Especially when you’re doing agile?
Richard 30:23
Yeah, I’ve got to say it’s become hard with COVID. Of course. So key to our success before was going out and meeting the team twice a year, building that personal relationship that all teams need. You don’t have time for people to have cultural differences or misread reactions to things. And I’m a big proponent of slack that actually people not using emojis can be terrible at times. If I say something, I think maybe controversial, I must remember to put a smiley on the end, because I could upset a whole team, just with a flippant comment about a joke about developers. Why did that developers look out the window in the morning? Because they have nothing to do in the afternoon? It’s a joke. Okay. So I need to make sure these things are communicated. Actually our problems worse than that, we actually have quite less stuff in the US now. So we have around 30 staff in the US in four five timezones, I think, so actually comes quite difficult. So there was a moment when my working days sort of started eight finished eight, I’ve managed to shift my changing roles, many more dealt with the US and Europe now. And that’s really how we don’t agree re divided some of the roles, we have some people in our product and engineering teams. But we put engineering management in India as well. So the person responsible at Kemal is in charge of the engineering team rather than me now being responsible. That gives us an extra four and a half hours of overlap per day. Our staff are also very flexible their working hours. So our staff in India will generally start around 10 o’clock. Unfortunately, some of them will finish at 10 o’clock, which I’m not happy about. So we need to fix the problem of people working long hours. But we also have a overnight shift. So for our customer service, we have a team who have been hired for the purpose of working from home, we had lead that was part of the contract. But working those extra hours, also extra work in those midnight hours for India, which cover parts of Europe and US, in Australia,
Pei Mun Lim 32:18
Australia as well.
Richard 32:21
So, as well, but no stuff. Our first a staff, one of the guys is in Singapore.
32:29
So yeah.
Pei Mun Lim 32:31
It sounds like it’s grown a lot more than that. I love it. I think we’ve grown 30% and staff numbers this year alone. How are you? So you mentioned before COVID, you went out twice a year to India? How are you pulling the global team together and make it so what I find that small companies are very good with the culture thing, because it’s easy. And as it grows, it becomes so much more difficult. And I think you and I lived through that change the company we were at. But that was all located in India. And now you’ve got a situation where you’re global? How do you find a way to make sure that the human connection is there. And it’s not just transactional, because it can easily go down that path, you’re working this hours, you’re talking to the customer, and there’s not so much of the human connection,
Richard 33:30
or the point, I don’t think we’ve solved it, we still have a way to go on that. And because we’ve gone from being a small company to over 130 staff now. And I say the staff in the US staff need to there’s no overlap in their working day. Normally. So we rely on things like slack to have that asynchronous messaging that communication. We rely on internal company newsletters, old hat, we rely on our company all hands meeting, which you know, in this day up late for us coming early for those that are on the west coast. So we rely on those mechanisms of people being flexible their time, you know, to have some level. But the way in terms of the engineering team I’ve handled it is to have special days. So last November, I think it was we had a window where I was able to break our sprint pattern and have a one week no sprint. I think it’s really important the engineering team to get some downtime and do some self learning. And in that time, I scheduled what we called an engineering day. So we had fun and games. We had talks, we had our own dream mini dream force. And it just was down to the people to present what was it they’re interested in. Tell me your call for papers what your idea is, I make sure there’s no overlap and off you go from present. And I was incredibly successful. But what’s really good is using the different online tools and playing agile games like my morning routine, you’ve probably done that one before was really really good for a scrum master and getting people to be more open and communicative about what they do without anyone judging them. Because Yeah, whether you have to Post before or after you brush your teeth really isn’t something anyone can criticize anyone else for it’s personal preference.
Pei Mun Lim 35:07
Now that sounds that sounds like quite fun, no sprint week. Yeah, we’re definitely do more, I hope different. Let’s see more of that. Okay, what’s our so you, you talked about this test manager module you’re working on? Can you tell me a little bit more about that, because I’m quite interested in what does that mean?
Richard 35:31
So the probably what you most people have come across is a lm, HP 11 fold now microfocus. So it’s a product that lets people capture both defects around their user stories, I suppose you could say it’s quite predates all of that around what they plan to do, but also capture what they plan to test. So a key part of that is to make sure to say that when you say you’re going to test something, you’ve captured evidence for it as well. And what test manager really do is extend provers very good at the test results, and give you history give you a nice report, at the end of it gives you evidence. And we already hooked that back into Salesforce into a free appexchange app for you to have the history results and dashboards. What test manager does is extend that by say measuring what you plan to test. But it also gives you a nice point hook in your capaldo or your flow some or whatever you’re using for release management, Deloitte have their own excellent application as well for it. So it lets you hook those processes in and have more governance around what’s going on and what was done. And allows you to look back and say, Okay, so the opportunity Management module, we have breakages every month every release. Why is that? Is it because our tests aren’t robust enough? Are we doing lots of changes, breaking changes? Was the quality of ad delivery not good enough? So it lets you be able to ask those questions. Why is that? It’s not gonna tell you the answers. Okay. I’m sure you could take with a data feed into Tableau CRM, and it will spit you out a more detailed answer. But there is nothing out there is no machine learning algorithm of everyone’s data. Nor should there be my opinion, there’s going to tell you a magic answer every time. customers don’t like to share data.
Pei Mun Lim 37:13
Now, I can imagine why. So that’s the thing that you’re currently working on. Is that something that excites you? This?
Richard 37:25
Yes. I’ve always liked building apps for Salesforce. There’s several I’ve built they’ve never seen the light of day. And I still had someone email me about my first app last week, two weeks ago now. And it’s a revenue scheduling app. And then weirdly, within Provo, we had a discussion this week around multi year deals and how we track that and how you measure ACB versus a total deal size, total contract value, versus annual recurring revenue. And I think to know what I must have solved this umpteen times in umpteen engagements elsewhere. And I wrote product for it 10 years ago. And I’ve that say, oh, maybe I’ve got to dust that off. So yeah, product has always been excited, because I like that, especially Salesforce, the ability to write something very quickly. You asked me about do I code? Yes, actually, I wrote an apex class yesterday. And I had trouble getting it to save and making changes. And I thought, actually, I need to make sure I use all the latest notations. I’ve got make sure I use all the latest accessibility rules. Because going through security review, the checks are much, much harder. And I thought, well, I should use it like Clayton. Remember Lorenzo’s app, I can use Clayton to help me do this. So I still like to code and do development. But there are people better at it than me, I would much rather be doing the innovation around the design what we should do, or given the feedback about what things good or not. If I had my dream role, it would be with a team of talented developers and saying mega do this. And it just happens with me not have to write anything down. It’s better for the world. He’s in intense labor, some of the best people we’ve worked with even Franco, who you can just say something to and it happens, you still need to write something down for them to work with. And if I can get better at that writing down. I’ll be very
Pei Mun Lim 39:12
happy man. Okay, okay. So this comes right back. Circles right back into we were talking about earlier on that you’re now the chief? technology innovation. Yes, sir. Yeah, officer. How, how is that different from the CTO?
Richard 39:34
So when I was CTO was in charge of both our product and our engineering teams. So it’s what should we build next? And how should we build it? I also unfortunately, inherited like lots of more companies, CTOs to our internal infrastructure. And I hate doing infrastructure is the least interesting thing. I’ve got the wrong brain for it left or right side, whichever it is. I actually do enjoy it. with suppliers, but I’m not one to worry about what solution we should pick or to do a procurement process around picking one supplier over another one, I’d rather just buy the tools or one going shopping, and just use them. But I do care about security, I do care about single sign on, I do care to make sure everything’s integrated. So now I don’t have to worry about any of those things. I don’t have to worry about where engineering team do. I’m not worrying about what a product team is saying is next, but I’m having influence over it. So I’m saying this is the product strategy for the next three years. These are the gaps in our product suite. And this is how we can achieve those, but not deciding the solution. So there’s a number of projects we’ve got going on at the moment. I’m personally working on test manager one because I feel I’m was the most qualified to work on it. Now there’s someone more qualified, come out working with me. And other things are happening as well that I can’t talk about, but using non Salesforce technology to do other things. And those are really excited because I don’t know I’m learning about, I can say technology, I’m learning about AWS, I’m learning about AWS fargate versus Google Kubernetes is so stretching me in ways technically, that I haven’t had to think about for the last 10 years while I’ve been in that Salesforce bubble.
Pei Mun Lim 41:14
Sounds like you’re heading towards your dream role very slowly shedding off the activities that doesn’t excite you and then moving and taking on things that does excite you, which is the product design and innovation. Yeah,
Richard 41:28
whether there’s a difference or you give up control to a product, it can be frustrating that you’re saying, look, this is really important. And you’ve been told, well prove to me why it’s important. Prove to me the total addressable market for that feature. There’s no research company out there that has that information. That’s nice to Salesforce testing. There’s no one out there that can tell you, should you improve in your product, how we handle experience cloud? Or should we work on it? Which or which industry cloud should we work on next? They will work but which one? Should we add accelerators for? Do we do financial services? seems obvious? What do you do Life Sciences and healthcare? was a difficult trade off? Both have regulatory requirements? Both very high wealth customers, very large customers? Which one do you do first? Very, very hard decision to justify.
Pei Mun Lim 42:18
So how do you make yourself decisions? How does he I can’t say is okay, all right. Maybe for another another episode?
Richard 42:27
Maybe another episode wants to talk about it. But at the moment, I can’t say because quite critical area moment.
Pei Mun Lim 42:33
Okay. I actually I was looking for a more generic answer to that, which is decision making? Not not as in what you focused on.
Richard 42:44
Okay. So you have to take into account your customers, what do they want? Okay. And one of the things I’ve been trying to put in place is improving how we serve our existing customers, how do we talk to them without annoying them too much. So I know I participate in a lot of Salesforce surveys, it’s reached a point where now I’m getting No thanks. I don’t wanna do that one. I’ve got too many. I’m on three pilot programs already. And now I’m talking about something on the partner community to do with user signups and stuff. It’s like, great, I’m interested in talking about it. But that’s my capacity. So how do we do that of our customers and get them to tell us what they need and what they think and what they require? But also, how do we also then look at the what the markets doing? So we have to look at what is important. So I was under pressure last year to do sec around artificial intelligence, we must have an AI feature. Why do we need an AI feature? Because everyone else has one? Why does everyone else have one? Because it increases the value to their investors. Okay. So what you’re telling me is everyone else has done a full machine learning or their data is pulled centrally, and they’re using that information to improve the testing for their customers. Oh, no, they’re not doing that. So what are they doing? They’re doing self healing. Why are they doing self healing? Because they’re located so brittle. We don’t have that problem. Okay, they’re doing natural language processing? Why are you doing natural language processing? Because no one can read the test results, right? We don’t have that problem. Okay. So why should we do AI in testing. And now there is a thing I spoke about recently on a event, ai in testing needs to be this future vision where you have a piece of code is written by a test. Okay, or the code writes the test, they need to go hand in hand. The problem with testing and development is they happen independently. So if we can somehow have something that does both, they write and write a test, and it will generate me some code, test driven development to the extreme, or I write some code, and I automatically have all my tests generated for me that spots all the weaknesses in it. So that for me that mutation testing is what really needs to happen for AI in testing everything else. If it’s not mutation testing for me, it’s a distraction, and just someone trying to raise their share price. Wow, sorry. You
Pei Mun Lim 44:57
just said something that kind of blew my head apart. Just conversation my kids about the dimensions first, second, third dimension, the fourth dimension. It’s this is just you know, this. Yes. So I think I’m gonna need some time for my brain to catch up there there was,
Richard 45:15
well the computing power required is going to stretch, even though all those Bitcoin mining servers and that’s the concern. So while we could do all these things, is it morally justified to spend enormous amounts of computing power, energy and resources on doing something today instead of a human doing it? There’s a price point where you go, I’ve got a great idea, this employee human to do it. They’re far better at doing AI than computers are. Oh, yeah, that’s true.
Pei Mun Lim 45:46
On that note, you know, this has been such a very stimulating conversation. I’ve not enjoyed conversation at the technical level on call this technical for me for quite a long time, and I am quite excited to see where you’re headed to next. So thank you very much, Richard, for spending time with me on this podcast. Thank you, Pei. Thank you for listening. I hope you enjoyed it. Thanks a lot. All right. Take care. Bye bye.