Ep.136 The Two Most Important Risk Factors in Customer and Employment Agreements
Are you a technology professional looking to connect with like minded people?
We have a thriving community of CTOs discussing these episodes and more.
Click HERE to set up a call and learn more about becoming a member.
About The Speaker:
Meetesh Karia, CTO & Chief Data Officer at The Zebra
Check out https://7ctos.com/
Nickolai Walker: [00:00:14] Hello. Hello, Welcome back to the CTO studio. I, of course, am your host, Nikolai Walker, on the mic and in your ear. We are continuing our conversation and carrying over from last week where we talked to Meetesh Karia, who is the CTO and Chief Data Officer at The Zebra. I love that name and we were discussing when, why and how to start the compliance process. So from there, we’re going to lead right into the two most important factors risk factors in customer and employment agreements. And Etienne, I’m going to have Meetesh finish his thought and then we’ll go from there. Here we go, everybody.
Meetesh Karia: [00:00:52] Me personally, when I look at contracts, the two areas I pay the most attention to are intellectual property. Who owns the IP and indemnification. The Last thing you want to do is sign yourself up to be on the hook for someone else’s mistakes or oversights or negligence. And so in my mind, that’s right along those lines of you just got to understand that risk has got to be spread out. It’s got to be diffused. It can’t be focused in just one area when in actuality it is spread out.
Etienne de Bruin: [00:01:33] Yeah. So tell me just on that comment about intellectual property. What are your concerns?
Meetesh Karia: [00:01:43] Well, unintentionally or accidentally or by contract something that is ours will be made property of a partner. So what I usually look for is something that essentially defines the intellectual property in a sufficiently broad but relevant capacity and says that the stuff that is the property of us at The Zebra is our property and will remain our property and is restrictive in terms of the rights. It doesn’t give them rights to use it as their own property or make money off of it. But that’s the key thing is just understanding does the contract all of a sudden say that they can go and treat this property as their own for free.
Etienne de Bruin: [00:02:28] And that IP generally in your data and your transforms and what you do to data? Or in your code or in your process?
Meetesh Karia: [00:02:42] Yes. In anything. So for example, when we I hope that Seth will be OK with me sharing this, but when we put together our agreement working with him as a virtual CISO, we drew the line in terms of our specific security program is our property because he was working under contract to develop it for us. But any generic tools and frameworks that he came up with in the process of making this that there weren’t specific to us, but that he used or developed could be his property. But being very clear about that. Just because he couldn’t just take the program he developed for us and go and say, that’s his program and go repurpose it and sell it. That’s our program.
Etienne de Bruin: [00:03:26] Got it. Got it. Got it. That’s a good example. And I think Seth would be totally fine with that. Yeah, I love how you sort of hone straight into the IP and the indemnification. You just scanned through this, but I do want to see something mentioned about these two or three things.
Meetesh Karia: [00:03:46] Yeah, those are the key. I mean, I look at termination. You look at things like that, right? But those are things that I also feel like any good counsel will catch. I mean, any good counsel will catch the indemnification too. They’re all looking at risk and liability, but those are the two that that I like to pay particular attention to.
Etienne de Bruin: [00:04:06] I like that. So I want to wrap up with some questions around the engineering teams, the departments. When it comes to risk management, your team arguably carries the greatest impact in. Doing things they’re not supposed to and knowing things they’re not supposed to, potentially inadvertently sharing information they’re not supposed to, whether they on board or whether they’re off board. So a lot of this stuff is encapsulated in playbooks and training, but also in culture and a culture of risk management. So understanding the risk and a culture of succession, disaster recovery, redundancy, so talk me through, I know when you said you went into the second phase, it goes from building the machine to building the machine that builds the machine. So how has that been for you? And a couple of points that you want to speak to on that?
Meetesh Karia: [00:05:33] Yeah, I mean, as you mentioned, there’s definitely training and education around it. You know, there’s best practices training, security training, and there’s even things such as when it comes to privacy, only exposing certain bits of data to people who truly have a need to know. So, for example, everyone has access to our our BI system and our analytics and our data. But a very limited set of people have access to email addresses of consumers and actual personal information. We use the technology and roles and groups and privileged access to limit that so that it doesn’t stop everyone from doing their work. They can still do it, but we don’t even give the majority of the people the opportunity to accidentally do something. But then ultimately, I think it really comes down to, as you’re building that machine, building that culture.
Meetesh Karia: [00:06:29] And I’ll go back to what I said, that culture of not saying no, but that culture of helping work with the rest of the company to figure out how and to manage the risk. Because I think if you end up with a culture where any time a developer or a team wants to go do something, they’re like, Oh, I have to go through this onerous process, it’s going to take forever. And they’re just going to say no anyway, so I’m just going to go do it and then hope they don’t find out about it, right? That’s one side. But the other side is, you know what? Yeah, I’ve got to go through this process, but they always get back to me right away. They’re going to help me make this better. They’re going to make me figure out if I’m doing this login system, when should I lock out? How should I do it? What is secure? You know, they’re going to help me figure that out and understand the risk to make it so that I can hit my deadline, but do it in a safe way and protect the company. That’s the other side, right? And so that’s where I think that culture is a big part of being able to reinforce the right behaviors and get that education to stick.
Etienne de Bruin: [00:07:42] Does that require an insane amount of trust? The always say yes approach.
Meetesh Karia: [00:07:50] It’s yes, but.. And the thing is that it requires some trust, but the thing is that the person who is making the decision on the risk to accept is at a sufficiently high level, right? So it’s not saying, you know, okay I’m going to inform you of this risk and you, a developer who is one year out of college is going to make that decision. But we’re going to help the team make the decision. We’re going to help the leader on that team decide, or whoever it is, make that decision to move forward. There is some amount of trust you have to put in that people will follow the process. People will run things through. And the same way you have different approaches to catching bugs and code, which is you want to try to catch them in the design, then you want to catch them with testing, then you’re going to catch some of them in production, right? It’s the same thing, which is you hope that you get most of them in the designing, in the planning. Some of it you may get when you’re testing stuff out before you release it, and then you just have to have a process for, OK, we detected this out in the wild. How do we quickly get that work done and resolved and patched and understand the impact of it? And it’s the same way, ehich is you have to cover all those bases. You’re never going to catch everything before it goes out.
Etienne de Bruin: [00:09:23] I like that, so it’s not like there’s this one governing rule or policy which shuts everyone out or brings everyone in. It’s really understanding, at all the different levels, pre mid or post, that there are processes and ideas in place to help people through that.
Meetesh Karia: [00:09:49] And I think that’s what I think the only way you build this culture where security isn’t a step. Security and privacy is not a step is part of everything we do. Robustness, reliability, security, privacy, resilience. It’s part of everything we think about at different aspects and to different levels. Well, fun stuff, huh?
Etienne de Bruin: [00:10:23] Well talking to people about it, it’s fun-ish, but just the topic is just ugh.
Meetesh Karia: [00:10:31] It is. It’s a lot. And especially as a CTO where you want to build cool tech, you want to move the company forward. It sometimes feels like this is a slog. It’s just like, Oh, there is this other thing I have to do. And I’ll be honest, there were many times where it was burdensome on me too. But I had to keep reminding myself that in many ways it was some of the highest impact, highest leverage work I could do if I could do it correctly. If we could do it in a way that helped the business move forward quickly and safely and not slow the business down, then that impact even though in many ways it’s completely behind the scenes. In many ways you want it to work in such a way that people don’t even know it’s working. You don’t get excitement for, yes, we weren’t breached, but one more day that we’re not breached is one more exciting day, one more day that shows that, hey, this work behind the scenes is effective.
Etienne de Bruin: [00:11:35] Yeah, I think that perspective that it is probably the most important work you can do at that stage because it is the one thing that can shut your company down. Or saddle you with with fees that you can’t pay or tap into insurance premiums or deductibles that are just, I think there’s something called co-insurance now where you pay, it’s a 50/50 thing. They don’t even want to cover the whole thing anymore. If, at your level, you start seeing the the employees, their livelihood, their families and, you know, if one or two bugs get shipped versus one or two privacy laws get broken, I think it is probably some of the most important work we can do to shield. And that’s why I want to emphasize that. Scaling companies have to focus on this.
Meetesh Karia: [00:12:43] Well, you know, I think it’s really important that you’re focusing on it. And I would say that, even before scale, I think the role of the startup CTO is shifting more to the implicit understanding or requirement that you understand that you have some knowledge of security and privacy and compliance. It is just now part of the gig because you’re not going to be big enough early on to have an infosec department, I mean, unless you’re working in banking or something that’s a market where you have to have it or there’s no other way. You’re not going to have the luxury of having an infosec team or some of these other things and a lot of that as, usually the most technical person in the company, is going to fall on you as a CTO.
Etienne de Bruin: [00:13:40] And also educating ourselves on what those risks are. I agree with you but I think I have a slightly different view on it, but here’s where I agree and this is what you did. Even at the brutally early stage, understand the landscape so that you can decide, like you did, when and how am I going to spend our company resources on the compliance and on the certifications? And I love that business pull through approach of, OK, let’s push that boundary as far as it will go until we have to be compliant to stretch it even further. But I agree with you that you don’t have the luxury anymore as a startup CTO to just say security or compliance, whatever, because then you want know how to make that decision. Meetesh, you are a scholar and a gentleman. Thanks for chatting to me.
Nickolai Walker: [00:14:53] Thanks again for joining us here in the CTO Studio and a large thank you to our guest Meetesh Karia, the CTO and Chief Data Officer at The Zebra. Now if you would not mind, please go over to iTunes and subscribe to this podcast. That way, you’re able to get it every week. Go check out. Meetesh Karia’s LinkedIn page and as always, check out 7CTOs.com. We will see you again next time.