Sarah Dayan (Algolia)

Welcome to the Staff Eng podcast, where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We're interested in the areas of work that set Staff Plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel-Romas, and I'm joined by my co-host, Alex Kessinger. We're both Staff Plus engineers who've been working in software for over a decade. Alex, please tell us a bit about today's guest. Absolutely. I'm stoked about this interview. Sarah Dayon is a Staff Plus engineer at Algolia, a search as a service platform, where she works in the developer experience organization. This is a great opportunity to learn more about Staff Plus engineering and how that works in a developer experience team. I learned a lot from this conversation, and I hope you do too. Let's take a listen. Well, Sarah, thank you so much for taking the time. It's really great to have you. Thank you. Thank you so much for having me. Can we start by having you tell us, I guess, introduce yourself, who you are and what you do? I'm Sarah. I've been working at Algolia, so we are a search and discovery company. I've been working there for about three years now, but I've been in the tech industry and working as a developer since 2010, so it's been over 10 years now. I started as a self-taught engineer way before that, but yes, this is where I'm at right now. Currently, I work at Algolia in what we call the DX chapter, so we in that chapter, which is a group of squads, basically, work mostly on everything that has to do with developer experience. Anything that enables developers working better with the product, this is what we do. You can count many things, including API clients or SDKs, UI libraries, but also documentation, which is the team that I'm leading right now. Anything that, open source or not, helps you as a developer use the product better is what we focus on. That's cool. One of the things that we've been trying to talk to people about is what a staff engineer does in a particular organization. I don't think we've talked to anyone who works on the developer experience side of things, and I'm curious, what do you see the role of a staff engineer is when it comes to developer experience? There are many things that are not necessarily related to developer experience itself, but some of them could be. I would say, and it differs in every organization, but the higher impact you have at the company where you're working on, and impact is the key part to define here, the higher you will usually go. It's not about necessarily how technically awesome you are or being just a beast technically, as one could imagine. It's more what you are enabling, how you're enabling others, what kind of multiplicator effect you're having in the company. One thing that is extremely important, at least in our case, when it comes to people who reach that level, staff plus engineer, is the kind of impact you will have on others. There is zero chance that you will get promoted, even to a senior role, if you're not mentoring other people, which to me is one of the most important parts. It's not the only one, but it's one of the most important, because if you're only working on code, there's only so much that you can do with your two hands and your brains. But if you're actually mentoring other people and enabling them to go higher in the career track, you're actually enabling a lot more than what you would do only on your own. That plays a huge role, at least in the company where I'm working, but it's not only that. There is also a lot of advocacy, and that's also something that you get with the more experience you have, is that the more you work on challenging projects, the more you're able to lead big changes and work on crucial parts of such and such application, the more you will have the ability to take a step back on what you do and be less caught up in technical detail on the flavor of the day or whatever, but have a step back on what you do and also help guide others in the decisions that they make. And the more you're able to have this kind of influence and the higher up, the more you can grow to such levels in a career track. That sounds really... It sounds like you have a really well-defined understanding of what you imagine a staff plus engineer does. I'm curious. Is that something that's defined, you feel, by the company that you work for, or is that something that you learned outside of Algolia? So the company has a career track, which is, I believe, the good thing about it is that it's not just a list of checkboxes that you check everything and it's good, but it's more of an overall feeling of whether you fit to a profile that they're trying to build. Now, the thing is that while you might have a really good idea of what a junior engineer is, it is much harder to have a clear picture of what a principal engineer or staff engineer or principal, whatever, senior staff is because you only have so many. There are usually a lot less people in those higher levels than you have at the lower levels, and you will probably meet less of them, and it will probably also be tied to very specifics of the company. So I think it's interesting to keep those definitions loose. Now, yes, what was interesting for me was to also look at the people who were staff engineers before I was promoted to that role and to take example, but then it's also about embodying the values, I would say, of your company. We at least at Algolia, we operate on values. It's a huge part of the culture. It's actually something that we are assessed on quarterly. And so this is also about that. It's about how you're able to embody those values, not only from a personal and human perspective, but how you bring them home in your own organization. And so this idea of impact, which can feel loose, is actually interesting because there are so many ways to have an impact. Some people will be able to have a huge impact technically because they know the language that the biggest part of the product is built on. And some others, like to give you an example, the engine of Algolia is built in C++. I don't write C++. So I will never, unless I learned language, but even then, I will virtually never be able to contribute on this. So there's only so much in terms of product impact, I would say, that I could have as a JavaScript developer, even though there are many other parts that can be interesting. But at least this is the core product, which is something that I will never be able to have an impact on directly. Now, this is not the only way to have an impact. An impact can be technical, it can be on many other aspects. It can be also on ideas and defining where problems are and what the problems that are worthy of solving. It's about going beyond only what you can do technically and be able to have conversations that are at more high level. Something that I've seen becoming really important, especially for the last years and its general in the tech industry, is that developers are being asked to be much more product focused than it was the case 10 years ago. When I started, it was more, and it was probably also the industry where I was, I was working in an agency. So it's not the same kind of dynamics as you have in a startup, but you were much less asked about what you thought, about your opinion, about what direction you thought things, where you thought things should go. And today you, I believe you have as a developer, especially in startups, much bigger opportunities around the product and about giving your unique insights to help your product managers and to drive products in an interesting direction. And this is an opportunity because this is driving impact. As a developer, you may think that you don't have anything to say about product, but you actually do. And there are things that designers cannot think of or product people cannot think of. And so that gives you a unique differentiator that will set you apart from someone who is just, and when I say just, this is not in a way to minimize, but someone who is interested in only coding. So this is where I see usually the biggest frustrations is, oh, why don't I get promoted because I am so good at X or at this language, or I can solve huge technical knots. Sometimes it will make a lot of sense to promote someone who's able to solve big problems that nobody else can solve, but technical literacy or technical ability is only one piece of the puzzle. This is only one part of what one can do and one can have impact. Cool. That was a lot. Thank you for explaining that. Did you level into staff engineer at Algolia or did you join as a staffless engineer? No, I joined as a staff level at Algolia's IC5. I joined as an IC3 three years ago. And so I moved on to IC4, then IC5 over the course of those three years. So I got the opportunity of preparing those promotions, working on them, applying for them, and then passing. Cool. Did you do any projects that contributed to your promotion process or was there a specific project that enabled you to level up? So I have to think back a little bit to remember that, but yes, I do remember that my manager and I, when it was time to think about the promotion, like every time we would try to think ahead at least six months to a year, depending on the levels, but we started thinking of specific projects. And so one that I remember at least when it was to move on to a more staff role was a full rewrites of the JavaScript, like the entire JavaScript of one of our projects. But then it's not so much one project, but more of a collection of different projects, like projects that made a difference. Yeah, there was, I can give you the example of an onboarding tutorial that we made, but it's not so much the projects, but more of a day-to-day, like day-to-day that you will, for example, how great and uplifting code reviews you can make and how you can teach other people to make good code reviews. When I say code reviews, it's not just about being extremely precise or being super uplifting, but it's also focusing on what matters. A code review can take forever and it can eat so much of the time of people. How do you teach other people to make effective code reviews where it's not going to be about arguing on things that don't matter, that work anyway and can be refactored later, but really focusing on what makes a difference and accepting that there are things that matter less. So that made a lot of the difference. But also, yeah, the attitude that you have every day, how you leverage your network is also something that can play a role. But again, it has to be flexible. Some people don't necessarily have a network or care about having a network, and they will make an impact in other places. They can do that. But when you do, and that's something that I like, I like networking, I like using my network on social media and you leverage that aspect of things. In my case, that made a difference being there in the community, especially because we are a product for developers. It made a lot of sense for me to also use that part and invest time in that to bring value to the company. How do you decide what to work on? How do I decide what to work on? It can be hard and there's definitely no clear path. The higher I go, and especially lately with COVID and stuff, I would say you have maybe more time to think because you're less in the buzz environment of an open space. What I'm trying to look at is where I can have the most impact and try to let go of the things that matter less, even if I think they matter. The line that I need to draw as a person of this I care about, but does that make sense? Is it important for the company? Is my time better spent on that? I would say code less. It's a pattern that I've seen for many folks who grow in carrier ladders, but a lot of time is spent on reviewing, on mentoring, on hiring also. What usually happens, and I think that makes a lot of sense, even though it can be frustrating, is that it makes more sense for me to help someone else tackle a feature and help them see things in a different way. At least in the documentation squad, a person that I work with closely, it makes a lot more sense for me to advise and to be there as a backup than tackling it myself because that person has a lot more... If that person works on that topic, then they will be able to grow while me doing that task is not going to... It's going to be done, but I'm not going to grow in higher levels by doing that task. It's not where I can have the most impact. Do you still find yourself contributing to projects directly, even if it's not in code, but in design and things like that? Or are you really trying to work through people more than contributing directly? I don't really have a choice because our chapter, DX, is quite small. Usually you don't invest as much on something like developer experience when it's not directly tied to revenue as some kind of other product team, so I don't have a choice. I could never not be working on code, at least in... But I think that's fine. It's also... I feel that it's, first, I like it. It also grounds me into the reality of the day-to-day that we're working on. I don't think working solely on architecture or thinking of the big next projects would be any beneficial because I like keeping a tight link between the ideation and the actual execution. I think it makes more sense. So yes, I definitely keep on contributing, but I contribute a lot less than when I just started at the company. Sure. That makes sense. You mentioned you wouldn't want to spend all your time on architecture or you wouldn't want to spend all your time on looking ahead to the next big projects that should be worked on. But obviously, as part of the staff role, one of the things that you do, at least to some extent, is probably looking ahead to some of the big projects that need to be worked on. And in that role, what are some of the things that you think about when identifying the next high-impact opportunities and how do you think about aligning the organization around you to do that? Hmm. That's a good question. I would say, again, that there is risk. This is definitely one of the things where I will try to look at, especially when it comes to technical. We all want to rewrite all of our projects every two days because code becomes legacy as soon as you write it. But identifying risk and defining, okay, that's worth rewriting, not because it's going to bring us a lot of money or anything like that, but because there is a high chance that it will break. And if it does, then we're going to be in a bad situation. But then it's more about, I would say, product. And it's more about connecting with other parts of the company that are not necessarily engineering. Usually the lower you are, and especially when I started, I was only discussing with other engineers. And that might make sense, but the more you want to define what's next, the more you need to connect with other people. Might be solutions architects, customer success managers, product managers, anybody who is working directly with customers and uncovering what are the pain points so that you can then use your own voice, because that's also something that the more, the higher you grow, the more authority you will usually have. And people will listen a little bit more. Then the more you can leverage your voice to promote those types of initiatives. So it's, I would say, a balance between risks, risk and opportunity, if that makes sense. Yeah, totally. And so how do you ensure that the stuff that you're working on is aligned with your organizational goals? It's really about aligning with your execs and aligning with your manager. And that's something that I try to do as much as possible, is be a partner to my engineering manager, rather than only being someone who is being managed. Usually, again, and that's something that I've noticed, you will spend less time talking about just yourself and your career with your manager when you go higher in your track. You will usually talk about the company, the organization and what's next. And so there's a lot that goes into communication. I spent a lot of time with my manager debriefing about what's going to be next, what he thinks are risks right now, where he thinks we could go and we should go, and debating between what I think and what he thinks to see if we're aligned. And if it makes sense, depending on what's on his end with his manager, which is higher up in the chain, is the biggest focus right now. So a lot of it is communication and making sure that you're going in the right direction. When I was telling you earlier about being able to draw a line between what you think matters and what actually matters, to me, this is key. For example, our docs is huge. It's really big. It's a lot of content and it's not going to downsize any sooner. And it's definitely a difficult topic. How do you keep this level of quality while growing? And at some point, there are things that you need to let go. There are things that you need to decide that are less important than others. And it's not about dropping quality. It's about deciding what to prioritize. And that is definitely something that can be harder to understand for an IC who cares about quality, especially as you grow, let's say you are IC3, IC4. So you were incentivized for years to be all about quality and making sure that everything is perfect or virtually perfect. And then at some point, there is a turn about making sure that quality does not come in the way of strategy. And so that makes also like that counts a lot. And that's definitely a turn that I've had to take at some point, especially in that role, because I need to make sure that I uplift other people to help them understand and embrace that vision. You cannot spend X amount of time making that thing perfect, because actually it doesn't matter or 20% of it doesn't matter. And you will ship faster, you will ship sooner. So definitely embracing the goals of the company as a company, and not only the goals of your perfect vision of what an engineer should be, is a key part of it. That can be frustrating, which is why it's might not be well suited for everybody, which is okay. Not everybody has to like, I think in many companies, you can probably reach a level probably senior, and it's fine if you never grow any to any other, any higher than that, and it's fine. We actually also need people who just care about technical stuff and quality, and that's fine. And there are people who will be miserable at higher levels. I think you have to accept as you grow into those IC roles, that it's not just IC, there's a little part of strategy, there's a little part of even manager stuff that you will end up doing. I'm digressing a bit, but my manager can, so my manager manages the entire chapter. He cannot manage everybody on everything. That makes no sense for him to be discussing technical topics with people, and to make sure people are going the right way, making sure that a junior is applying the practices that they should apply. So that makes a lot of sense for me to be closer to those people and be mentoring them and kind of managing, but not really managing them, but making sure that those things get done and it's going in the right direction than them doing that. But again, that's strategic and you have to care about people and you have to care about making the company more efficient. More efficient means that you want to have more people who get better. You don't want to have a pyramid forever. You don't want to have a lot of junior and just one staff engineer. That's not really... You will usually have something that is more pyramid shaped, but you want it to grow more and more rather than just have the people who work on the important stuff and the people who do groundwork. That makes no sense. Yeah. A couple of times you touched on the idea of helping people make strategic trade-offs or working with your manager to plan out your communication. In my experience, sometimes those conversations can be difficult. Do you have a particular approach that you take to having difficult alignment conversations? That's hard, definitely, because you also bring your own... As an IC, because you are still an IC, so you still do stuff, you still have your hands in code, you know that you're going to be the one maintaining it, or you're going to be on call, or you're going to have to manage people who are on call. It is definitely difficult, but I would say it's really about open-mindedness and being aware of what you're getting into. When you prepare for becoming a staff engineer, because that's the promotion that you're targeting, this is something to keep in mind exactly as if you were becoming a manager. If you decide to become a manager just because you want a better salary, let's say, but you're not passionate about people and you're not passionate about making other people grow and you still want to be hands-on on code, you're going to be miserable and it's going to be hell for everyone. I would say it's the same when you're targeting staff level or senior staff principle. You're going to have to make bigger compromises than deciding what the linter rules are. It might be even challenging regarding your own values as a developer. Sometimes you're going to think, okay, this is going to be a problem because I care about this and I think it should go that way, but at the same time, I have to understand where the company is heading. I would say being able to take a step back and not be stubborn, which is easier said than done, but of course it helps to know what you're getting into beforehand. If you don't think that you're going to be able to do that, or if the company that you're working on makes some strategic choices that you, and most of them you don't agree with, but you like it there because you like working on the tech, maybe that's not the best idea. Being able to work on compromise, to make compromises and being patient on things, I would say is crucial. Changing the minds of people usually takes time and sometimes you have to show and you have to show several times before it ever happens. That's something to be prepared. You have to be prepared for that. You have to be prepared of needing to back up your arguments a lot. It's different from making technical arguments where it's more about, okay, that's obviously better or that's better because X, Y, Z, because sometimes it's like, it becomes more complex. That can be difficult, but that takes time and yeah, that takes patience. I would say you have to be ready to have those conversations. You have to be ready to be pushed back hard on topics that are not technical. They're not inherently the core of what you know and the core of what you're strong at. You might be strong at having technical arguments because you have the technical literacy and knowledge, but having conversations where money becomes... becomes one of the factors, or strategy becomes one of the factors, means that you will also have to grow on those topics and deepen your knowledge of those topics and be able to make trade-offs based on those. One of the interesting things about the staff role that I found is that you're often in the sort of strange position of simultaneously advocating sort of, quote unquote, upward in the organization toward leadership on something, while also advocating, quote unquote, down into the org around sort of the priorities that leadership has set out. So you want the teams that you work with to sort of rally around certain ideas, and you also want leadership to sort of buy into, for instance, investing in open source and things like that. Do you have any techniques? When we talk about sort of bringing teams into alignment, do you have any techniques for helping sort of drive that? I think oftentimes there can be sort of, obviously, all teams have different priorities, and when you're kind of trying to steer the ship, sometimes it can be hard to sort of bring everybody on board with a new vision. Have you seen that? And what kind of approaches do you take in those scenarios? It's always going to be, and that may sound very generic, but it's always going to be through communication. I really like, one of the things that I like is making sure that things are said as honestly as possible from the get-go. I think we lose enormous time and also trust when we try to make things look less worse than they are, just because we're afraid that people are going to overreact. That's I think a bit patronizing, that's actually very patronizing, and people hate it, and then they become extremely defensive, while thinking developers are going to freak out because you say that this is going to happen or that is going to happen is actually not true. People are able to, people know that they work in a company, they are not working on a pet project, so they are able to hear stuff. What is usually also very helpful is to provide people with the ability to find solutions. It's usually, I found a really bad idea to come and say, okay, so this is the new direction and this is how it's going to be, I hope you adjust with it, rather than say, okay, this is something that we discovered or has been discovered or is a problem, and we need to solve it at some point, and there needs to be changes. What do you think could be interesting to do? How would you tackle that? And so when you give people the ability to solve the problem, especially an engineer who's usually a person who loves fixing problems, not everybody is about fixing problems as an engineer, but most people are, when you give people an opportunity to do that, that's actually going to be uplifting. They might not know initially, and it might take them a little bit of time to think about it and ponder and just, you know, bounce the ball and make sure that, okay, they understand the entire problem scope, but giving them the opportunity to do it is usually going to be a lot more productive than telling them what to do, because then what's going to happen is that they're going to, if they're not happy with it, but they feel like there's nothing that they can do, frustration is going to start growing and they're going to start talking about it with other people, never telling you about it directly, and then you're just working with someone who lost full trust in you, full trust in anything happening from the top and it becomes you versus them. So trusting people for being interested in solving problems and not only interested in solving their own problems, I feel usually helps a lot. Every time I've had conversations with people around stuff where I thought that might be difficult because that's going to change a lot of things from the way we're working right now, usually when you have conversations around, okay, there's this direction that's taking shape, what do you think we could do? Is there any way you could see this working? Or when someone comes to you and is like, I don't think that works, instead of being like, well, that's just the way it is and you're going to have to adjust, creating room for that conversation helps a lot because people feel like they can be part of the solution. But yes, that's an aggregate of many things. And I think, yes, having a trust based relationship and making sure to keep that trust based relationship solid, robust, plays a huge role. You're never going to have collaboration coming from a relationship between two people who don't trust each other. If you are a manager and you don't have the trust of your team, then they're never going to be incentivized to make your life easier because they will always think that you have an agenda. If people see you as a partner, if they think that you got their back, if they think that you're like minded, if they think that you're not trying to trick them or to fool them or make them do more work or for less pay or same pay or anything like that, then there is no reason. There might be pushback, there might be arguments, but you most likely will have collaboration and you will have something constructive coming out of it rather than pushback just for the sake of pushback, which becomes basically politics, office politics that nobody cares about and nobody wants. How do you think about the difference between staff level engineering and engineering management? And then how do you think about the relationship between those two roles and how those those two roles can best collaborate together? So I would say some of the clear differences is that I would not expect a manager, an engineering manager, to touch any code and to take any kind of decision regarding the specifics of a project. An engineering manager, it's important for an engineering manager to know, to still know technical level stuff. Usually it's someone who used to be an engineer because it's going to help them appreciate the different aspects of a career ladder and to make sure that someone like you want to be able to have conversations about the day to day of someone, especially when you're working with people who are deep into code. You don't want to be like, I don't understand anything about what you're doing or saying, but it looks fine. But you're still, you're a manager, so you're still on the people aspect of things. As a staff engineer, and so depending on the team organization, you will have staff engineers often be the tech lead in a team. Not always, but often, or at least be someone who is a reference when it comes to a certain area, technical area, is someone who will provide a lot more guidance on things that are specific with the projects and the code. So in my case, I work mostly on the front end and where the kind of interactions that I will have with people, besides from the day to day, the code, this project we're working on, will be, I often have more junior people coming to me regarding career advice and what to do to go to the next level, how to get unstuck. I plateaued, I don't know what I should do next to grow because I feel like I've hit a plateau. That's not necessarily a conversation that you will have with your engineering manager. I think it can happen depending on the kind of engineering manager that you have. If you have a junior manager who was just in a technical role and just became a manager, that may make sense, but usually you will want to have those conversations with someone who is an IC because they are still in that IC position. And so that's the kind of conversations that I will usually have with people while their managers might be more on the people aspect of things. That can blend sometimes and depends on the organization, but that's the obvious line that I would say. Now, regarding the relationship, again, as I said earlier, to me, it becomes much more of a relationship as you grow. When you're a junior or you're IC3, IC4, usually you will expect a lot of things from your manager. You will expect them to guide you. You will expect them to vouch for you or like you have a lot of expectations. It goes in kind of one direction. Wow. And it sounds like you've got a really well thought out concept around this manager stuff. I'm definitely going to learn a lot from this, I think. One of the things you touched on earlier was sort of mentoring and maybe sponsoring. Do you see that as like an official part of your role? And also, do you have like an approach that you take to mentoring or sponsoring other engineers? When a company hires someone, they make an investment. That investment is likely going to get a return after a couple of years if the person grows. If you stay junior for three years, the company like and that depends, like the calculation depends on every company, but every company usually knows that. They know when a developer or a new hire starts showing returns on investment. If you hire junior people, you invest in junior people and they never grow and you always have the same people working on the big stuff, then you have a problem. So from a very strategic point of view, that makes 100 percent sense that your most senior people create more senior people, that you make sure that the people who have the most experience help other people get more experience. So the sum of people who are able to tackle problems is wider. So that's a purely from an investment part, like aspect of things that definitely makes sense. Now there's the human aspect. I don't think it makes sense for me to do all the code and work on all the features just because I enjoy that. That's not how you create strong teams. And again, like we've seen stories, we've read those stories where you have one person who is like the genius, even though I hate that term, but everybody sees as the genius. And so everybody goes to that person, that person capitalize all the knowledge around the product, capitalize all the technical literacy. They know all the quirks and all the bugs and all the workarounds. And yeah, again, from a strategic point of view, that makes zero sense. If that person dies tomorrow, if that person quits tomorrow, which is more likely, which will happen eventually, either because they are burned out or because they they are doing so many things that they are a profile that everybody wants. And at some point, a company that pays better and has something more exciting for them, or they have more senior people and they're going to be doing less of all the work is going to come around and steal them from you. It will happen. It's not about if it's about when, if you don't have your own back, if you did not prepare for when that person was going away, then you're in a very, very difficult situation and it's going to take you a while before you recover. So, yes, that makes a lot of sense. And because I think if you want to grow teams, if this is your mindset, if you want people to work in teams and that's the culture that you're creating, you absolutely need to understand that it not everything is about you in your career. It's not all about you. And yes, that thing might make you shine and help you shine, but it's also going to help another person shine. And it's in my opinion, this is a lot, a lot of it is about the long run. If I decide to use my authority or the way people look at me to say that thing is for me, I want to work on it and nobody is going to argue, then yes, I might work on stuff that is exciting, but I'm not going to create any relationships where someone will have my back later. And I don't know everything. There are things that many other people do much better than me. I want to be able to rely on those relationships and count on them when I need them later. I want to, when it's time to do a big project that I think is important and I have an approval for, I want to be able to create a team of people who are going to be super excited to work together. In 10 years, I might be in a different company and I want to refer somebody. I want to bring somebody from a team that I used to work in. It's going to be much easier if the people that I used to work with think of me as a partner who helped them grow. And I see them as people who are super valuable and I saw them grow rather if I did everything on my end and they did nothing. And so we did not create a trust relationship. Yeah, that makes sense. Changing gears a little bit, a question that I've sort of had from listening to you is sort of where you've learned all this stuff. I'm sure a lot of it has come from sort of with time and experience, but I'm curious if there are any resources, whether that's books or blogs or people or anything else that you would refer folks to. I probably won't have much books to refer to. Most of it, I would say, really comes from the relationships and the conversations. Common sense, I would say, plays a role. But yes, it's even outside of tech. It's just trying to be a decent human being in general. And there's a lot of things that you don't have to read about necessarily to understand. It's really more about common sense. If you go past what you want right now, I want to work on cool stuff. If you go past that and you just take a step back and think, OK, what's the bigger picture? Where could I have more impact? How could I help other people? Does it feel right that I always work on the same kind of things? Do I feel like I'm making a difference? So, yes, it's usually conversations. I'm lucky enough to work with really awesome people who provided me with a lot of insight and I was able to be challenged on things that I thought before. But yes, opening your mind to other stuff than tech and trying to listen to, yeah, I don't know, other podcasts about not just tech stuff, also about people and relationships. And you know what, now that I think about it, there probably is one resource, one podcast that I've listened to for years, which is the seanwes podcast. One thing that it talks about a lot is the long term and how to have a long term vision. And that really changed my mind on things because I feel like, yes, as you grow and especially when you reach those levels in your career track, you have an incentive to take a step back and to think of the long game, of the long run. It's not about only what I'm going to work on this quarter. It's about where I see us being in one year. It's about what kind of connections and relationships I'm going to be able to foster in three years. It's about the awesome relationship that I've preserved from that place I worked at 10 years ago. And now I remember that person who worked on cool stuff and they were a wizard with that thing and they were interested in that other thing. And we talk on a recurring basis and I'm able to bring them because they make sense at a given moment. So the long game mindset and thinking of things more as investments, be it projects, relationships, anything more than just how can I make something quick and visible right away just so that I shine and then everybody forgets about it, I think plays a big role. Many, many things that have high impact happen on the long run. Not all of them. You cannot just be focused on the long run. Otherwise you run out of money. It's a balance to have. But on the other end, if you're always going into, OK, how can I make something impactful right now, you know, like making blips on the radar, like spikes, you're never going to build a robust foundation. And I don't want to make like cheesy analogies, but I would say it's kind of the same with the project. You can rebuild every two years. Everybody loves that. But that's no way to work on enterprise software. You cannot make anything only perfect. You cannot just work on polishing everything and making sure it's stellar. Otherwise, again, you're going to run out of money. Nobody puts out software that is bug free. But trying to find the balance and making sure that what you build is at least has some good processes to make sure that they stay sane is how you're going to build something that lasts and something that is not terrible to work on in 10 years. I'm not in the best industry for that. I do web so that's easier to redo projects. But some people who work on on very enterprise software, like, I don't know, 3D enterprise software for huge companies, then it's like you maintain something that you will still have to maintain in 15 years. And that makes a lot of sense to think of it as we're building this for the long game. It's not going to be perfect, but we have to think of the long run. That makes a lot of sense. I really appreciate that idea of like learning from outside of our industry. I, for instance, I'm learning a lot right now from sort of like reading a lot about industrial safety and human performance. And it has this really interesting Venn diagram with operations. So the last question that we have been asking everyone that has come on the podcast so far, and it's just really a curiosity and hopefully it's a fun question, is how much time do you still spend coding? Oh, actually, coding, I would say probably a bit less than 50 percent of the time. If you put reviewing as not coding, which sometimes is a bit bland, but yeah, a lot of time is spent of reviewing. So, yeah, I would say maybe 50 percent of the time on the best days. Nice. Awesome. Sarah, it was so nice to meet you. Thank you so much for taking the time today. Thank you for having me. It was really fun. That's it. Thanks so much for listening to Staff Inj. If you enjoyed today's show, please consider adding a review on iTunes, Spotify or your podcatcher of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it. You can find the notes from today's episode at our website, podcast.staffinj.com. The website also has our contact info. Please don't be shy.