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. 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. And after a year there, I quit and came to Silicon Valley. I wanted to see what the fuss was about, what the Bay Area is all about. I came to work at Cloudflare. For me Cloudflare was, I was a customer, I'd 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 you know every two weeks when payroll came around it was kind of stressful and sometimes we passed ourselves over as co-founders, it was you know it was precarious. So Cloudflare was in this nice sweet spot where they at that point were already you know 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. So that's the gist of my career path. I actually started managing the SSL team when I got here, so universal SSL if you have a certificate from Cloudflare, that was the team that I managed and over time as Cloudflare grew we needed more sort of structure and now my role oversees a good chunk of the control plane. So 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, and I work in the San Francisco office which is a great office from what I remember pre-COVID and 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. So we've traditionally I think at Cloudflare and in engineering Cloudflare 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 and it's been an adjustment to get used to remotely but it's also was happening anyway with respect to how many offices we have and being remote from people you work with. So we can talk sure in the Q&A we'll cover a lot of that as well and yeah introduce you to my peer Allie. Awesome. All right so 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. So 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. So 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 drew drove me to that was understanding how things work. I wasn't okay with like 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 right. You can't iterate on anything if you don't know kind of the priors. So I was really interested in just kind of 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 like a mobile app challenge at my college. I like started with a group of five friends developing a mobile app. We actually ended up winning the competition. It was like nine months long. We actually developed the application and that contest like our competition was sponsored by IBM and I actually 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 then 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 Allie 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 trade-offs every day that you have to make. Like you learn things throughout the life cycle of a project and you're gonna 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 trade -offs 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 nother 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's it seems like oh I can decide what our products look like. It's a whole discipline and a strong PM speaks with a voice 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 the 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. 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 can have that conversation. 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. It's two words but like what do they mean by that? Do you want their same password complexity policy? 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 over specifying I think. Yeah and 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 spinning 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 so 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? 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. You need 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 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 we 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 and be iterative. And so those two written artifacts are like the start of how we how we work together. 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 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 that 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's that is a healthy tension that you know only works with trust. If you mix that without with no trust then you have a real recipe for disaster. But you also don't need to be you know you know too friendly to each other that the pressure is useful. Great okay great. So we can jump into the Q&A section. Before this session we reached out to 1500 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 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 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. 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 turn to 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 you know more tractable and sometimes that's an approach or an algorithm or but those resources proved useful even you know recently this isn't 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 it's by pushing us to to squeeze the most CPU out of a computer that gets really innovative solutions and so it's not it's not that we can't you know solve it but but that 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 could 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 re-evaluate this in a year, 18 months. So once we've kind of you know gotten ourselves through 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 a 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's 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 oops you turned it into a product. That's something I would consider in terms of what matters most. I would say you're now 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 going to 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 but 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 Ali can speak to this better than me that MVP and iterate from there. So that's it. 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. 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 going to 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 software isn't usually done. 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 working on it, improve your code quality, add features. The days for many of us of shipping software and burning it on a CD and mailing it to a million people are behind us. So you have 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 focus on speed. Shipping, getting feedback, iterating. Every version is just will be you know an old version three days from now. So 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 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. A 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 report to them. That's part of our job. It's making sure that we know how people are doing and 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. 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 we can for paying attention that we can pick up on. So it's an important topic that I think you know we rely on 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 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. This 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 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 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 it's double -edged sword and in the end 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 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 each standardize on one thing it's harder because people are going different ways and have different 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 I you know it just feels like that spirit just how we've hired you know has 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 ton 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 learn is something that I can learn in a day right so there are 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 that all 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 are just insanely passionate about the product and you think it's going to 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 got to get out of here which I literally was and I did but my startup wasn't you know a 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 it doesn't seem right to 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 or the projects that that the team might tackle in the future like being able to see that passion on someone's face the interest in 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 I really like that in the interview process yeah from the 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 Allie 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 love to talk about person personally so I 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 all 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 are 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 on that project whichever engineer that is now from 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 we don't ever actually get consensus yeah there are 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 the notion of some of one accountable person even if there are many contributors is important also I think good fences make good neighbors is Robert Frost's New Hampshire's it's classic that's great not computer related it's just from home um Allie this question looks like it's for you what does a good background for product management roles look like and and this is going to vary from company to company like I said really uh 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 uh customers or users of that product and uh in a large-scale way like those are the two things that I think are essential for for a background um for a product manager product manager at Cloudflare for sure great um 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 um and I think you know I don't know that I have a lot of advice except that you're not alone um actually I would have imposter syndrome if I'd ever work to 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 um but for the part um we're all learning all the time uh everyone around us knows something different at Cloudflare it's really you know it's it would be really easy to feel imposter syndrome foremost experts in dns and ssl and cryptography all around you um you might feel like you don't belong but um we all have a lot to learn in some area um it's it's there's no expectation that but you know everyone knows everything if you if you read the Cloudflare blog and you're intimidated by some of these low -level linux um you know blog posts half of us are too uh it's it's they're experts in lots of different things and you're not an imposter for working they know alongside them right ali i've often yeah i was gonna open this session up to you as well yeah yeah so um i think like all of us i have good days and bad days right i the the comedy the confidence over the course of my career has gone up um for sure but i will i will be 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 even me right in the position i am i'm in now and what gets me through is um also just like keeping keeping notes of like accomplishments that i've had um just reminding myself in the moments where i don't feel uh quite as like competent that day um of all of the great things that i've done before and why i do deserve this and that just that's like a personal thing that's helped me um in in those like uh lower moments um and then also recognizing that often um if you're not understanding something in a conversation or you're kind of uh having a conversation but not actually having the conversation you thought you were um 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 um and uh framing it in that context makes it feel a lot less intimidating um and uh yeah so those are those are the two pieces of advice i have on this i think everyone looks like they have it more together like at a distance um but nobody really knows what they're like everybody's got a weakness uh it's it's uh we're all in the same boat yeah it's kind of like falling forward keep tripping to success um 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 um is start with the hard part like um i do that i suggest that professionally as well but do um when they say work and set up 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 um 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 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 um 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 of 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 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 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 uh are where you get caught up which is not your intent not their intent um it's if you go on honestly going in with the the right understanding of the problem is also going to 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 you i totally agree the 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 ideas um but also the other thing i think 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 get allies and 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 cloud is a really interesting place from this perspective i think largely uh credit to my boss but we automate meeting agendas we automate status we automate prioritization um it's it's there's a place for automation 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 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 so certainly at Cloudflare automating internal operations is especially in engineering a product is i think a real strength of ours great um i really like 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 have 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 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 these new users who may have otherwise used like some combination of competitors now your solution is is the one that's the 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 if you're doing it yeah go ahead 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 then it's game over it's really hard i think 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 or virtual on site 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 gonna as someone who's trying to hire you also gonna consider it part of my job to make you excited about the 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 on site 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 uh 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 run a service we you know uh and and so ways you can spell that out in your resume include you know you have 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 will actually wasn't really in previous companies wasn't something that was 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 above or 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 read into it like you didn't make the bar or you were 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 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 um yeah things change there are more great people than there are open roles that is for sure definitely um 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 um well thank you both so much for kicking off mentor flair this has been a great conversation um i'm so excited for this series to continue uh we have michelle zatlin next week um so we'll talk to but thank you both so much it's really been incredible thank you awesome bye guys you