Compliant Unicorns

**NOTE: Generated via ML. Expect crazy stuff to be translated by an imperfect algorithm that may have never actually been said by the host or guest :-) ***

[00:00:21] MC: Nearly all companies that have started in the last few years have been cloud-native from the start. It's no different for our guest today, Nate Lee, from Tradeshift. Tradeshift is a cloud-based business networking platform for supply chain payments, marketplaces, and applications. It had a large round of funding back in 2018, which was led by Goldman Sachs, and at that time, was one of the few companies to reach that valuation of over a billion, making it unicorn status.

In today's interview with Nate Lee, we're going to talk about their journey, his time there over the last seven years, and how you can leverage things like automation, DevSecOps, in order to scale on some very difficult items like ISO 27000 and different certifications. I hope you enjoy the podcast today.

[INTERVIEW]

[00:01:12] MC: Nate, thanks for joining us today.

[00:01:13] NL: Oh, thanks for having me.

[00:01:15] MC: Tell us a little bit about yourself, Tradeshift and your role there as the CISO.

[00:01:21] NL: Sure. Well, as to myself, I've been in tech for 25 years, to the point where you start losing track, I suppose. Initially, I got my start to general IT work, servers network, all of that, from back when everything was just under the IT umbrella. Then, had ended up gravitating towards network. I'd done a ton of network engineering. Ended up working at Target Corporation. Had a lot of exposure to the corporate side of things, The fortune 50, extremely large scale, and was working for Minnesota where Target’s headquartered. A little over 10 years ago, moved out to the Bay, I guess, the siren sound of Silicon Valley was calling and came out and got into the startup scene, working as a architect, so helping design systems and networks for a video conferencing company.

Very quickly there, I just was really excited by the DevOps thing and the direction everything was going. I had gravitated in that direction, and ended up running the operations team there, which grew and grew and grew. Took security, since all of that is parallel to work that was already being done between servers and network and whatnot. Ran ops, and then came to Tradeshift, where I'm at now, seven years now, which I guess, is quite a long time by Valley standards, or any standards really in tech.

I've been here seven years. Came over running the ops team, but very quickly, it was clear we needed someone focusing on the security side of the house. One of the things, I guess, that I'd experienced previously is just security that wasn't really engaged in the business, or wasn't compatible with engineering goals and having some of these arbitrary controls that no one likes. I ended up jumping full-fledged into security at that point, partly for self-preservation to keep someone else from having to impose those things on me. I've really just been passionate ever since about it. I mean, I think it's such a wide-open field that melds tech and culture, people business, all of that, which is why I really ended up liking it.

[00:03:20] MC: I noticed that back in 2010, you obtained your CCIE, which is I believe that at least it used to be the highest level of certification for Cisco routing and switching. Is that right? Do I have that right?

[00:03:32] NL: Yeah, yeah. That was the doctor network. I don’t know. Marketing person came up with that or something. It certainly was extremely hard. I mean, I think I still have a pinched nerve in my back from studying for two years straight, non-stop, all day, every day. Actually, that is what led me to the broader DevOps and software and doing SaaS, was I’d spent all this time on networking, I'd realized I'd hit the top level of whatever the networking side of things had, and just wanted to know what else was out there.

It didn't seem like I should have topped out. Again, running into the broader ops systems, DevOps, it was just a whole new thing. I'm glad I have all that knowledge. I probably don't need to know as much as I know about BGP and OSPF, but it has helped me in strange moments. Certainly, now with things like Kubernetes, or whatever, having overlay networks and underlay networks and understanding how all these things proxy back and forth. I mean, not the worst bit of knowledge to know, I suppose.

[00:04:29] MC: Yeah. That sounds something that from a DevOps perspective, they're typically in my view, there's usually a dearth of knowledge around that where it's almost like, yes, we still rely heavily on the network, but we really don't need to know that much about it. Maybe that is a good thing. A lot of that has been abstracted. Absolutely, a good thing. Now, I'm sure there's not nearly as many CCIEs being minted as there was a decade ago.

Tell us, so you obviously have a networking background with the CCIE. How did you transition into security and then into senior leadership? What was that journey like?

