This transcript was generated automatically by AI. If you find any mistakes, please email us.
>> Announcer: hello everyone. You're listening to CloudNext, your go-to source for Cloud innovation and leaders' insight brought to you by Global Dots.
>> Ganesh the Awesome: It's one thing to build a great product, it's another to keep engineering teams aligned, creative and productive. As you scale, how do you maintain speed without burning people out? How do you empower engineers to innovate without creating chaos? And how do you align all of it, technical work, production direction and business priorities under one roof. Our guest today has a unique perspective on all of that. Jonathan Spies is VP of Engineering at Cloudflare where he leads more than 240 engineers across some of the company's most critical products, including Zero Trust and more. With a background that blends deep technical understanding and strong product instincts, Jonathan brings a hands on people first approach to engineering leadership. I'm Ganesh, the awesome solutions architect at Global Dots where we research innovations every day so you don't have to welcome Jonathan. Super happy to have you on the show. I'm personally a massive fanboy because I use the products that you're engineering every single day. So I have like, a little bit of like fame in the eyes talking to you and we really appreciate you having you on the show. So welcome.
>> Jonathan Spies: Yeah, ah, thank you. thanks for having me. I'm glad to hear that you're getting great use, out of the products. That's one of the reasons that we do it is to hear that people are making great use of them. So thanks for having me.
>> Ganesh the Awesome: Not at all. so let's cut straight into it like you're leading a very large team of engineers across multiple products. Like how are you balancing keeping that many people efficient and giving them space to be creative? What has actually worked for you?
>> Jonathan Spies: Yeah, that's a tough balance, because it seems that balance between, you know, innovation and efficiency, because it always seems like you're sacrificing part of one for the other. not in a binary way but in more like a percentages way. We've tried a whole, a lot of different things. we've made a lot of mistakes and you kind of ebb and flow back and forth with one or the other. It's very easy when you're small in Greenfield to be very innovative and creative. you don't have the maintenance, tasks to do, you don't have all the feedback coming in from eight different ways, or all the bugs getting piled up or the technical debt that you've accumulated, that get in the way of efficiency, and so you have to figure out how to produce those things. So I guess the things that have worked and we're still looking for ways to improve this, but I guess two things that have really worked, well, ah, is keeping teams small, which I think is becoming an industry standard or maybe even has been that people think about can I have these small teams? There's like the famous pizza sized teams, like can your team eat two pizzas? And that's the size of the team. but I think what we see in there is, is this, the second step of that is really giving those teams as much autonomy as possible. It's not just the size, it's also what they, what their responsibility is. So I try to give all of my teams as much autonomy as possible to make decisions on the fly and to move quickly and to make their own mistakes. And some teams will run at a different, say, efficiency level and some will run at a different innovation level. And what I find is if you've got 12 teams building a product suite together, you don't need every team to be innovative at the same time. You need some teams to be innovative, ah, at a time so that you're constantly innovating on the product as a whole. And so there's this also this up and down in those small teams. so then I think the second thing that I found that works well for us is making sure we have the right balance of engineers, between what we call fungible engineers, engineers that you could put on any project, and get results and versus deep subject matter experts. You need both on a team. There's definitely room for both. You need people who are going to sit in one area for a long period of time and learn everything there is to know about that technology and that product case and the use cases. and that's where you're going to find really deep innovation on what's next for that product. But then you have other engineers who can work on any product at a higher level and you can shift them around these teams as you need to produce more across the org. So those two things are techniques that we've used in building an engineering org to help with this balance between innovation and efficiency. And I think layering on top of both of those techniques is this just idea of alignment and communication is very important for the autonomy and the fungibility aspect. Right. If everybody's rowing in the same direction and has the same goals and can communicate them to each other, then you're going to find that balance is a lot better and you're going to find a lot more innovation in what you do.
>> Ganesh the Awesome: I, I, I always find it super interesting to know what didn't work or what was a war story. And you mentioned as part of that that you, you tried some things that didn't work. What, what didn't work at that scale.
>> Jonathan Spies: what didn't work at the scale for efficiency. I, I, I, something that I hear a lot that in my opinion doesn't work. And I hear a lot of people talk about it in my own company, in my experience in other companies, talking to other leaders from other teams is a lot of people try to assign a percentage of work towards like maintenance and technical debt and then, and that will take care of the efficiency aspect. and they'll say okay, well we're going to say 60% of our work is innovation and 40% is like the task that we've got to do and that'll keep us efficient and it will keep us from, from stacking up technical debt. I don't see that working. I don't, I've never seen it work. I don't see a world where it does work. the business world is too fast paced and changing. You have to respond to interruptions, you have to respond to tactical changes or strategic changes. And I, I just, I don't, I don't see that as a viable way to run a ah, team but it's one that I've tried and I've also just heard a lot of people try all the time. Another one is like, is very heavy process. You think that oh, if I can make a really streamlined process we'll get really efficient. and being more efficient will give us more time to innovate. and I think that's true. Being more efficient will give you more time to innovate. But I don't think that a, a heavy handed process will help you be more efficient. I think it will make you be less efficient and that's one that I see. I'm a firm believer in just enough process, that that's, I don't know if that's something people say, but it's something I've been saying for years. Whenever my teams ask me, I say just enough process, like what's the bare minimum that you can do and can you automate it all process needs to be automated. If you can't automate it then you're just, you're just putting paperwork on your engineers or Your other employees, desks, and that's just going to slow them down. So those are the two things. I've made the mistake and other people do too.
>> Ganesh the Awesome: That's a good segue because, you know, we're talking about Cloudflare and Cloudflare is kind of unique scale. You know, there's not so many companies your size, generally globally. those small and mid sized companies, what can they do as a practical step so they don't fall into this trap of too much process?
>> Jonathan Spies: Yeah, I think it comes down to your people, you've got to be able to trust, your people to do the right thing. So for me, you know, the easy answer is, hey, you could, you could escape this trap of too much processes if everyone knows what to do. All right, that, that, that sounds a pie in the sky. so I think that for me the question is, how do I, how do I get to the point where I can trust, my people to do the right thing? and there, there's some things that you're never going to escape, especially at scale. You're going to have compliance and regulation and there's just, there's just process that you have to do. and then you're going to have things that you want everyone to think the same way about, that you're not going to escape. I guess a good example of one of the things that we have that feels like a lot of paperwork but is really important is we write our functional specs, and we have a template. And the template has all of the things that you should think about for every project. And some of the sections don't apply to every project and that's okay, you just can delete them. But if, but by requiring people to start with that, it forces them to think through it all and make sure that we're thinking together. I think the real question is how do you build the culture to do the right thing, without too much process? I think that's kind of, how I think about it. And my team in particular has grown a lot in the last couple of years, kind of doubling each year, the past couple of years. And we have to really think how we do this, how we keep this, engineering culture. and I think one of the things we have to be really cognizant, of and planned well is the people that we bring on, when we bring them on and who we bring on at certain times. If you double your team and you bring, say you have 10 people and you bring 10 more people on at the same time, you're going to have a totally different culture than when you started. It's going to be a new culture that's a mix. and that, that maybe that's okay. but there's some things you want to maintain in your previous culture if it was working for you. And so you want to make sure that you're bringing people on staggered. But also, you know, what experience level are they? Do they have a similar culture already? Are you bringing on five juniors at once or five senior engineers at once? And which ones fit into the culture more quickly? so we're very careful with, you know, we need more people to move faster. But we also know that if we bring them all in at once it could really change how we work. So we kind of stagger when we bring people in, bring them into the, bring them into the teams. We absolutely want their new perspective. I'm not saying we're like for all the Star Trek fans, we're not like assimilating into the board. We want new perspectives and skills, but we also want to bring them into things that we do well. And that's something that we're really thoughtful about and my team is thoughtful about as well. I think that's really important.
>> Ganesh the Awesome: It's interesting talking about that process trap because actually whenever I see a large enterprise wanting to break into a new technology, they do the exact opposite of following process. So like the last big obvious one was cloud computing and all of these big guys, I won't mention names because it will reveal people who I'm talking to to business. But very large shipping companies on a global scale, they want to start something in aws. They don't follow their own processes. They create a little side project for innovation. So I think in some way like abundant innovation and lots of process, are an awful thing. But then sort of unchecked innovation just going, going completely wild, you can't then bring it back into like corporate control. So it's kind of, yeah, some, some sort of chicken egg type situation. With innovation.
>> Jonathan Spies: It's always I, I, first of all, I love that model because I, I think that you need to find out very quickly if your new idea is going to work. And putting all that process in place before you know if it's going to work can just be a waste of time. Right. And so I, do like that model and we use that at Cloudflare as well. But you're right, you have to. It's very hard to know when do you flip, you know, when do you switch gears to say, okay, this is sticky, this is going to work? Now we need to, you know, put the process in place for replication and efficiency and getting all the go to market engines spinning up around production, product and engineering. It's difficult to know when. It's always easy in hindsight, but in the moment it's hard to know when. So you're absolutely right. There's a balance there as well. And I mean that's kind of how I run my life and my career is. I think there's a balance of pretty much everything that we do. And knowing when to switch from one to the other back and forth is the difficult and the challenge and the fun of what we do.
>> Ganesh the Awesome: Yeah, I think if people decided to put loads of processes around having kids before having kids, they would just never have kids because they realized how much, how much process was involved with that process. so you mentioned in our prep call that you've always been a product orientated engineer, particularly focused on things that people will actually use, which makes a lot of sense. But how has this mindset influenced you, in your role today and how would you encourage others to think the same as you?
>> Jonathan Spies: Yeah, I think, I mean, I think there's definitely, you know, benefits to, to thinking that way in terms of building a, a big product that a lot of people are going to use that has wide appeal. And I'm, I'm happy to encourage others to think that same way, but I don't, I don't necessarily think that everyone needs to. I think there's a place for all different, you know, viewpoints and personalities and passions, in what we do in our industry and in any industry really. And I need those, I need the engineer that is going to sit down and dig into like, you know, the annals of legacy software and solve really complex problems for no reason other than the challenge of it. I need those guys. They make me look good. Right? Like they're, it is important, to have them on your team. So I don't, I don't think that everyone needs to think the way I do. I think having the, the, the differences is good. I will say that I think being part of a, part of being a good business leader in engineering means having that viewpoint, but it also means recognizing that people are different and putting the right people in the right places. So I think that's, that's really important to, to start off with is, is. I don't think you have to think this way to be a great engineer or technologist. but I do think it helps when you're in the business world and you want to look towards leadership. So I think what's helped me m, that mindset has helped me in the way I lead today is I'm a huge proponent of putting something in the user's hands as soon as possible and not being afraid of of, of mistakes or errors or just suboptimal approaches. I hear that phrase a lot from engineers. Suboptimal. I'm cool with suboptimal because that's how you learn. Get in the user's hands as soon as possible, get the feedback, don't let perfect stop you from being great. I see that often. and so I've taken this sort of kind of startup mentality and used it at a large scale as well. because I think it's so important to be used and seen early and often in everything that we do.
>> Ganesh the Awesome: Yeah. And as a reseller, integrator and overall user of the Cloudflare platform, it definitely has that feel about it where the innovation and the features ah, are almost coming out too quickly to handle, but then at the same time they're nowhere near the finished item. and I think with other software companies people maybe wouldn't accept it as much, but I think actually you've built your own culture of users around it where we're like, okay, this is out, it's not quite finished yet. But we know Cloudflare, we're gonna add features to it. So you don't kind of, you don't bulk when you see a new thing come out that maybe doesn't have all the bells and whistles on it. So I think that approach definitely works. I would also say about the engineers talking about having the right ones in the right place if they're more introverted. I would guess that they are definitely not the people to be on sort of product orientated type things because that means you're going to have to face the product team. And I can only imagine that they're quite aggressive in Cloudflare. I don't know if you've got any comments on that.
>> Jonathan Spies: I mean I think everyone works with the product team. So the way that we work is we have product managers that they're not, they're not necessarily one to one with an engineering team but, but they're, they're not far off from 1 to 2 or 1 to 3. And so all the engineers do interact with product managers. But, but yes, Product managers, they want to get features out, they want to, they want to push the teams, they want to, you know, they want to innovate and that's great. We need that push. And sometimes engineers need to work on some technical debt I think, particularly in my world. with Cloudflare one and the security suite that we build, you know, resiliency is our number one feature. and so we often have this balance of, you know, speed of iteration with making sure it's up and available at all times. And engineers need to push back. And I have seen that with a particularly introverted or newer to the industry can struggle with that ability to push back and collaborate, with a strong perspective. and that's where we, I encourage them in every part to say, you know, what's right, you know, what's going on here, speak up. Use your team to speak up. one of the great things about engineering is even if it's a 1 to 1pm To a team, there's usually one product manager and you know, six or seven engineers. So we've got this cohesive front where we can make sure our point is heard.
>> Ganesh the Awesome: so talking about features, that's another good link into what's happening at the moment in Cloudflare. And sort of pre, pre, recording chat, we talked about some, some changes that are coming in there, particularly with access, ssh, IDP in a browser, just in time, workflows and some of these other improvements. what makes this stand out for you particularly and in terms of like real world problems you're solving, how does that look?
>> Jonathan Spies: Yeah, the the Access suite is, I have, I have a very soft spot for it because it's where I started at Cloudflare and I, I literally built, hands on, wrote the code, with the team, ah, it was a very small team where this was our very, you know, innovative stage where we didn't have a product. We're trying to figure out what that product looked like. And so it's been a long time since I've been hands on the code at Cloudflare, but that's where I started here. And so I've always got this place, in my heart for that. But also, not just, not just that, but I think that the Access suite, ztna, ztia, the way in particular that we build it at Cloudflare, leveraging our huge network, is a great user experience. And so many times in cybersecurity there's always this kind of sacrifice for user experience. You trade for security and people seem to be kind of okay knowing that hey, yeah, it's going to, there's going to be a few little annoying things, but it's going to be more secure. And look, sometimes there's no way around that. but I think in this particular suite in Access, not only is there a way around that, I think we've actually made the user experience better in some cases where using the full zero trust policy controls in the browser over SSH with nothing to install, no secure certificates to install, no client to install. It's actually a better experience for administrators and engineers, users alike, with how we can augment the SSH process. And I just think that's exciting to see that we're moving forward in security with high security and better experiences. and I don't see that in a lot of places, in the cybersecurity world, including some of the things that we do right, there's trade offs we always have to make for security. But, but I think that's what makes this space so special is you know, putting lower level protocols in the browser makes it easier to onboard contractors or remote workers without needing any device management. putting just in time workflows allows you to onboard your employees without like massive paperwork trails on day one. you don't have to give them access until they, they ask for it and they don't have to ask for it. With a complicated ticketing system they can just go to the thing they want to use and it's got their identity and their reasons for access. And I just think it's a great place where we're going to see more and more advances in experience and distributed work. so that's why I'm really excited about it. It's continuing to get better and better.
>> Ganesh the Awesome: Yeah, I would echo that, the general, just through the browser stuff as I would like encapsulate a lot of that, you know, totally sits in Cloudflare's world obviously because everything prior to that was about web based, you know, browser based applications already. So you're in this sweet spot. But just the things that are possible now were like black magic five years ago. I mean if you showed somebody, you know, using SAML authentication through a browser to get direct SSH access to a server, it would have been like dark magic five years ago. So I think it's pretty interesting to see where it's going to go in the next five years because I feel like more and more does the browser is going to be the way for everything essentially, including internal apps, including code repos, everything. I just don't see that the, I don't see that the future of things is installed apps on computers basically. I just think it's all going to be somewhere else. and I, I feel like you're at the forefront of that.
>> Jonathan Spies: Yeah. And I think that the browsers are the, you know, the companies behind the browsers are doing a great job with you know, expanding what it can do in a, in a great way and that helps us move along as well. Security advances like tab sandboxing and bringing in like quick protocols, you know, early. Those are great things for us to, to be able to move forward quickly as well. I mean we've got customers who have been moving to just Chromebook deployments because a ah, significant percentage of their staff just needs the browser because they've already moved to this. And so we've seen a shift that way.
>> Ganesh the Awesome: I wanted to go back a little bit because we talked about alignment in the teams and you have a lot of teams, you have a lot of products, you have a lot of priorities. How do you align all of these? What helps you keep alignment strong and what advice would you give to the leaders who are struggling with this sort of technical execution?
>> Jonathan Spies: Yeah, alignment, alignment can be, can be tough. This is another one of those areas where you know we've tried a lot, I've tried a lot, failed a lot, found some things that worked well. I love to say I have it all sorted and give a playbook but we're always developing it and it changes as your size changes and your org design changes. but I think there's some, some, some, some principles that work that are important. I think one is no matter what size you are, you, you have to have a strategy that's longer term than your current projects and that doesn't change when your tactics change. And I, I think if you step back and think about it that's kind of obvious. Like it feels obvious that that should exist but in the heat of the work it's, it's not always true. So you have to really put in the thought to make sure that the strategy is high level enough to not change when the tactics do. And I, I think as a leader that helps you communicate. if you have this thing that you can point to for at least a year then you can communicate the same thing often with your team. That this is the goal, this is where we're we're looking towards when interruptions happen and fires happen. You don't have to change your strategy, you don't have to change alignment, you may have to change priority, but the end goal is the same. And that's important to communicate as well. I, I, I think that there's, there's, there's, there's nothing more than communicating with the group. And that gets really, it gets difficult as, as your group gets bigger when it's, you know, five people in a room every day. When you're starting something out, it's really easy. and then as that, that grows, you have to, to figure out how to do it. So, so one thing I do is I keep a small, tight group of direct reports between four and six. I don't go big and wide and enough that I can see them very frequently, multiple times a week and we can speak about the direction and the strategy. And then they have to do the same thing with their layers. They have to, to communicate that same strategy all the time at the same time. I don't want to risk a game of telephone where the message gets mutated every time it's told or passed on. So I also have to find ways to spend time with engineers on the front line, communicating and asking them and listening to them about how their work fits in with the goal. if they can't articulate it, if they don't know, or if their work doesn't fit in with the goal, then that's where I know. You know, I've kind of made up, or made a mistake in that telephone game. So I trust that my team will communicate, but I also go verify and try to spend time with engineers. honestly that's the thing I miss the most about my current role is daily time with engineers. And so I find kind of, creative ways to spend time communicating with engineers. in groups, small group settings. I do a lot of Q&As with teams, and I love those. They'll ask me all sorts of crazy questions and then I'll ask them questions about their work. we've also done this thing that I call an interactive read through where we get on a big video call together and we read a non technical document like a business document or a proposal or support, a report on support and we'll, we'll talk through it as a group and ask questions. And I think that's really important too is engineers need to know how the business works. and I think they want to and I think so Many times they get left out of those discussions and I think that hurts the alignment. When they don't know what we're, what we're trying to get to with our financial goals and our revenue goals and our support goals and other departmental goals. I think that really breaks up the alignment. And so I, encourage everyone to speak to their whole team about what they're actively trying to do. And you may have to teach people what acronyms stand for, and what they mean and how they work and, and I've just found that engineers really like to hear about it and they, they really want to dig into it. and it helps them align and it helps them make decisions day to day because ultimately that, that's what the alignment is for. Someone needs to make a decision today. You talk about, we talked about efficiency four questions ago. Someone needs to make a decision today. You want them to be aligned, to be able to make the right decision there on the spot instead of going up the chain. If they have to go up the chain for every decision to find someone who's aligned, then you're not going to be effic. this is so important to the autonomy and the efficiency we talked about earlier is do the engineers know your business goals and do they understand them? It's really important. that resonates with me. That's a lot of what we do.
>> Ganesh the Awesome: That resonates very, very well with me actually. And I previously worked for a company here in the uk, the Racing Post. And one of the main drivers was, it's a sports betting website but the main driver was to get on the bet slip on the page as many integrations as possible so we could get as many referrals from as many different gambling companies as possible. And it was just known inside the business. And we went about. The bet slip was a nightmare and we had to rebuild the bet slip and we, you know, it was sort of early days of APIs and we rebuilt it as an API based thing so very sort of recomposable parts and blah blah, blah to make the whole thing quicker. And we neglected to actually tell the engineering teams what the business driver was. They were all told that they had to rebuild the bet slip as an API and got all the diagrams and the schematics and whatever. But we missed the point and eventually came back to us. Then they wanted to know what, why on earth we were doing it. And then we, we did have this session where we explained that the only way we really make money is through the bet Slip. So for us to make more money, this is the most important part of the website and that sort of reinvigorated the development team enormously. But prior to that. And distance was a problem as well because they were outsourced in another country. But the they were feeling like they very low energy because they'd already built a bed slip and they didn't, didn't know why we want to rebuild the bed slip. So we're asking them to rebuild a sort of critical bit of infrastructure without any explanation. So yeah, that resonates a lot with me and definitely overlooked I think in terms of business teams to passing things to code monkeys essentially. You know, they want to know what it's for.
>> Jonathan Spies: That why, I mean that why question that you hit on a few times is so important. They, they need to know why. And it's not just. I mean I cropped up. Curiosity is one of our core things we look for even when we're interviewing. We want everyone to be curious to ask why all the time. but not just to satiate some curiosity, but to use that to be, to be better. I'm only as good as each one of my engineers in what I do and what I build. and so yeah, you hit it on the head to answer the question why is so important.
>> Ganesh the Awesome: again, we love to have a good war story on the podcast and in the pre staging we had a great one from you.
>> Jonathan Spies: I would love to. I need a little bit of reminding what the story was. I've made so many mistakes in my career.
>> Ganesh the Awesome: Love it. Good. Just start from the top. No, you you're working for a startup. It was a, I believe a financial transactions company.
>> Jonathan Spies: Yeah. Yeah. I'm happy, happy to talk about, you know first I want to say I think that m. I think that mistakes are a huge part of our success and they feel terrible in the moment. But I, I don't I don't think I would be where I am today without the mistakes that I made. and so I think that's important and, and it's nice that I can look back and laugh about this because it was not a laughing matter when it happened. But yeah, this particular war story, yeah, we were taking transactions so two parts of the company. One was point, ah, of sale order transactions. The other side was processing the payment, ah, gateway, with processors. and we built both functions. They were more or less independent systems that worked together. but we, we had a large scale, we worked a lot of large events. And so very peaky, very spiky traffic. you might be processing, you know, one order a minute at one point and then 60,000aminute the next minute. and up and down based on what events were going. And you know, Friday night, Saturday night, sports nights in America, those, those numbers skyrocket into the number of transactions per second. And so we had to build a system that could, could handle that with a lot of older dependencies on on payment processing. And this was a huge lesson for me with third party vendors and dependencies. When they worked they worked. And when they didn't work, you know they didn't work. And we wrote systems that could handle both and could queue up and do retries and, and be very safe. and then one day one of these processors started looking like they weren't working, but actually working to process transactions. And so they would take 30 seconds, a minute, two minutes to process a transaction. And our system would hold on as long as it could and then mark it as an error. And so it would go back into the retry machine and we would do these retries and, and not, not all. Some of the modern payment systems have idempotency built in where they do the check for you. this particular kind of legacy system did not. So, so we ended up with these, all these payments, in an unknown state. And some of them had gone through and some of them hadn't and we had no way to know, and there was no way to automatically query. And so our system just kept running overnight and charging and trying to shore all this mess up. And you're right, we woke up in the morning and people had been charged 2, 3, 4 times for the same order. Now luckily these were events and most of the orders were not huge amounts, but it was still PR nightmare. And then we also ended up in a war room with engineers kind of manually working through this with the payment processor for days afterwards. very little sleep, lots of manual work. and then we ended up in the newspaper, of a particular town with a small town in Texas with a huge American football team. And half the town went to the football game and got double charged. And so it was all over their local news and it was rough. And it was the first, first time that I, in my career as a leader of, of a group that had made a mistake, had to go and you know, talk with almost all of our customers, one on one about it. And and really approach with humility and and making sure that we could learn a lot to keep it from happening. And so that mistake was huge in the moment, but it taught me so much about we had this hubris where we thought, we thought of everything that could happen with this dependency that we're accounting for all of their mistakes and failures. but we weren't. And I think the lesson is that you can't. There's always going to be errors that happen and you have to, you know, build systems well, that almost know how to handle the unexpected. And I think it taught us, taught me a little bit about humility and realizing that you're never going to build a system that can handle everything that could be thrown out at you and you have to have these kind of fail safes, just to know what you're going to do when it fails. And we didn't. So that was fun. I mean in retrospect it was fun. It was horrible in the moment.
>> Ganesh the Awesome: Yeah, yeah, no doubt. interestingly actually I spoke to somebody last week specifically about doing these war room emergency situations, which is missing from a lot of companies definitely where. And she was saying even like once a week not to do a whole war room, but just do half an hour simulation of what does a sort of P1 incident look like and how do we respond to that? To sort of build up the muscle memory of who needs to be involved and how you react so you're not in full blown fight or flight mode when it happens. And yeah, quite an interesting perspective. I would have never imagined that you would need to spend half an hour a week on that. But then you see these ransomware attacks that happen and we've had a couple of really high profile ones in the UK recently knocking off like major supermarkets for months basically on their online deliveries. And they were just handled very badly from the beginning, like handled really badly. because they weren't practicing that. So I think there's kind of way probably over time is spent thinking about the technical vulnerabilities and then under time spent thinking about kind of emotional slash, human characteristics of dealing with those kind of events. So yeah, it's definitely interesting.
>> Jonathan Spies: Yeah, you, you, that, that you've got to practice it. You want it to be muscle memory, you know, you want it to be automatic when, when it happens for real. And so I like that. we do something similar. We don't stage war room events but we. So we have our first production environment we call Dog for Dog Fooding and only Cloudflare employees use it. And we have most of our incidents there. and we treat those as if all hands on deck. It's as if it went down globally. and so we, we end up getting that practice whenever we find something in this sort of, you know, pre customer environment. and, and you, you, yeah, you build up, you get better at it. It's a skill and it's something that you do enough, you get better at. and if you're not making any mistakes, then you've got to, you got to fabricate a war room incident so that you know how to do it when it does come, because it will come. And everyone should, should, should realize that it's going to come if it hasn't and you need to know how to do it.
>> Ganesh the Awesome: And if you're magically not making mistakes, we salute you. Somehow I don't know who those people are, but wherever they are, so we come towards the close of the episode and we always like to ask our guests the DeLorean question, which is, if you could go back in time and give yourself one piece or more of professional advice, what would it be?
>> Jonathan Spies: Oof. This is a, this was a, this is a tough one for me because like, like, like I said, I didn't do everything right. But like I said, my mistakes are part of my success. And so I don't want to go back and give myself, like, here's some advice to avoid these mistakes because they're such important moments in who you are, I think. But I think what I would say, an advice I would give to others is, to really entrench yourself in the business side of software earlier, if that's what you want to do. Right. because I think we all got into this for technical reasons. Very few engineers I know got into it, got into programming specifically for some business goal. And that does exist. But I think most people got into it because they wanted to create something, something technical or like a game or they wanted to make, you know, some database for managing this thing that they had that they wanted to track or just the love of solving problems is a big one. So these reasons that we get into programming aren't necessarily how the business runs. And the, advice I give to myself is to dig into that earlier. I think it would have helped me move a little more efficiently in the product sphere and really connecting with customers. I think it took me a while of my career. I've always been good at listening to customers about requirements. but I think it took me the early stages of my career to really get into the customer's shoes with their business problems so that I could help solve them with products. And I would push myself to do that earlier and not shy away from it. And I think it would have helped me with a few things like technical problems where I really tried to solve every problem with great engineering or technology when really like throwing some money at it would have probably been a lot cleaner. or going too deep and spending too much time on what us engineers like to call an elegant solution on something that had no potential to return a same sized yield. Right. Like, and realizing that while I had a lot of good times doing that technical project, it really wasn't as impactful to the business as if I had thrown up some, you know, script that I wasn't proud of, but got the job done. and learning to prioritize and I guess what I'm saying is like learning that prioritization early, I think it's something I've developed well now. but learning it, learning a lot earlier would have, would have gone a long way.
>> Ganesh the Awesome: And I think that will probably resonate with a lot of people because as said, most people didn't get into this because they wanted to be involved in some sort of business process. It was, it was more for the love of technology than anything else. and those people bits sort of come a bit too late. But, very wise words. Jonathan, you've been a pleasure on the show. Any parting words before we leave you?
>> Jonathan Spies: No, I feel like I've talked a lot. I appreciate it. Thank you for having me. It's been great. You've been the questions have been really good to think back and to kind of think back through my, my career and the, the times that I've had, it's been, it's, it's been a really good process. So I appreciate that.
>> Ganesh the Awesome: That's it for today. Thank you all for listening. If you're ready to rethink your cloud practices and cybersecurity strategy, then the team and I at Global Dots are at your disposal. We've been doing it for over 20 years. It's what we do. And if I don't say so myself, we do it pretty well. So have a word with the experts. Don't be shy. And remember that conversations are always for free. I'm ganeshly awesome. And this episode was produced and edited by Tom and sound editing and mix by Bren Russell. Stay tuned for more episodes.
