Show Notes
In this episode of the Tactics for Tech Leadership Podcast, Mon-Chaio and Andy discuss common questions that CFOs, CEOs, and other stakeholders should pose to the technical leaders within their organizations. Based on a blog post from payslip.com, the discussion focuses on how CFOs can inquire about tech investments’ cost efficiency, agility, flexibility, and security. The conversation emphasizes developing thoughtful questioning processes and the importance of mutual understanding between roles.
References
- Tech Questions a CFO Should Be Asking – https://payslip.com/resources/blog/tech-questions-a-cfo-should-be-asking/
Transcript
Andy: Alright, we’re here for another episode of the Tactics for Tech Leadership Podcast. This time what we’re gonna try is are there questions, common questions that a CEO or CFO or some other stakeholder might have that as a lead or manager or CTO of a technical organization, you might get asked and you might need to answer. We’ve kind of done this a little bit in the past Mon-Chaio, but this time it’s really focused on a particular article. And in this case, that article is from the blog of payslip.com where they, they say, what are questions that the CFO should be asking about the tech of their organization.
Mon-Chaio: Mm-hmm.
Andy: So let’s get into this.
Mon-Chaio: And like all of these, we will link it in the show notes so that you will have it, uh, because obviously we won’t be talking through the entire article or every little thing. The title of this blog post is Tech Questions A CFO Should Be Asking. So maybe we could start there, Andy, just with the title.
Without going into the article, what do we think are the types of tech questions A, CFO should be asking, if any?
Andy: I think that, I think that they should be asking tech questions. I would expect that they’re gonna be asking tech questions much more focused about the impact that decisions of the tech organization are going to have on the financial, uh, financial, uh, health of the organization, of the
Mon-Chaio: Mm-hmm.
Andy: and, and I guess they should, they should really be looking at it from the standpoint of what are the important things that could impact that?
What, what kind of information could they gather that would change the financial health of the company?
Mon-Chaio: The thing I think about, Andy, is you nailed it on the head, which is what are they gonna do with the answers to these questions, right?
So what sort of expertise does a CFO or any stakeholder who’s asking these questions have in order to be able to evaluate the answers? So generally speaking, and then I think, you know, then maybe that’ll be a great way to start to dive into some of the examples in the article. Generally speaking, I think the CFO should be asking questions as a way to raise thoughtful thinking processes to the CTO that the CTO might be missing, instead of evaluating the concepts of the answers in order to determine whether they’re valid.
We kind of talked about this a little bit, Andy, when we talked about the how do you have accountability? Accountability without knowing episode. Do you remember that?
Andy: Yep.
Mon-Chaio: And in that episode, it was the other way around. It was how does the CTO hold other functions accountable when you can’t understand what finance is talking about?
They’re talking about all these models, you’re like, I don’t know. Or they’re talking about GAAP accounting principles. You’re like, do I now have to be a CPA in order to be able to understand whether what you’re saying is true or false or you need more data, or whatever the case may be. And I think this is just the other way around.
So questions that I think the CFO should be asking is, you know, what are some of the metrics that you’re using to ensure that we’re spending money in the right way?
Andy: Okay.
Mon-Chaio: How are you connecting your product roadmap to revenue. And the answer isn’t so much like, oh, well this feature’s gonna deliver this much revenue.
It’s like, no, I don’t think you did this right, because like when you thought about it, you didn’t take into account market conditions. Because I don’t think a CFO can get into the weeds like that, but it’s to raise questions and it’s, it’s kind of like a briefing back briefing thing, right?
And one thing I talk a lot about when I talk about briefing, back briefing, and I don’t know if you do as well, I think it’s kind of central to the topic in my mind, but there’s a lot of different ways to do it, right? Is it’s not so much the details of the answer, the tactics of the answer in the back briefing that interests you.
It’s the, what would I call it? It’s the, um. It’s the general feeling and sense of the answer. Right. It’s
Andy: it’s the sense of are we talking about the same
Mon-Chaio: Right, right. That’s a really good way to put it. And so I might not agree with all of the things you say. I’m like, no, that’s not what I would do. I wouldn’t look at that number or whatever. But that’s not what I’m focused on. I’m focused on, oh, you understand the problem the way I understand the problem.
And then you are now looking at it in the same way. Um, and then you have that level of trust. So that’s kind of how I think about CFOs and anybody really. Asking questions from the stakeholder perspective.
Andy: And so I think, I think as we go through, and it’s only three questions that I think they outline here, uh, as we go through these, I think maybe that’s the, the lens that we should be looking at it with, is it growing that accountability between the sides and is it helping ensure that in asking this question and in evaluating what you hear back that you are, that you are getting confidence that you’re actually talking about the same thing.
You may not agree about your assessment of it or things like that, and that’s a possibility of further conversation, but you need to check, are we even talking about the same thing?
Mon-Chaio: That’s exactly right. I feel like when I read this blog article, the questions themselves made reasonable sense at times, but I think the details, um, are where I think I’ve had a little bit of trouble with this blog article.
So the first one they mentioned, uh, as a high level question is, are tech investments cost efficient? So, I mean, I think everyone can agree that we, that as it’s senior leader in technology, you need to make sure that’re cost efficient.
If what you’re doing is hand waving and say, I don’t wanna look at numbers ever. All I’m worried about is whether I’m building the right thing that is wrong. That’s just wrong. You can’t do that,
Um, but when they dive into it, they say, “one instance of which the efficiency of investing in a more tech-based product can be seen is in the comparison between a cloud-based model SaaS and an on-premise model. By investing in a SaaS model, you are cutting out The added requirements of having this technology installed or maintained as a cloud-based model does not come with the day-to-day running costs and ongoing maintenance is the responsibility of the cloud provider.” That almost in a nutshell, to me, is the difference between briefing, back briefing and diving into the details with limited slash un nuanced understanding of the problem.
Andy: Yeah. And, and, and I think because when, when I looking at this question, I, I think there’s a problem with the question that will never get you to an interesting conversation.
Mon-Chaio: Mm-hmm.
Andy: And the problem I have with the question is that it’s a binary question.
Mon-Chaio: Mm-hmm.
Andy: give me your assessment rather than take me through your reasoning.
Mon-Chaio: Mm-hmm.
Andy: So, uh, to me, and, and, and so what it’s, what it’s doing is it’s saying that as the CFO, you now need to have a way of assessing the yes or no you get.
Mon-Chaio: Mm-hmm.
Andy: and I think Mcha what you’re saying is, as a CFO, we shouldn’t expect that you have that knowledge to understand the nuanced differences in technology strategy between going with SaaS versus cloud versus on-prem versus custom built versus. And also, I would also say that those aren’t mutually exclusive, like
Mon-Chaio: Well there therein lies the nuance, right? And think. Um, some, it, it was definitely a non technologist that wrote the article. I’m not gonna go so far as to say I was a finance person or, or what, I don’t know. Right. But the, um, that last line that I read, you showed that there was not a nuanced understanding.
I will say, Andy, I kind of disagree with you on saying that the problem is binary versus I’m taking you through the thinking. I do think that having a binary answer is challenging.
Andy: Mm-hmm.
Mon-Chaio: the briefing becomes yes. Or the back briefing becomes yes or no. Right. But I also think, and you may disagree with me, I would love it if you did, because I think another point of view on this would be very, very interesting.
I think often taking you through the details is challenging because they don’t understand the details.
Andy: Yes, you, you are right. I, I, I agree with you on that. And so that gets to, to the person that is being asked this, it’s knowing how, and, and I think this is what we talked about in that other episode, it’s knowing how to talk at the particular level and explain it and take it through for that person of that other discipline so that you can have that conversation.
So to me, that’s part of being able to be accountable. So I think, I think the, someone should be asking questions like that. Not binary, but instead with the expectation that you can take me through your reasoning. Now, if you end up as the tech person only spitting out all the jargon or hedging everything so much that basically they can’t understand the account you’ve given.
Mon-Chaio: Mm-hmm.
Andy: I don’t think that you’re giving a good account.
Mon-Chaio: I agree.
Andy: I think, I think the binary, it’s almost that the binary doesn’t allow the discussion, and so you need to open it up to a discussion and not let that discussion turn into zero communication.
Mon-Chaio: Right, and let’s use this as an example. Are your tech investments cost efficient? Right? So we, we agree that that’s not a great question, but we can kind of role play it out. So I think maybe a better question is help me understand your thought process to make sure that your tech investments are cost efficient.
Andy: Oh, that’s a really good question, Mon-Chaio. What we do is when a new investment opportunity, basically a new project comes up, we work through it with either the sales group or the product group, or sometimes if it’s in more of an internal product with your group or whoever else we’re, or we would be doing this for.
We work through what is the, uh, advantage that we get from doing this. What is the upside? And then what we look at is as a tech team, we come up with multiple options. We came up with, uh, I don’t, I don’t like it if we only have one option. I don’t feel like that’s an option. So I make sure that the team comes up with at least three options of how we could do this, and that might be buy it off the shelf, that might be, uh, something else.
And then we cost out each one of those options, how much each one would cost. And we think not just about right now, we also think about the future. Like if we built our own code, for instance, we would then need to continually maintain that. But if we bought it off the shelf, well, we’d have to continually pay some sort of license fee possibly.
So we have all these different things. And then once we’ve got that, we’ve kind of got the two sides of the, uh, the, the balance sheet going on, and we can work out which one is the, the. The, the kind of spread that we’re okay with, as well as thinking about, and this is the really part where it gets complicated for us, and you’ve probably heard us deal with this before.
We also then think about what’s the impact of doing that on all of the other things that are happening. So, so the cost efficiency, we don’t look at just on that one thing. We look at it across whatever else is going, going on.
Mon-Chaio: Great. Andy, that makes a lot of sense. But what I’ve never heard you talk about is outsource all of engineering to India that we can save cost. So are you really thinking about being cost efficient? So let, I’m pause there now. I think the first question that I asked and Andy’s response, I think were really good, starts to the conversation.
Right now, I just asked a follow up question. Was that a good question to follow up with?
Andy: Was it, uh, I actually think that it is a completely reasonable question devoid of any context
Mon-Chaio: Mm-hmm. Mm-hmm. Sure.
Andy: There could be context in which that’s not like a, a genuine question following up, but it could also be that you’ve got information that the situation is different from our conversations in the past, in which case it can be a completely genuine question and we need to reevaluate it, or
Mon-Chaio: Yeah, and I would say look, like I would say, um, let me, I should probably as the question asker lean into a little bit more curiosity than that. Right. I should say stuff like, I’m hearing a lot that a lot of companies are developing things really quickly and really cheaply with overseas labor.
Andy: Mm-hmm.
Mon-Chaio: Let me know how you think about that,
Andy: Yeah. Yeah. Or what advantages would we have from doing that, and what problems might we encounter?
Mon-Chaio: Mm-hmm. And here is where sometimes I think we get, executives especially, can get tripped up, which is now we’re starting to get into the nuance, right? We might, um, as technical people have an answer like, well, um, especially you and I, Andy who’ve done a lot of technical due, diligences have seen a lot of companies, um, we can kind of use our experience to say, well, generally in our experience, here’s what we see.
Here are the pros here. What, here’s the types of things that work well to outsource. Here’s the types of things that don’t. This is the reason why we think. Our situation is probably closer to one or the other. Right. Um, and I think often when we start to get into those types of discussions, I feel like this is where our stakeholders then start to get away from the back briefing part.
And they start to get into the challenging part. It’s well, no, um, like our competitor has a similar product and they’re doing it right. So this becomes a “prove to me your expertise”
Andy: Yeah,
Mon-Chaio: when I have a very un nuanced understanding.
But if someone presents you a nuanced answer like, oh, in my experience and since I’ve been in the industry, like these are the pros and cons and I feel like we fit more into the cons, that’s probably, in my opinion, maybe you disagree.
The time at which a stakeholder is like, huh. This person’s the expert here,
Andy: I, I actually, that that last one I have a slight issue with,
Mon-Chaio: okay?
Andy: which is it’s an appeal to authority.
Mon-Chaio: Mm-hmm.
Andy: I’m the authority. I’ve been doing this for 20 years and I don’t think we should do it. That’s not much of a reason.
Mon-Chaio: Yeah. I’m not suggesting that that’s the only reason I think. I’ll say like, it would be something more like, you know, I have done 50 tech due diligences, and I’ve been in the industry for 20 years and here’s kind of the nuances that I see. Um, generally companies who do this find these types of problems.
Generally, the companies that do it over here find these types of problems. I feel like it’s really important that we think about that and like, I’m really worried that we’re gonna fall into a pattern here. This is why I’ve made my decision.
Andy: Yeah, I, I, so this is, thinking about this in terms of like the person hearing this as the account. I think that’s the, that’s the key is I, I wanna be listening for is there a logical fallacy in the account that I’m hearing? Is what the account that I’m hearing, just an appeal to authority.
I’m the authority and so trust me. Or is it, here’s a model, we’re going back to models, here’s a model for how to think about this. Here’s the inputs of our situation into that model. And so that model then would say, that would not be a good fit. I can’t say that my model can’t tell me that it would be an absolute disaster, but my model can tell me that we don’t seem to fit the, the style of work that would make that okay.
Mon-Chaio: Right, like as the accountable person, my judgment is we don’t seem to fit. And I like that you started with f logical fallacy because I think there are things that people can sense, um, who are attuned to it. Things like logical fallacies, which you should absolutely push back on. No, that’s a rhetorical argument.
No, that’s a whatever. That’s a appeal to authority. But when your, when your expert says something like, it’s pretty well accepted in the industry that people working together, collaborating synchronously are more effective than people collaborating asynchronously.
Andy: Mm-hmm.
Mon-Chaio: And then as the stakeholder, you say, well, I don’t believe that.
Prove that to me. I think that’s where, in my opinion, you start really getting down the rabbit hole of like. Now I have to show you everything right. Now I’m gonna go pull a paper on that and then, you know, and then you say, okay, well now I believe that, but like, um, you’re telling me about these Dora metrics and, and practices and so many companies don’t do that and they seem successful.
So then you go pull the DORA stuff and they’re like, okay, but I don’t like the methodology in which they sampled because it didn’t have fi. Right? And, and you start going down rabbit hole after rabbit hole after rabbit hole.
Andy: And there, I think now it’s a thing to have a conversation about, like, why are we doing that? What’s, what’s going on here that says that we’re going down these various things. Where I am, I am referencing things, you can go and look them up and we can have a discussion about that, but like, let, let’s have a discussion about why we’re doing that.
Mon-Chaio: Yeah. And I think that ends up being really challenging from a, getting back to the CFO perspective. A lot of the times it’s like I need to make sure that my dollars for engineering on the books is as low as possible, right? Um, but as low as possible or as low as reasonable means somebody has gotta define reasonable.
And
Andy: Not, not just constantly lower.
Mon-Chaio: Right. If the technical leader can’t define reasonable without proving every single thing down to first principles, I think you’re gonna have a very challenging time working through that in any case that you put forward.
Andy: Yeah.
Mon-Chaio: And so I think that’s, that to me is the crux of it, is.
You don’t have to believe the first principles. Just like when I talked to the CFO on a financial topic, I don’t have to believe that GAAP accounting, like that GAAP is the way to go. I may think GAAP is bunk, right? May think SOX is bunk, but what I have to believe is that we’re aiming towards the same goal.
They understand the severity and importance of the goal as much as I do. That when I ask some probing questions, there’s models to think about it that don’t have logical fallacies, and at which point I can be like, okay, there’s not a logical fallacy there. I think there’s a ton of problems with GAAP. Done.
Right? Like that’s your thing to work through at that point, in my opinion.
Andy: And, and, and I think you, at that point, you can start questioning the outcomes.
Mon-Chaio: Mm-hmm.
Andy: saying like, oh, look, but we’ve been working on this and this is what we’re getting out of it. What’s going on? Or, I don’t, I don’t think we’re heading in the right direction. What can be changed?
But that’s getting to a different question.
Mon-Chaio: Right.
Andy: of a, a follow up question. Let, let’s move on to the, the second question from this blog post, which is, is the technology agile and flexible? Sorry, I, I, I laughed as I was reading it, so I kind of transmitted, uh, I, I telegraphed my, my thought on it.
Mon-Chaio: Let me, uh, let me read something in the paragraph in that section. “Any new technology that you are investing in needs to not only be scalable, but it also needs to be future proofed. Make sure that any investment that is made now will still be valid in five years time.” So, Andy, every investment we make now is valid in five years time. Right? That’s a really important distinction and challenge that the CFO should be making to their technical stakeholder.
Andy: I, I, I think that’s a recipe for gold plating and overspending. I, I mean the, I I can get behind the, like we, we, we don’t want to be locked in, but. There’s some things that matter and some things that don’t,
Mon-Chaio: Mm-hmm.
Andy: and I think also be, still be valid in five years time. There’s some of these things that you won’t care about in five years time and you don’t even know whether or not you will now or not.
So I don’t, I guess maybe that’s the thing behind agile and flexible. Uh, I, I think, I think one of the big issues with this is that I suspect that A CFO and a CTO would mean completely different things when they hear those words.
Mon-Chaio: Oh, interesting. What do you mean by that?
Andy: So A CTO would think is the technology agile and flexible? They’re going to think, are we following Scrum?
Mon-Chaio: Mm-hmm.
Andy: And flexible will mean, uh, are you com comfortable with the tech debt?
Mon-Chaio: Mm-hmm.
Andy: I don’t think that that is what the CFO would mean by that. I think the CFO would mean something more along the lines of, uh, am I gonna be stuck on a five or a 10 year contract for something that we won’t need?
Or are we about to spend a million dollars on something that won’t exist in five
Mon-Chaio: Mm-hmm.
Andy: and. And I think that’s, that’s kind of what they’re wondering about. So I, I think that those words, it, I think this is a one where you need to, you need to really make sure you’re agreeing on what these words mean, especially since agile is such a jargony word that it’s almost lost all meaning
Mon-Chaio: One of the other examples, they do say like, um, you know, make sure these are valid in five years. The other example they give further on down in that section is make sure that the technology can scale as the business scales, right. And I think that’s look like, I think that’s a reasonable concern. Um, what.
I think is less reasonable to me is the bottom of that scaling paragraph is “sufficient research should be carried out to determine the long-term suitability of any new technology investment.” Uh, okay. I, I think at a high level, sure. But they’re talking about the CFO and the research the CFO is gonna do after hearing the answers from their technology partners. Which I think is, is really problematic, Andy. Um, this is how you get into those tech due diligence is that do no due diligence, right? Because it’s people looking at white papers and, uh, recommendations and reviews and not at the details.
And so I think this is another example where you lean in with the briefing back, briefing with curiosity.
How are we making sure that as the business grows. Technology will continue to be able to quickly change as we need it to of being a burden that we have to re-platform on later.
Andy: Yeah.
Mon-Chaio: Right. And then I think, again, you listen for those answers around are there any logical fallacies? If you feel like there’s a gap, you lean back in with curiosity, right?
Like, oh, um, I heard you talking about building a workflow engine. Um, aren’t there classes of technology that are better to be. You know, uh, to or to be better, like for a vendor to do, like, help me understand your thinking around that.
Andy: Yeah, I think, I think this, let me ask you this, Mon-Chaio, is this one where giving specific details of that would be helpful. Where say, say we were doing this and uh, the workflow engine came up and I said, yeah, you’re right. There are ones that we could have bought, but when we looked at it, the licensing fee for the one that we would’ve we would want to use is 10,000 a year. And I just didn’t want to commit to 10,000 a
Mon-Chaio: Mm-hmm.
Andy: So instead what we’re doing is the engineering team is going to build one and now we’ll have complete control over it.
Mon-Chaio: Mm-hmm.
Andy: I think in that case, providing like that exact number and our determination to do something else could be very useful for the conversation because I can imagine a CFO saying 10,000 a year. I think we could handle that. Would that speed us up?
Mon-Chaio: Absolutely right. I think it’s important to get back to the briefing, back briefing. So as the CFO, I would expect them to not focus on the number, but focus on why that was the number. Right. And so the question, the, the briefing back to them would be something around, there’s definitely a trade off between cost and build. I’m not hearing that you understand the magnitude of the trade off.
Andy: Yeah.
Mon-Chaio: Like how did you determine, um, that 10,000 was too much? Right. And so they might be able to give data back and maybe when they gave data back, it’d be like, oh, okay, I get it because we’re already spending $7 million on, uh, uh, uh, cloud costs or whatever, right?
And like that’s projected to grow by 25%. And so even small amounts like this makes sense. Okay, but if they give an answer, which is like, oh, well I’m basing it on revenue, then the briefing might be like, oh, here’s the way we think about capital investments with regard to revenue. Right? Not, not this 10,000 we should spend or not
Andy: Yeah.
Mon-Chaio: I think generally speaking, when you have a senior leader who’s the primary technical stakeholder, they need to be able to have these skills. You shouldn’t hire them. And if you’re forced to hire someone that doesn’t have these skills, I think you’ve kind of already set yourself up for failure because there’s no way the CFO, the CEO, you know, the chief marketing officer, the chief people officer, or anybody in the company, can get enough nuance out of that person to truly double check their decisions, because that’s not their field.
Andy: Yeah. It’s that, it’s that identification of, for the question that I’m asking, am I getting an answer that is, are they, are they skilled at providing a reasonable answer? And then there’s also, from the asker side of, of what you’re getting at is a a bit of self-reflection. Am I skilled in evaluating the answer I’m getting?
Mon-Chaio: Mm-hmm. Right. Oftentimes I feel like people think they are.
Andy: Yeah.
Mon-Chaio: Well, I mean, that’s all of us, right? Like, uh, way back in the day, um, our mutual friend Julian and I had a conversation, you know, a, um, a very brash conversation, uh, uh, this was like 20 years ago where we were like, you know, we as software engineers could probably do anything we wanted if we put our minds to it.
Like we could launch rockets, we could be hedge fund traders, you know, we could do anything. Right. I think a lot of smart people end up thinking that way. Like as long as I acquire enough knowledge I can do it. And I don’t even have to acquire all knowledge. I just have to know to ask the questions for the 5% that matter the most and then like, I’m an expert essentially in being able to steer, right.
So, yeah. So I think, um, that self-reflection really around, can I even evaluate it? What is this person here to do? What is my role in making sure that like I hired the right person, that they’re doing it, they have the skillset.
Andy: Yeah, I think, I think, I think it’s a key skill. To have and a, and a key thing to constantly watching yourself and, and in this thing that I’m doing right now, am I actually skilled or do I just believe that I am because I’m willing to give it a go.
Mon-Chaio: Mm-hmm. Well, and let me give you a really, really personal example. Um. I’m running a technology organization right now, which includes a lot of different things, including corporate IT support and cloud IT support that fits within my purview, right? So if I’m thinking about staffing my next level of leaders, I feel like Andy, everybody knows this, you know this we, you know, our listeners know this.
I came up through engineering and I don’t have a formal product background, but, i’ve always worked in a place where like I took a lot of connection with product and really tried to understand what product was working on and sometimes even had to lead from the back product to do the right thing.
And so when I think about it, I think, well, if I hire my engineering direct leader who’s gonna lead my engineering team, um, or my product leader, um, I could probably get away with a more junior engineering leader because I can help steer them because I know that front and back. Right now for the product side, probably a little more senior, but I still feel like I have a good steering capability.
Um, but they have to have a little bit more structure. I don’t know all of the ways, like, I don’t know, six different ways to do, um, prioritization, for example. I hope my product leader does great ’cause then I can lean on them, right? But the area which I really don’t know, is IT support.
I definitely have enough knowledge to be dangerous. I definitely have enough knowledge that when they come in and say, Hey, we should do this, I’m like, really? Like, talk to me about that, that that doesn’t quite fit, right. The way I understand it, that doesn’t quite fit. But I really have to be able to trust that person because there is no way I’m gonna get a quality product if I feel like I take my 5% of IT knowledge.
Continually harass and harangue that person over every decision that they make in order to double check. I have to be able to kind of set that to the side and say, oh, you know, you want to not purchase machines or you want to purchase 10,000 or a hundred thousand dollars worth of machines now because you think the tariffs are going up.
I don’t know that we will, like, I don’t know that that’s what I would do. But you know, and then brief and back brief, like, have you dealt with this situation before? Talk to me about your trade-offs. Right? And then I have to lean on them to make that decision because I don’t have that expertise. And so I have to hire a much, much more senior leader there than I would in other areas of my organization.
Andy: Yeah. Yeah, I think that makes sense. So you don’t understand AD through and through.
Mon-Chaio: Yeah, I had this, uh, whiteboarding discussion just the other day on, uh, on, on SAML tokens and stuff. Um, which of you know, you’re like, oh, of course I understand it. They’re just claims. It’s like a hash that you pass through or whatever, right. Um, but obviously it’s more nuance than that.
Andy: Yeah. Yeah. Saml. Cool. Um, do we go on to this last question or, uh, do we kind of wrap it up here? What do you
Mon-Chaio: Let’s see, is my tech infrastructure fully secure?
Ah, okay. this one because this is so cringey, but,
Andy: I kind of, I kind of feel like this last one is my tech infrastructure fully secure is like the previous one on steroids. Like from a risk perspective, absolutely. Being interested in what kind of risks are we taking on?
Mon-Chaio: Mm-hmm.
Andy: Is my tech infrastructure fully secure? I mean, any, any tech person you ask that question to, they’re gonna say, well, no.
Mon-Chaio: Right. Yeah, no, I agree.
Andy: If you want it fully secure, remove all people and shut it off from the internet. Let it run on. Its in its own data center, not connected to anything.
Mon-Chaio: Well, and I saw a company that did just that and their infrastructure was so convoluted because of that.
But, uh, in the article they say things like, areas with connected data flows are also critical to look at. Examples include tech stacks and human resources, payroll and finance. If a data breach occurs within one of these areas as a result of poor infrastructure security, then the integrity of all three is brought into doubt.
Andy: Yes.
Mon-Chaio: That’s true. Uh, i, I just don’t know. I mean. Again, there may be that briefing, like, have you thought about the intersections of data that, you know, uh, data that, uh, you are not developing? We’re ingesting payroll data, et cetera. Like, um, help me think about how you’re thinking about that, right? And then listen for it versus have you secured your finance data?
Okay, I have my checklist, right? Have you secured payroll data? Have you secured Salesforce data? Have you secured, I mean.
Andy: I, I think actually this is a really relevant, now that I think about it, it is a relevant one and we should think a little bit more about like what would be a better conversation here. And the reason I say this is, Mon-Chaio, I don’t know if, I don’t know if this has gotten across the pond. you know that in the UK there have been two major hacks that have been all over the news recently? Both are grocery stores or larger stores like grocery stores, so it’s Marks and Spencer’s and the co-op, both of them got hacked. Co-op was able to shut it down a little bit earlier, and all it is is that there’s been shortages on their shelves throughout the country for a few weeks. M and s Marks and Spencer, you have not been able to order online from them for about two months.
Mon-Chaio: Yikes.
Andy: Yeah, and, and you can’t even like go into the store and say, can you order this thing? They can’t do it either.
Mon-Chaio: I’m sure their CFO is pissed.
Andy: So it is absolutely a relevant concern. It is a thing that they, these companies should be talking about, but I don’t think that this is a useful question.
Mon-Chaio: Yeah. I mean, and again, it’s comes down, you have to have some level of trust, and if you don’t have it, that’s fine, but like, find the real, find the people that are gonna help, right? It’s like, um, I think that’s a, it’s a very clear conversation if I were the CFO to have, say, look, based on your background and kind of based on our conversations, I’m not having high confidence that this is like an area where you have a ton of expertise. I would really suggest that you go find an expert because like, here are the problems. If we get hacked, right? Like let’s point to the mark and Spencer’s thing. Here’s the amount of revenue and stuff that they lost. Like we obviously can’t have that happen here. So like introspect a little bit. If you don’t have the expertise, we’re more than willing to go out and grab a consultant to help you out.
Andy: Yeah, so it’s, it’s really let, let’s go through what we are doing to understand the level of security that we have, the risks that we have, and what, what are we doing to keep an eye on that and improve?
Mon-Chaio: Mm-hmm. Yeah. Like, do you have a, do you have a plan? Um, does your plan seem reasonable? It’s not full of logical fallacies. It seems like there’s continuous improvement,
Andy: yeah. Is there execution happening? Um.
Mon-Chaio: Mm-hmm.
Andy: you can have all sorts of plans, especially on security. You can have all sorts of plans and then say, no, sorry, we never have resources to do that.
Mon-Chaio: No, absolutely. And then it gets back again. I think to my point, as even if all of that is happening and you feel in your gut that there’s a gap, you need to be able to articulate it. Like, is this the wrong person? .
Andy: Mm-hmm.
Mon-Chaio: Is there a skill gap? .
I told you that I maybe don’t think that you’re the right person here and that you should go out and find the right person. But if at the end of the day you introspect and you feel like you’re the right person, I kind of have to give that to you. Or you take accountability away from them,
Andy: Mm-hmm.
Mon-Chaio: right? And you say, look, now it’s my job.
I am gonna go out and find a vendor that’s gonna do the security review. Now, I’d love your help in determining the vendor ’cause I don’t have expertise, but like, um, we are gonna get a second opinion and it is my accountability to go and get that second opinion, not yours anymore.
Andy: Yeah, I think I, I like that Mon-Chaio. I like that there’s a point at which you may not trust that account.
Mon-Chaio: Mm-hmm.
Andy: You need to go and find someone to help you get what you would consider a trustworthy account. And working with that and being honest about what it is you’re doing and why you’re doing it. Um, I think that that, that’s great.
I think it would be sad if it got to that point where you had to do it unilaterally, but on the other hand, it’s better to do it unilaterally, when you hit that point than never do it and end up sitting there with all of this risk.
Mon-Chaio: Right. I think the big thing in my mind is that accountability then has to sit with you. You go get a consultant from a consulting company, you interview them and your technical person sits there, is like, they have no idea what they’re talking about. All they’re doing is reading like an industry council white papers and you’re like, no, this is the person I’m gonna hire and I’m gonna have them tell us what to do.
Right. That accountability has to sit with you. And then if you’re saying, well, there’s so many things that I have to do that because you know, there’s so many gaps.
Well, okay, so that’s a conversation about your technical stakeholder.
Andy: Yeah. That, that’s, that’s the, the thing about, do you have the right person here? you need all of these things. We’ve gone through the three questions. We went way into other things that I I was not expecting where we went with that.
I would say this for myself, but no, I’m trying to wind down my involvement. If you have anything where you think someone could help you out on this, uh, contact Mon-Chaio at hosts@thettlpodcast.com, and he might be able to help you coach your, your stakeholders or coach you on how to interact with your stakeholders. So if you’re looking for something like that, reach out.
Mon-Chaio: But if you need a woodworking analogy to help with that interaction, Andy is your man.
Andy: If you want a chair or something like that, get in contact in about a year. So until next time, Mon-Chaio. Be kind and stay curious.
Leave a Reply