[00:05:03] NL: Sure. I mean, I think security is always there, right? If you're building systems, whether that's corporate IT stuff, or network or whatever, you're always thinking of, “how do I protect this?” Even if there wasn't a dedicated security department, or team or whatever, looking over designs and changes, it's just something you're always considering. I think, at some point, when I was at Target I studied for and did the whole CISSP thing. Again, was really drawn to the ideas of it not being just about tech and being about running a broader program, which always appealed to me. The transition was fairly straightforward, I think, because it was just more focusing on an area that I'd already been working on.

Certainly, there's been lots of learnings and lots and lots of people helping me along the way to get there. I think, transition-wise, moving to security was less difficult, maybe than grokking all the cloud native stuff that I know you talk a lot about. There's just such a culture shift and paradigm shift, and even some of the skills like we were saying, some of that networking stuff that I'd spent a lot of time on, not terribly useful to me day-to-day. Making sure that I'm always learning things, staying abreast of the latest things, I think, were the biggest change. I mean, that's any field these days, I suppose.

 [00:06:20] MC: Let's talk a little bit more about what Tradeshift does as a business. Because I actually found it fascinating. I was like, I've never heard of this company, but they sound like they do some pretty cool things. Part of the company's vision is to digitize and connect everything that happens between a buyer and a seller, anywhere in the world. That's an ambitious vision. Where does cloud come into the picture? What's the evolution been like? Where are you guys in terms of your cloud usage? How does it all come together?

[00:06:48] NL: Sure. I guess, at a basic level, Tradeshift is it's a business network. I guess, similar to how LinkedIn is between people where you have connections. This is going to connect businesses and connect them at the API level, so an intermediary for purchasing procurement. If you're a large Fortune 100 company, or Fortune 500 company, which is the bulk of our customers, they might have 50,000, or a 100,000, or more suppliers. Then they're trying to get them into their ERP and invoicing system and what have you.

It's a huge, heavy lift to get everybody integrated. For each of these suppliers, who are medium, small companies, sometimes larger, if each of their customers is asking them to integrate, I mean, these are a bunch of different integrations they need to do. One of the big value prompts we have is, once you're integrated on the platform, you can connect to anyone else that's on the platform.

As we target verticals, like logistics, where we're particularly strong, we sign a new customer, sometimes 20 percent, 30 percent of their supply chain is already on the network. Rather than having to try to convince them to take time to build an integration to send purchase orders and invoices, which they really, really don't like to do, it's already there and now it's setting up the connection and just piping those things back and forth. That's the base bit that we have.

You need to be cloud native to do that. You want to have that single network. Because if each company runs their own instance, you lose all of the network effect and the value there. It gets into a lot of the stuff we're working on now going forward is financing. Being able to provide liquidity into the supply chain. We can do that in a way that others can't because of this network. That's where a lot of the value becomes, because we have historic transactions of everyone on the platform, which allows financiers to get a much better idea of risk, as far as borrowing money out to the suppliers.

[00:08:38] MC: Where does cloud come into the picture with all that?

[00:08:41] NL: I mean, it's cloud native. Everything from the very beginning was built in AWS. Certainly, we've historically had customers who want to run Tradeshift in their data center, or their cloud, or whatever. A lot of that just comes to us making sure they understand the vision you were just talking about, which is connecting every company in the world. You can't do that with a bunch of islands running in individual data centers. I mean, it was it was an easy choice to be cloud native back then, as well as a smart choice in general, for any company starting these days.

If you're starting it, it's much easier to provision and get things up and running and iterate quickly in AWS, than it is to spend a bunch of capital on racks and servers and switches and routers and what have you.

[00:09:21] MC: A lot of our listeners are not cloud native. They weren't born in the cloud. They're not cloud natives. One of the challenges that they often have is just the whole evolution. They've got a ton of tech debt. They've got a ton of legacy stuff from either data centers they own, or data centers that they've got through colo facilities. Maybe talk to us a little bit about from your perspective, being born in the cloud. You're still going through an evolution, right? You guys have been in the cloud – you've been there seven years. You've said they've been there. What's been maybe the biggest struggle, right? Because you can be cloud native, I suppose, and still do it the wrong way. You can still be very manual. What recommendations might you have for your peers who are behind you in the journey to cloud?

