Latest / You've Been Heard / 408- Your Career Isn't Defined By Technology w/Stephen Chen

Transcript

408- Your Career Isn't Defined By Technology w/Stephen Chen · You've Been Heard

• 0:09
  Speaker A: Everyone out there listening to you've been heard. We're talking with Stephen Chen and the better half of the technology world. Forget basketball, you got to have basketball and technology. You can't have basketball without technology. Guarantee it. I guarantee you basketball would not be where it's at without technology. So let's go back in time. How'd you get started in this gig now?
• 0:29
  Speaker B: Absolutely. Basketball in technology. I was at a Warriors game a couple weeks ago, right, replays. Now they have actually replays. That takes it down to the nanosecond or milliseconds to actually truly find what, what might be wrong. So you're absolutely right. Not just basketball, but pretty much anything right now you have technology involved in it. So how I started it was really interesting. I mean I got interested in kind of computers, was actually in the lab with my dad, so I was probably 10, 11 and my dad was getting his graduate degree and there was a couple of computers in his lab and I don't quite know what that was and there was actually another of his colleague in there and he was doing some research, was doing some computing and kind of showed me at that point in time it was initially I think was a x86 like IBM compatible kind of computer and I started doing programming in basic. I, I still kind of remember I did hello World loop. Then it's like oh this, this is actually pretty cool. So I've always taken like the technology and computers and that's really where I, I kind of got started.
• 1:42
  Speaker A: Okay, this is great. This comes across your desk when it comes to AI adoption in your organization it's not even AI adoption, it's really more AI planning, AI road mapping, AI expectations from C level executives, board members, whatever it is. When it comes to AI as a cto, cio, IT leader in your organization, what is your single biggest frustration, problem or concern?
• 2:07
  Speaker B: I think at least for me right now, I think there's just a lot of interest and pressure to say you have to get AI in somewhere and from before it's more about adopting kind of some gen AI stuff from a user perspective now to eventually you got to have something in your process for automation to not agentic and things like that. I think just unnecessary urgency trying to rush into AI adoption on the back end of it. I do think that within a year or so there's going to be more and more data desire to look at AI governance, it's going to look at AI from a security perspective. Especially now people are looking at agentic AI. End of the day they Behave like a user. And one thing I find that it's going to be very interesting is how do you detect agents as for a potential insider threat? So we go through a lot of trainings for our employees to make sure that they understand what material or data they're touching, how they behave. But in the rush to get agentic AI to do automation, I feel like there's not enough energy and rigor spent on how do you secure agentic AI before it something catastrophic happens. So that's one thing is you could say it's a frustration, but it's also a balance that I am trying to figure out. How to adopt AI in such a way that we don't put the enterprise and the business at risk.
• 3:41
  Speaker A: Can you give me an example of a question that you would look like, is this a good response? Or can you give me an example of what you were talking about? Most IT leaders don't have an Internet problem. They have a management problem. Multiple locations, multiple providers, multiple bills, different contracts. We help IT leaders make Internet boring again by consolidating visibility, billing, support and monitoring without changing providers or forcing upgrades. If nothing needs fixing, we'll tell you that's vendor neutral advisory. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save.
• 4:19
  Speaker B: So for example, a very typical one is going to ask you about your password policy right then, then right? So like a security assessment from a client. What is your password policy look like? What's the length, what's the complexity? How often do you change it? Who have access? Is there a different level depending on the access you have and that. Right, I know the questions, but I won't be able to know the answers off top of my head every single time. And a bot will actually give me very accurately what exactly is like I
• 4:53
  Speaker A: said this in the last 50 and it's all kind of the same, but not really the same. Is that what you're saying like your answer?
• 4:59
  Speaker B: Yeah, well I mean I say a different way and then the answer kind of evolved over time, right? So like perhaps the complexity used to include special characters, words and stuff like that. And then that's one way to look at it. And the other way to say is a lot of company has gone from just password complexity to path phrase to password less. And so having that knowledge base allows me to explain how our policy actually evolved versus just answering the question.
