Latest / Talk Commerce / The Top 3 Secrets to Accelerating Your Digital Transformation, with Ben Johnson of Particle 41
Transcript
- Brent Peterson (00:02.237) Welcome to this episode. Today I have Ben Johnson. He's the founder and CEO of Particle 41. And in the green room he explained to me that they don't make boards for the lumber industry. That was a joke. Sorry about that. Ben, go ahead. Do an introduction for yourself. Tell us your day -to -day role and maybe one of your passions in life. Ben Johnson (00:21.486) Yeah, sure. So I'm CEO of Particle 41. We are a global software development consultancy. And I'm super passionate about building high functioning tech teams. And I'm a serial entrepreneur, so I love growing businesses. My wife says I have hobbypreneurs, which just means that even my hobbies are somehow business related or ways of... of making money like I own two bounce houses and love optimizing the sales funnel for renting out these two bounce houses. Brent Peterson (00:58.141) Nice, you could optimize the funnel for getting the kids out. Ben Johnson (01:01.614) That's right. That's right. Yeah. So far, the audience of my bounce houses are, you know, friends and family. But you never know, I could get that random, that random purchase off my Facebook page at some point in time. But yeah, I have a lot of hobbypreneurs. Brent Peterson (01:20.861) That's awesome. Alright, so before we get into content, you have graciously volunteered to be part of the Free Joke Project. And all you have to do is say, should this joke be free or should we bounce it off the show completely? So here we go, and it's guaranteed to be a really good one. A sweater I purchased was picking up static electricity, so I returned it to the store. They gave me another one free of charge. Ben Johnson (01:49.678) Ah, yeah, I don't I don't think that's a keeper. I do think that that comes into dad joke dad joke territory for sure. Definitely should be on the list. I once had dad jokes on command line. So on the anytime I needed a dad joke, I could just hit a command line command and and get a get a dad joke on demand. Brent Peterson (02:16.381) Yeah, that reminds me, I think OpenAPI has a database of dad jokes that you can reference. Ben Johnson (02:22.028) Mm hmm. Yeah, that's exactly what it was. Brent Peterson (02:24.125) Right, perfect. All right, well, let's talk about things more meaningful to business owners. In our green room, I asked you what OKR means. So let's start there. Ben Johnson (02:34.99) So I think what separates an entrepreneur from just about anything else is being purposeful with how you're planning your business. So OKRs are a framework for goal setting. It's one thing to say, hey, I have this. When I learned about OKRs, I actually put my family through them. I know. I would probably get charged for child abuse in some cultures. But what I did is I asked, Hey, what is it what is it that you guys want to achieve? And then how do you know you're you're getting there? And so my oldest son at the time, he said, I want to be a professional video game person. Okay, cool. How are you going to measure that? How do you know you're becoming? I understand that's what you want to be or you want to achieve that goal. That's your objective. But how are you going to know if you're getting there or not? And so he came up with the key result of, well, if I'm playing competitively rather than casually, then I'm at least making some progress or some attempt at being a professional video game person. So he started tracking the number of hours he spent in a competitive league versus the number of hours he was clocking with friends goofing off. And so that would be the objective. The objective is to be a professional video game person. And the key result is, I'm going to go from zero hours of non -professional play to X number, Y number of hours of professional play. That would be your key result. So in business, we talk a lot about KPIs. We talk about how to measure the business. OKRs are just a way of kind of succinctly putting all that together in objective key result. And then you have about three to five as a high level. for the high level company and then each department may cascade down from there how they're going to measure their progress towards those objective key results. For example, you may say, hey, I wanna sell a thousand more widgets, that's your high level one. Sales may look at that and say, well, if we're gonna sell a thousand more widgets, then we really need to see that we're getting 10 ,000 leads a month. So they may... Ben Johnson (04:57.454) talk to the marketing department, and then you may see this other goal of like, hey, we want to do 10 ,000, we want to collect 10 ,000 leads a month in order to hit our goal of selling a thousand widgets. So it brings a data driven culture to the organization to do your goals in this way. And I've just loved working with executive teams and showing them this method. smart goals are an analogy, a very like, adjacent style. And it, I would really recommend like you can read measure what matters, which is the kind of the OKR book. And then smart goals are also there. They're both saying, Hey, let's make our goals measurable, and figure out where we are and where we're going to. It's a common thing. And I think okay, it's just get a little more specific about the data -drivenness and the purposefulness of the goals with the measurement, the objective with the key result. And so learning from that, even if you decide to do a little more React style with smart goals, that learning how to be so data -driven would be helpful. Brent Peterson (06:10.877) Yeah, so I'm a big EOS person and a lot of the listeners are very familiar with EOS. So, okay, I would be very similar to a scorecard item and obviously the goal would be or not maybe be a rock for the quarter. Is that how you'd frame it? Ben Johnson (06:13.74) Mm -hmm. Ben Johnson (06:25.494) Yeah, yeah, that's the EOS terms are great. I didn't learn about this stuff through EOS, but I am familiar. And yeah, you're like, yellow, green, red ranges would all be kind of symbolized by your OKRs exactly. Brent Peterson (06:43.989) Is there a complete framework wrapped around this similar to what EOS, like an open source framework that you can implement? I mean, I've read Traction. I haven't read the book you mentioned earlier, but I am interested. Ben Johnson (06:57.248) Measure What Matters is, I remember the author, he helped Google with this back in the day. So definitely in the software world, we hear a lot about Measure What Matters and OKRs. Lattice is a piece of software that will help you even more so with some of the cascading. EOS is so great and versatile for anything from small business beyond. But Measure What Matters is totally worth the read because it tells good stories. And I always like business books that tell good stories. Brent Peterson (07:35.869) Yeah, I knew that Google had their own sort of framework. So this is the framework that Google would hang on to for their business operating system. Yeah, nice. So tell us a little bit about Particle 41 and how that fits in with what you're doing. Ben Johnson (07:45.678) That's right. Ben Johnson (07:54.382) Yeah, so Particle 41 has four major service lines. We have C2 advisory, software development, and we're especially good at application modernization. So like right now we're working on a COBOL mainframe, bringing it into the modern age. But application development ranges from mobile apps we work on, applications for VR headsets, just a very wide range of applications that we work on. We also do DevOps and then data science. Of course, everybody's buzzing about AI and we have several active AI projects going on. But what we do is put together really good tech teams. And a lot of folks think of outsourcing software development as the asset of manpower, like, hey, I just need some more bodies. But we really take pride in being the asset of skill. So we have a lot of companies with skills gaps and that's where kind of the DevOps and data science come in. Yeah, so we've been doing this for about since 2014, but I'm a serial entrepreneur and I always had a partner that was on the, you know, on the outsourced software engineering side and then eventually he and I partnered up and we've been kind of combining. that C2 advisory and boardroom expertise with a real specialized software development expertise for WAH. Brent Peterson (09:30.301) I just got done with a fractional CTO gig. And the biggest thing that I learned and was I think was what I was able to sort of impart to the client was leaving a good system in place. And what I did, what I feel like I contributed most was just the agile work process and having a way of like a third party development company was a vendor. making them work in the system that the client wanted rather than making the client work in the vendor system. How do you work with that if a client has a different idea of how they wanted to do software development to how you do software development? Ben Johnson (10:12.302) Yeah, I think we're definitely opinionated opinionated may come across as stubborn, I don't think we're stubborn. But definitely opinionated in that we need to have a work list. That work list needs to be processed iteratively. We don't want to have big bangs. So there's some principles that were fairly opinionated on. We you know, we love JIRA. as kind of a tool of choice for managing work. But at the end of the day, we have seen a lot of diversity. And if the client doesn't have something, then we will express our opinions and recommendations. If the client does have something, then obviously we don't want to break or, you know, we don't want to break what's not broken or fix. You get my point. Brent Peterson (11:06.013) Yeah. It oftentimes that I found, especially with legacy clients, probably the ones that are on cobalt, like they may insist they want to work in an agile format. I mean, in a waterfall format, but then they want to get started right away and they don't want to do a bunch of preplanning. They just want to get going, which is in effect going to be agile. And a lot of times it's just how you name it with the client. How do you manage that process of? Maybe it's just nomenclature on what words you're using and how they're running their system. Ben Johnson (11:38.638) Yeah, so on the I kind of think of it as on the executive side. We definitely want to understand what is the commercial outcome. Executives love to see something that looks like a roadmap or a Gantt chart where there's a start and an end and some diamonds where things are kind of coming around. The reality is nobody knows that upfront exactly how that's going to play out, but we at least need to. visualize the goal and so everybody can be associated with the mission. This part of the visualization, like, hey, we're going to work for eight months and we're going to have a release of all this functionality, that starts to feel very waterfolly to folks. But I think the iterative process, so if you're working in two week sprints, the agile process, you still have to be kind of aiming at something. aiming at a commercial result or a commercial target. And so we kind of have those two things working in tandem, or we've said, Hey, what's the schedule? I call it the schedule that you want. And get that from the executives, like what's the outcome you're trying to generate. And then with the tech team who wants to work iteratively and stay away from Big Bang, result sets, you know, then we align to that. But I think both those things are very important. You can't try to be so purely agile that you're not committing to an outcome, say three, four, how many ever sprints down the road. And by doing that, I feel like we've come up with a really good balance of saying, we do understand that you need a commercial result, but we also need to discover as we go and work towards that commercial result through iteration. Brent Peterson (13:30.909) In EOS, there's a way of saying, here's my three, this is what sets me apart from my competition. Typically, there's three things that set you apart, my three uniques. What makes Particle 41 unique from the competition? Ben Johnson (13:48.11) Um, I think it's, uh, so our, our three core values really line up to that. Uh, we, we want to first act in a very visible way. Um, so what that looks like is everybody posts what they're, they, they do kind of a virtual standup. What did I work on today? Making everyday count and being highly visible. So we train it, train our teams and our teams really adopted this idea of like, Hey, I'm proactively communicating. I'm telling you what I'm working on. And we're very flat in that way. We don't funnel information through a single person and have them deliver the TPS report once a week. So visibility is super important to us. And, and then velocity, we know how we know that market competition and speed to market are kind of like two. Factors, the customer needs their things. The customer is the constant. So velocity and moving quickly is super important to us. And then vision. Vision is the third thing. And that's really, vision is the right solution for the proper stage of the company. So vision is acting with quality, building a quality system. but not so much so that you build the perfect system and by the time you're done with it, the market opportunity has already passed. So we really pride ourselves in the correct vision for the solution that matches the company's needs and the market demand. And so we're really having that good vision. And we feel like if we do all three of those Vs, we have a cheeky thing where V cubed equals D. And the D is dependability. We want to be, if there's one thing we want to be known for, that's just being a dependable tech partner and doing what we say we will do. Brent Peterson (15:43.997) I sometimes I wish a tech salespeople would skip the we're going to get this done and whatever you need to get it done. And the client then says, okay, well, we're happy to get it done in six months. Like I think that I love the way that you're framing that, that we're going to have an iterative approach and we're going to get something to market quicker. It'll be a minimum product, but we're going to get it to market quicker and you can start using it. So you don't miss out on that opportunity. That's there already. I think that's such a great approach. Um, Ben Johnson (16:13.422) Yeah, one of my favorite clients is Forte. Forte is definitely worth checking out. It's a online music lesson marketplace. And so you can grab an award winning teacher and they can show you how to play piano or violin. So you can have access to like a teacher that's been trained in Juilliard, but you could be sitting in the Midwest enjoying a music lesson. And their first initial prototype was like 90 days so that we could honor some LOIs that they had with some music schools and help them through the COVID process and try it out and see. So we had an in -lesson experience available for them with earlier versions internally, even at the 30 and 60 day mark. But we were ready to go live in 90 for a limited use case, but a use case nonetheless. and really find out which devices it was working well with, which browsers, and then iterate from there. So they were successful in launching a stopgap measure for COVID, and we were able to deliver something really quickly. Brent Peterson (17:27.357) I love that and I'm really wanting to learn the ukulele. I know how to play piano already, but the ukulele is one thing I'd like to do. And as an older person, it's always hard to find number one, the time and then the finger, the fingers to make it work. I can read music, but anyways, so having said that, how, how do you then help make sure that that whole process is optimized for the tech team? Ben Johnson (17:58.03) Well, I think the optimization goes into a set of playbooks and standards and reference architectures. We don't want to be operating based off our own understanding. The internet's been getting iterated on for 20 years, 30 years. And so there are a lot of patterns and lessons. And so this idea of looking for the best practice or the pattern. before implementing and then collecting those in a community of knowledge is really important in our industry and having those playbooks and things for people to leverage. So it's not a Google search every time. There are people in our organization that have done these things and we're collecting this book of knowledge and sharing it with folks. And you know, because you just don't need to... start from scratch and rediscover all the lessons that are already readily available, even within our 100, we're 100 people, 115 people, even many of the people in our group have the scar tissue to say, hey, this is why we do microservices this way, this is why we use these frameworks. And, you know, just to give people that quick jump of learning to solve the problem accurately. Brent Peterson (19:23.069) Um, I interviewed the CEO of e -techs last year and he talked a lot about making, making merchants or vendors work or work within the system that's there to save money rather than trying to make it custom where you're going to spend 90 % to gain 10%. How do you educate the client on using a framework versus writing the entire thing custom, uh, using something that already exists as a plugin to a system. rather than writing it custom, how do you work through that? Ben Johnson (19:55.502) Yeah, no, that's one of my favorite things. There's two pieces of this that are in our CTO advisory. One is we have a periodic table of business tools. Think of this as like, we kind of lay out a map, like everybody probably needs a CRM of some sort. Everybody needs an accounting system of some sort, like a QuickBooks or a zero accounting or whatever it is. You probably need email. So you're either Gmail or Microsoft. You're probably using some kind of internal message. So we map all that out, and we kind of figure out the lay of the land in terms of there's tool categories, like your liquids, solids, gases, this kind of thing. And just to kind of talk about that IT stack first and say, hey, these are things you already have. And then to set that next to a model of high need versus high value. So high need things. Generally, high need things are well established in the market. I don't know anybody who's going to go make their own email server or make their own computer and host it in their garage or, you know, there's just certain things that are so necessary, like having a computer for things to run on. Having a place to store files, these kind of things, they exist. And so those are like your high need things. And when we have high need, so I put that at the bottom of the diagram, those things, we just want to partner really well, pick the best to breed, you know, top right corner of the Gartner reference chart. And then as we move up, we move up towards high value. And so the highest value things, generally speaking, are the things that make us different between our brand and the customer. These are where customization is probably the most needed. I've seen a few people go grab like a off the shelf product, like a Salesforce or these types of tools and try to customize those all the way to the customer. And that's usually where there's some rub. There'll be some limitations. You know, I can't quite get it to be perfect for the customer. I can't, you know, so. Ben Johnson (22:15.758) That's where we start to talk about, hey, this is probably the place where we want to invest the most. We can integrate and customize some of those platform type of things like Salesforce or NetSuite or whatever, but let's not put that all the way out and just, you know, put all the eggs in the basket of, of customization and partnering. Let's leave a little bit of room for. the truly custom so that we can give that user exactly what they want and truly be different in the market. And so we talk about that user experience and maybe around that user experience later we should be as custom as we can be. Brent Peterson (22:57.031) Um, we haven't talked about AI and you mentioned AI earlier, but do you think that AI is, is making it easier to develop or making it more difficult because maybe the client is trying to do some chat GPT coding on the side. Ben Johnson (23:12.653) Um, I, so I think it's really important for developers to understand what they're doing. Um, what is the code that I'm writing? Uh, even, even just helping to write messaging with, uh, with AI, you know, you can't, you can't kind of get lazy, intellectually lazy, uh, in either respect with the written communication or with the, uh, the coding, um, like a co -pilot. type of environment. It is saving keystrokes like to to get meeting notes to be able to kind of work with an AI on some brainstorming and great tool. But we just can't fall asleep at the wheel and the early adopters who have done that, you know, the lawyer who used AI to write the brief and ended up arguing a fault like a hallucinated case gets disbarred. I think that like, we're still going to be accountable for our output. But in much the same way, calculator helped with math, I do think that AI will continue to help with writing. And, and I'm enjoying using it in that way. But the attention to detail will still have to be there. And you'll still have to very much know what it is that you're doing. you know, in software, you got to be willing to go deep and think those three, four moves ahead and be willing to have that intellectual focus. AI is not going to prevent software developers from having to do that. Brent Peterson (24:52.509) Yeah, I mean, that's such a good point. And I like what you said to be accountable to the output. And I, right now I feel as though people are really getting stuck in a corner, you know, letting things run just on their own. And sometimes that output is garbage. Um, a lot, a lot of times right now it's, it's output is just written, you know, a tweet or a blog post, but, uh, uh, like you said, the lawyer who argued a brief, but didn't edit his, yeah. Edit what was cut, what he had written. via whatever chat, GPT, that is a real danger and you are accountable to that output. If you're looking into 2024, do you see that AI getting exponentially better still in some of these areas? Ben Johnson (25:38.028) I don't know. When we apply AI, we're finding that we're narrowing it. It's helping us arrive at what we want the program to do. We're realizing what we want the program to do. And then we're trying to use AI to do it. We're getting some sloppiness because the AI source information is so wide. And then we're kind of coming back around to a more literal solution. So. I think a lot of folks that are saying, oh, let's use AI for that are going to, they're going to learn something from the failure, the AI could really help with this. And then they're going to go like, okay, no, we're just going to have to program these, this five step process in the most literal way so that we can get the accuracy that we wanted. So I think that's just going to be, people will try to apply the AI models and then either, narrow it so much so that they just come up with a straightforward solution. And I think we're still very much at the beginning for how it's going to be applied and how it'll be leveraged. But the learning set is so wide that I don't know how, like in the legal case, which is another use case we're working on, we're really narrowing it down to say, Hey, this is a set of contracts that we've written, we want to output contracts like this, take that very narrow set. And then by the end of the day, you're basically saying, well, you should have just written this paragraph, here's the paragraph, just write this one every time. So I don't know if that made sense. But the narrowing is a thing where you're you're almost arriving back at a literal solution, rather than a generated one a thought about. Brent Peterson (27:28.571) Yeah, I think. Yep. Yeah. I would agree that using the use cases right now anyways, more of a, of a, take small little pieces to get you some help rather than trying to do the whole thing in one big chunk. And I can definitely say that, you know, the, the hallucinations of things like that happen. And even in the text to the text to voice, my experience has been later on in that longer conversation, the, the text to voice gets lazy and. it maybe starts mispronouncing words that in the beginning it said the right way. So I think there's a lot of things to come down the line. So as I close out the podcast, I give everybody a chance to do a shameless plug. What would you like to plug today? Ben Johnson (28:20.686) Oh, shameless plug. I would just say if you're a business owner or entrepreneur and you want to collaborate on anything, say you did a digital transformation back in 2015 that's starting to shoot sparks, one of the things we say is we fix slow. So if something's going on, whether it be slow team delivery or slow applications, we love to people help fix slow. So look me up. I'm very easy to find. on LinkedIn and you can book an appointment with me straight through our website at particle41 .com. Yeah, I love to collaborate, so don't be afraid to reach out. Brent Peterson (29:01.533) That's great. And I'll make sure I get those those contact details in the show notes. Ben Johnson, the CEO and founder of Particle 41. Thank you so much for being here today. Ben Johnson (29:12.43) Yeah, thanks man, it was fun.