[00:10:04] NL: Sure. I mean, well first, don't get discouraged. I mean, everybody has tech debt. I mean, if you're a cloud, or cloud native, it just lets you run up tech debt more quickly as you wish. Maybe an advantage or not. I mean, I think one of the big things is it's a cultural shift. How you're approaching building systems, letting go of control of certain things. Another side is, really, you need to think about how are you going to automate things. Things are going to iterate quickly. Really, to be able to keep up with competition, you need to be delivering software quickly, or changes, features, however you're adding value and delivering value to whatever your customers may be.

If you think of traditional ways of developing and delivering software, there's a lot of roadblocks and hurdles and gates and stuff. You want to be pushing as much as possible, out to the edge some of these responsibilities. At the same time, especially from the security side of things, not everybody's going to be a security expert. It gets to thinking about how can you enable teams to have autonomy to build and release quickly, but doing so in a secure manner.

If you can automate and think of things, infrastructure as code, or maybe everything is code, and then you can start templating how you're building things. Default servers, default network rules, IM policies, all of this. You can have that for developers to use and your technical teams to use, so they can start getting things out quickly. That does require again, that culture shift of learning some new things. I mean, being able to code is very highly in demand, I think, from everyone on the security side, but things like Puppet or Terraform, or whatever you're using for managing all your infrastructure, I mean, it's a new way of thinking of how you're building and managing your systems.

[00:11:46] MC: Is it safe to assume that you guys are building everything from things like Terraform and the like, or there's still pockets where things are done manually?

[00:11:56] NL: For us, from the beginning, I think, we've had a fairly strong push to make sure everything is done as code. It's nice, because you can have checks in your build systems. It's easy to have peer review for everything, versus I can just think back to again, being at a larger corporation, filling out a big change management request. I think, it got reviewed by someone who probably didn't know anything about the change I was making, and then make sure all the fields were filled in and stamp it.

Now, we're able to have, it's a pull request in GitHub, it goes to someone else. You can flag people. It's checking for common mistakes when it comes to code, all of the standard static analysis stuff. You get all these checks automated, so you don't need to burn people on that. Then, you just need someone to review, make sure it's a sensible change. It can be your peers, so there's not a change review board for everything. That's worked really well for us. It does require a bit of a change in how you think of things. Really, all of that is a drive towards how do you empower your engineers, your developers to act autonomously, but I guess, with some guardrails, so you can keep them within bounds. Certainly, there's risk with doing changes that way. It's the same with any other way you would approach that. 

[00:13:06] MC: When you think back, that it makes me think of another question, which is when you think back to where you were seven years ago, you said that you've guys have built a lot of automation in from the start. When you think about the strategic focus of your security program, in terms of how far left you've shifted, where security is looking, has that changed? Or have you guys had a pretty consistent focus on trying to get things as close as possible to the developer in terms of security processes, tools, things like that?

[00:13:38] NL: Yeah. Well, when I started, we didn't have a security program, necessarily. At least, not a dedicated one.

[00:13:44] MC: Because there was no shift left.

[00:13:46] NL: Yeah. I mean, we started, I guess, fairly far in the – I think, with that directionality in mind. Certainly, there wasn't a lot of checks built in from the start. We have invested considerably in the basics against things like, dependency management from GitHub, making sure people get flagged and get automatic tickets when dependencies are out of date, static code analysis, so you can kill the OWASP top 10 type things in code.

We've probably been slightly less successful doing so on the infrastructure side, just because there's so many different variables on how people might need something configured that a lot of it has business context of why do you need this or that? We’ve been working on training developers and other infrastructure teams on security best practices. I think, part of it is knowing that if you're not in the team, you're not going to be a security expert. We do want people to be, I would say, knowledgeable enough to know where something might go wrong. At least they know, “Hey, I don't know enough about this. This seems like an area where if I make a mistake, it would be important. Can I get a second set of eyes here?”

I think, we've been really pushing that. A lot of it ends up being ensuring that you have the right relations across engineering and the business. Because if people think you're just going to make their life horrible and say no, they might just push that stuff live without anybody knowing. You want to make sure that they feel comfortable that you're a good partner, and you'll be collaborating with them to come up with the best solution.

[00:15:16] MC: On your LinkedIn profile, which I was obviously trolling before this interview, you mentioned very proudly that you were named, “Annual MVP award winner by the sales organization two years in a row.” What's this about? How is it that someone in security has garnered favor with the sales team two years in a row?