• 5:29
  Speaker A: Okay, this is great. So like when I looked at all these different vendors, we ended up breaking it down to like eight different Categories. For an mssp, it was like remediation, price versus value, like EDR technology, proactive detection, response speed, security awareness, email security, vendor accountability. Like, I mean, when you go deep into the security assessments, it can get like really deep, like what you're talking about, which is what I really like. But what we realized was that a lot of people, in their terms and conditions, this is when we looked at them, a lot of people will say, yes, we guarantee response within, I don't know, 15 minutes or instant response or whatever it is, right? And then a lot of clients don't realize they think response means remediation. We were finding out how many people think response means remission. They think, oh, they're responding. No, that's not. No, they're just responding. Yeah, they're not remediating anything. And we've had people, they were like, oh, yeah, we're. And I've just talked with just kind of like on the side in general. They're like, yeah, we're gonna go with these guys. It's great. They've got all this, that and that. And I was like, oh, cool. Let me throw it through our. Let me throw it through our, like, whatever. 100 points, 800 categories scored across. This is which we built like a really long prompt, right? Like all these different details and skills and add in this skill and we have all these skills saved. And now we've got this like security MSSP prompt. Then we've got all these different articles that we wrote and we put that and then we break it down into this. And what we realized is like, hey, we took those 10 pages of this and that and we put it weighted up against all of our other guys. And did you realize that they're not providing any remediation, like at all? Like zero, like zero remediation. They're like, what?
• 7:15
  Speaker B: They just, they just tell you that you have a problem and here's the problem. And they yet to probably see you later.
• 7:20
  Speaker A: Like, have a nice day. Like, and they're like, no, I'm like, yeah, I like, I'm like, it's right here on page 7.6.5 in highlighted. Whatever it says. Like, which is. That's a simple thing. Like, everyone should be taking their T's and C's and putting it into. And have a good. And this is just the basic stuff. This is just like, right. This is just LLM stuff. Let alone like creating a bot that's going to do different things. Like, we have a few things running on a completely separate machine testing things Out. And I was shocked at. One of the problems we have is like when we run a Kanban board and we're doing like a scrum thing, right, we might have all these projects going on at one time and then what's like some of the biggest problem? Well, if you have two people that get really excited about a bunch of things and you've got other projects going on at one time. One of the things that we found when you have a small kind of niche team is that people aren't always going into the Kanban board and updating different things or you don't always have your daily standup meetings or they end up going. They draw on into too long and decide topics and all these different things. So we literally have like the cloudbot thing that's like just constantly going back and forth with people in a like a special messenger that's like going back and forth and updating the team and everything and then updating the Kanban board like automatically so that it stays up to date. So then when you get into a meeting it's like, oh, it's all up to date. And like now we can actually see where we're at and where the. And it'll be like, this isn't. And then like the bot will remind you like, hey, this is not the main challenge right now. We're supposed to be staying on target with like this one challenge which is like two laser focused like podcasts a day. In fact, I should probably have it talking to me right now. Like, Phil, you're going way off subject. You're not even on topic today. It should be talking to me like this. But I'm just that leap over the last, I would say last two weeks, we didn't have that.
• 9:13
  Speaker B: I see, I see.
• 9:14
  Speaker A: That's how fast AI is growing. And you got, then you know, you got these guardrails and someone else is gonna be like, oh, this is gonna be so great. I could use it for our taxes. It could be our own accountant. And then next thing you know, it's like there's data everywhere and all kinds of craziness. Yeah.
