Changes in engineering management craft, career growth and all hands demos for inspiration and context w/ Lindsey Simon #252

We're doing a special in-episode feature with our friends and sponsor Unblocked. Every time you go down one of those paths that is incorrect and you're doing that correction, it's costing you tokens and it's costing you time. Stay tuned forward later in the episode, Dennis Polarinos, founder and CEO at Unblocked, breaks down the hidden cost when AI agents operate without context, and how a context engine gives agents what they need to generate mergeable code without the babysitting. When you join a company to increase the output and impact of a group of people to show up and claim that you think you can do that, there's a pretty bold claim. I think the best strategy, and this isn't new, is to really try to understand the company you're going into and what you think they should do differently. You might go, "I'm a really good manager. You need a really good manager. I'll figure out the company later." I don't think that's going to cut it anymore, and so I think in this process of, "Hey, you're going to go and try it on for size. Show, do your homework. Go in wanting the job. Practice for yourself with that means. You're a manager. You're also a salesperson. You're also a product manager. You're also a customer support engineer. You're also an IC." Hello and welcome to the Engineering Leadership Podcast, brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC, and I'm Patrick Gallagher, and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. Live from the Vercel Recording Studio, Lindsay Simon, VP of Engineering at Vercel, joins us to talk about the evolution of management craft and career growth strategies. We dissect the practice of live all-hands demos as a tool for context, accountability and inspiration. Plus, Lindsay's vote with your wallet framework for career strategy. We also get into how a customer support engineer pushing code to his open source project. While on a quest to debug, inspired him to apply to Vercel, and why the most effective VPs right now are building hobby projects to maintain AI competency and empathy for non-technical users, let me introduce you to Lindsay. Lindsay Simon is VP of Engineering at Vercel, making the web better has been his lifelong career ambition. Prior to Vercel, Lindsay spent seven years at Google where he helped launch App Engine as an original core team member and worked as a tech lead on the Google Translate and web performance teams. Lindsay's lived in San Francisco for the past 15 years, and his creative hobbies beyond coding include writing music and hunting for wild mushrooms. Enjoy our conversation with Lindsay Simon. Thanks for inviting me to the Vercel Recording. It's really excited to be here. How's your day going? It's Tuesday? Yeah, it's Tuesday. There's a lot of energy in here. We had our company all hands this morning, and so if you came in and noticed a pack of people in the kitchen, they were all in their listening. I did. I opened up the door and I was just blown away by the energy. So we're going to talk about a lot of different things and how it's shifting in this era. Can we start with all hands and how it's evolved a little bit? Because I'd like to get a sense of how is that evolved? Because I think that is such a missed opportunity for people to create a powerful moment for their teams or their companies is to use that in a really intentional way. So yeah, tell me more about how it's evolved. It's certainly become more organized in the sense that we do think about making it more intentional because it's 600 plus people spending their time in an hour. It's an expensive meeting in that sense. We do the prep for it. When I joined, all hands was there was some degree of preff, but it was much more of what we do now on Fridays at 8 AM, which was we call demo days. Meaning that all hands was a show-and-tell of what you were building, pitching, why you were building it back to the rest of the team. And so it kept everybody in context around what was going on. You could infer how well the people building it understood the mission or were changing the mission. And they were sharing their thoughts about that in real time. And so it was really inspiring. And you would get to see their craft work. And what people could do week over week to rebuild parts of the system or build new parts of the system was super impressive. That context piece and that ability for people to get a sense of how things are evolving real time is one of the hardest challenges of this premise of being in the AI era. The environment that people are in is that things are accelerating. What you can build is moving faster. I find myself oftentimes, I'm definitely like, how things are moving so fast, like, and I miss something. And so to me, I can see that demo day is such an important way for people to gain the right operating information in their heads to then go and do more things, or to challenge what they thought is possible. Did you find that really helpful for teens in terms of decision making and changing workflows in some of those elements? Yeah, I mean, the thing that helped me the most and I think was different about Versel is it was very visual. I think a lot of times these meetings are yapping. Or, hey, I'm going to show you my document. I'm going to share my document on the screen. This is the thing I'm doing. And it wasn't that. It was never meant to, and nobody shares video. It's live. It's real. It may not work, but it's the current state. And I think when you start showing artifacts of things that were even a week ago, you're now getting into a world where, okay, you produce this video of a feature or thing you're doing, like, you know, you gussied it up, right? And now it's actually dated. Like, the thing you shot the video a week ago isn't hot anymore. You've been working on it since then. Like, what did you do differently? And so I think that that contributing to that real time sense is showing the real time, like the real thing right now, not the thing it was a couple days ago, or the thing you've packaged together. It's like, okay, you can ask questions and somebody can be like, oh, yeah, well, we didn't build that part. Well, okay. I noticed, you know, it's like there's an accountability about what's actually real right now. It was pretty fresh for me, and I loved it. Accountability for what's real. I like that concept. So, how do you prep for like a day like today? Like, what do you do to help really anchor it on it being real on it being like visual and to create that sense of progress? Yeah. So, you mean like if I'm presenting or like, or even like contributing to the whole thing? Yeah. I mean, honestly, not as much as you think. I try, usually for me personally, as a developer, I try to get the thing to work really well and feel comfortable, but it's not rehearsed. I have a narrative in my head, and it either goes that way or it goes some other way, and I try to make it real. But I think there's something about sharing the novelty for yourself and other people. It is not new to you at all, then it's not new to anyone else either. And you get to experience the joy of victory or the agony of defeat in together, and that's kind of okay. There's something like so fun, because you know, a couple of events in the Bay Area, like there's like this big culture on live demoing right now, and like it being such a such a mark of street cred. And I think that is so true is like in the live sharing with people your energy or excitement around a particular thing, and then to bring everybody into the thought process behind it, it's like potential and like the implications of it. Like it's really fun to kind of be a part of that. I think that really maximizes the like live time that you have with people, is in sharing the energy or enthusiasm of the promise. I think we consume a lot of pre-crafted media, and there's something about the raw, you know, the stakes are high in the sense that, you know, you don't really know how it's going to shake out. If the stakes aren't high because it's just going to work and it's going to be fair in the middle. I mean, it's still good. You can learn things from that, but I think we all kind of revel in the back and forth of, well, then this may not work. And I think that goes back, like the history for me of getting into programming was going and doing meetups. I mean, there used to be a thing we call it bar camp. In Austin, where I was growing up as a programmer, we would rent venues out during the day, because they didn't do anything during the day. You know, they were just stocking beer and, you know, the smell terrible, but they had a stage. They had, you know, room at a space, it was like a big enough space to accommodate 40 people. And you know, we could bring a whiteboard or something and people could bring computers and, you know, you could have this live unscripted meetup bar camp. And that was really exciting for me. I would go to those with the idea that I was going to try to show a really cool demo that would excite other people and see some that would excite me too. That was pretty addictive. Live demo cultures, I feel like a good pulse for how we know San Francisco is back. Because so many live demos going. It's true. I mean, there are so much, so many more events right now on a given week. We have an intern program. And one of the things I, you know, excited about them coming to San Francisco for is that, you know, in addition to events that we might be a part of or they're doing because it's very active now. There's so many. I mean, you're, you're, if you're in San Francisco right now and you want to go network and meet people, it's a very welcoming culture for that. Absolutely. We're taking a quick break for a special feature with our friends and sponsor Unblocked. Dennis Polarinos, founder and CEO at Unblocked, breaks down the expensive reality when teams have to babysit their AI agents and shares how a context engine stops your team from wasting time and tokens in correction loops. Historically, people have been the ones who write software. The folks who can write mergeable code quickest are the ones who have the context for how their organization works, how their software works, how their system works. And what we're seeing is that increasingly agents are writing code on behalf of these organizations and they actually lack that context. We have a team that has 110,000 repositories and 30,000 engineers. Imagine trying to get an agent to like be able to like understand how that system works or why it works without pre computing any of that information. If you're inefficient in the way that you're looking for information or getting information, you basically end up going down these rabbit holes. Where you go down the path, you think you have the information that you need, you take that information back, you try to execute against it, it's actually incorrect. You kind of go through these correction loops where you're constantly saying no over here, no okay now over there, no okay over there. Every time you go down one of those paths that is incorrect and you're doing that correction, it's It's costing you tokens and it's costing you time. I think very viscerally what ends up happening is you're copying and pasting spoon feeding these agents all the information that they need. And you end up doing that because they basically do a bunch of local tool searches, trying to find the information that they need in order to accomplish that task. The outcome or the result of that is that you end up spending a bunch of tokens. So if you can shift all of that context earlier in the cycle, you spend less time burning all those tokens all that time. So Unblocked helps developers and their coding agents get all the information that they need in order to get their jobs done. What it does is it pulls together information that exists in systems of record like Slack, Confirmative GRO, Google Docs, Notion, Linear, anything that you use in order to build your software, pulls all the information that you need together such that an agent can be efficient in getting its job done. Instead of you having to copy and paste a bunch or to constantly point the agent at the place that it needs to get the information, Unblocked does this in a very token and time-efficient way. You don't have to do these back and forth babysitting loops trying to explain how that system works or why it works that way. We see our customers do this all the time. They take the exact same task. They ask the agent to do using Unblocked and they ask the agent to do it without using Unblocked. And almost every single time, depending on the complexity of the task, the Unblocked result is far more efficient in terms of literally wall clock time. Give your coding agents the context your best engineers have. Your agents can read code, but they don't know how your team works. Rules and MCPs give access to information, but not understanding. That's why you still have to tell them where to look and what to look for. Unblocked gives your agents the history, conventions, and decisions behind your code so they can generate mergeable output without the back and forth. It automatically services the right context for every task. So agents stay on track without the setup tax or the correction loops. Ship faster with AI outputs that actually reflect how your system works. To get started, go to getunblocked.com/elc. That's getunblocked.com/elc. But this was kind of fun because you and I spent some time in a dinner together a few weeks ago. And this career-grossed conversation came up because you were reflecting on meeting Jerry Lee, founder of ELC, while you're at Salesforce, and sort of discussing what to do next. Tell us about that story in that moment. I was trying to crystallize for myself how to think about what I wanted to do going forward. I could tell that the company that I had been with, Quip, and acquired by Salesforce was instead of targeting productivity at a very broad scale, was trying to target, well, how do we make things that people are using Salesforce more productive within that ecosystem? And I didn't have any experience in that ecosystem. I was learning, and it was interesting to me, but I also didn't, I felt like I didn't have the intuition that I wished I had to have instinct for things in there. And some of that was just my own background. Like I didn't have experience selling directly. I didn't have experience of being a forward deployed sales person at that time. So I didn't know how to think about the interconnection, what sucked about those tools or what would be great. And so when I was talking to Jerry, I was sort of reflecting on there were a lot of interesting companies and people building interesting technology. And I was trying to figure out, well, what makes sense? I had gone to a quip with the intention of perhaps spending more time as a manager. I'd been a tech lead before that. And I was a tech lead when I started, but the thing was, okay, I was going to try to give up using code as my only lever within the company. It's not the only lever, but it was the one that I could fall back on. I could produce a lot of impact through code. And so I was going to try to not do that or do it differently. And so talking to Jerry, it was really fun back and forth because I had a feeling he was talking to a lot of startups and a lot of other people and other companies had a really broad view. So I wanted to prick his brain about what he saw for people who felt like they were feeding their ambitions correctly or struggling or where they were feeling stagnant. And one of the things I left that conversation with him and a few other people was I wanted to go somewhere where I was voting with my wallet, meaning they had some degree of product market fit in the world and I was part of that. And it was kind of a liberating way of approaching what usually was the job search, you know, 'cause it's like, okay, well, would I use this? Okay, that gets you excited about the mission. It's very different from, am I using it right now and I have no idea if this company has jobs. You know, imagine you're sitting there looking through your subscriptions and thinking, okay, this is the sum total of all the places you could work. It's not that many, but it's enough. And I wondered if that would work for me. And I had already, I think I had just started and met Kisharamo and explored Zite and I was pretty convinced that was gonna be what I wanted to do. Like I was a paying customer. I didn't know anybody of their company. I knew who some of the people were but I was so fascinated and excited about what they were building. And in fact, before I went to Quip, I did my interviews for Quip and for Segment, which was another company I was excited about using NextJS. Like, you know, usually interviews have a building part. And so I used NextJS to build my interviews and that was kind of a signal and sort of like, okay, this makes a lot of sense. It felt intuitive. - There's a lot to get into there. And I really like this idea of thinking about where you wanted to go next. And there was this level of, you know, your instinct intuition or sort of being drawn or in different areas as sort of like your strength. So I kind of perceived that as like a way of analyzing your strengths or the unique experiences that you have that you could sort of double down on in your next opportunity. And you really be able to use that as a way to impact a feature organization. And then the other was like, I love taking stock of like, what are the things that you've used and love as almost like a discovery point? Because you're right, like I can think of like five specific things that I use that I'm like, oh, I would be an evangelist for this. Like, in a heartbeat. - Well, it makes sense. When I met Shoei, I was like, we talked sometimes about career growth. Like I obviously gave up on that idea. Like time ago, I guess because my conversation was not about looking at my path from, you know, job role to role. I mean, I was just like, I just wanna work at the company. I actually don't care what job, I'll be the janitor, you know, whatever, I didn't care. In fact, I was talking about being an advocate and doing dev rel or something like that. Because I was so excited about what the company was building that I felt like I could talk about it in a way that would share my infectious energy with other people. Now, I didn't have experience doing developer relations, you know, concretely. Like, I wasn't a job title on my resume. And I think his punishment for that 'cause Sheremo made me a job title. I'd also never had on that resume, which was product manager. So I actually started as a product manager. And it wasn't like we discussed that and I agreed to it. It was I had already agreed I was gonna come work here and figured all that out. And then a week before I started, Sheremo, sort of dropped the bomb on me, I was gonna do product. And in the end, it was really great because it was the code shouldn't be your primary lever as a manager, theoretically. And so it was gonna continue that. But also, I was gonna be talking to customers. You know, it has a lot of elements of developer relations 'cause our customers are developers. So it really, you really satisfied a lot of that itch for me. And it was a great experience. - I think the other part of your story thing is really interesting about this is also, there's a lot of noise when it comes to finding opportunities. And I think that your story with how you got involved in First Cell, I think is really fun in terms of like how you identified it and then how you started to, you when you sent everybody a message being like, "Hey, this is really cool. How do I get involved?" And so I wanted you to, I was already able to tell us the story of like how you first got involved with First Cell and like what was like the early interactions like? Because a lot of like I'm trying to think of right now and I was like, how do people get attention in the noisy markets or the overarching goal? But I think the way that you initiate your conversation with First Cell is really interesting. So we have pretty recent in that. - It's luck. I mean, in this sense, so it actually started with customer success. So this point, Zite the company had published, there was next JS and then there was infrastructure and services to be able to take your next JS app and put it on the web. And there was a change to that infrastructure called NowV2. So if you remember, there was a NowCLI, which was amazing. You could buy a domain and create a project with one CLI command. It's kind of a, you know, start your company and one CLI command moment. And I thought that was really powerful 'cause buying domains was historically, you know, go to some nasty website, click around, suffer through the 10 pages of upsells. This is just like a command line and you just had your domain. It was, and it was connected. It was on the web already. - So it felt amazing. And I had filed a ticket because my open source hobby project, which was actually about collecting rainfall data for figuring out whether you should go hunt mushrooms 'cause I hunt culinary mushrooms on the other of the coast. And so I was like, oh, is it, the rain in point raise in the last two weeks? I mean, it may not have rained in San Francisco, but it might have rained in point raise. So, you know, you had temperature, you know, all these, you're still available. Is this the forecast? - It's forecast is no longer available because weather underground can their API. - Oh. - But it would get weather data from people that just created those weather stations all up and down the coast. - So it was an amazing thing. - But I started hunting morale mushrooms in the northwest. - Oh yeah. - And so we just started getting into tooting into the seasons that that's available, timing and stuff. So it's, no, it's not, you've got to have it all right. You have to have elevation. You have to have, you know, and the truth is you can figure this out on social media pretty easily because people love to post their stuff. But I wanted to do it through heuristics and science. And I thought the fun programming project. And it was. But for some reason, when now V2 came out and I was convinced I wanted to use that because, you know, I wanted to use the new thing. And, you know, I was in programming that much. I was in my day job. I was like, okay, I noticed my build failed because I just, you know, made an edit that morning or something. And so I wrote in and I didn't expect I would actually hear back. I was a paying pro customer because I had bought that so that my mentor who also worked on this project with me could also go through the experience of seeing what modern deployment on this new system looked like because I was excited about it. And he never actually deployed anything but I had bought two seats. So at the time, you had to be a pro customer and I have collaboration. So I will. I wrote in and I went about my day and I didn't expect anything. And then I got an email from GitHub that somebody was pushing a change up to my open source project. And I was excited about that. So I looked at it after work and it wasn't a person writing, you know, working on sports cast unsurprisingly. It was a Versel customer support engineer pushing to a branch to trigger the build system to try to help figure out why it wasn't working. And you know, they didn't email me. They didn't send me a ticket number. They didn't do any of that, but I just saw that this person, Paulo Dmitry, who was a CS engineer at Versel Azte, was writing code to interact with me. And you know, I don't know if he was relying on the systems to notify me or just didn't think about it. But I thought that was incredible. If that's what this company did to support developers, like that looked like the future of what developer relations should be. You know, it was kind of code first. It was tech first. It was an email cons and a system. So I was excited. I just wrote into John Zidzite.co and said, Hey, here's my resume. I promise I'm not a suit because I had a fancy title, right? I'm going to be a pub engineering. And I didn't want them to think that I was looking for that. I just wanted to work at the company. And then I ended up coming and meeting Gershirmoh and Tutol Nei, you know, one of the other engineers. I'm Kevin Van Gundy, like some of the people just really early on. And I knew it. I knew the moment I walked up the stairs above Tomasos Pizzo in North Beach into a tiny little startup office that I was back. I've done this before. I love going to companies where that is kind of, you know, it's an end to the department of cords on the floor and, you know, one little conference room and people just hacking. The story is incredible because I think it's so indicative of culture when you're working with a particular person. And the way it kind of occurs to me is like impact versus process. But like the person was like, we're going to do whatever we need to do to figure out what their problem is. Regardless of like a customer service ticket or just putting Lindsay in line. Yeah. I think that's really interesting. Do you feel like that culture has continued in different ways as the system's growing? Yeah. I mean, we have a, we have a values system for Versaul. We share with people who join the company and one of the values is to dig deep. Talk about dig deep. I mean, Paulo went and dug into my project. Like, I can't believe you. I mean, he cloned it locally, noodled on it. I mean, what a, what a flex. I mean, you know, like for somebody who in my mind at Google or had been companies, you know, customers, I never interacted with customer success as an engineer. And meanwhile, I'm having this amazing interaction with somebody who, you know, is an engineer by every definition and trying to help me. And it felt amazing. And I want, I want other developers to have that experience. I want that to be their experience of using this platform. So that's still true. And I think that, you know, if you fast forward into what we do now, one of the things that I've worked on here was to change the experience of getting support to incorporate AI. It's quite good. You know, something now nine out of 10 things you would ask normally have filled out a ticket for we can help you without you having to fill out a ticket and wait for a response. So it is great at giving you the information you need. And so nobody wants to fill out a web form, let alone wait six hours for a response. If you can get on your way and empowered and personalized information back, like, oh, for your account, this is the error. Here's what we think you should do to fix it. That's amazing. And these systems are quite good at it. So we now spend our time making the system feel more self-healing than we do making you wait for us to heal it for you. I really like this concept of make the system feel self-healing. I feel like it's a really powerful product principle to design your system around. Totally. And so one, it's got me into this space. When I worked at Google, the first big team I was on was called App Engine. And the whole premise of App Engine was that it would be an auto scaling system. I had spent years learning how to scale VMs and chart databases, things that I did not have any interest in. I wasn't interested in that part. I was a builder, but I had to do this because otherwise it wasn't fast. And if it's not fast, it has a terrible experience. And I care a lot about the experience. So I had to learn how to make it fast. But then the principle of App Engine was you would have a directory and a project and Google would take care of the rest. That's very powerful. Versel has the same ambition. It's that, okay, if something happens now, we have like build observability. And an agent that tells you what it thinks you need to do based on the logs, based on the data, you have the option to let it just do it. You can intervene and do things yourself. It's really empowering. So Versel obviously cut your attention with Palo. Really demonstrating some of the best qualities and characteristics of great support. So you're kind of a phase where you're like, you knew you wanted to do something different and you were starting to pay attention to what that might be. How would you recommend somebody at that same phase take the next step? Like, what would you have them pay attention to? What should they be reflecting on when they're thinking about a next career step? What I tell people generally is like, you have a few angles to consider in this. There are the people. There's the mission of the company and then undeniably there's probably this part of your own sense of your career story. And you're going to weigh them differently in the process. Like sometimes you can go all in on all I care, you know, all I care about is the mission. I don't care if I do it for free. I can do that right now in my life. You may not be in a situation where you can do that. So you're going to make trade-offs across these dimensions and what I've usually advised people to do is make it real. Go start interviewing, talking to people. From challenge yourself, you don't have to accept every opportunity that comes your way, but you should feel the urgency of what it would mean to consider doing that. Because if you spend, if you're just doing that in your own head, it's not very real. Once you start interacting with other people and other organizations, your own expansion of what's possible really does open. And you know, can't just be you reading about things that you have to go meet people and talk. At least that's what worked for me. But it wasn't like the first time I did that. It was immediately obvious what I should do next. You know, I probably interviewed at six different companies just to go through the process over seven months just to try to, you know, suss it out for myself. To segue into management culture and how it's shifting, I guess maybe the first question is bold strategies for an engineering manager to get noticed in the interview process. And I'm thinking about like, Paulo and like locally cloning your project and then dig into it. And that being something that really stands out to you. And I'm like, what are bold strategies that managers can do that can have them stand out in the process beyond submitting an application? And I maybe that's kind of teeing up like how management culture is shifting and what people are being assessed on where that assessment is sort of shifting or where impact looks like shifting. Yeah. I mean, I think that when you join a company to increase the output and impact of a group of people to show up and claim that you think you can do that, there's a pretty bold claim, especially if you don't know those people yet and et cetera. So I think the best strategy and this isn't new is to really try to understand the company you're going into and what you think they should do differently. Now, obviously it's somewhat naive. You don't know that much about the company and any company you go to knows that. They know you don't know the inside baseball. But when you have conviction about something that you think they should do, immediately you kind of bond, right? You bond over the mission of the company. And you know, I think traditionally, you know, I don't know that this was always the case, but I can think of counter examples too, but like, you might go and say, I'm a really good manager. I'll figure out the company later. I don't think that's going to cut it anymore. And so I think in this process of, hey, you're going to go and try it on for size, do your homework, go in wanting the job, practice for yourself with that means. You're a manager. You're also an IC. You have to know all of those things. And so when you go to a company and you're, if the privilege of talking to them about joining their mission, you should know what you're talking about at some level. Now, you know, again, that depth is something, but you can't go in and be like, oh, I'm trying to learn more about your company here live. You know, do your homework. You know, we, even at Google, they used to ask candidates in the interview process, like, hey, go to the homepage of Google. You know, how should we make it better? And sometimes candidates would say, oh, it's perfect now. You know, they're sort of afraid of breaking the glass of the person on the other side. That's the wrong answer. You know, if it's perfect now, we could all just retire and go home and it's not. Yeah. You know, it's course, it's not. You know, you should be able to go to the homepage of Google right now and tear it to shreds. I love this idea of creating a point of view. Like when you're, when you're going to a company and interviewing with them is like, if you do the prep work ahead of time and develop a recommendation, a strategy and approach, or just a point of view on product direction, even management approach to help X team that you're interviewing for achieve different results. Like, for me, that's like such a more productive exercise than how do I change the phrasing on my cover letter to match whatever values that they're looking for, which feels also like you're sending that into a void. But I think like to me, it feels more controllable also to develop a point of view. Yeah. And I mean, the other side of that is obviously like, be resourceful. You know, you can, you can send in your resume on the web form and sometimes that works. But go grind, go find people. You know that knows somebody that knows somebody at that company, work your way in, be resourceful. And again, that assumes you've targeted some companies you want to go after. You can do both, you know, you can get pulled into ones you know less about and see what that experience is like and go after some of them. You do want to go after the ones you really want after you've practiced. Like everything in the world, practice makes perfect. And so if you go do your first interview, the company you're dying to work at and you haven't been interviewing and practicing, you may just knock it out of the park, but you probably won't. It's no longer enough to just be a good manager and figure out the company later. I like that trend in terms of framing people. So when you're thinking about how management and engineering leadership and like the culture of that is shifting, like what are some other or observations or trends that you're seeing, maybe have yourself, but maybe broadly more in the industry, are there certain things that you're seeing shift or certain things becoming greater priorities for managers to do in terms of their impact and how they operate? The nice thing about AI and the sense is, to go back to your point around code isn't you're only lever. As a manager, just people managing isn't a thing anymore. You an engineer, first and a manager, second, how do you balance these things? I think that you can't really understand how to help people if you don't live in their shoes. You've got to do IC work on the team. You've got to do customer success work on the team. You've got to do product management on the team. Ultimately, your job is to enable them to focus more in one of these capacities. That's important too, but it doesn't mean you don't try to live in their shoes and experience with their experience. You don't go through the experience of trying to land code. How do you have empathy when somebody's like, the build system takes eight minutes. I'm dying here. You're like, "Okay, well, for me, it was 20 minutes back in my days. It's been minutes now." You can't have that attitude. It should be 0.1 seconds. What does it feel like when it's eight minutes now? It feels too slow. You have to feel it to be able to share that experience. I think being able to share experience with your team is key. Knowing what's going on in people's lives. A lot of the principles of being a good manager still apply. It gets totally changed, but I think it's easier to stay connected now into what the day-to-day life and work is like, because it's changed so much. You have a responsibility to learn yourself now what that means. Manager without AI competency today is a very risky world to live in. My next question is what maybe patterns of behavior look like for somebody to help build out that shift in default behavior. Maybe there's somebody who's been an engineering leader, default people manager. For me, I definitely like, there's a lot of human behavior friction to change your style of work and your patterns and what the default things you do are. What types of things can help somebody shift into getting deeper as an IC, diving into some of these different tools, doing more PM work or doing more customer success work? I also really love this idea of you need to feel all of these other dynamics to be effective at, enabling other people. You've kind of said that a couple different times, different things that you've talked about, but that feeling in terms of product taste, that feeling in terms of how you enable customer success to be more effective with your customers, but also in your product management and developing product taste. Feeling the problems that you're working with is such an important thing for intuition and productivity. How can somebody shift in? What are some of the behaviors that you're seeing or patterns of work that drive that? The nice part about learning phases, go build something. The word engineer, the idea that we build things as a job, it's privilege for sure. Just ask yourself, what's the last thing you built for fun or for a use purpose that has a stakeholder that's not necessarily a technologist? I think that people who do consulting and any capacity gain an empathy that people have never done it just don't understand when you are beholden to someone who doesn't care how you did the thing. They might appreciate it, but that isn't really what they care about. They care about how well it works for them or saves them time. You're building a system to improve some productivity. Well, either it doesn't. You're going to get very raw feedback from somebody who doesn't care how the sauce is made. It's a good analogy too. You could use all the best equipment in the world and produce something that doesn't taste good. It cares. You've got to have checks and balances out there. I usually tell people, build something for your parents or for your community where somebody will give you honest, raw feedback. That will force you to go back to trying to learn how to build this thing to be useful. You can start from scratch right now. It shouldn't be that scary. The tooling is so much better now. It's so easy to get a web page on Versel through V0 to getting something live that then has a get repository. These things seem like I need to be in a terminal on a command line on a Linux machine using GNU systems. Nobody's thinking about that anymore. I interview a lot of people who don't know that history now when they're using these tools. I think that's okay. You can learn that. Also, your job is to build upon the shoulders of the things that have come before you. You'll be able to revive Sporkasts. Would you reimagine Sporkasts using modern tools? Probably not. I have other means that work better for me, because friends. You know, I think social networks better that. But I still use, I sell hobby projects that I build and work on every week relentlessly. The same one that I demoed to Gisharmo before I joined this company. I still work on every week and I use every week. It's kind of personal software. You can use it too, but you might not write music. Having chords and lyrics and the ability to look things up may not be interesting to you. So it's fine. But I love working on it. It gives me a chance to play with my own expectations for how the software should work. And I depend on it. I'd be curious to get your perspective of what great management looks like at Versel. Then maybe some of the previous normal patterns of management that are maybe less relevant now. And comparing and contrasting where you're seeing great shift to and then what are some things maybe that are becoming less impactful as a manager. Well, I'm going to turn it on. I actually think it's the same principle as was true before as is today. Great people doing great work have conviction. They know how to unblock other people and themselves. You know, that's part of it too. You need to know how to unblock yourself. And then you learn, figure out how to unblock other people to make them feel empowered and have agency. But sometimes that's sharing context. Sometimes that's sharing things you've learned in your own experience. And sometimes it's sharing technical wisdom. It needs to be kind of all of those things. So I think great leaders are, it's the same principle. So the tools are different and probably it has more to do with who your audience is. But look, we're a developer tools company here. And so you need to be a developer to know how to build there. And so helping your developers build for developers is really fun. It takes great communication skills. You need to be fantastic at getting your point across concisely and definitively. I think the way that you frame those high level categories is really powerful because it's like being a great manager hasn't shifted. It's just like the tools that are changing are. And so you have to become familiar with those in like personal projects and experimentation there's going to help you drive and get that context. And then that's also going to then in the context of these new tools and how it's impacting products, workflows. You have just a much better sense of how then you can unblock people. Because the specific tactics to unblock are changing. So if you can get a sense of that, that's going to help you then do the thing that isn't changing, which is unblock people be effective and help provide that context in the wisdom. And I mean talking to customers remains like the magic of figuring out how to do that is understanding how to go from scratch with somebody's problem. It isn't a way going back to like sort of the service industry mentality. It's like somebody's coming to you with a problem. They're on fire. You don't know everything about what's going on in their situation. So you're really flying blind and trying to be effective and the best people are exceptional at that. You never were kind of talking about this idea of like co-learning with your team as like a really important principle right now. And the reason why I think I wanted to kind of bring this up is we did a hackathon under a conference. And for a lot of engineering leaders, it was actually like their first time using some of these tools and V-thera was one of the ones that we recommended like use this play round. One of the things that was interesting was people sort of mentioned previously like a sense of imposter syndrome or like a fear of looking bad if they were doing these tools and like failing and not an expert them immediately. And so I think that for like a lot of managers to maybe like our hesitant to come into them. That's a very real fear. One of the ideas you know are kind of talking about was you know learning the craft alongside your team as a way to like both bond people but then also to sort of create a system of learning. And for some people there's like this internal fear of like if I'm not perceived as the expert like I'm not going to have credibility or like people won't then list me. So I don't know if I have like a question maybe just like a reflection of the mind killer. That's the thing. Fear is the mind killer and if you're afraid of looking or being perceived a certain way it will dog you forever. That's the thing to get over. Be vulnerable. I find that goes a long way too. What you're trying to really assess what the people around you is trust. And if you're dishonest like you're not going to build trust and so if you're straight forward about the things you don't know and you don't try to dance around that you will build trust with the people around you. And the alternative to that is you will erode it and it's very very difficult to retain so showing what you don't know to other people is a perfectly good way to build trust. And the alternative is waiting until you're an expert. You're not going to likely become a expert. I want to jump in a little bit into interviewing and some of the because I know that you and Versailles vulnerable motor roller. Oh gosh. Yeah. Well, the inherent power dynamic of somebody assessing you for fit is anxiety inducing to say the least. But I know that you spent a lot of time thinking about interviewing and Versailles in a lot in terms of experimentation and thinking critically about how that's shifting. So part of it is I want to spend some time just hearing what you're learning what you've been experimenting with some of the insights or trends or observations that you've seen with interviewing. Well, maybe from like a hiring person side but then also from a candidate side going through the interview process. We can kind of tackle that a few different ways but yeah, I mean, I think there have been a few pretty monumental shifts and what this looks like in my time in the industry in any case. I mean, my first interviews were "Stake Dinner" with the CEO and Austin. That was kind of the final boss, whereas my final boss interviews in Silicon Valley were systems design and algorithms and big O notation, math. So it was very different experience. And then I think another shift was when you started seeing more remote interviewing. Not a phone screen, but something where you were actually coding more and it felt live. Some people are doing fully remote and some people are doing in-person experiences. So you get a lot of different fidelity around somebody in terms of assessing their capabilities and fit. And certainly AI has changed. That's probably the biggest shift is the thing where you would remotely ask somebody to write code is incredibly sus. Our tooling is, you have a Jason mine sitting on your desk alongside this thing that's connected to a video. You don't know what's in their head or what they're reading off a screen. Also, you want to assess their abilities with those tools. So I think knowing how well somebody works with AI tools. Because you're not starting day one without those things. But it's not so to say someone would be like, "Hom interviewing them." They're going to look up the answer on Stack Overflow. In some ways, it's not that different. So I think for gaining experience through the process of interviewing other people, the only way to do that by doing it. And in a position of a company, you should try to figure out how to get that experience. And if you're on the other side of that, again, going through the experience, don't put your golden company as your first interview. Go through the process. Get familiar with it. Because there's probably a mean to every company interviewing at the present time around how they operate. Some people will let you use AI. Some people will want. Some people absolutely need to see you use AI. What company do you want to work for? There's a lot of principles back to, I think I always go back to some of Joel Spolsky's Vlog posts of the old days like, "Okay, are they going to give me the best tech money can buy?" So you should get in your interview process. If you don't have access to the best tech money can buy to demonstrate your abilities, do you want to work at that company? So I think you have to think about a lot of these things in the process. What matches what you're looking for? Related trends there, I think, are knowing how to learn during the process. You might get to some point and then now your interviewer is going to tell you something. Can you listen? Do you pay attention there? Can you repeat back what they're saying? Some of this is like comprehension, under stress. That's pretty relevant to most work environments depending on the nature of the company. Are there certain patterns of interviews that are shifting that you're starting to see? So you were kind of mentioning there is this thing where people want to see how you operate without AI tools and how they operate with AI tools. Are there certain ways that those sort of assessments are looking or shifting or how does the versatile approach? Yeah, one of the things we're doing now is people come and spend a day just working. In some ways we might see more of that because it's just so hard to tell what is and what isn't you over a screen anymore. I think we'll probably see more of that. The proof of work or the demonstration of your abilities, I think it's such an effect. It's far from sharpify. Who's our fifth person on the podcast ever? I still think about his principles on hiring because his thing was there's no better way to demonstrate experience than experience and to show that. It is interesting to think about the dynamics of that right now is that if you can do something live with somebody and co-create with them or co-learn with them, you understand how they operate and how they behave and what that looks like. I think that probably does. How they communicate whether you want to sit next to them every day. Are there any experiments or things that you're seeing how interviews may shift in the future? Or patterns maybe that may change? Like I said, I think the working and come spend a day or a week working live with a company is probably going to become more normal. I think it was always the case for smaller companies to do this. You go back to Eli Gil's book on building startups and that was just a requirement. You spent a lot of time. You hired slowly. You really were careful about this. You would definitely want to spend time working with someone before. Why is day one, day one? And so I think that we'll see more of that probably scaled up to even larger company. In saying that, I also think that having a point of view and doing all the work ahead of it is such an important prerequisite for that then conversation because if you've developed a point of view or maybe a sense of where the product is, then you can sort of build that, communicate all of that research ahead of time with the people you're building with and probably sit you for more success. Well, and also the mistake not to mention a trend that we had, COVID really sent everyone into full remote work. And certainly, San Francisco right now is very much an in real life experience of working. There are remote companies here. It's a semi-sense that they are not the norm. And I think the capital is investing in people working in person and iterating together and sweating the details together, feeling the pain together, feeling the joys together. And that's just a fundamental human organization that's worked for a long time. And I think it's back. We've got some rapid-fire questions, right? Okay, let's go. Okay. What are you reading or listening to right now? Well, I was listening to an interview with Eileen Goody this morning because she's very popular. Does this sort of take on how you think before you talk? It's very relevant for this podcast. And I thought it was very eloquent. I'm going to look at it. What was it? Yeah, Eileen. A limpian, yeah. Yeah, that's great. Friend and I shared it. You've created a JavaScript, so I immediately shared it back with my daughter. That's great. Number two, what is a tool or methodology that's had a big impact on you? Unix. The principles of reusable, composable, lightweight things to make systems. Building upon tools that don't do too many things, but you can build upon them. It's so fundamental. And I think especially with our ability to think less about how the code is composed for human readability. That used to be a really big deal. Human readability was a fundamental part of assessing code. I think we'll, you know, now obviously it's a lot less relevant. But figuring out whether it works well and how well those systems compose themselves and how adjustable they are, how tunable they are, how error-free they are, those things will come back. And so that Unix philosophy is pretty key to that. What is a trend you're seeing or following that's interesting or hasn't hit the mainstream yet? Well, I don't know if I'm the trend maker considering I'm taking wetstone knife sharpening classes in my free time when I'm not programming. So, you know, I'm learning what those are from our interns. It's probably the right answer. Well, the thing is, you know, encouraging people to talk to your interns for like what's new, like what's emerging. That's great. The last question. Is there a quote or a mantra you live by or a quote that's resonating with you right now? Yeah. The one that comes back to me is the cheesiest woman is so good. You know, don't look back because you're not going that way. It can be hard to think about your decisions in the context of how you're feeling and you can get stuck thinking about that. And it's just not a good way to be. How that resonates with me as you're sharing that is, you know, right now things are moving fast and they're sort of like a discomfort with that. And I think a lot of people that, like the dinner that we did a few weeks ago, kind of talk about that discomfort. And so for me, I find a lot of, I guess, comfort in thinking about like don't look back or think about all of the ways that, you know, maybe you were comfortable or shifting, but think and look forward and think about how you're growing and kind of sitting with that discomfort. What do you want to explore? Yeah. And it is obviously, the pithy form is not. Don't care about history, but I think it's, you know, don't get stuck on, you know, human readability. It's still important, you know, get over it. It's not. And it doesn't mean that it's to relevant. Lindsay, thanks for inviting me. Yeah. To hang out. Coming. And thanks for incredible conversation and reflecting on career and how management things are shifting. It's been a lot of fun. So thank you. Wow, it's my pleasure. If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community. Click our chapters page. You can see that on the menu on the left. Find your local chapter and click join. We're hosting virtual and in-person events all the time. And this is the best way to help you get involved. Expand your network in your city and support your leadership and career growth. So pull up your phone head to elc.community. Join your local chapter and get involved. A huge thank you to all of our local leaders who make community happen. And thank you for listening to the engineering leadership podcast. Yeah. Yeah.