[00:15:37] NL: Yeah, that probably is a bit of a rarity, now that your highlight it. I guess, it goes to not having a security program when I had originally started. Part of why we needed one was obviously, want to be secure. It starts being a blocker in sales cycles. Especially maybe seven years ago, it was less common that companies had, say, a SOC2, or ISO, or whatever certifications they were doing.

That was one of the main goals of starting the security program is we certainly can't be losing sales, because people don't have enough confidence in us. At the same time, I think, we're a 200-person company or something, or 300-person. It's hard to convince a Fortune 500 that you're going to take care of their data and be a good custodian if you don't have some way to prove it. A lot of that was working with the sales team. Again, building those relationships to understand what are some of the concerns, meeting with a lot of customers and prospects to understand their concerns, and then aligning that with a security strategy that we can implement.

I think, the big thing was moving so quickly. I mean, we went from not having a security program to doing a – we did it as a three-month timespan SOC2, but we went right into a type two SOC2. We're able to really remove that as a blocker for sales. Then throughout the next year or two, it was building a lot of collateral, building training for our sales engineers, so that – I mean, there's common concerns that are going to come up from when you're having a team at a large company evaluate a new vendor. There's common concerns of how are you doing vulnerability management. If you have an audit, what does that mean? How do you manage your secrets? Educating them on what we're doing and why. It went from it being a blocker, or at least a major slowdown for a lot of sales to not. That in my bubbly, effervescent personality, I think, are really what made those words.

[00:17:30] MC: Security was actually a differentiator, right? I mean, at the end of the day, that's what it sounds like.

[00:17:35] NL: Yeah. I mean, that's it. I mean, now, it's table stakes, right? If you're dealing with anybody's confidential information, I mean, especially if you're not a major player, although they all have this sewn up as well. If you don't have some audit and report that you can show somebody, that's a red flag. Maybe not a deal breaker. We all know that being compliant doesn't mean being secure. At the same time for a lot of companies, doing vendor security checks is – I mean, it's a check the box type of thing.

Making sure we can check the box and then having a more full featured framework, so that when somebody does dig in deeper, we actually have sound answers and reasoning and a plan in place for any of their concerns.

[MESSAGE]

[00:18:20] ANNOUNCER: Prisma Cloud security infrastructure, applications, data and entitlements across the world's largest clouds, all from a single, unified solution. With a combination of cloud service provider APIs and a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructure’s code templates, container images, serverless functions, and more, while gaining powerful full stack runtime protection. This is unified security for DevOps and security teams. To find out more, go to prismacloud.io.

[INTERVIEW CONTINUED]

[00:19:12] MC: You mentioned that you've been at Tradeshift for longer than the average tenure of a CISO. You've led security and compliance efforts, as you just mentioned, I know looking at your website, GDPR, SOC1 and 2, ISO 27000. How do you maintain all of these different compliance standards at scale in the cloud?

[00:19:33] NL: Yeah, that's a good question. I mean, part of it is we have a compliance team who's really focused on that. They're also doing sales enablement in some of these things that I've been previously building out. I think, it again gets to – when you talk about 'at scale’, I mean, you can manage it. I think, part of what makes us good at it is that we're doing it with I assume, many less people than other companies are. I think, we owe a lot of that to again, the automation having everything in infrastructure defined as code, because now you can do programmatic checks.

If you're looking at doing firewall rule checks, or security group checks, or network policy checks, whatever they are in the different systems. All of this is codified. Now you can build systems that can pull it out and can show proof of compliance across the board. 

I think with cloud providers like AWS, or GCP, or Zero, or whatever, that you have tools now that you can again, pull all of your configuration settings. I mean, it's common stock now that they can look for a basic security issue, so open buckets or what have you.

We also have PCI for the virtual cards that we use and generate for our customers, and having all of these tools that are able to span all of these different accounts, it really reduces the legwork. People aren't logging into individual servers to pull proof anymore. It's looking at the tooling. That really goes back to automation.

[00:20:52] MC: I'm curious, is this – I know, I asked you earlier around just what was the evolution like? How automated were you and how far left has security shifted? Maybe another way to look at this would be metrics, right? How are you, other than just looking at hey, SOC1 and 2, say X, Y and Z. I'm just curious, with your program, again, it has all these different certifications and compliance efforts, are there certain metrics that you track? Obviously, there's thousands of them that could be tracked. Are there any key metrics that you look at?