• 9:25
  Speaker B: So when I look at. Yeah, you, you mentioned about mssp very interestingly, I actually moved away from mssp. The reason why it's a little bit what you're talking about that the tools that's out there now, Kaseya, The SolarWinds or Netwise, they're so sophisticated that you just run those tool. It will give you a lot of information and that you need. Right. You have this problem you have this alerts you need to your patch automated. I'm connected to whichever vulnerability and get it it would deploy all that stuff. Now the biggest difference for me for MSP is actually that service level.
• 10:04
  Speaker A: Right.
• 10:06
  Speaker B: And trying to. You mentioned about. Well they. They tell you. Yeah, yeah, yeah. So I'm actually looking for that experience in remediation. That experience when there's actually an issue how fast can you alert me and how fast act on it. Right. And so that's the key thing for me. And then at least for my business I decided to move away from MSP and use them as needed basis. Because these tools is giving me almost 80, 90% of the things.
• 10:37
  Speaker A: What do they really do? They manage all your tools. So you get it in one bill in one place.
• 10:42
  Speaker B: Yeah.
• 10:43
  Speaker A: And they kind of do them managing and monitoring. Maybe give you like a nice GUI platform, whatever they want to use to manage everything.
• 10:50
  Speaker B: Yeah, but. But it's actually talking to the people that when you have an issue call them up and. And those people have the experience to say ah, I have seen this before. We have this in our knowledge base that to me is the differentiator that you often don't see. You kind of like a evaluation criteria. Right. Because that's.
• 11:10
  Speaker A: We call it that big mean the big R. The big. The big R matters Remediation like. Cause if you're a one let's say because there actually are one man. It shops out there with a thousand users. Yeah, I see it. There's one guy, he's got a thousand, so he's got to rely on an MSP and then the MSP is going to tell him well we can do the MSSP piece at the same time and which obviously you should not do. But like if you're like a one man shop, no matter how smart you are, even if you are the best ciso, you're CISO number one. That's at your heart and core. But you're also the CTO or whatever and an event does happen, you want to be able to rely on someone that's going to remediate that and stop it and cut everything off immediately. Like. Like immediate action numbers and acting nice and speaking nice as a subject matter expert and all that stuff is really, really good. But yeah, numbers don't lie. People lie.
• 12:02
  Speaker B: Y. Yeah, I. I'll say in addition to the. The big R remediation it's also aversion or. Or prevention that there are patterns that. That can be detected that before you get to the point where you. You're getting have issues that is start telling you that hey, you're headed in the danger direction and you should be thinking about those things. So I love to always talk to my team that we don't want to get to the remediation where we can. We wanted to kind of avert it or minimize it so that you don't really get to that point and so that you're trying to stay ahead. Yes. I also mentioned one other thing for you, Bill. You mentioned that with some of the AI stuff, especially from a RFP perspective, MSP vendors might hate how fast AI can actually digest and kind of interpret some of the responses. In my other world where, where I actually tried to do sales software, we actually use it from another direction where we built based on the RFP question, we built Persona. So for example for you Phil, if I go on the Internet look for on your LinkedIn profile, I will be able to build a profile for you in AI and then I will actually try to sell you the product that I'm selling. So I'm using that to train my sales team to actually say, hey, you have these different personnel. Here's the role that you play or here's your experience. I'm selling into a university, I'm selling into R and D organization, I'm selling into E commerce environment. You could build that Persona and then have your sales if and only if
• 13:37
  Speaker A: you actually have like the actual product anyways.
• 13:39
  Speaker B: And yeah.
• 13:41
  Speaker A: So what part of your role fires you up the most? Like what's the real exciting part is
• 13:46
  Speaker B: actually I think I, I'll at the highest level, I think this question is related to how also how I transition from really a developer to kind of more in the a business leader is actually that ability to actually do what I call the translation. Right. I know that in my background I've been to huge companies and also start companies and that ability to actually translate a business need and then make that into a technical solution, that's something that I'm always very interesting and then be able to kind of explain it back to the business user, say how is this going to help you? How is it going to solve your pain? And then when they go, oh, this is it, this is what I really need and I think be able to be that bridge has always been something that I pride myself in and it's something that still very much excite me from a business world, from a technology world. Right. I get excited about technologies and I just like to try different things. Some of the developer I work with only like that to actually understand what exactly is a user looking for versus someone translated that into a product requirement or a ticket and things like that. So, so that's one the other I think experience.
