Mentorflare

Hi, everybody. Welcome to another episode of Cloudflare TV. If you didn't watch last the episode right before this, I'll reintroduce myself. My name is Ellie Jamison and I'm on the recruiting team and this episode we are introducing MentorFlare, which I'm really excited about. MentorFlare is a virtual series of conversations with different leaders at Cloudflare and some guests that we'll have throughout the tech industry. The main purpose of MentorFlare is to provide mentorship to the students interested in learning about Cloudflare, wanting to stay connected and also those that are interested in future opportunities at Cloudflare. So this company was born out of the last economic crisis in 2008 and 2009 and so we care very deeply about those students that have been challenged due to the current health and economic climate and so that's why we're doing MentorFlare. We want to empower those students by sharing our resources. So I'm really excited to talk to Tom Lianza and Aly Cabral and Tom, I'll let you go ahead and introduce yourself as well. All right, so I'm Tom. I'm an engineering director at Cloudflare so what that means is I manage engineering managers who manage engineering teams, engineers who actually do the work and build the product. I started at Cloudflare about five years ago. Really my first job, they asked us to describe our first job regardless of career, I served coffee at a drive-through coffee restaurant. I was not a barista, I did not make anything fancy, I just poured drip coffee. I got interested in computers sort of near the end of high school and I went to Carnegie Mellon, majored in information systems and human theater interaction. I loved web apps, web stuff and building things that people used, but out of school I ended up going to Cisco Systems, so a big networking company, probably not one you think of as consumer and friendly web apps, but I worked on web stuff there. Went on to work at F5 Networks, again seems like a hardware networking company, but I worked on the UI and config stuff there. Eventually left to do a startup in the old days in the web 2 .0 prime when everybody was building stuff in Ruby on Rails and I wanted to get in on that too and me and a friend did a startup. We were acquihired and subsequently acquired and acquired and about eight years later I was working for a big company in China that had bought the last version of our startup. After a year there, I quit and came to Silicon Valley. I wanted to see what the fuss was about, what the Bay Area was all about. I came to work at Cloudflare. For me, Cloudflare was, I was a customer. I used it at my startup, so I love the product and it was a company that I worked at big companies where I felt like I didn't have much of an impact. It was just a cog and I worked in small companies where I had a big impact, but every two weeks when payroll came around, it was kind of stressful and sometimes we passed ourselves over as co -founders. It was precarious. Cloudflare was in this nice sweet spot where they at that point were already well -known, successful, but still small enough to make an impact and that's really what attracted me when I met the folks here. They were really smart, kind, and I was astounded at how few of them there were relative to how much Cloudflare does on the Internet. That's the gist of my career path. I actually started managing the SSL team when I got here. Universal SSL, if you have a certificate from Cloudflare, that was the team that I managed. Over time, as Cloudflare grew, we needed more sort of structure and now my role oversees a good chunk of the control plane. When you tell Cloudflare, configure it, you're interacting with systems that I work on. I don't work on the edge, which is what most of the world knows Cloudflare to be, the big proxy around the world, but I work on the software that tells the edge what to do, the brain. I work in the San Francisco office, which is a great office from what I remember pre-COVID. Increasingly though, the people I work with and who work on my teams are all over the world in all of our major development offices. Traditionally, I think at Cloudflare and in engineering, Cloudflare has been very in-office. We value being able to sort of swivel your chair and talk to your boss, talk to your peers, and I love that. It's been an adjustment to get used to working remotely, but it's also what's happening anyway with respect to how many offices we have and being remote from people you work with. We can talk, I'm sure, in the Q&A. We'll cover a lot of that as well. I'll introduce you to my peer, Allie. Awesome. All right. I'm Allie Cabral. I am the Director of Product for Cloudflare Workers, which is Cloudflare's edge compute platform, really a serverless platform that allows application developers to take advantage of this wide distributed network that Cloudflare has built up over time. My first job ever was not coffee related. It was more classic than that. Mine was being a babysitter for some local neighbors going and watching other people's kids. I think that's probably a lot of people's answer to that question, so not unique in that sense, but I got into engineering in college. I actually studied mechanical engineering, and what drove me to that was understanding how things work. I wasn't okay with thinking that a computer was magic. It's not empowering to think that things can be reduced to magic because then you don't know how to make something better. You can't iterate on anything if you don't know the priors. So, I was really interested in getting a base sense of how things worked in the space around me so that my ideas about how to improve things I could validate. So, that was really exciting. And then I got into computer science when I entered a mobile app challenge at my college. I started with a group of five friends developing a mobile app. We ended up winning the competition. It was nine months long. We developed the application, and that contest or competition was sponsored by IBM, and I ended up getting a software engineering offer at IBM coming out of school to continue building mobile apps, so working in Java, specifically on Android. Now I hear great things about Kotlin, but Java and using basically the Eclipse ID was not the best experience at the time. Now with Android Studio and Kotlin, I hear things are much better. But, yeah, so that's how I got introduced into computer science. I was an engineer for a couple of years and then actually got introduced into product management at IBM, left IBM, went to MongoDB, and now I'm here at Cloudflare. And I'm excited to dig into the questions you guys have for us today. Yeah, great. Thank you both so much. So, the theme of this MentorFlare episode is how things work, perspectives from engineering and product management, and so that's why we brought Tom and Ali along today. And so, I think we can go ahead and just dive into the conversation about engineering work and PM and why do they need each other. So, let's just go right in. Why do engineering and product management need each other? Well, there's the classic nice negotiation between the two groups within industry and within any company, really. And to be fair, product management looks and smells different company to company. But I can speak to my personal experience and how these relationships are best or like when they shine the brightest. It's when you have a product team that helps kind of funnel back the information from the field and scales those efforts, comes down, like, creates quality feedback, and then works with the engineering team to build the solution. So, like, the product should own the customer voice, the user voice, what users want and need. And then, really, the engineering team should work on how we get to that solution. Like, how do we get there? And together, we kind of negotiate what you learn throughout an implementation is there are tradeoffs every day that you have to make. Like, you learn things throughout the life cycle of a project. And you're going to be making those calls throughout the project. When you have good relationships with product management and engineering, you're just making sure engineering is setting the long-term vision, creating those pillars so that when engineering has to make their tradeoffs day to day, I'm not having to look over their shoulders to be confident that the team is going to deliver what our users want. So, I view, like, product management's role is rallying the troops around, like, a good and, you know, evidence-based vision, and then engineering kind of following through on executing that vision. Yeah, I feel the same way. And it's interesting at Cloudflare particularly, but actually most everywhere at work, everyone has opinions on what the product is, how it should work, what it should look like, what color the button should be. At some point, and especially Cloudflare, because we build a technical product for technical people, so engineers like us have strong opinions. I was a Cloudflare customer. I can tell you what I want out of Cloudflare. But I was just one customer. The product managers take this to a whole other level of what our customers as a whole really want. And they're not all just, like, me and my little startups. They're huge companies and small companies. And we, as much as it seems like, oh, I can decide what our products can look like, it's a whole discipline. And a strong PM speaks with a voice that you, that's authoritative and that you respect because they've spoken with customers and know, you know, what they want. And that's what I look for in a PM. Just tell me what we need to build, what's most important, what are people really demanding. I'm excited to build whatever it is. I'm excited to solve a real problem. So please bring to me the problems that will make the biggest difference. That needs help. Right. And I think where I've seen the relationship sour in the past is when either product management is devalued, like the opinion is devalued, or product management is, like, presenting a vision that is not achievable. And then for some reason, you can't actually get to any kind of negotiation on a compromise. So those are situations to look out for as well. Yeah, I think the two ways I've seen it go sideways. So there is a line where product explains the requirements, what problems we're solving, and they can go a little far and tell us how to solve them too. And that can create some tension. I don't actually mind, that tension seems okay. It's like, hey, you know, leave this, you know, you can have that conversation. The more, the trickier one is when requirements are underspecified, misspecified, or like, you know, I'll make up an example that has never happened here. But if you go to an engineering team and say, I want you to build a clone of such and such website, Facebook. And it sounds easy, right? Like, okay, clear requirement, clone Facebook, two words. But like, what do they mean by that? You want their same, you know, password complexity policy, this like, there's a whole lot to unpack in there. And a strong product manager knows that, like they would never say, here's your requirements, just clone, you know, Facebook. And so underspecifying what needs to be done is a real, it's a bigger problem than overspecifying, I think. Yeah. And I think, yeah. And I, Tom, I think to your point, like one of the big things about product management, one of the values is focusing the team on the right things. And you can't do that if you're not specific, right? Because a lot of the time, that's not just about like painting this like long term great vision. It's also about telling the team what not to focus on, what's not important, so that we're not kind of spitting these like, or spending these like wasted cycles on something that's actually not gonna make the product better for the end user, ultimately. Yeah, I think the best engineers that I work with, and what I look for when I hire engineers is a sense of motivated people who are motivated to deliver value. And so, because then they're worried about shipping, they're worried about getting their product in front of people, the customers, the customers can use it, because if that doesn't happen, then what are we even doing here? The flip side of people who are motivated by delivering value is their product manager needs to be good. Because if they're told to build something that nobody wants, they're going to be that much more frustrated, like their job, their purpose, the thing that motivated them is now, you know, they're failing, you know, to deliver value. So, I think, you know, the strongest engineers, you know, demand a lot of product managers and good product managers get a lot of the engineering team that supports them. Absolutely. Great. So, can you both describe, you know, the normal or average process of working together, whether it's day to day, or if you don't communicate every day throughout the week? What does that look like? Should we tell them that we've never actually worked together? It happens to be true. We personally have never worked together, yeah. But Tom, you actually have quite a bit of insight on the overall process at Cloudflare, and how product and engineering kind of work to build out in scope a project. Going over that at a high level, I think might be great here. Yeah. So, Cloudflare, I think, you know, like all companies started small. And like, unlike many companies, I think we try to stay small, like feel small, don't become an enterprise, you know, a big company before you have to. And so, we do wind up, you know, creating more processes so we can work together, because as you have more people, communication gets harder, the more tooling and just an agreed upon set of norms and standards. And so, I think we have a decent balance here, where basically, our ask in engineering is that we are given in writing a set of requirements. Like, we don't, it's not, I don't go open my email to check what I'm supposed to build or what my team is supposed to build. We get it in writing, and we have a template, and you don't have to follow the template, every little thing, but we give you, you know, we give PMs a start. Like, this is the kind of thing engineering wants to see. And in response, engineers respond in writing, this is how we're going to solve for the requirements that you've written. And PM gets to review that, too. And so, we do have some written artifacts that we review to make sure we're clear on the scope. I mean, the biggest, the thing I worry about the most with projects is scope getting out of control. And managing scope is how you ship on time and ship quickly, be iterative. And so, those two written artifacts are the start of how we work together. And it's a little bit of a contract to make sure we're delivering on what we promised. Great. Awesome. So, I know you both mentioned a couple of things that happen when the relationship between engineering and PM goes sour. So, what are some of the challenges in working cross-functionally, just in a, like, a successful relationship between engineering and product management that you kind of see and, you know, you have to deal with? So, there's a lot that is really based on this foundation of trust. Now, this has to be trust that's earned. Like, for example, one of the things Tom just mentioned that he's worried about is scope increasing a lot in a project. If you have, or if you're a product manager working with an engineering team where that tends to be the pattern, you might actually feel like you have to be more hands-on and get into, like, the weeds of the details and, like, how we build something, which is more classically a decision for engineering. And then there's going to be tension that comes out of that. So, there has to be trust from the product side to engineering, but there also has to be trust from the engineering side to product management that we are, like, going out and talking to users. We are a qualified voice of those users. And I think it really, and product management needs to, you know, go and do that legwork in order to actually be able to speak with that authority and not just have the authority implicit based on nothing. So, there's kind of two sides to every coin, but I think that really trust is an essential part of this process, and things break down when it's not there. Yeah, I also don't think we, it's easy for me to say that we should, you know, be friends or, I think there's a healthy tension that's important. Like, I want product to challenge me. I want them to ask for something that's really hard for me to do, not to be so buddy-buddy that they don't even bother to challenge engineering with something hard or, you know, get cynical and, like, just do whatever. You know, there's some tension there that's healthy, and the product manager, and it's why in our organization, I think many product and engineering are separate departments. It's because one department is pushing the other. And so, that is a healthy tension that, you know, only works with trust. If you mix that with no trust, then you have a recipe for disaster. But you also don't need to be, you know, too friendly to each other. The pressure is useful. Great. Okay, great. So, we can jump into the Q&A section. Before this session, we reached out to 1,500 students and asked them to submit questions for Tom and Allie, and we got some incredible questions. So, I'm excited to dive in. So, our first question is, how do you tailor the product so that it is interesting to work on for engineers, but also get the customers excited? Yeah, so this one is a particularly hard problem. I do view it as part of product management's job to motivate the engineering team around exciting problems. What I find is, even not the most interesting technical solutions can be interesting if you actually understand the value. Like, people need context on the projects they're working on, and not everyone is just motivated by how technically interesting something, some amount of work is. A lot of people tend to be more interested in the amount of value they're producing, and, like, when you see the amount of new users using a new feature that you built, that gives you more fulfillment than even maybe doing the technically interesting work. So, from my perspective, it is product management's responsibility and job to take engineering along the journey of why we're doing the product change, whatever that is, or, you know, just providing the business case and context not just to leadership, but to the team that will be building it out, because I think that really helps with motivation and fulfillment. Yeah, I completely agree. You know, when I started my career professionally, I worked on call center software, which sounds like it would be so boring, but when your product manager, when you go visit a customer, and you see how it works, and you see people using your software, these abstract metrics, like average handle time and average time to answer and all these things, become very real, and your work all of a sudden becomes very exciting, even though, you know, on paper or at a distance, it seems like, you know, it wouldn't be. Right. So, the context and a product manager that helps give you that context is absolutely, totally great. Great. Okay, next question. If no developers on your team can solve the problem that you need to solve, what do you do? Yeah, this is an interesting one. So, I think there are alternatives. So, I think this is rare, first of all. Like, developers wind up steering towards solutions they know how to build. At the same time, I can think of some examples, even recently, even at this company, where we steered towards a solution, and then we realized, wow, this is actually a much harder problem than we thought. And we're very fortunate at Cloudflare to have some really smart folks, and we were able to turn to folks outside the team to do a prototype, or do a proof of concept, or just help steer us back on track, so we could get it, get the problem put into, you know, more tractable. And sometimes that's an approach or an algorithm, but those resources proved useful, you know, recently. This isn't one that I come across very often, though, I would say. I wish I could say we're solving these incredibly hard problems all the time, but a lot of it is we're solving solvable problems. Well, I guess that's good, then. It is. You know, we also do get pressured, I think, sometimes to solve impossible problems. And I'm not sure that, you know, the expectation is we solve impossible problems, but it's that we try. And it's by pushing us to squeeze the most CPU out of a computer that gets really innovative solutions. And so it's not that we can't, you know, solve it, but that pressure, again, helps us, drive us to create innovative, pretty close solutions, closer than you would have gotten to if you weren't challenged. Right. Great. So, the next question is for Allie. How do you say no to features that are pitched to you for a new or current product? Right. So, I'm assuming that I'm saying no for a reason and not just for the sake of it. I'll read the question that way. Honestly, no's might mean a couple of things. One, it can mean it's not the right time. There are higher priority things that we need to be focused on in the short term. And my reaction to that kind of no that I would have to give is to tell them, give them context on the short term goals that we are working toward and say that we can reevaluate this in a year, 18 months, once we've kind of, you know, gotten ourselves through the initial hurdles that we need to kind of jump over. Or the no might be there's a reason why this is not going to be a good experience for our users. Or this is not the target market of our product. And to me, as long as the no comes with context, people are way more willing to accept a no than you give them credit on first glance. Because you're inviting them into the conversation. Right. You're letting them understand the context of the product. But it takes time and effort to do that. So I think it's important, though, if someone's coming with the energy to pitch a new product idea or new feature that I meet them with that energy to explain to them what our current thinking is and why this is not something we would tackle now. Because you want them to channel that energy into the areas that you find important and interesting as a product manager. So you can kind of if the best no's are the ones where you can get them excited about what you are working toward. Great. The next question is for Tom. What matters most, the code quality or the speed slash hitting a deadline? Yeah, my favorite questions. So I think code quality is, you know, there's a floor, there's like an unacceptable level of code quality. I think usually that's when you are sort of prototyping something and hacking around and then oops, you turn it into a product. That's something I would consider in terms of what matters most. I would say you're not, you might be below the floor of code quality. But for the most part, speed matters most. Like get the product, get the MVP working so that people can start using it. I'm not a, I don't have a lot of confidence in people's ability to predict the future. Engineers, product managers, anybody. So the best way to see yourself into the future is to get something out there and get feedback and iterate your way into it. So you don't have to, you know, guess what's gonna happen a year from now. You can learn as you go. So in that, you know, product management triangle, read the trade-off. This is quality, speed, whatever. It's usually scope is what I would try and cut. Ship something that does not everything you want, but does, you know, I'm sure Allie can speak to this better than me, that MVP, and iterate from there. So that said, I wouldn't say speed and hitting a deadline are synonymous. There are some deadlines that are really important, like 1.1.1.1 ships on 4.1, right? It doesn't make any sense to ship on 4.2. That deadline matters. A lot of projects that you do, you scope, you set a deadline, and they don't, you know, you miss by a day or two and life goes on. In fact, if you hit all your deadlines, the one sure way you're gonna hit all your deadlines is if you sandbag all your estimates. And so I think missing some deadlines by a little is healthy. It's almost a red flag. If you're hitting all your deadlines, you're probably not challenging yourself enough. But, you know, being directionally correct, having a deadline shooting for it is another tactic to help control scope. And so I think that's just critically important. And, and software isn't usually done, like, you know, as far as I know, Google's still working on search, they didn't finish it 10 years ago. So like, you have plenty of opportunity to keep to keep working on it, improve your code quality, add features, the days for many of us of shipping software and burning out a CD and mailing it to a million people are behind us. So you're all manner of opportunities to keep updating it. So I don't think the sort of golden master, you know, world is that relevant for many of us these days. So I would I focus on speed, shipping, getting feedback, iterating, that every version is just will be, you know, an old version three days from now. So don't don't get too attached to it. Great. I think this is a really good question. When managing a development team, how do you gauge the capacity of your developers to prevent burnout? Yeah, this is especially topical right now. There's a mix of anxiety producing an anxiety filled environment in the world, and in a distance where I don't, I can't just look around and see if someone seems down. So it's particularly challenging now, like you're more likely to be burnt out, and I'm less likely to know. The few things that we do, all managers at Cloudflare do one on ones with their direct reports, at least every other week, if not weekly, and I do the same and I do one on ones with my reports reports. And in those meetings, we don't talk about project status, or you know, we don't, you know, repeat things that happen in other meetings. It's just it's about how you're doing. And it's really important that managers have that connection with the people that reports them as part of our job. It's making sure that we know how people are doing and that we're accommodating and you know, they can't do their best work if like they're stressed out and we and we won't know what you know what work to steer them steer away from them if we're not in tune with them. And so that's an expectation we have of all of all leaders at Cloudflare. We're also doing a lot more training on how to spot burnout because it's so topical right now. Looking for cynicism, looking for dramatic drop offs in productivity, there are a lot of signals that that we can for paying attention that we can pick up on. So it's, it's, it's, it's an important topic that I think, you know, we rely and training and having managers stay on top of with each of the direct reports, because there's just no, you know, no one wins in that situation. And it's, it's really, it's hard for a lot of people right now, especially when you work from home and, and, you know, you never are away from work to slip into a burnout situation. So make sure we keep an eye on vacation, not to make sure you take enough of it is something a lot of managers are doing now more than ever. Because it's, it's, yeah, it's a challenge. Great. And leading, leading by example, as a manager, making sure that we are taking vacation, we are actually turning off when we do take those vacation days, and making sure that our team knows that's the expectation. And they need to kind of like, take that time for themselves to come back ready. Yeah. Yeah, absolutely. I think that's a great question, because burnout is definitely at the forefront of working environments right now. So great. So moving on the next question, how is the engineering culture at Cloudflare? So, one thing about the Cloudflare engineering culture, I think is particularly unique is how autonomous it is. We don't have a lot of edicts about what languages to use and, and what patterns you must follow and double edged sword. And then I think people get to explore different languages and patterns and, you know, feel empowered to do things the way they think is best or try things, try new things. And on the flip side, there's kind of a mixed hodgepodge of tools and technologies and patterns. And so when you walk into a new team, you might be walking into a whole new world in terms of how they do things. If we want to get everybody at the company to sort of march in one direction, or you standardize on one thing, it's harder because because people are going in different ways and have different ways of thinking. We probably build the same things twice more than, you know, if we insisted that we share stuff. But I think net, we think it's a virtue that we hire smart people and let them have a lot of autonomy in terms of technology choices. And it's interesting that almost organically, I think Cloudflare has a shared culture of what languages we collectively like and don't like, you know, it just feels like that spirit, just how we've hired, you know, as standardized on some things, but it's, it was not a, it's not a top down sort of culture. Yeah, and for those of you who are watching that may not have had a chance of industry experience yet, there's a, tends to be like a trade off here in industry. It's like, if you are a big company, you start to kind of optimize on not making the same mistake twice, or learning the same thing over again, across our different organizations, engineering organizations, if you have 500 of them, or whatever, it costs a lot to make the same mistake 500 times. So it's really, it's really appealing to try and solve that problem by making someone learn it once, and then everyone else can kind of like, get that trickle down information. But how this manifests most of the time is through processes where you have maybe like an approval process where like, I'm going to submit my architecture for my app. And then I wait for an architect to kind of tell me, that's okay, give me the sign off. And all that process is now going to take me maybe three weeks of back and forth, instead of just being able to run in a direction. And maybe that mistake that I learned is something that I can learn in a day, right. So there's some trade offs there. And I think there's a lot of pain at bigger companies of kind of over trying to optimize the engineering decision making process, and not leaving a lot of room for organic learning. Awesome. Okay, so the next question is for Tom about his startup journey. When do you know it's the right idea to push for and work towards? If I have an idea, but the more I look at it, the more disenchanting it seems? Is it worth pursuing still because it might work? Or is a belief in the product we are trying to make an absolute must to begin with? Yeah, I like this question, because I think I did it wrong. Maybe I'm sure this isn't like the answer. If you read any book of these successful people, you'll see like, oh, and then, and then we thought, you know, all hope was lost. But miraculously, you know, we came through and now we're, you know, wildly successful. But it's a whole like survivorship bias, like series of stories. The failures never wrote books. I think you need I think creating doing a startup as a founder is totally irrational. And you can only do it if you are, you're just insanely passionate about the product, and you think it's gonna work. Because it probably won't, because most startups fail. And I'm not, I don't even think that's my opinion. I think numerically, so you have to be insanely passionate to be a startup founder. And I was at the time, I just had an itch. And I'm sure a lot of people have an itch, maybe you're sitting in a big company, or you're literally in a cubicle staring out the window saying, I gotta get out of here, which I literally was. And I did. But my startup wasn't, you know, success and not writing books about that learned a ton, highly recommend if someone has an itch that they scratch that itch. But if you're already on the fence, and you haven't even started, doesn't seem right to me. That's my advice. Right. Okay, so the next question is interesting. This came from a student who grew up on a sailboat sailing around with his family. And he asked, What advice do you have for those who perhaps didn't have the resources that their fellow college students did, but are nonetheless keen to stand out in the fiercely competitive tech job market, and land a dream position at one of the top influential information security companies? Something that really makes someone stand out is is their passion. And that's not something you need resources to show in the interview process. If, if you get excited asking questions, like, whether it's about like the product that the team is working on, or the projects that, that the team might track tackle in the future, like, being able to see that passion on someone's face, the interest in the technology that they'd be working closely with, that comes through. And I think that, to me, in my experiences is the thing that really makes someone stand out above a lot of other interviews I'm having is when they come and like meet my energy, my passion for the product with with their own. And I really like that in the interview process. Yeah, from the pre -interview sort of screening, I'm sure if you have a non-traditional background, you worry that your resume doesn't say Stanford or whatever keyword you think people are looking for. And, and there is certainly systems that are filtering resumes that look for keywords. But by the time it gets to a human being, I want to see a story. I want to read it and, and understand it. Tell me a story about, you know, like Ali said, your passion, or maybe you worked on something that's just particularly fascinating. But there's got to be a story there. And so I can see who the person is that we're dealing with. And, you know, if I think if somebody lived on a sailboat and taught themselves the program, I could, there's this fascinating story. I'd love to talk to that person, personally. So, you know, the days of, you know, requiring traditional education backgrounds, I think are, you know, waning as well. We've all worked with so many amazing people from so many different backgrounds that, you know, I don't think we take that as seriously as folks used to. Right. Yeah, I definitely agree. So to the next question, a lot of the times I feel like responsibilities in the team are ambiguous, or two or more people share the same responsibility, like the design of a product, UX and things like that. Are there consequences to this? There are both consequences and benefits. I recently, I had never heard this saying before, but I recently heard the saying, good fences make good neighbors. And I think to a large extent, that is very true. Like when you have true, like hard lines and responsibilities, it makes the problem space easier, right? You know, who'd hold accountable at any given point. So how I like to think of like, a project going through its natural life cycle, where you need the input of design, you need the input of product, and maybe areas that product doesn't own, you make that very clear. So like, for example, like, Tom spoke about having a product requirement stock, and then going into a specking. Now, engineering has input on the product requirement stock, but product management is the owner, right? They're the team that is responsible and accountable for getting that document over the line. But you do have a lot of inputs in that process. And similarly, like the spec part of the project, I'm going to read and review and will comment on if I see anything that's like, maybe out of scope that I think we shouldn't be tackling right now, as an example. But I'm not the one responsible or accountable for holding, like getting that spec over the line. That is the project lead on that project, whichever engineer that is. Now, from my perspective, having clear ownership, but still kind of keeping open conversation around like, direction and all that good stuff, so people have a place to have input. But then for each of the milestones throughout the project, someone is the owner who will be held accountable for getting us over to the next milestone. I think that's important for making sure that you're not icing people out of the conversation, not boxing them out, but still, you know, progressing, not just having a decision by committee mentality where we don't ever actually get consensus. Yeah, there's some, you know, formal ways of expressing that to the daisy, the racy, you know, we don't, we don't do them super formally, although I think we do a crack at it at one point. But I totally agree. Having, you know, the notion of some of one accountable person, even if there are many contributors is important. Also, I think good fences make Robert Frost's New Hampshire's classic. That's great. Not computer related. It's just from home. Ali, this question looks like it's for you. What does a good background for product management roles look like? And this is going to vary from company to company. Like I said, really early in the beginning of this conversation, product management looks different from company to company across this industry. Some companies will favor a design background. That's more consumer facing background for Cloudflare, specifically in companies like Cloudflare. We look for strong technical backgrounds, in addition to being able to manage relationships with customers. So having previous experience, both building something potentially or working on something technical, and then also interacting with customers or users of that product and in a large scale way, like, those are the two things that I think are essential for a background for a product manager, product manager at Cloudflare, for sure. Great. Tom, my relative who is currently working in the field of software engineering has a slight imposter syndrome. Did you ever have that feeling? If so, how did you overcome it? Yeah, so it's interesting. It's very common. So that's the first thing everyone should know is imposter syndrome, super common. I don't know how, I think I avoided it because I never thought I was very good. Like, I'm not an imposter. I'm just, when I was a junior engineer, I had no illusions of that fact. Teach me, I don't know, you know, I just came out of school. And I think, you know, I don't know that I have a lot of advice, except that you're not alone. Actually, I would have imposter syndrome, if I'd ever worked at one of those companies where they give you massages and three meals a day. And I like what to write some code, then I would feel like I don't deserve any of this. But for the most part, we're all learning all the time. Everyone around us knows something different. At Cloudflare, it's really, you know, it would be really easy to feel imposter syndrome, foremost experts in DNS and SSL and cryptography all around you, you might feel like you don't belong, but we all have a lot to learn in some area. There's no expectation that, you know, everyone knows everything. If you read the Cloudflare blog, you're intimidated by some of these low level Linux, you know, blog posts. Half of us are too. They're experts in lots of different things, and you're not an imposter for working alongside them. Right. Ali, I was going to open this question up to you as well. Yeah, yeah. So I think like all of us, I have good days and bad days, right? The confidence over the course of my career has gone up, for sure. But I would be lying if I said I still didn't have days where I'm like, I don't know if I'm cut out for this, even me, right, in the position I'm in now. And what gets me through it is also just like keeping notes of like accomplishments that I've had, just reminding myself in the moments where I don't feel quite as competent that day of all of the great things that I've done before, and why I do deserve this. And that's like a personal thing that's helped me in those like lower moments. And then also recognizing that often, if you're not understanding something in a conversation, or you're kind of having a conversation, but not actually having the conversation you thought you were, and it's often a language mismatch, and not a capabilities mismatch, right? It's not that this other person is more capable than you, it's that you're not speaking the same language. And framing it in that context makes it feel a lot less intimidating. And yeah, so those are, those are the two pieces of advice I have on this. Yeah, I think everyone looks like they have it more together, like at a distance. But nobody really knows, like everybody's got a weakness. It's, it's, we're all in the same boat. Yeah, it's kind of like falling forward, keep tripping to success. So this question was written by the same student. He says, I am currently working on a variety of personal projects, and I sometimes lose interest due to the sheer amount of work and setup that has to be done, especially for those projects with thousands of lines of code. But I really want to make this project, what are some methods to not be afraid of those mountains of work? So one thing I'd suggest is start with the hard part. Like, I do that, suggest that professionally as well. But do, when they say work and setup, I picture someone like, well, I want to build this, you know, shiny thing. But in order to do that, I need to set up a database and a build system. And, and like, they start with all the tedium, and you end up blocked on like the, like, in a gumption trap right from the start. And so I would revert, like, make sure the order in which you're working on things is do the hard and interesting thing first. And if that works, you'll find yourself motivated to do the tedious boilerplate stuff. But that's the only way, I mean, I would think to get through it. And I like that professionally, too, because sometimes the hard and interesting stuff is the stuff that's the least certain. And you really want to do that first. Otherwise, you're less certain of when you're going to be done. You probably know how long it's going to take you to build the boilerplate, because you've done it so many times. That's why it's so uninteresting. Do the do the hard stuff first, the stuff that you're least certain about and see, see if that gets you excited about it. That's the advice. Great. So I really like this question as well. How do you pitch a new idea to your manager, uh, where a company has already, uh, a set process or procedure in place? The first step would be, um, making sure you and your manager agree on the problem and the importance of the problem. So like making sure that you're not just coming in with an idea for change, whether that's through a process or a procedure, but that you're acting off the same priors when you go into that conversation, right? You both understand that it may be taking you an extra week or whatever the, what's, whatever's wrong with the current process is the problem, uh, that we're trying to solve for. And that there's not maybe like a larger piece of the puzzle that you're not actually, uh, aware of. Maybe this is optimized for leadership's time saving, not yours or vice versa, right? Like there, there might be, um, some calculus there that you're not, uh, necessarily, uh, you haven't been shown yet. So it's good to make sure that you mutually understand the problem space, that you, uh, are acting off the right priors when you're going into that conversation, because otherwise it becomes a very conversation that like, it's a conversation that's not, it's not based on a problem. So you're talking mostly about the, the facade of the solution, right? Like, like the, the details are where you get caught up, which is not your intent, not their intent. Um, if you go on, honestly, going in with the right understanding of the problem is also going to have your manager take ownership of solving the problem too. Um, making sure that they're aware of it. Yeah, totally. I don't have anything to add, but I totally agree. You should be prepared, um, to be wrong. Like maybe, maybe, you know, there's more to it than you think. Uh, so don't, don't get too attached to your ideas. Um, but also the other thing I'm thinking, if, if you bring an idea to your manager, where that delivers value to some other people, um, bring them along to like get the constituents to back you and get allies in the, in the point you're trying to make. And if nobody else thinks that there's value, then, you know, you might want to question this idea. But, um, if, if you, if you see people that you would be helping with this idea you're bringing, I would engage with them too. Right. Yeah, absolutely. Um, next question is, is automation only in testing side, or is it also helping developers for automating the development cycle? Yeah. I mean, Cloudflare is a really interesting place from this perspective. I think largely, uh, credit to my boss. Um, but we automate meeting agendas. We automate status. We automate prioritization. Um, it's, it's, there's a place for automation in all of it. And, and part of it is, uh, the reason we automate it is, it's just like, we run a project. Is the project on track? Who, who do you depend on? Like, these are the same questions for almost any project. So we can automate it. Uh, what's, what are our priorities in what order? Well, let's make sure we cover those first. Like these are the sorts of things, um, after an incident, how bad was the incident? How important, you know, we should make sure we prioritize the things that would prevent those incidents in the future. We automate all of these things, um, because they're, they're not, you know, necessarily unique snowflakes that we need to re-explore every time we can mechanize them and make everyone more productive, prevent shoulder taps, prevent misunderstandings, have a shared understanding. Um, so certainly at Cloudflare automating internal operations is, especially in engineering and product is, I think a real strength of ours. Great. Um, I really liked this question as well. How do you define product market fit? How do you find your edge? So often it's about listening to what your users are actually doing with the product and, and their, um, impressions and what often it's funny because we have a lot of theories about how people are going to use a product before we put it to market. Often your users are going to surprise you in new and interesting ways. Once you launch, launch a product on how they want to use it and why they're using it and what those use cases are. Now that's not to say we shouldn't do the upfront research and that's not valuable because often you'll get a solid chunk of that right. Um, but then without listening to the users, you kind of miss some of the things that might've otherwise been surprising and didn't immediately come out of research. So some of this, like finding a product market fit for a new product in a new space is about going out and listening to what users want and need. Um, and then developing something that you think fills that need, iterating on that. Um, and then going and asking them if you did a good job, if they're using you now, right? Because you assumed that once you solved this great problem for them, they were going to start using you. Um, and then you listen to if they haven't, why they haven't. Um, and then you kind of keep going back and having these conversations, um, until you get closer and closer to it being obvious they should start using your product. Like all of these new users who may have otherwise used like some combination of competitors. Now your solution is, is the one that's the obvious choice. Um, so a lot of finding your product market fit is an iterative process that takes a lot of cycles with your users, um, or prospects that aren't currently using any of the company's technology, uh, and just, and just listening. Um, yeah, go ahead. Sorry. If you're doing a new startup, this is your existential question. If you, uh, this is do or die. Uh, so iterate, iterate, iterate, like I said, and if, but if you don't get it, it's game over. Um, it's, it's really hard. Yep. Right. Great. Um, so I think we're running out of time. And so I wanted to make sure that we talked a bit about, since you both hire for your teams and you both manage large teams, um, any tips or advice on getting a job at Cloudflare or even on your team. And it could be an internship too. So an internship or a full time job. Yeah, with, with my teams. Um, one of the things that's really interesting that I touched on earlier is, is showcasing your passion and in the interview process, once, once you do come on site, like, uh, or virtual onsite these days, um, being able to kind of show that you either like looked into the product or why you've used similar products and why this space is particularly interesting to you. That's really important. Now I'm going to, as someone who's trying to hire you also going to consider it part of my job to make you excited about the work. So you don't have to do that all on your own. Um, but I think when, when we do have like a conversation of why this is exciting, seeing that resonate with, with you is really powerful for me. Um, and then just making sure, uh, you're building the expertise we look for on the product team. So both the customer facing side and the technical side is something that we'll look in, uh, look out for by the time you're speaking to a human, we've screen screen for some of that. Um, and your first caller too will, will be additional screening on that. Um, but once you're on that virtual, virtual onsite will be, uh, more like whether you have the passion, whether you're hungry for tackling this problem space, that's really important in product. Yeah. The, um, in engineering, I have a real emphasis on, on ownership, on, on showing that you, you own and operate the things you build. You don't just, you don't build a thing and expect someone else to take it live and maintain it for you. But like, we are owner operators, we were, we run a service, we, you know, uh, and, and so ways you can spell that out in your resume include, you know, I've been on call, I've been part of, you know, emergencies, uh, do disaster preparedness, whatever it is, but like that, that's something that I, I value and emphasize at Cloudflare, which actually wasn't really in previous companies. It wasn't something that was the high order, high order bit. Uh, another thing I'd say is if, if you are, aren't selected as part of the resume screening, um, it doesn't mean you're not a fit for Cloudflare, like don't read too much into that. It could just mean you'd be a great fit for Cloudflare, we just don't have a role open for that skill set at that location at this time. Like don't, when, if you get a notice that like you haven't been selected for a role, it will say, please reply in the future. And it's, and we mean it like, please do. It doesn't, there's no, don't read, don't read into it. Like you didn't make the bar or you rejected. It doesn't mean that at all. It just, it just could be there's not fit at this time for, for what you're interested in or for what we see that you would be interested in. That happens to me all the time. This is a great resume. I know exactly what this person would do. I just, you know, we're all full up at the moment in that, you know, that particular capability. So I wouldn't get, make sure people don't get discouraged. Yeah. Things change. There are more great people than there are open roles. That is for sure. Definitely. I completely agree with that as well. I think, you know, don't shy away from applying in the future. If something didn't work out in the past, I think that's really important. Well, thank you both so much for kicking off MentorFlare. This has been a great conversation. I'm so excited for this series to continue. We have Michelle Zatlin next week. So we'll talk to her, but thank you both so much. It's really been incredible. Thank you. Awesome. Bye guys. Bye.