[00:21:25] NL: I think, for metrics, like you said, there is thousand, right? There's all the different things. I always struggle with, okay, I want to make sure we're measuring meaningful things. Then, you also have to look out for – you get what you measure, and sometimes that can be unintended. I try to think of how can we have a countervailing measure? If you're just looking at maybe time to patch, that's great if people are patching stuff immediately. If you're not taking into account severity, exposure, other mitigations, what have you, I mean, you can really kill developer velocity too, right?

We want to make sure how long our pull requests for these things sitting open, things like that. I think, some of the major things when we look at our threat model, and what we can measure to have a good idea of how secure we are, one is just how long our vulnerability is open for. I think, that's much more important than at least for critical and high vulnerabilities, that's much more important than the total number of vulnerabilities, because that's a number. I guess, it’s something you can measure, but it doesn't necessarily mean you're secure or insecure, because are they exploitable? If it's a low severity one, then it really doesn't matter. Also, probably not super important to measure.

I think, for our overall program, the biggest one I look at is for critical and high-severity vulnerabilities, how long were they open before they get closed? Then it's something that you can offer as a business trade off. Because for any of this, there's some amount of risk. If you're going to have it open for a week, there's some amount of risk, and you can actually lower that, but now you need people to do that. Some of this is how do you translate it to business metrics that can be used by the exec team and the board, whatever to make a decision and get visibility to what does our residual risk look like here.

[00:23:11] MC: As a fintech startup, you mentioned this already that your engineering teams, they need to move fast. I found an article that you wrote back in 2014 on Medium titled, “Transform Technical Debt from Burden to Tool”. I'm going to read you. This was my favorite quote from the article. I think, our listeners should go and go and find this back on Medium. It’s called “Transform Technical Debt from Burden to Tool”. This is my favorite quote. “You need to keep a balance between being responsive to the immediate needs of the company, and providing the longer view, ensuring that the infrastructure your product is delivered on is efficient, supportable and scalable.”

Assuming that you still agree with that statement, how have you built a culture that supports innovation and speed, but at the same time, one that's also secure and compliant?

[00:24:05] NL: Yeah. I mean, I think I haven't read that one in a while. Clearly, I've done a lot of writing since then, if that's the main post.

[00:24:11] MC: It might have been the only post. I don't remember.

[00:24:13] MC: It's the only one. Yeah. It used to say, wait for part two, which never really came. I think, when it comes to technical debt, the biggest thing is making sure everybody understands the trade-off. I think, a lot of this is true, whether it's engineering technical debt of you just have something that is hanging there that you need to fix, or maybe it's a medium severity vulnerability that requires a larger upgrade. Do you push it or not?

I think, visibility to that trade-off is probably the most important thing. It's very easy to say, “Okay, we'll get to that later,” push it to the backburner in lieu of whatever it is, a feature that needs to be developed, or some other more urgent fix. Having that flexibility is really important, because at the end of the day, you're there to run a business and be successful and deliver value to your customers.

The problem ends up being when there isn't visibility to that pile of debt that keeps working its way up. I think, it's one of those situations where it's fine, until it's not. I guess, if you look at log per day or something as a recent example, if you have become super far behind in all of your systems, you haven't been investing in automation, maybe you're using an insanely old version of log for – I don't know if there's braking changes or not. For some of these systems, the longer you let them get out of date, the heavier lift is, and now you get hit with whether it's a critical vulnerability, or a customer who really needs a function that requires now dealing with your technical debt.

If you haven't stayed up to date on that, suddenly, you're now in a very bad place, if you're critically exposed and it's a six-month project to update things. I think, when it comes to technical debt, the biggest thing that we've done is really try to make sure that there's continual visibility to that. I don't know how successful we are. The human psyche is very good at pushing away things that aren't concretely a problem right now. We do try to make sure that teams are aware of these tradeoffs, and that we're constantly keeping that as part of the decision-making process of how much is too much? When do we need to make sure we're actually spending time to work that down?

[00:26:19] MC: How do you keep those lines of communication open? I don't know the organizational structure for your team, versus the DevOps team. What do you guys look like organizationally? How do you keep those lines of communication open?

[00:26:30] NL: Sure. I mean, we have an application/product security team. Then, there's a infrastructure. I guess, probably, people call it Cloud Sec nowadays, but focusing on that end of things. We work very closely with the partner non-security org. For app sec product security, they're working very closely with the product teams and engineering more broadly, and then on the infrastructure cloud sec side with our DevOps team. I guess, that probably goes against the paradigm of DevSecOps of having specialists. I mean, I think when it comes to the reality of it, security is a fairly specialized field, and not everybody's super interested in being an expert. There's that.