• 15:06
  Speaker A: I think I thought of an example by the way. I think.
• 15:08
  Speaker B: Okay, go, go ahead, go ahead.
• 15:10
  Speaker A: Just because you're in software and we're. We were talking about salespeople earlier, right? So let's use Salesforce as an example because they're one of the companies that I believe is going to go under with all of the coding. Like this is my prediction. Salesforce will not be much of a company anymore in the future. This is my prediction. I have a prediction that we're not going to need Ms. Whatever side software companies that charge you $20,000 to implement Salesforce. I just don't think that. Well, any salesperson out there knows that their sales manager is asking them to enter information into Salesforce. And does the sales rep really want to be entering information into Salesforce? No, they do not. Nowadays might be different because we have AI. It's probably just take notes form and enter it. And that's a whole nother discussion. From a call center contact center standpoint, it's going to collect all information the sales rep said and do it for them anyways. Great. We have solved that problem. That is an AI use case that's actually solved big time and eliminating census calls. That's something that an AI agent actually can do very, very well from a healthcare standpoint. Id so this is kind of like the, the metaphor for the software engineer not really understanding what the sales, what the end user needs. Because what does the sales manager want? The sales manager wants reporting. He wants to know how many calls the sales rep made, how many deals are in the funnel, what's your forecast for the month. All of this stuff does not help the sales rep make another sale at all. But it's important information that they have to enter into Salesforce and if they do not enter that into Salesforce, they will get a demerit or something. I don't know. But if the sales manager was actually delivering and asking the sales rep to do something or give them something that actually helped them sell more deals and do a lot better. And if sales Salesforce actually helped them do that, which I don't know if it does, I don't think it does other than it helps a really disorganized person, which a lot of salespeople are very disorganized, then in that case it might actually help them forecast and follow up on deals. More and give them reminders and all that type of stuff. But for the. Did you see, where am I going? Am I getting it?
• 17:24
  Speaker B: I understand what you're saying. I understand what you're saying. Yeah.
• 17:27
  Speaker A: So a software developer should be thinking about how do we help the sales reps make more sales and what do they really want in this software? Not what is the sales manager telling me I have to build into the software?
• 17:40
  Speaker B: Yep.
• 17:41
  Speaker A: Okay. What other examples are Anything in the logistics industry or manufacturing or what's another really good example of where you saw where you were like, yeah, we got it, guys. We're not asking the right questions. We're not talking to the right people.
• 17:53
  Speaker B: Yeah, I mean, so let me address one thing that you just mentioned. Software developers. Slowly. I don't look at my software folks as software developers. We start using the term software orchestrators. So they're actually orchestrating. They're looking at how to put requirement in such a way that you could actually feed it directly into the software.
• 18:17
  Speaker A: Okay, that's better. All right, so let's hit a few more meaty questions. And this is going to be.
• 18:23
  Speaker B: Let me also come back what you mentioned. I do have an example that you mentioned, finding out who the true end user are. That's something I, I feel like I've learned through failures where in many companies where management, sometimes you talk to them and they represent the users and this one case where the leaders completely misunderstood or completely misrepresented the end users, that even though as a company we built exactly what was wanted, what was needed, but when they actually deployed to the end users, it wasn't what they needed. All right. And so that gave me a really good lesson to actually ask a lot of questions up front so that you actually pinpoint who is actually ultimately going to be using the system and knowing that what they need is actually very important, not necessarily their representative think that they need.
• 19:21
  Speaker A: Can we role play that right now let's fire off some of the questions. How would you dig in? And I bet you, you could do the same thing like you did with the security. You could do with this as well. And we could come up with a really, really good. What do your end users really need?
• 19:36
  Speaker B: Yeah, so I mean, I start by asking about, have you used the system right? And what's your role in the system? And tell me about some of the challenges that you are seeing in the system today and what functionality are you looking for that is not there? Now when you start asking these questions, you start detecting whether or not someone really knows the system or they're reading from some script or some documents because you'd be able to go in and go, I went into the system, I click on this thing and on, on this page there, there's that functionality that's not working. And so that's where you wanted to kind of separate the people who are actually think they know what the system should do versus the people that's really using the system and trying to figure out what functionality, what need they are. Or in that case we're actually building something new. Right. So you could come from it. In that case, from an operation perspective, what does your day to day look like? What does your workflow look like? Right. Those are the people that, who ultimately is going to end up benefiting from a automation on the system, not the managers who's looking at, at some metrics and things like that. So I think it is actually digging into the kind of daily operation, whether that's actually using the system or kind of their workflow and their pain point that allows you, allows me to actually pull out those key things that ultimately contribute to developing the right solution.
• 21:08
  Speaker A: Okay, what is the definition of done? I love that so much because it's like how many times do we start projects and we, we don't know if it's done but we move on to something else and then something comes back and we got to fix it or we got to do something else and we kind of keep, we have these open loops, so to speak.
• 21:31
  Speaker B: Yeah.
• 21:32
  Speaker A: And every time you have an open loop, it creates stress and it creates work and things come up out of nowhere. And I think that that's where really it kind of dies in the soul of it.
• 21:44
  Speaker B: Like it's important to make sure that you set the expectation and people are aligned on what that expectation definition of done. That's important. I mean, I'm going through a project right now with a vendor and in our definition of done is not the same. Right. In oral, that means your time's up, your budget is up. But is the solution truly delivered? It's not. So you're so right that you gotta make sure that everybody's aligned what done look like and that both sides are working towards that.
• 22:22
  Speaker A: If you don't mind me asking, how far off are they on their definition of done? And you are off on their definition
• 22:29
  Speaker B: ultimately. Right. There's always some financial aspect of things that I think the first thing people go back to is really what the sal. Where the contract says and then you start interpreting it and there, there's some Give and take. So in the end of it was that both side have to give and take a little bit. And our interpretation was even though the word says what the word says, but our interpretation was different. So it does take time and cycle and in this case casualties, meaning that we ended up replacing some the project manager on the project and kind of bring a new person and then now we're aligned. Now we literally said this is what this means and we're going to record it, you're going to transcribe, you're going to have the transcript and this is where we're going to look for to completion. So I think we were, I don't, I won't say that we're way off, but we were far enough apart that everything ended up getting escalated on both sides.
• 23:31
  Speaker A: Realignment call. Yeah, we're going to be on an open. What are they called back in the day? Open bridge line. For the next two weeks though. What's the worst of this ever that you've experienced? I think that's very important internally as well. So where does this show up the most? Where I see this showing up the most is in ERP deployments. Right. It's the definition of done is not clear. So the definition of done to the CEO is different than the definition of done to the cto, which is different from the vendor as well. So the definition of done for the CTO is. Well, ERP is deployed. End users are using it. We have all the additional add ons and different deployments and API things that we needed to add on that we said we were going to add on six months later, after the first deployment. Six months after the first deployment. But after the first six months the CEO is like, we're done. Awesome. Cross that one off the list. And you're like, we're not done. So I think things. Yeah, this, this definition of done. So important. Okay, what's the most important idea you wish every executive would understand about modern IT? Or turn to page 34. What do most CIOs get wrong that you think is obvious?
• 24:43
  Speaker B: I'll say this, I mean this is a little bit of my takeaway as well, that whether you're a CIO or executive, especially in this day and age, don't look at it as a vertical department, but look at it as a horizontal capability that cuts across everything.