Maybe back to your original question, one of the things we've done for making sure that communication lines stay open is we have someone from our team who's part of the – we have a crew tied to software development lifecycle. When we look at our SDLC, what are the requirements for updating dependencies? Do we pin version so that you don't break anything, and you have deterministic builds? Or do we only pin major versions, and you take some risk there, but now you don't have to constantly be updating all of these dependencies? I think, having those close lines and really working together with broader engineering, or technical organization, just as another problem related to how are we building and managing software. Security is, we like to think that we're special, of course, and we are. As much as you can relate it to general engineering practices, or the general practices of the broader org that you're working with. I mean, I think you're always going to be more successful.

[00:28:03] MC: Do you guys have any concept of any – besides the goal of having a product and platform that’s secure, do you guys have any types of shared goals, or shared metrics between those other different organizations and security?

[00:28:18] NL: That's a good question. I mean, I think the vulnerability one is probably a big one with the broader engineering side of things. When it comes to my compliance team, it's when we're doing our quarterly checks, how many things are we finding? Because that's a bit of a leading indicator of how well we'll be doing for our audits. That is a leading indicator of problems that we will have or not during the sales cycle. I think, those are probably the two bigger ones. Again, there is a lot of different metrics we do measure and could use. I think those really, if I were to summarize the joint goals that we want to have to know if we're doing well or not, those are good. 

For a while, we were actually doing NPS survey. How likely are you to recommend working with the Tradeshift security team? We were sending this out just to everyone that we work with? If it's engineering, or professional services, or what have you. I actually still really like that metric, because the more people are happy working with you, assumably, it's because we help them be more secure. We're removing blockers, we're adding value. It's not one of those metrics where again, I feel very questionably without context, any single metric can be abused.

I think, something like that has been helpful, because it also pushed us to make sure we're being helpful to other teams, proactively reaching out, making sure we're following up and not just telling people what to do, but making sure they understand why we're doing things and collaborating on solutions.

[00:29:37] MC: I love that. An internal NPS metric.

[00:29:40] NL: Yeah. It was definitely met with some questionable looks when I first proposed that. Of course, people picked that apart, six versus seven, and what does that mean? Actually, it was pretty successful.

[00:29:50] MC: I mean, it sounds like a great idea. I don't know if I've heard too many other teams doing that, and maybe they wouldn't be interested in their NPS score. Maybe that's part of the problem. You didn't get to where you are today alone. I would love to hear from you, what's the best piece of advice a mentor ever gave you?

[00:30:08] NL: I mean, I think I have a couple of one, probably more strategically meaningful, and that was having empathy for whoever it is you're working with. In the sense of really understanding where they're coming from, what problems are they facing? How does what I'm looking to do align with that, or not? Using that to frame where a lot of times, we have things that teams have to do. Hey, you have to do X, because we're not compliant, or this or that.

Making sure that, again, we're framing it in the context that's native to the person we're dealing with. It helps you be much, much more successful. I mean, certainly in security, in every other field, but definitely in our field, where you're telling people to do things. They're busy. They have other stuff to do. They probably don't understand enough to even understand why this is important. Really relating to them and helping them understand how this adds value that could be again, through unblocking sales. It could be protecting customer data, helping them really understand what the implications are.

In the reverse sense, making sure you understand, hey, if I'm going to implement this control and impose it on a broad group of people, what is that impact? If it's going to make their life painful, making sure that I understand that and then I can make a smart decision, ideally with them on, is this trade-off worth it? If we think it is really painful, how can I help them by either modifying a control, or thinking through the process, how can we make it so it's amicably done on both sides?

I think, when I first moved out here to the Bay Area and took a job in a startup, that was one thing our CTO had told me, because I think I was maybe coming in a little too hard-charging and excited to fix things. Just that perspective shift was really helpful for me.

[00:31:49] MC: One thing I've learned myself from just reading many, many books on those that are successful in terms of leadership is that leaders consistently, usually have two traits. One is they've got a high level of self-awareness. Two, they are constantly learning. I'd love to hear from you. If you had to make a book recommendation, or maybe some of your favorite podcasts, how do you feed your learning?