• 25:06
  Speaker A: He's smart with the business, isn't just my guess, I don't really know. And then, yeah, Zuckerberg, there's something about that video of him like in his little underneath his bunk bed and he's on his old computer and his dad comes in, he's. He's like, I got in. Or someone's like, I got into Harvard.
• 25:23
  Speaker B: Like, oh, yeah, of course.
• 25:24
  Speaker A: Like, it's like, like I went to school with those type of kids. And to me that the fact that he is. It's just amazing, like what happens when these people, like get control. How are we still calling the department of IT and tell them we've signed off on this new system, we need them to implement it by March 1st.
• 25:46
  Speaker B: But I think some of that challenge, we many IT leaders do it to ourselves.
• 25:52
  Speaker A: Oh, that's.
• 25:53
  Speaker B: Yeah, that, that's. I mentioned about translations. Right. So a lot of us gets very excited. Then we start talking to our colleagues at business side about what AI could do for you cloud all these things. And they're like, we need it.
• 26:07
  Speaker A: But are we really saying, like, look, we need it because this. And it's going to result in this. And I promise it, or at least some sort of level of growth and not maybe not promise, but like business, like real hardcore business. And I think that's kind of the gap.
• 26:23
  Speaker B: I tend to agree. Right. I think having the right KPIs or metrics, that's against. Speak to the right stakeholders, whether that's the board, the C level or operation leaders, that having the right metrics that speaks to them is very important. Instead of uptimes performance level and things like. That's more of a kind of IT speak and be able to translate at the same time. Uptime is user experience. This is how much user experience is going to look like. Performance means your operation team will be able to actually have access to the system all the time, that you're able to actually run this report, make your decisions. Those kind of things I think are very.
• 27:06
  Speaker A: We expect that that's the bare minimum. Uptime, it better be up.
• 27:11
  Speaker B: Yep, absolutely. When you don't talk about that. Right. So that's why you don't need to talk about that, because that's part of my internal measurements. But again, it's. How does that translate into client experience? Right. How does that mean that by the system being up, does that translate more into revenue? Does that mean there's more business coming in? Those kind of things that allows different departments to actually appreciate uptime a lot more versus it should be up?
• 27:39
  Speaker A: Yeah. And it just goes both ways. It's really about it forcing that conversation with executive management of what's really going to move the needle and being able to coach executive management we're sitting at the same table. The point is we don't want to just have a seat. That's nice. We actually want to be heard and listened to and respected, right? Well, we might be respected, whatever. But it's like we have a seat at the executive roundtable. That's nice. How much nicer is it to be heard? So how do we actually be heard? And it's kind of like, how are we teaching? We sit on these meetings. We kind of know what the general the goals are for the year, this, that, everything. But are we really, like, close business partners with the business, and are we asking the right questions to get them to deliver to us what we really need to build or make happen to move the needle? It can be very challenging. I just know from my own personal experience it can be very challenging because there's numerous times I talk about things, and for some reason, technology guys think that it's this or it's that and it's like a fight. But it could be one little tiny thing that one little tiny difference that would make all the difference in the world. It's like, oh, okay, you need this in Salesforce, and you need this in Salesforce, and you need this in Salesforce. Okay, great. But the other IT guy asked one better question.
• 29:01
  Speaker B: Yeah.
• 29:02
  Speaker A: And he implemented AI to sift and sort all contacts in Salesforce every 24 hours to see if there was any shift in the marketplace or if they changed jobs or they did anything within the last 90 days or whatever and how that would affect a deal in the pipeline or anything. I mean, Zoom Info kind of like did that with their, like, insights and stuff like that.