[00:32:12] NL: Well, lots of reading. I mean, I have a shamefully large stack next to me of one quarter to three quarter read books. I mean, I think it really depends on, I don't know that there's one really great book for everyone. It really depends on an individual situation. I think, it's much more important, like you said, being self-aware, where can I learn the most? Then just having the gumption and willpower to go and read. I think, the times where I've taken breaks, it does take a little effort to get back into it, just like exercise, or whatever else. Once you get into it, and you're reading, I mean, that's the important thing, right? You're constantly learning. I think, in security and in software development these days, I mean, if you're not constantly learning, you're falling behind just as quickly. It's a must have.

 I think, if I were to recommend a book for people, like you said, that are maybe not quite all cloud native yet and are working to get there and looking to change culture and things like that, I mean, I think DevOps Handbook was one that really stands out to me, as just making sure you're really aware of how your systems are working and really thinking about delivery of software as systems and being efficient and looking at it as a collaborative system, as opposed to handing off between individual departments and the shifting left, all of those bits and pieces.

Yeah, Jean Kim, Jess Humble, I think they wrote – the unicorn project as well, which is the fictional adaptation of DevOps Handbook. That one was great as well. I think, those would be ones that if you're looking to move to a more cloud native mindset were probably a good place to start.

[00:33:45] MC: How about podcasts? Are you podcast guy? I recently put a poll out on LinkedIn asking, “Hey, I've noticed that in the last two years myself, I've traveled less. I've noticed that I listened to a lot fewer podcasts.” I asked my network, do you listen to more, about the same, less? Last time I checked the poll was, the majority of people were saying it's less than pre-pandemic. I'm just curious, is there podcasts that she listen to? Which ones might you recommend?

[00:34:12] NL: I'm not much of a podcast person. Honestly, when I – before pandemic, when I was biking to work a lot, I would listen to podcasts, but it was all Spanish stuff, because I was trying to learn Spanish at the same time. I found tangentially that listening to a Spanish podcast made me think enough while I was biking that it slowed me down and therefore, made me safer riding a bike in the streets of San Francisco. Yeah, no technical podcasts at my side. I mean, mostly just reading, I suppose.

[00:34:39] MC: Did you learn Spanish?

[00:34:40] NL: It's one of those up and down things. If I have a planned trip where that will be useful, I'll go and study for six months beforehand, and then it slowly fades away. I'm back in the lull here having similarly not been traveling in a couple years. I have to find a new commute too, because I don't go to the office anymore. That's definitely killed some of that listening time.

[00:35:02] MC: Everyone is hiring in cybersecurity. I know you guys are at Tradeshift as well. The real question, and we were talking about this before we started recording is, why should, if someone's listening and they’re part of the great resignation, they're looking to do something new, why should they come work at Tradeshift?

[00:35:18] NL: Yeah. We're talking about how it's probably better to phrase the question that way, rather than are you hiring? Because of course, everyone's got a million openings. I think, what makes it special, or at least very enjoyable for me here is having a team that's really cohesive. We work well together and focusing on partnerships with all of engineering, and then being a fast growth company, there's so much to learn. I mean, we have a million projects that need to be done. We are able to have a lot of flexibility of working within the bounds of what someone is interested in, if they want to focus on infrastructure, or vulnerability management, or detection, or what have you. I mean, there's a million ways that that we can run.

Really, the team is – I mean, that's why I've been here for seven years. I've never stayed in a place longer than three years before this. I just really like my team I work with and the company in general. I know everybody says that about the company they're currently at, but I think being here seven years probably speaks louder than anything else. Yeah. If there are folks listening that are interested in hearing more, definitely feel free to reach out. Happy to talk more and be delighted to chat.

[00:36:24] MC: Where can listeners learn more about you and Tradeshift?

[00:36:28] NL: The Tradeshift website is probably the painfully obvious one. Or if you'd want chat with myself, you can reach out on LinkedIn. Even if it's you're not looking for a job or something, if just to chat about specific concerns or talk security, I'm certainly open to that as well. Definitely reach out.

[00:36:43] MC: Awesome. Awesome. Well, Nate, it's been awesome having you today on the podcast. Thank you for joining us.

[00:36:47] NL: Great. Well, thanks for having me. 

[END OF INTERVIEW]

[00:36:54] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com.