• 29:29
  Speaker B: In many ways, I differentiate business requirement from technical requirements. And when the user kind of tells you, hey, I need this field or I need this extra thing here, that in some way becomes a technical requirement. And that's limited or myopic in a bigger scope. I would rather come back to kind of what you said. What is the business objective you're trying to achieve? Let me help you decide whether adding a field makes sense or is there an AI solution out there that will get you there? And a lot more. So there. There's that line of kind of trying to figure out when is it a technical requirement that what I need to get. Get it done, or you ask a question to move it upstream to say, what exactly is the business value or the business requirement that you have, and then let me kind of design that solution. And that could be a form, a feel, a report, or some sort of AI Thing in many ways, actually, developers actually like that so that they could be creative versus be told that your job is to create this webpage or put this form together. But to say, hey, there's this problem that think through, and then let's talk about two or three options and then we'll pick one from there, or at least we'll start with those.
• 30:49
  Speaker A: I think that's the paradigm shift I was looking for. Yeah, I think that's it. Which is weird because a lot of business leaders have to be entrepreneurs or very creative and kind of like make something out of nothing. I just quote, I remember from years ago, like, go out, make someone out of nothing today. And yet we're treating the something that we made out of nothing. Like we're gonna just then, oh, but now we need to buy a product for this. And we feel, to your point, very myopic about how we're going about and choosing the piece. Like we're not also then sending that same feeling of solving this problem and making something out of this problem over to our team and trusting them to come up with the best way to do it. So what I've noticed is that a lot of times when we force the solution, we're like, hey, here it is. Here's the solution. We end up with kind of like a lot of broken pieces. Whereas if we actually handed the problem over to the IT guys to begin with, then it wouldn't have had those issues. Yeah, that sounds very vague. Yeah. So engage your IT team with the challenges and problems and get them involved early. And we've been saying this for years, but like, it's kind of like, what does that really mean? It's like, don't just give them the solution to implement. I know that sounds dumb because we've been talking about this forever, but give them the actual problem to solve. But is there anything more to it than that? Is there like a deeper iteration? Is there anything there to help kind of bring the two together better? Is there? And the end goal is this. And by the way, what we're trying to achieve is this,
• 32:26
  Speaker B: I would say, trust that you built. Right? You have to kind of prove yourself and kind of develop that relationship so that the business will kind of open up, right? And they will come to you early with the problem and the challenge they're facing so that you could be brainstorming, partner with them and that. That if you're able to successful doing that, to build that relationship, build that trust, then your probability of success goes a lot higher. Because now you're actually in a partnership where you're, you're trusted confidant in, in. In saying that we need you to actually help us solve this problem. I, I could see based on our discussions, how it is kind of leading and kind of collaborating to actually come up with the right solution.
• 33:15
  Speaker A: And the craziness of all this, that may actually eliminate the. We have so many projects on our plate right now that we couldn't possibly finish them all by 2100. Yep. Is that right? 2020? Yeah. 2100. It's impossible. There's so many projects right now. There's no way, so. And why is that? Because everyone. And everyone's throwing something that they think that they need at it, but they're not trusting them with the problem. I need a screwdriver. I need a hammer. I need whatever this tool is. And you're like, well, what are you trying to do? Well, I need a hole in this wall. It's like, okay, the screwdriver might be right for that. What do you need the hammer for? It's like, who knows? I need to go do this. And you're like, no, no, no, that's not what you. You have a different problem. So I. It. How does that make sense? How does that eliminate all the different problems? It eliminates all the problems because if you trust IT guys to help you solve the problems, most likely you will trust them with kind of the goals and aspirations of the business as well, and they should be good enough. And I'm hoping everyone listens to this very, very strongly. And I hope, I don't know whether you agree or not. Let me know. You should have a good enough environment or a healthy enough environment that your IT team should be able to tell you. I don't think this is a priority for you right now because how does this lead to selling at once we reach $1 billion? Or how does this lead to our main goal of producing two times more widgets this year? We have to solve this other problem first. And this one's kind of like a little side project. And I really appreciate you bringing this here and I think we could really knock it out of the park. But are you sure you want to do this right now? Whereas do you think most IT project, I just. If you don't have that relationship going on, then they're just going to be like, oh, we better say yes or we're going to lose our jobs.
• 35:08
  Speaker B: Yeah. So I've been at my current company for seven years now, and I was brought in to do digital transformation Right. And when you think of digital transformation, you think of technology. But the reality is if I look at 80, 20 rule or 80 to 90% of this digital transformation effort, it's not really about technology, it's really about culture and change management. How do you change that? Because when you come in and you say, we got to put in new system, it might be the right thing to do, but there's going to be a lot of fear, a lot of kind of pushbacks. And so a lot of it is about culture. As you mentioned, that to have a relationship, to say, we don't need this, you don't need this, we could help you do something different. And then people are willing to open up, to actually have a dialogue with you, to say, I really hate the system. And. But I think if you can help me solve this problem, that's my priority. And you start building that trust, building that relationship. And so I think a lot of my early time with the company in digital transformation is not about technology. It's all about understanding the culture, how to evolve that and building that relationship so that people understand when change comes along, why. And they're part of it.
• 36:23
  Speaker A: Yes. I mean, that's it. That's it. Just as a foreshadowing to a future event, AI Roundtable is security. And that, like we talked about, like, what's your single biggest frustration problem concern when it comes to AI? And well, we had Benny Zhang on the show a while back. He's a cio and so he's like, yes, I'm totally in, let's do it. He's like, by the way, read my new article, Digital transformation is dead. So everyone out there, Digital transformation is dead. Never mind that our community is a Digital transformation leaders rebranded. As you've been heard, never dead. Anyways, it's good. We're going to welcome AI RE Engineering. So that's a call out to you, Benny Zhang. So if everyone wants to find. Find Benny Zhang on LinkedIn and read his digital transformation is dead. Welcome AI re engineering. Let's go. He has two comments. And let's see if we can make it big right now and re reshare his article and make it go big. But he's going to join that roundtable. So, yeah, Stephen Chen, been an absolute pleasure having you on the show. And, and I wanted to ask you what is that big disconnect between IT and C and C level leadership? But I think we already answered that and that is this. It's not an us versus them. It's part C level Leadership, trusting it to have those conversations, to hand off the, to hand off the problem to them, not the solution. Because maybe IT and technology guys that have labs in their house and are very curious individuals that have been playing with this stuff all their lives might actually get more excited and do a better job when you give them the problem, not the solution, that's going to create more problems to begin with. And then, yeah, IT guys, what, what is it for us? What do we have to change? I can't remember, is it we have to, like, come out of the cloud server closet where there were solo teachers under the door to us?
• 38:13
  Speaker B: Yeah, I, I think translation. Yeah. So, I mean, when I look at it, right, So I, I, I know one of the things that we're talking about, if you're a aspiring leader, right. I, I, I think your career, my career is not defined by your technical ability or technical choice. It's going to be the, the business problem that you choose to own, right? So I think your technical ability gets in the room, but your ability to translate business complexity into kind of technical solutions will kind of get you a seat at the table. So I think if I use that as a takeaway, that's something that I stand by and something that even talking with you, Phil, today, it's very enlightening to learn and hear from yourself and the community.
• 38:58
  Speaker A: That's a mic drop. That's one of the best quotes I've ever heard. It's the business problem you choose to own. Is that it? Did I get it right? Yep, that, that's it, man. You got any other great ones? What else are you hiding away from us? We've been talking for an hour and a half. What are you hiding? What else are you hiding?
• 39:12
  Speaker B: No, no. Again, I think some of the initial material that you shared really kind of inspire me and to actually prep and things like that. But I really do appreciate the opportunity to exchange and be part of the community because I know that I got a lot of stuff to learn and there's lots of great, smart people and great leaders out there.
• 39:31
  Speaker A: Steven Chen, you've been heard.