Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
{"version":"https://jsonfeed.org/version/1.1","title":"StaffEng Podcast","home_page_url":"https://podcast.staffeng.com/","feed_url":"https://podcast.staffeng.com/","description":"Exploring engineering leadership, AI, and building impactful technology.","authors":[{"name":"StaffEng Podcast","url":"mailto:voidfiles@gmail.com","avatar":"https://twitter.com/voidfiles"}],"items":[{"id":"https://podcast.staffeng.com/season-2/babylist-ai-adoption-karynn-ikeda/","url":"https://podcast.staffeng.com/season-2/babylist-ai-adoption-karynn-ikeda/","title":"How BabyList Accelerated AI Adoption in Engineering with Karynn Ikeda","summary":"The return of joy and creative empowerment may be the most important signal of all.","content_html":"\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/x4-0qVUVnxw?si=rBwlHzNN-dK2Re7V\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen\u003e\u003c/iframe\u003e\n\u003cdiv id=\"buzzsprout-player-18878451\"\u003e\u003c/div\u003e\u003cscript src=\"https://www.buzzsprout.com/1687069/episodes/18878451-how-babylist-accelerated-ai-adoption-in-engineering-with-karynn-ikeda.js?container_id=buzzsprout-player-18878451\u0026player=small\" type=\"text/javascript\" charset=\"utf-8\"\u003e\u003c/script\u003e\n\u003cp\u003eKarynn Ikeda shares the full arc of how Babylist adopted AI across its engineering organization — from a six-week Windsurf pilot on a single team, to company-wide Claude Code adoption and a bold initiative to onboard product managers and designers into the codebase. She discusses leadership buy-in, measuring developer sentiment over raw velocity metrics, the shift toward agent orchestration, and why the return of joy and creative empowerment may be the most important signal of all.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHosts:\u003c/strong\u003e Alex Kessinger \u0026amp; David Noël-Ramos\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGuest:\u003c/strong\u003e Karynn Ikeda — Former Engineering Manager → AI Enablement Program Manager at Babylist (\u003ca href=\"https://x.com/ktikeda\"\u003e@ktikeda\u003c/a\u003e)\u003c/p\u003e\n\u003ch2 id=\"links--references\"\u003eLinks \u0026amp; References\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eGuest\u003c/strong\u003e: Karynn Ikeda (\u003ca href=\"https://x.com/ktikeda\"\u003e@ktikeda\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBabylist\u003c/strong\u003e — \u003ca href=\"https://www.babylist.com\"\u003ebabylist.com\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eShopify CEO Tobi Lütke\u0026rsquo;s AI Memo\u003c/strong\u003e (April 2025) — \u003ca href=\"https://x.com/tobi/status/1909251946235437514\"\u003eOriginal post on X\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnthropic Code Review for Claude Code\u003c/strong\u003e — \u003ca href=\"https://claude.com/blog/code-review\"\u003eclaude.com/blog/code-review\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClaude Code\u003c/strong\u003e — \u003ca href=\"https://code.claude.com\"\u003ecode.claude.com\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDevin\u003c/strong\u003e (AI coding agent by Cognition) — \u003ca href=\"https://devin.ai\"\u003edevin.ai\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCursor\u003c/strong\u003e — \u003ca href=\"https://cursor.com\"\u003ecursor.com\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWindsurf\u003c/strong\u003e — \u003ca href=\"https://windsurf.com\"\u003ewindsurf.com\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLovable\u003c/strong\u003e (vibe coding tool) — \u003ca href=\"https://lovable.dev\"\u003elovable.dev\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eV0\u003c/strong\u003e (by Vercel) — \u003ca href=\"https://v0.dev\"\u003ev0.dev\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n","date_published":"2026-03-20T00:00:00Z","date_modified":"2026-03-20T00:00:00Z","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-2/will-maier-stripe/","url":"https://podcast.staffeng.com/season-2/will-maier-stripe/","title":"I Haven't Opened an IDE Since November — Will Maier (Stripe)","summary":"I personally have not opened an IDE since the end of November. And the engineers that I work with also have not. The magnitude and the speed of that change is so much greater than anything I've experienced.","content_html":"\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; margin-bottom: 2rem;\"\u003e\n \u003ciframe src=\"https://www.youtube.com/embed/52cZCc7Sy3c\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border: 0;\" allowfullscreen\u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\u003cdiv id=\"buzzsprout-player-18827390\"\u003e\u003c/div\u003e\u003cscript src=\"https://www.buzzsprout.com/1687069/episodes/18827390-i-haven-t-opened-an-ide-since-november-will-maier.js?container_id=buzzsprout-player-18827390\u0026player=small\" type=\"text/javascript\" charset=\"utf-8\"\u003e\u003c/script\u003e\n\u003cp\u003eWill Maier leads growth engineering at Stripe, where he\u0026rsquo;s spent the last five years working across nearly every surface of the product. His background isn\u0026rsquo;t CS — it\u0026rsquo;s the history of science — and he\u0026rsquo;s been through enough industry shifts (racking servers, the cloud transition, DevOps) to know when something really big is happening.\u003c/p\u003e\n\u003cp\u003eFind us now also on YouTube: \u003ca href=\"https://www.youtube.com/@StaffEngPodcast\"\u003e@StaffEngPodcoast\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eIn this season premiere of StaffEng, Will joins Alex and David to talk about what changed for him after November 2025, why he spent the holidays building a Lua distribution from his phone while doing laundry, and how he thinks about the organizational dynamics of AI adoption inside a large engineering org.\u003c/p\u003e\n\u003cp\u003eTopics covered:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhy Will hasn\u0026rsquo;t opened an IDE since November — and what replaced it\u003c/li\u003e\n\u003cli\u003eThe psychology of AI adoption: shame, hallucinated PRs, and \u0026ldquo;AI vegans\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eSkills as the new packages: how improvised markdown files are changing how teams share leverage\u003c/li\u003e\n\u003cli\u003eWhy measuring token usage (the wrong metric) surfaced the right insights\u003c/li\u003e\n\u003cli\u003eThe case for making the incident report critic, not the incident report writer\u003c/li\u003e\n\u003cli\u003eWhat the cloud and DevOps transitions teach us about where AI is headed\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"links\"\u003eLinks\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/jart/cosmopolitan\"\u003eCosmopolitan libc (jart/cosmopolitan)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/whilp/cosmic\"\u003ewhilp/cosmic — Will\u0026rsquo;s Lua distribution\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eAlex (00:01.692)\nHello and welcome back to the Staff Ang podcast. New season, new format. We\u0026rsquo;re gonna go a little bit more raw this season. Just jump right in. I\u0026rsquo;m Alex. Last you heard from me, I worked at Stitch Fix. Now I work at Stripe. I\u0026rsquo;m gonna let David introduce himself and then we will get into it with our guests.\u003c/p\u003e\n\u003cp\u003eDNR (00:24.2)\nI\u0026rsquo;m DNR. Last you heard from me, I worked at Stripe. Now I no longer work at Stripe. It\u0026rsquo;s the musical chairs are out here apparently. Yeah, I\u0026rsquo;ve been doing an AI startup for the past year or so. Very excited today to have Will on the show with us and to kind of dig into the new world that we all find ourselves in.\u003c/p\u003e\n\u003cp\u003eAlex (00:45.01)\nYeah, so Will, I\u0026rsquo;d love it if you just sort of give us a quick rundown, introduce yourself.\u003c/p\u003e\n\u003cp\u003eWill (00:50.732)\nSo I\u0026rsquo;m Will Meyer. I work at Stripe. I haven\u0026rsquo;t changed jobs at all and it is an honor to be the raw, the raw guest and get this started weird, which feels fitting for, for the topic. I\u0026rsquo;ve been at Stripe for almost five years and lead growth engineering, which is not obviously or specifically topic, topic to, to dig on here, but does mean that I do a lot of work just broadly across Stripe. Basically, every surface we can, we want to make it work well for users around the world who are just finding Stripe and getting started. So they need the product to work great, and we need to have a lot of high leverage. And so I kind of back into a lot of quality and technology and then lately, AI issues from there.\u003c/p\u003e\n\u003cp\u003eAlex (01:38.596)\nAwesome. I think maybe a great way to sort of start, and this is a question that we asked ourselves when we started this is like, when was your sort of like aha moment of like, my goodness, this is gonna change everything. You know what I mean?\u003c/p\u003e\n\u003cp\u003eWill (01:50.926)\nI mean, the change everything was November 28th or whatever, right? The Opus four or five splash. I feel like I\u0026rsquo;ve been through waves of that feeling in the last couple of years. I remember doing workshops, we have an internal tool, you know, just a basic chat thing. And even that, you know, like for standardizing incident report shapes and executive summaries, you know, that was like, whoa, you know, this is already doing stuff that I\u0026rsquo;m old enough to remember that being, you know, not a thing that\u0026rsquo;s going to happen. And we\u0026rsquo;re always just a little bit ahead. But last November was really different qualitatively in terms of what felt feasible and then how fast things have moved since then, especially like the jump in model quality followed by, you know, harnesses getting better, us humans figuring out how to work with these workflows better.\u003c/p\u003e\n\u003cp\u003eAlex (02:56.998)\nYeah, do you remember the project or the project that you were working on or what you saw? What was the quality of the thing that was like, my god.\u003c/p\u003e\n\u003cp\u003eWill (03:04.238)\nYeah, like a lot of people I sort of like had a bookmark in my brain from end of November and then you know for us at Stripe December is usually pretty busy until it stops being busy completely. And like many other folks I was in the 2x usage thing on Claude and so I spent the holiday doing something that I\u0026rsquo;ve wanted to do for a really long time which is make a good Lua distribution that has a really rock solid standard lib for system programming. Have you used Cosmopolitan, Lib C, Justine Tunnies?\u003c/p\u003e\n\u003cp\u003eAlex (03:43.482)\nI\u0026rsquo;ve heard of it, haven\u0026rsquo;t had a chance to use it yet. You might want to just give a quick rundown for what Cosmopolitan is.\u003c/p\u003e\n\u003cp\u003eWill (03:49.974)\nSo like turn off the podcast and go check this out because it\u0026rsquo;s that good. It\u0026rsquo;s a pretty brilliant set of hacks, frankly, to make portable executables that run anywhere, everywhere, and that include a really big, reasonably built C-libc. And Lua is not a great language, but it\u0026rsquo;s especially not a great standard lib. And with agent stuff, I knew I wanted something that I could program, that agents could program, that would be, you know, distributable, reliable, and complete. And so I dived in, like, just within a couple days, had the libc patched up the way I needed it. I had the Lua distribution building. I don\u0026rsquo;t, frankly, speak C, so that\u0026rsquo;s a thing. And that\u0026rsquo;s a multi-million line of code repo, it\u0026rsquo;s a big chunky thing. And then from there, you know, in early January, I was building an agent harness, like, just the pace and layers got really weird. And I ended up writing a trip report just for myself, just like stepping back and looking at what had happened at the end of 2025. And I had felt that sense coming out on November, like I couldn\u0026rsquo;t escape it by the end of December.\u003c/p\u003e\n\u003cp\u003eAlex (05:15.91)\nYeah, so I think that\u0026rsquo;s amazing. I think there\u0026rsquo;s a couple of things that I want to like sort of call out there and make sure I\u0026rsquo;m getting this correct. Lua as a language is kind of amazing because it ends up being an embedded language in a large number of different things. And so it\u0026rsquo;s used quite broadly because of its ability to sort of like kind of fit into a place. And sort of where you identified an adoption issue where, because of its tooling, it wasn\u0026rsquo;t easy to use or great to use for end user quality. And so you were like, if I can make this one tweak, I\u0026rsquo;m making this language that is used very broadly in a lot of different places easier for all the people who have to write it.\u003c/p\u003e\n\u003cp\u003eWill (05:54.586)\nA little bit, almost the opposite in a weird way. Justine uses Lua as the sort of scripting language in Red Bean, which is like yet another awesome weird thing built on top of Cosmo. Red Bean is like a web server C program. And she built in this reprogrammable Lua bit, which is like a really reasonable common use of Lua. As a side effect of solving that problem, she just fit Lua well into the cosmopolitan ecosystem. And so I kind of inverted that. And instead of using Lua to script a C program, I just jammed the rest of the standard lib into Lua and exposed it through the Lua C bridge. And so you get Lua for better and for worse with the whole breadth of a good libc that can run on any system without the programmer needing any awareness of the system they\u0026rsquo;re running on.\u003c/p\u003e\n\u003cp\u003eDNR (07:18.196)\nSo before we go on, because I\u0026rsquo;m a little nerd sniped here, what are some examples of use cases?\u003c/p\u003e\n\u003cp\u003eWill (07:25.506)\nBecause of how solid and comprehensive Cosmopolitan is, it has SQLite in it, it has everything you need to do everything Curl does in it, it\u0026rsquo;s sort of like nuclear batteries included in Cosmopolitan. And so without really thinking much, you just expose that up through Lua, and then you get a single thing that can do all of the stuff you\u0026rsquo;d want to do for systems programming. And for working in a Claude Code web interface, I just drop that in. It teaches Claude how to use it basically through the help flags. And then I can solve any coding problem that I want there.\u003c/p\u003e\n\u003cp\u003eDNR (08:11.38)\nSorry, you\u0026rsquo;re using cosmopolitan via Claude Code for web — like Claude is running your CLI in the Claude Code microVM?\u003c/p\u003e\n\u003cp\u003eWill (08:26.862)\nYeah, the Claude Code web is just a gVisor sandbox situation that they spawn up and my motivating problem in December was like I wanted to write actual code there and run my tests and have a normal development experience. And doing normal things in that context is hard because you have to download Python and all of its steps or node and all of its steps, etc. But because Justine\u0026rsquo;s a genius, this is just like one five-meg thing. It\u0026rsquo;s the same asset that I just build in GitHub and run everywhere. And so I can drop it there and then it exposes help flags and docs and stuff to Claude, sort of like a dynamic skill. And then Claude Web or Claude on my box or my own weird agent harness — they all just learn how to use it because it\u0026rsquo;s a normal libc under the covers.\u003c/p\u003e\n\u003cp\u003eDNR (09:20.52)\nVery cool. Okay. I\u0026rsquo;m going to un-nerd-snipe myself because I think we want to ask some sort of higher level questions. Before we move on, where could listeners go? What\u0026rsquo;s the one URL to rule them all for this stuff?\u003c/p\u003e\n\u003cp\u003eWill (09:34.316)\nThe one is Justine\u0026rsquo;s because she\u0026rsquo;s the one who did all the really cool stuff and that\u0026rsquo;s jart/cosmopolitan on GitHub. And then the hacks here are whilp — W-H-I-L-P — slash cosmic, which is the Lua distribution.\u003c/p\u003e\n\u003cp\u003eAlex (09:59.922)\nI think like some of the stuff that you\u0026rsquo;re talking about — the quality — we are all engineers and we kind of tell ourselves a little bit like, yeah, if I just have enough time, I can get to that thing. I can learn C if I just have enough time. And so we have this huge list of things. And I think one of the things you\u0026rsquo;re explaining is like the thing that knocks our socks off sometimes with this stuff is like, you can be like, I\u0026rsquo;m just gonna take that notion I have and I\u0026rsquo;m gonna throw it out there in the world and it\u0026rsquo;s gonna come together really quickly.\u003c/p\u003e\n\u003cp\u003eWill (10:38.092)\nYeah, it\u0026rsquo;s both — ambitious, maybe. I know C kind of, but not enough to do what I wanted to do here. And then it\u0026rsquo;s totally work that I never would have taken on. So it\u0026rsquo;s both lowering the bar in terms of what I need to do to sit down and make some valuable increment in the software, and raising the bar in terms of what I feel like I can go do. And as you mentioned at the beginning, I\u0026rsquo;m a manager. So I don\u0026rsquo;t do this every day, most days. That\u0026rsquo;s been really empowering for me. I was sitting in the laundry on my phone, having Claude Web do stuff to this system, hanging out with my kid. And the fact that this was during the holidays and that I could be in the holidays and also doing pretty massive hacks at the same time felt new in my career.\u003c/p\u003e\n\u003cp\u003eAlex (11:33.234)\nYeah, so that\u0026rsquo;s a great transition point. So you are a manager, you had this aha moment. So you just walked in on Monday and you probably did nothing at work, right? I\u0026rsquo;m curious what you actually do.\u003c/p\u003e\n\u003cp\u003eWill (11:43.534)\nI mean, I\u0026rsquo;ve been flipping out basically every day this year in the sense that it\u0026rsquo;s getting probably a little annoying — but the sense I had that like, okay, actually, yes, this is different qualitatively. This is a change for better or for worse and about which I\u0026rsquo;m still pretty ambivalent. But a big, really quick change. That was a very stark feeling coming out of the holiday break. And then the way I thought about January is like, I just want to work outside of Stripe for a couple of reasons — to figure out how weird this can get, and especially to quickly figure that out. Because my belief was that the tools are not set — Claude Code was releasing at least daily in this period. Everything is changing fast. Second, it doesn\u0026rsquo;t make sense to bake stuff yet into how a big company does its work. This is still a discovery phase. And third, I personally need to figure these things out so that I have better intuition.\u003c/p\u003e\n\u003cp\u003eSo for January, I was just hacking a lot. And then trying incrementally to port sort of the basics back into the work we\u0026rsquo;re doing at Stripe. So having Claude Code, yeah, but then are we moving into skills? Are we sharing those skills and making them available to each other? We now have an internal plugin marketplace. But incrementally, figuring out the furthest thing I could think of and then coming back to layer on the next thing and the next thing. Doing that just because everybody at Stripe is trying to figure these things out — not because growth engineering has a specific mandate on this. This is just about how the craft we do is changing.\u003c/p\u003e\n\u003cp\u003eAlex (13:43.986)\nI\u0026rsquo;m curious — skills are an interesting sort of point of diffusion. It\u0026rsquo;s almost like a library or a package you could distribute back in the olden times. What do you think has been some of the most impactful skill categories? What have you seen your team use most effectively?\u003c/p\u003e\n\u003cp\u003eWill (14:09.656)\nWe have a fun one. The best ones have been kind of improvised internally. One of the ones I really like — you can think of these tools as intermediating your work, or maybe reflecting or in this case criticizing — an engineer came up with an incident report critic. Take an incident report, tear it apart, and identify all the ways in which you could go deeper in understanding the contributing causes, in which you could make the timeline clearer, in which you could identify remediations and pull it out.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s just a hundred lines or something. Super straightforward. But just pulling that out of the \u0026ldquo;I\u0026rsquo;m making the report\u0026rdquo; loop and into a \u0026ldquo;here\u0026rsquo;s the opportunity to improve this report\u0026rdquo; — that was really cool. And especially cool because that engineer just did it and shared it. It wasn\u0026rsquo;t a big fancy thing.\u003c/p\u003e\n\u003cp\u003eFor us at Stripe, we had a lot of goals last year about incorporating agentic stuff into our work and we made progress, but that required coordinating — the team would need the primitives on the roadmap to support the agent thing. In contrast, January felt like it\u0026rsquo;s not a big deal. Everybody is experimenting with basically markdown files that can do who knows what. The simplicity, and the improvised nature, and the pulling it out of \u0026ldquo;doing the work for you\u0026rdquo; and into \u0026ldquo;helping the human understand the incident\u0026rdquo; — the work of making the report is valuable. If we instead criticize and level up that work, we get the benefit without losing the insight you get when you make the report.\u003c/p\u003e\n\u003cp\u003eDNR (16:12.682)\nYou mentioned something interesting — just like everybody is now able to play with markdown files. My experience since November has been a more playful experimentation with a lot less overhead to try new things. One of the conversations we had during our listening tour — someone talked about AI vegans inside their organization. People who have some sort of aversion to adopting AI. How do you think about those objections? And philosophically — Block just laid off like half their engineers. It\u0026rsquo;s possible to get down a rabbit hole of \u0026ldquo;my God, everything is changing.\u0026rdquo; How does that fit into the organizational dynamics you\u0026rsquo;re working inside of?\u003c/p\u003e\n\u003cp\u003eWill (17:48.782)\nThe reason I\u0026rsquo;ve been flipping out is because both — I\u0026rsquo;m interested and excited and I get to do this C thing I\u0026rsquo;ve always wanted to do and I feel like I have superpowers — and I\u0026rsquo;m terrified. This is so fast and so big. Absolutely there\u0026rsquo;s a huge variety of people at Stripe. Zooming in on engineering — folks at various points in their careers, brand new interns whose entire experience of the craft starts from here on, and folks who\u0026rsquo;ve been at Stripe for years. Everybody is starting from a different point.\u003c/p\u003e\n\u003cp\u003eSome of the most inspiring stuff I see is our interns — they are in deep. When I look at the data, they are very curious and trying everything. I\u0026rsquo;ve seen cases where interns are using Claude\u0026rsquo;s \u0026ldquo;teach it to me\u0026rdquo; mode to explain the codebase back or build little walkthroughs of the codebase. That feels purely good. Just a beautiful, unalloyed good.\u003c/p\u003e\n\u003cp\u003eAnd then absolutely there are folks who tried any of these tools on November 27th and it sucked and they\u0026rsquo;re busy. They\u0026rsquo;re trying to ship. They\u0026rsquo;re maybe feeling deluged by sloppy PRs filling up the review queue, bugs that are landing that they need to clean up. For me, it feels a lot like what I remember the pre-cloud world to be. I remember the pre-cloud world — the first part of my career I spent putting machines into racks in data centers. AWS started to be a thing, and soon my personal job shifted from doing that to writing software to build cloud infrastructure. My job went away. It changed over a couple of years. That felt fast.\u003c/p\u003e\n\u003cp\u003eI personally have not opened an IDE since the end of November. And that\u0026rsquo;s not atypical — I\u0026rsquo;m a manager, but the engineers I work with also have not. The magnitude and the speed of that change is so much greater. The disruption that comes with it is going to be real. There were people who built all of Netflix\u0026rsquo;s data centers and ran their DVD shipping operations, and then it was in the cloud. Individual people can make that leap. That\u0026rsquo;s why I feel so engaged with my teams in particular — dig in and just figure it out. The ambivalence I mentioned is very deep. Very big potential upswings and very big potential downswings. The only thing I feel at the end of that is urgency to get in there and figure it out.\u003c/p\u003e\n\u003cp\u003eAlex (21:43.378)\nI also started my career at an ISP doing hardware stuff. The tectonic shift — I actually remember at an ISP seeing Amazon for the very first time, allowing you to buy a computer, and asking the people who ran the ISP if this seemed like a problem. They told me all the reasons why it wasn\u0026rsquo;t. I wasn\u0026rsquo;t convinced. Is the cloud transition a useful mental model for AI adoption, even though AI is moving way faster?\u003c/p\u003e\n\u003cp\u003eWill (23:16.354)\nI think it\u0026rsquo;s way faster. Nobody says \u0026ldquo;growth hacking\u0026rdquo; anymore. My focus is not just engineering — growth is very cross-functional. Zooming out, this is about people who work in knowledge and make things with their brains. This is the DevOps for work moment. How we do all of the things is changing kind of at the same time, flowing out and becoming more evenly distributed across everything.\u003c/p\u003e\n\u003cp\u003eMy experience of DevOps was empowering and liberating, but it wasn\u0026rsquo;t obviously a good thing. It wasn\u0026rsquo;t foreordained that this would be net best. There were a lot of risks implicit in it. Same with cloud — we\u0026rsquo;re going to put everything in Virginia, this is going to be okay. And it wasn\u0026rsquo;t always okay, and still isn\u0026rsquo;t. The sense that there will be disasters as we adopt these tools, there will be really big problems until we figure out how to operate in the system safely and efficiently — that feels very true. Then again, do we make the incident report writer and forget how to write reports and forget how to learn about the incident? Or do we make the critic that guides us to better and deeper understanding? There are at least two paths. I\u0026rsquo;d be excited if we can start to develop more of a DevOps-style culture — automation, but also measurement, shared ownership, plural pillars — that we haven\u0026rsquo;t built yet into the tooling changes happening now.\u003c/p\u003e\n\u003cp\u003eAlex (25:48.686)\nYou give a lot of cheerleader energy and I love it, but you also make sure we have critical conversations. I\u0026rsquo;d love it if you could chat about the thread you started where it was like, I think people might be feeling awkward about their use of AI — can we talk about that? And more generally, how do you find and bring these conversations to a bigger audience?\u003c/p\u003e\n\u003cp\u003eWill (26:43.02)\nI feel really lucky that my day job is actually getting things done with people who need to get things done, rather than just thinking about this. In the past, there were DevOps engineers and then there were teams that did DevOps — the latter were more successful insofar as they were informing what they were doing with a way of doing it rather than focusing on the tooling itself.\u003c/p\u003e\n\u003cp\u003eMy engagement is fueled by what I\u0026rsquo;m hearing from the engineers I work with. The intern on my team, the engineer who made the critic — these are people trying to build careers and trying to figure out what all this is. I have my own experience of hacking in the laundry, and I\u0026rsquo;m also hearing from engineers and interns about what\u0026rsquo;s working and very much not working. The sense I had — this was a couple of weeks ago, which feels very far — was that there was a little bit of shame. As folks were getting further faster, they were making mistakes. One of my engineers made a whole PR based on essentially a hallucinated fact about a system we don\u0026rsquo;t own. That\u0026rsquo;s not uncommon — we did that as people two years ago because things are really complicated in the guts. But it played a role in the scenario, and they felt like, crap, I should have found this, I might look like a bad engineer.\u003c/p\u003e\n\u003cp\u003eSo it felt important to try to find somewhere to have a conversation about how it actually feels as an engineer to be exploring this now. I was really blown away by the thread — TLs, important people, and just tons of engineers shared that feeling. They tried something, got their wrists slapped for it because we\u0026rsquo;re still not sure about the right security guardrails. Or they shipped something accidentally sloppy, then went in and cleaned it up. That sense of guilt or shame came through. Just in the few weeks since, I think that\u0026rsquo;s subsided a little bit. We\u0026rsquo;re normalizing stuff that felt edgy. I sent an email internally last year, subject was \u0026ldquo;it\u0026rsquo;s good to feel bad.\u0026rdquo; I really believe that — when I feel bad about stuff, it\u0026rsquo;s me reminding myself I want it to be better. Some of those feelings are right and we should respond to them. But already we\u0026rsquo;re past that edge of shame and into broader adoption, and a new set of bottlenecks around how do we actually review the stuff we\u0026rsquo;re making, how do we verify, how do we integrate and deliver. More practical, less emotional — but still the thing we have to push through to get to the value.\u003c/p\u003e\n\u003cp\u003eDNR (30:51.338)\nIt\u0026rsquo;s a really interesting observation — the psychology required to succeed with AI. You have to be okay making mistakes. But with AI in particular, you\u0026rsquo;re effectively delegating to an entity you don\u0026rsquo;t know that well yet. Anyone who\u0026rsquo;s worked as a tech leader understands that delegation has always been a fine balance. And forcing yourself to do it when you\u0026rsquo;re working blind is scary. It reminds me of first becoming a manager — finding the balance of \u0026ldquo;I would have done a better job of that particular thing if I did it myself.\u0026rdquo; But you have to get out of that mindset. Counterintuitively, everyone is now a manager. Everyone needs to learn the rules of delegation. And the organizations who move fastest with AI are the ones who have always had enough give for individual contributors to make mistakes.\u003c/p\u003e\n\u003cp\u003eWill (33:45.464)\nYeah, one of the things I\u0026rsquo;ve been struggling with is I\u0026rsquo;m not seeing enough mistakes at all. The question I ask frequently in one-on-ones: tell me about something you did that was wrong. I\u0026rsquo;m not seeing enough. It makes me worry that either they\u0026rsquo;re happening and folks are obscuring them, or more likely we\u0026rsquo;re just not pushing hard enough — not close enough to the envelope to discover both the valuable stuff and make these mistakes while there\u0026rsquo;s still time to change what we\u0026rsquo;re doing. I\u0026rsquo;m really intensely interested in what is weird, what is janky, where are the mistakes happening, and how do we funnel those back into what we do as managers and in central tooling in order to pave a path around or past those mistakes.\u003c/p\u003e\n\u003cp\u003eAlex (35:02.13)\nI had an opportunity to lead a conversation just about AI, and I took a more objective path — pulled up an internal report, went to the top users, and just asked what they\u0026rsquo;re doing. It led to some of the most insightful conversations because we had one engineer describe how they\u0026rsquo;re using the tool to create PR comments on their behalf. You could tell others were like, I didn\u0026rsquo;t know we were doing that yet. That led to amazing conversation around legitimacy and quality management. But I don\u0026rsquo;t think it gets there if we don\u0026rsquo;t more actively throw these things into the world and say, I did this weird thing — what do you all think?\u003c/p\u003e\n\u003cp\u003eWill (36:03.278)\nI made a dashboard and sent it around last week. Take everybody at Stripe — not just engineers, everybody — and look at their token usage on a trailing seven day basis, chunk it up into groups. First, that\u0026rsquo;s the wrong thing to measure. Just using tokens is not what we\u0026rsquo;re doing. But it\u0026rsquo;s hard to use that many tokens at the upper chunks if you\u0026rsquo;re just hitting tab in Cursor. Those are both bounded by how fast you can move your finger. There are people at these weird echelons past that point who have figured out the next thing. Sometimes they\u0026rsquo;ve figured out a multi-agent or continuous agent workflow that as a consequence consumes these tokens. The coolest thing I heard was \u0026ldquo;I just had no idea that was possible. I didn\u0026rsquo;t know you could consume that many tokens.\u0026rdquo; And folks, because they could see themselves in context with where other folks were, started to reach out and say, \u0026ldquo;you\u0026rsquo;re number three on the whatever — what are you doing? How do I incorporate that?\u0026rdquo; Having that situational awareness is really hard. We should be careful about exclusively measuring the wrong thing. But sometimes measuring the wrong thing can give you insight about the right thing, and especially can distribute that insight so we can start to converge people on higher value, higher leverage ways of working.\u003c/p\u003e\n\u003cp\u003eAlex (38:02.142)\nI had sort of a meta question. You mentioned you started racking servers and worked your way back through software. Are there existing priors or tools that helped you navigate that journey, and do you feel like it\u0026rsquo;s the same set of tools helping you navigate AI?\u003c/p\u003e\n\u003cp\u003eWill (38:29.932)\nYeah, I have never taken a CS class. My background is the history of science, which both meant I was inevitably going to work at Stripe — there\u0026rsquo;s an odd concentration of people who care about this there — and also that for the last 20 or almost 30 years, how people learn stuff and how that changes has been the constant theme of what I\u0026rsquo;ve studied and what I\u0026rsquo;ve worked on. So when the racking thing wasn\u0026rsquo;t going to be the long-term, first I was like, this sucks. Second, interesting — this is a big change. What is the paradigm shifting here, who\u0026rsquo;s participating in it, how does that change accelerate? So I joined a startup that couldn\u0026rsquo;t buy racks even if we wanted to — enabled by or predicated on a cloud provider we could spin up with a credit card.\u003c/p\u003e\n\u003cp\u003eThe waves of changes in how we make computer stuff have always meant somebody\u0026rsquo;s got a specialized skill with a shelf life, and what\u0026rsquo;s changing actually increases the amount of work we need to do. There\u0026rsquo;s not less software today because of object-oriented programming. I feel really clear that there\u0026rsquo;s going to be a lot more software this year than in any alternative. Even when I imagine everybody on my team doing pure high-leverage AI stuff, there\u0026rsquo;s still a hundred-X more software needed in bespoke, highly contextual ways — just in all the nooks and crannies at Stripe, let alone all our users, let alone the whole world. We are so behind where people need computers to be. And if the labs stopped working today, we have years of work at Stripe just to catch up to the outputs.\u003c/p\u003e\n\u003cp\u003eI used to watch every Claude Code release, read all the changelogs. I\u0026rsquo;m exhausted. Not because the advancements don\u0026rsquo;t matter — they\u0026rsquo;re really important. It\u0026rsquo;s just that from a little before November to where we are today, we haven\u0026rsquo;t figured it out yet. And I don\u0026rsquo;t think they have figured it out yet to tell us. Nobody is going to come down from the mountain with the best practices markdown file. We really need to figure this out in context. Just like we did when things changed in the past. I still feel the change here is bigger and faster than any I\u0026rsquo;ve experienced — and that makes me excited and also terrified.\u003c/p\u003e\n\u003cp\u003eDNR (42:11.05)\nWhat do you think are the right forums for people who want to figure this out? Industry best practices emerged from the cloud and CI/CD transitions. There are conversations happening on X about AI best practices. Is there anything that jumps out? Any conversations you wish were happening, conferences that you wish existed?\u003c/p\u003e\n\u003cp\u003eWill (42:44.354)\nThis is very much back to the future for me. My account had been dead for years. I went back to Twitter at the beginning of COVID because that was where I could learn quickly what was happening. A lot of the speed and superlinearity of this change really reminds my muscle memory of that phase. And then the DevOps and cloud world — I\u0026rsquo;m coming back to Twitter/X right now, which I think is reminding me that yeah, this is that kind of change. Bunch of people together trying to figure out what\u0026rsquo;s what. The last time I also went to a lot of conferences — DevOps stuff — and I do think we need as an industry that kind of integrating behavior where we sit down and talk about what this stuff is.\u003c/p\u003e\n\u003cp\u003eI wonder though — it would be hard to plan the conference for this year given November, which was truly basically weeks ago. The pace is intimidating in terms of how we as people are used to integrating that change. I think the reality is that most of the world is not yet contending with the really weird frontier parts. But it feels very urgent to figure out, at least in small groups, how we start to have those conversations — especially within companies, but across companies. I don\u0026rsquo;t have the answer. I think online environments should be an advantage. We should be able across the world to connect and share things. I hope somebody figures it out.\u003c/p\u003e\n\u003cp\u003eAlex (44:37.36)\nThe general pattern you\u0026rsquo;re bringing up is: lean into the signal. It might be high noise, but lean into the signal in moments of disorder or discovery because that\u0026rsquo;s going to be the rawest place to quickly gather new facts and incorporate them into your daily life.\u003c/p\u003e\n\u003cp\u003eWill (44:55.726)\nI personally do this as a manager — I don\u0026rsquo;t shield my teams, I try to connect them. That\u0026rsquo;s just my intuitive behavior. This is a moment of massive disruption and creativity and chaos and disorder, which sounds epic. And so I\u0026rsquo;m doubling down on that behavior and trying to connect other people to scale it out. I don\u0026rsquo;t think everybody needs to go on Twitter and follow everybody in the AI space. But more people need to, and we need to get better at distributing and circulating what we\u0026rsquo;re finding in compelling ways. There are folks inside Stripe who have concise newsletters that thousands of people read. It\u0026rsquo;s a great opportunity for somebody to be the best at whatever it is. Those opportunities are scaling really rapidly. For individuals who are curious and have that bandwidth, there\u0026rsquo;s a big opportunity. For everybody, it\u0026rsquo;s just a question of practice — integrating it into the day, getting dissatisfied at the tab thing, and responding to that dissatisfaction with some spikes, some exploration, some bounded thing, and asking somebody else what they\u0026rsquo;re doing.\u003c/p\u003e\n\u003cp\u003eAlex (46:30.992)\nThe old question from last season was \u0026ldquo;how much code are you writing recently?\u0026rdquo; The joke was that staff engineers weren\u0026rsquo;t writing code, but the funny thing is they\u0026rsquo;re probably all going to be writing code now.\u003c/p\u003e\n\u003cp\u003eWill (48:06.83)\nThe question is how much are you typing, right? My dotfiles — I celebrated the 20th anniversary of that repo last year. They\u0026rsquo;ve been really important to me. I don\u0026rsquo;t think they really matter at this point because I\u0026rsquo;m in the shell all the time. But the configuration of Vim doesn\u0026rsquo;t really matter anymore because I\u0026rsquo;m just conjuring the state of the code. I\u0026rsquo;m not typing it. But I am landing a lot of code — a little bit internally and then a lot externally, because I\u0026rsquo;m still trying to figure out what\u0026rsquo;s actually going on.\u003c/p\u003e\n\u003cp\u003eWill (49:06.38)\nThe question I\u0026rsquo;d like you to ask is how often am I landing code that I didn\u0026rsquo;t write or review? That\u0026rsquo;s something I\u0026rsquo;m pushing on a lot in a lot of places. I have agentic loops I\u0026rsquo;m trying to iterate on GitHub. And I\u0026rsquo;m increasingly trying to step back and optimize the process that is producing the software — and expect that it\u0026rsquo;s my job to make sure it\u0026rsquo;s safe to land. The count I\u0026rsquo;m actually thinking about is how many changes to these code bases are happening that I did not artisanally inspect if not artisanally type.\u003c/p\u003e\n\u003cp\u003eDNR (49:53.32)\nArtisanal code generation, I love it.\u003c/p\u003e\n\u003cp\u003eWill (49:56.38)\nI am from Portland, so everything is a little bit artisanal.\u003c/p\u003e\n\u003cp\u003eAlex (50:01.586)\nIf we think of the fully CI/CD version of AI as: we are producing outcomes without a huge amount of human oversight that are producing value, not dramatically increasing technical debt, and not removing our ability to understand what we do — if those are the three bounds, how much of that are we doing? Because that\u0026rsquo;s probably a true measure of how close we are to the escape velocity we\u0026rsquo;re looking for.\u003c/p\u003e\n\u003cp\u003eWill (50:33.314)\nIf I came on here and explained all the ways I\u0026rsquo;m inspecting the binaries I\u0026rsquo;m producing, you\u0026rsquo;d tell me to get off this podcast. We\u0026rsquo;ll be in that world — or rather, we\u0026rsquo;ll get past that world. I think it\u0026rsquo;s important now to try to make a binary, get the compiler to produce the output and run it. And as intuitive as that is for us in some contexts, extending that intuition to the full software production process is the current problem.\u003c/p\u003e\n\u003cp\u003eAlex (51:05.627)\nWe\u0026rsquo;ll call it the Will question.\u003c/p\u003e\n\u003cp\u003eWill (51:10.606)\nWell, thank you. I really appreciate the opportunity to kick off the raw season. And I\u0026rsquo;m just glad folks are trying to dig in and think through what is happening now. And I hope everything on this edition is like totally invalid next week.\u003c/p\u003e\n","date_published":"2026-03-16T00:00:00Z","date_modified":"2026-03-16T00:00:00Z","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/alex-kessinger-stitch-fix-and-david-no%C3%ABl-romas-stripe/","url":"https://podcast.staffeng.com/season-1/alex-kessinger-stitch-fix-and-david-no%C3%ABl-romas-stripe/","title":"Alex Kessinger (Stitch Fix) and David Noël-Romas (Stripe)","summary":"One of the things that I've learned from the show and that I've tried to take away and try to sort of model in my behavior is like, take a step back, make more space, let more people talk, listen a lot more and just be humble.","content_html":"\u003cp\u003eThis episode is a celebration of the journey we have been on as this podcast comes to a close. We have had such a great time bringing you these interviews and we are excited about a new chapter, taking the lessons we have learned forward into different spaces. It\u0026rsquo;s been a lot of work putting this show together, but it has also been such a pleasure doing it. And, as we all know, nothing good lasts forever! So to close the circle in a sense, we decided to host a conversation between the two of us where we interview each other as we have with our guests in the past, talking about mentorship, resources, coding as a leader, and much more! We also get into some of our thoughts on continuous delivery, prioritizing work, our backgrounds in engineering, and how to handle disagreements.  As we enter new phases in our lives, we want to thank everyone for tuning in and supporting us and we hope to reconnect with you all in the future!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/davidnoelromas\"\u003eDavid Noël-Romas on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/voidfiles\"\u003eAlex Kessinger on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.stitchfix.com\"\u003eStitch Fix\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.stripe.com\"\u003eStripe\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742\"\u003e\u003cem\u003eJavaScript: The Good Parts\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://crockford.com/\"\u003eDouglas Crockford\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.monkeybrains.net/\"\u003eMonkeybrains\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Kill-Fire-Manage-Computer-Systems/dp/1718501188\"\u003e\u003cem\u003eKill It With Fire\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Trillion-Dollar-Coach-Leadership-Playbook/dp/0062839268\"\u003e\u003cem\u003eTrillion Dollar Coach\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://martica.com/\"\u003eMartha Acosta\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://extfiles.etsy.com/DebriefingFacilitationGuide.pdf\"\u003eEtsy Debriefing Facilitation Guide\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884\"\u003e\u003cem\u003eHigh Output Management\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034\"\u003e\u003cem\u003eHow to Win Friends \u0026amp; Influence People\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X\"\u003e\u003cem\u003eInfluence\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9781276-alex-kessinger-stitch-fix-and-david-noel-romas-stripe.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast. Today\u0026rsquo;s episode is a special one. If you\u0026rsquo;ve been following along, you know that this is the show where we interview software engineers who\u0026rsquo;ve progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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\u0026rsquo;m joined by my co host, Alex Gestner. So why is today\u0026rsquo;s episode special? Today\u0026rsquo;s episode will be the last episode of Staff Inch. Alex, why don\u0026rsquo;t you tell us more about why that is?\u003c/p\u003e\n\u003cp\u003eAlex: Sure. Well, I think off the top, nothing lasts forever, especially nothing good. And I think that, you know, I feel like we did some good interviews, but like, you know, I think doing this show takes a lot of work. And just if anyone at home is curious, David does far more work than I do to make this work. And it was a lot of work for myself. And so I\u0026rsquo;m really proud of what we\u0026rsquo;ve done and I\u0026rsquo;m proud of the interviews that we did, but I think we can sort of let this go and let it live on its own. I don\u0026rsquo;t know. How about you? What do you. Why do you think this is the last episode?\u003c/p\u003e\n\u003cp\u003eDavid: Oh, man, I feel so bittersweet to be having this conversation. But, you know, I think that there\u0026rsquo;s something special about, you know, as you say, sort of things being finished, and there\u0026rsquo;s something kind of more valuable in that than sort of things that outlast their. Their time. It\u0026rsquo;s also just sort of like a changing time for me. When I started the show, I was really interested in learning a lot about what it meant to be a staff engineer. And I feel like, you know, one of the lessons that I\u0026rsquo;ve taken away from the show is that first of all, like, it never ends, right? You have to keep learning. And also that sort of like, there\u0026rsquo;s more different about what we do than there is sort of. That\u0026rsquo;s the same. And so the show could go on forever, right? There\u0026rsquo;s. There\u0026rsquo;s no shortage of people to ask and things to learn. But I feel like the commonalities that are there, we\u0026rsquo;ve covered, right? We\u0026rsquo;ve picked up a lot of commonalities throughout the show. The other thing that\u0026rsquo;s changing for me is I\u0026rsquo;m, you know, moving into a different phase of life. I\u0026rsquo;m going to be a dad by, by the time folks hear This. I will have been a dad for a couple of months, and so I\u0026rsquo;m really excited about that, but thank you. But I\u0026rsquo;m expecting that to sort of, you know, it\u0026rsquo;s going to require a whole new degree of focus. And so I need to, you know, as we talk about in the show a lot, focus is a big deal. And being able to sort of choose the right project, so to speak, is, you know, I guess my next project is going to have. Have her own little heartbeat, so.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Yeah. One thing I\u0026rsquo;d like to tell anyone, like, we\u0026rsquo;re going to. We\u0026rsquo;re going to talk to one another and we\u0026rsquo;re going to sort of learn a little bit about ourselves. But one of the things that I want to highlight is that in any organization, there\u0026rsquo;s people who you might look at them and think that they know more or they are sort of like people you can\u0026rsquo;t talk to. And I just would highly recommend, if you see someone in your organization that you respect, that you think you could learn a lot from, just reach out. I think people are so generous with their time, especially with people who seek knowledge. And so just ask. And if you work at a place where you don\u0026rsquo;t feel like you have access to folks there, the Internet is a real. And the people on it can be kind. I think just keep asking and seek out communities of expertise.\u003c/p\u003e\n\u003cp\u003eDavid: Absolutely. And the other thing I would say is, like, people should be aware that, you know, I didn\u0026rsquo;t get a single no when I was soliciting folks for this podcast. You know, everyone out there wants to help and is interested in helping. And, you know, same goes for me and for Alex. Like, her contact information is out there on the web, and we\u0026rsquo;re happy to talk to folks. I. I have sort of inbound messages from strangers all the time, and I love it. I think that\u0026rsquo;s great. And I think that\u0026rsquo;s part of sort of the community that we\u0026rsquo;re trying to build. And so, you know, my hope is that although this is the end of this staff Eng podcast, I hope that we spring up a whole lot more in the years to come. So, anyway, let\u0026rsquo;s actually get to something that\u0026rsquo;s kind of meaty. Alex, you\u0026rsquo;ve alluded a bunch of times throughout the interviews to sort of some of your background, and it sounds fascinating to me. You know, you mentioned that you worked at a startup with Brian Berg. I think Brian\u0026rsquo;s awesome. Want to hear all about that startup. You also mentioned in the interview with Amy that you have a background in libraries, which Seems fascinating to me. So let\u0026rsquo;s dig into some of that. What\u0026rsquo;s your story?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I think that I follow a pretty typical experience with other people who were introduced to computers at a young age and just immediately found them fascinating, you know, and I remember really early on, I think I was watching like 60 Minutes or just some new show and they mentioned the word hackers. And I was like, whoa, that\u0026rsquo;s for me, you know, at the age of like 11. And I think what\u0026rsquo;s interesting is like, I did sort of like follow the sort of like, I want to break into things. I want to, like, cause havoc, but very quickly. One of the things you run into if you are, you know, want to become like a serious hackers, you\u0026rsquo;ve got to learn how to program because you\u0026rsquo;ve got to learn how to like, break things.\u003c/p\u003e\n\u003cp\u003eDavid: And.\u003c/p\u003e\n\u003cp\u003eAlex: And so I found this programming thing and I remember getting like a book on QBasic and typing things like letter for letter from a book into a text editor and making them run.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s an experience that no one\u0026rsquo;s ever going to have in the next 20 years. Copying code from paper into a computer.\u003c/p\u003e\n\u003cp\u003eAlex: I don\u0026rsquo;t know. You know, I actually, I gave my son. My son asked me the other night. He was like, hey, I want to learn how to program. I\u0026rsquo;m like, okay. He\u0026rsquo;s like, do you have a book? And I was like, I might. And I had to, like, I had to go through like rows of like old Perl books and like, this isn\u0026rsquo;t for you. And I found a copy of JavaScript, the good parts. And I was like, okay, this is a good one. And he came upstairs the next day and he\u0026rsquo;s just a very literal guy and he had literally wrote the book into a notebook, like parts of it, like the whole book. So anyway, long story short, I think. I think there\u0026rsquo;s still room for it, but I think you\u0026rsquo;re right. I think lots of people, and I think for what it\u0026rsquo;s worth, is like, I love that there are many different ways to find computers. Right. Like, my way doesn\u0026rsquo;t have to be the only way. And I think we\u0026rsquo;re all coming to programming in different ways. I think that\u0026rsquo;s amazing.\u003c/p\u003e\n\u003cp\u003eDavid: Absolutely. By the way, just to interject really quickly because there\u0026rsquo;s a parallel there between something we said earlier. You mentioned JavaScript, the good parts. I love that book and I\u0026rsquo;m a big fan of Douglas Crockford, but riffing on the idea of sort of like you can contact anyone in our community and they\u0026rsquo;re Happy to chat. One of my cherished emails in my history of sending and receiving is a thread with Douglas Crockford. Because I contributed a small bit of code to. I contributed a JSON parser, JSON.org back in the day. But you know, all that to say that, like, people are out there and totally accessible and happy to help. Anyway, sorry for the interjection.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, no, I actually worked at Yahoo when Douglas Crockford was there. And so you could, like, any given month you could go like, get a class taught by Douglas Crockford. It was amazing.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s so cool.\u003c/p\u003e\n\u003cp\u003eAlex: You know, so sort of flash forward to I think my, the start of my professional career. Sort of funny enough. Like all through high school and college I was like, programming requires too much math, so I\u0026rsquo;m not gonna go get a CS degree. That\u0026rsquo;s not my strong suit. And I actually started studying like broadcast communications. And I was really excited. I, you know, I still am a fan of like movies and tv, but I think sort of halfway through my college career I realized that I was a bigger fan than I was a producer of media. But at that time I had started writing code to solve like homework issues. And that still wasn\u0026rsquo;t the light bulb, by the way, that maybe I should be a programmer. But I was really lucky to live in San Francisco at the time. And there was a small company that if you live in San Francisco, you might recognize called Monkey Brains, that is like, they\u0026rsquo;re a wireless service provider now for the whole city or large parts of the city. But in the early 2000s, they were sort of like a colocation company and they were looking for an intern. And that was my first gig where I was like putting FreeBSD on boxes. I was doing jails and setting up websites and I was writing code for a purpose, like for people. And that I think that sold it. So from there I was able to get an internship at Yahoo, which turned into a full time gig. And, you know, I was just thirsty for more experience, more knowledge. And I just kept learning and learning and learning. And so living in San Francisco, like In, you know, 2008, 2009, I wanted to work at a startup. I did that with Brian Berg at a place called app.net or. I mean, the company\u0026rsquo;s name is Wix Media Labs. And I had some amazing experiences at startups. But you know, startups can be stressful and they can be, they require a lot of time and energy. And so after my startup experience, I was really, I wanted something, I don\u0026rsquo;t know More, Less stressful, but also just like, different. And I was lucky enough to find this library services company in Berkeley, California, which is where I was living at the time. And for me, I\u0026rsquo;m not ashamed to say this, but, like, the first selling point was that I could walk to the office from my apartment.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s awesome. Yep.\u003c/p\u003e\n\u003cp\u003eAlex: And I got super lucky, but. And then it was just a lovely experience, like working and building code. For libraries and librarians, you just learn a whole bunch and their ethics are just amazing. And I think a lot of the things that we\u0026rsquo;re learning now in our industry sort of about being more inclusive and celebrating diversity and a lot of things that I think are important for the continued health and growth of our industry. I was learning them in that community far before I saw people in our industry sort of speaking up about this stuff. Anyway, that was a lovely experience. But then I continued to want more and more growth and, you know, it\u0026rsquo;s. Libraries are just always underfunded. We never give them as much money as they need. And so I had to sort of branch out to find new experiences. And I\u0026rsquo;ve been now at Stitch Fix for the last three years. About half that time has been as a principal engineer. And I continue to love to write code, but I think as we\u0026rsquo;re learning, as you grow in experience and influence and impact, you know, I write less and less code and I focus more on.\u003c/p\u003e\n\u003cp\u003eDavid: Oh, don\u0026rsquo;t. Don\u0026rsquo;t answer that yet. That\u0026rsquo;s for the end, Alex.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;ll save the percentage of how much I write code for.\u003c/p\u003e\n\u003cp\u003eDavid: Okay, good.\u003c/p\u003e\n\u003cp\u003eAlex: Anyway, I love working with Stitch Fix. It\u0026rsquo;s kind of an amazing place to work compared to. Well, anyway, it\u0026rsquo;s just an amazing place to work. So that\u0026rsquo;s my story. I\u0026rsquo;m really curious, David. I feel like I know far less about where your time before, where you\u0026rsquo;re at now, so I\u0026rsquo;d love to learn more.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, absolutely.\u003c/p\u003e\n\u003cp\u003eAlex: So.\u003c/p\u003e\n\u003cp\u003eDavid: Where does it all start for me? I mean, I think I came along a little bit later than you did, but it was a similar sort of beginning, like copying code from books for sure. And, you know, a heavy interest in sort of the Internet and how it worked. I think my introduction to programming was. I certainly wrote some basic, but I think there was lots of like, of web programming early on and, you know, there\u0026rsquo;s still pretty early days. I remember when CSS became a commonly available thing in browsers, you know, and like, it was interesting. I. I taught myself. First thing I did was teach myself HTML, and then I was like, hey, I Want to, I want to make some of these things move. And so I learned some JavaScript and then I was like, okay, well I want to, you know, process some data that gets submitted by users. So I learned some, I think it was pearl at the time with like CGI scripting and then eventually that became sort of like php. And my first work was always freelance stuff. So I grew up and live in Winnipeg, Canada, which is very far out of the way, you know, far out of any sort of tech ecosystems. And so I was pretty isolated and I was doing stuff kind of on my own. I was finding people that needed websites. I was like a 12 year old kid that was finding people that needed websites and going out and building it for them, right? And then, and so that also developed sort of the entrepreneurial side, which I\u0026rsquo;ve been interested in for forever. And that was part of how I put myself through school. I went to school for electrical engineering. That was part of how I put myself to school. I also worked my first kind of real job doing, doing programming work was building training material for the Canadian military online learning systems. And so that was pretty interesting. It exposed me to sort of, you know, big organizations. Although the military isn\u0026rsquo;t really, isn\u0026rsquo;t stereotypical in all the ways, it certainly isn\u0026rsquo;t representative of tech organizations. But you know, there was more people involved and a bit more rigor required as you can imagine, compared to sort of some of the freelance websites that I was putting together when I was 12. And after school I kind of had a choice to make where like by that point I had enough freelance work that it was sort of keeping me busy and paying the bills and you know, I could have gone and gotten an electrical engineering job, but I just, I just really liked programming, right. And one of the things that I like about software versus hardware is like the quick feedback loop, right? Hardware is just so slow. Like it\u0026rsquo;s fun to do things and it\u0026rsquo;s cool when you build something and there\u0026rsquo;s like a real physical, tangible thing in front of you, but to get there it takes so long. Whereas putting pixels on a screen is instantaneous, right. So that was kind of the direction I took. I did do a startup right out of school that involved some hardware stuff. And so it was a good kind of crossover. It was display advertising. So we had these like special units that, that I devised which embedded into mirrors. It\u0026rsquo;s kind of a long story, but it was kind of neat. And so they, they had sensors that would activate when you walked up to them and it was Like a graphic display that showed up through the mirror. Anyway, that was know, one of the first startups and then I was sort of continuing to do some consulting and freelance work. All along. I worked at a company that did software for the construction industry. Did that for several years. I was a CTO in that, in that startup. There was about 30 people in the company overall, so really small. But, you know, there\u0026rsquo;s interesting technical challenges focused on, you know, one of the things that we had to do in that startup was like synchronizing data between lots of different places. It was sort of like, you know, the core product was a mobile app, but it needed to have a lot of. It needed to share a lot of state between a lot of different systems. And so that was kind of an interesting technical challenge and interesting architectural challenges. Then I did a startup where it was kind of like, imagine if you could use Slack to send SMS and email to your customers as well. It was sort of like that. It was like a communication platform that was primarily around similar maybe to something like Front that exists out there. But anyway, this was for, for a niche market and ran that for a while. And that was, you know, that\u0026rsquo;s an interesting product. But, you know, somewhere along the line I had a friend who was working at Stripe, and again, like, kind of an Internet acquaintance, right? Not someone who I knew very well, but someone who I had, who I had met online and had some exchanges with. And you know, they said, well, why don\u0026rsquo;t you try working at Stripe? And so I definitely knew, knew about Stripe, right? I\u0026rsquo;d been using their, like, payment platform all over the place, but it never really occurred to me anyway to try to work at a place like that, largely because my assumption is like, well, I don\u0026rsquo;t want to move to San Francisco and therefore these things are not options for me. Right? But Stripe has actually always had remotes. And more broadly, the industry has obviously, you know, even prior to Covid, the industry was heading in that direction for, for a while and now that\u0026rsquo;s. That\u0026rsquo;s accelerated. So, you know, it was. Joining Stripe was awesome. It was lots of fun. It was sort of like a lot of the stuff that I\u0026rsquo;d been doing sort of on my own to try to build my own community online and whatnot was sort of replaced by this huge group of people that were exactly like me that all, you know, cared about all the same things in the sense of like, you know, both technology and sort of like caring about startups and, you know, the. What sort of makes startups tick. Like, one of the cool things about Stripe is that our customers are startups, too. And so everyone in the company is kind of wired to understand or try to understand, like, you know, what are all these companies out there that are trying to collect money online?\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eDavid: Well, why is that a hard problem and how we can make it better? Right. And so that was something that was, like. That I intrinsically understood and, like, valued. So, anyway, working at Stripe has been tons of fun. I started there coming up on three years now, and, yeah, that\u0026rsquo;s kind of been my path.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. I\u0026rsquo;m curious, you know, to learn a little bit more about your work as an engineer. You know, one of the questions that we ask is what are some examples or projects that you\u0026rsquo;re really proud of in your career? You know, especially when it comes to maybe staff or staff plus engineering, you know, does anything come to mind?\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I mean, I think all the most relevant examples would come from Stripe, because one of the things that I feel distinguishes staff engineers is sort of the extent to which we\u0026rsquo;re not only solving technical problems, but we\u0026rsquo;re combining that with sort of the organizational challenges that come along with it. You just don\u0026rsquo;t get that in a small startup. You get other things. Right. And we\u0026rsquo;ve talked about it a lot of times on the show how, like, in startups, one of the main sort of virtues that you learn as an engineer is this idea that, like, you have to take ownership over problems. Right. And so, but to apply that as a staff engineer in a bigger or rapidly growing organization is about more than just taking ownership of the problem. It\u0026rsquo;s also about understanding the levers that you have at your disposal to make it happen. Right. And like I said, it\u0026rsquo;s more than just technical. So I think one of the projects that I\u0026rsquo;m really proud of happened pretty early in my time at Stripe, where there\u0026rsquo;s a whole platform of kind of internal tools that exist at Stripe. And when I joined, those internal tools were, you know, pretty loosely structured. It was basically a service that people could add code to kind of whenever they wanted. You know, obviously we\u0026rsquo;re subject to the reviews and whatnot, but people could add code and build their own internal tools. And, you know, there wasn\u0026rsquo;t a lot of structure to it. There wasn\u0026rsquo;t clear ownership necessarily of. Of those tools, and there wasn\u0026rsquo;t. It was a little bit overly coupled in the sense that, like, you know, everyone\u0026rsquo;s code is going to the same place, and it was all tangled together. There\u0026rsquo;s lots of implicit dependencies and Things like that. Implicit interdependencies, I should say. And so one of the projects that happen in kind of my first year at Stripe was converting that into sort of more of a platform approach where it\u0026rsquo;s. Instead of having sort of a hodgepodge of everything all kind of tucked into basically one application, we split those out into separate apps that shared an underlying framework which we published and which we made available to, you know, other engineers in the company. So that when people wanted to build internal tools now, first of all they had, you know, some best practices established, they had good documentation, they had, we wrote a little bit code generator that basically got rid of all the boilerplate for them. And you know, the benefit to Stripe and to us as maintainers of the platform was that we got, you know, sort of more hooks into like sort of a, a consistent view into what was going on in the system. So, you know, first of all, everything was clearly owned. We had analytics that were separated by the different applications in the platform. We could better enforce security invariance because we sort of now had an understanding of how the functionality in the platform was split up and sort of which pieces of the platform were more or less sensitive and which pieces of the platform were being exposed to more or less users, things like that. So that was kind of, that was sort of one of the first cross cutting projects that I did at Stripe. And it was, it sort of was a good eye opener for me of like the, the impact that someone operating in sort of a staff capacity can have where it\u0026rsquo;s sort of like the main value that I was bringing to the organization was that I was mapping sort of a lot of the technical requirements and a lot of the organizational requirements that we had into, into something that kind of worked together and then like driving and following through on, on the migration of that because you can imagine there was, you know, hundreds of different applications in the end, you know, many dozens of teams that owned this code. And the whole system is business critical to Stripe. So it\u0026rsquo;s handling millions of requests a day. And we, we had to, you know, we had to kind of. I always liked the analogy of like turn the car into a plane while it\u0026rsquo;s running sort of thing. So yeah, that was one example. And you know, it\u0026rsquo;s, I think a lot of things have sort of mirrored that shape over time as I\u0026rsquo;ve continued to strength. What about you?\u003c/p\u003e\n\u003cp\u003eAlex: Sure, yeah, so there\u0026rsquo;s definitely lots of stuff that we\u0026rsquo;ve done at Stitch Fix that I would call like this kind of work. Like I\u0026rsquo;m still actively involved in a project to sort of migrate large parts of our customer facing applications to GraphQL. But there\u0026rsquo;s actually a project that I think is like, I think of as like my first staff project, even though no one. I didn\u0026rsquo;t have the title at that.\u003c/p\u003e\n\u003cp\u003eDavid: Point, by the way. That\u0026rsquo;s kind of like I think key. Right. Like I didn\u0026rsquo;t have the title at that point either. Right. You have to demonstrate that you can do the work.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, absolutely. And I, well, I think I did this work at the library services company. So I\u0026rsquo;m actually, I\u0026rsquo;m reading this book right now called Kill it with Fire by Marianne Belotti. And it\u0026rsquo;s amazing because it really speaks to this idea of working on legacy systems. And so just a quick shout out, like, I think I wish this book had existed when I started to do this work. But the library services company that I worked for had been an evolution from a journal publishing company that was one of the very first companies that would help you sort of keep track of a digital journal. And when I say journal, I mean like that in the academic sense. So like people would publish paper, there would be peer review and they would published the peer reviewed articles and they would do, they created a system that would allow you to sort of have these peer reviewed journals and do the whole peer review process, you know, online with email. And they were doing this in the late 90s and so they were pretty early for this process. In the early 2000s, you know, librarians and people who sort of like are very, you know, clued into the sort of scholarship realized that more and more of our scholarship was happening in digital first and it wasn\u0026rsquo;t happening in paper first. And that doesn\u0026rsquo;t mean that those objects are any less important than the things on paper, but that digital objects have a far more likelihood of just sort of like disappearing from the world because there\u0026rsquo;s no paper record. And this company, having been in a position to publish journals, realized that they could also now be in a position to, to create this new tool called an institutional repository where libraries and institutions could be like, okay, great, here is our digital scholarship that\u0026rsquo;s happening. I\u0026rsquo;m going to put it into a place and it\u0026rsquo;s going to be organized and it\u0026rsquo;s going to be secure and archived and hopefully we\u0026rsquo;ll keep it forever. So in like 20, I don\u0026rsquo;t know, sometime in like 2012, I guess 13, 14, they decided that they wanted to, that the system was sort of experiencing all sorts of issues and they wanted to do something and so they started doing some microservices stuff and they wanted to split out their Python stuff. They wanted to create a microservice with Python. And I joined the company around that time. Fast forward. Like I didn\u0026rsquo;t realize that sort of like not having a well bounded monolith was an important first step. And we published this, you know, this microservice of Python and it didn\u0026rsquo;t go well. Let\u0026rsquo;s just say that it didn\u0026rsquo;t go well. Like we ended up making something that did go well, but you know, just, it took multiple years of work before I was there. It. We had to turn it off for a month. So like this is a system that like people were using every day and for us to do the migration we had to turn it off. And still to this day it was like one of those. And we had only planned to turn it off for a week. Right, that\u0026rsquo;s the other part. So just like red flags everywhere, right. And I remember after having sort of done the hard thing, the thing that I didn\u0026rsquo;t feel really great about, I then had the opportunity to turn my attention towards the monolith, the thing that was causing all the issues. And it just sort of like I wanted to start working on it, I wanted to start making things better. I wanted us to be able to introduce better practices. Because at the time it didn\u0026rsquo;t have continuous delivery, it didn\u0026rsquo;t have like a test suite that would run. There was no sense of like a pull request or anything. And so like people were just sort of pushing code and they were pushing, they were manually pushing code to any environment that they chose, even production. They were like patching production. And I wasn\u0026rsquo;t certain yet exactly what was the biggest issue, but I knew that it wasn\u0026rsquo;t producing value and I knew that the engineers were having a really tough time making things better. Right. And so I just wanted to do something. And what I ended up doing was I ended up working on continuous delivery for this system that had never experienced continuous delivery before. Code was being pushed to an NFS directory and then they would restore all the servers so that they could pick up code changes. And it was just a whole different world. It took me a long time to figure out how to package a Perl application, to package things that never wanted to be packaged in the first place, to get the test to run inside of a container for this thing that never expected to live inside of containers. And it just took so much time and effort. And like at the end of it, to me, myself, I was like, I Was like, man, I only got continuous delivery done, right? I was sort of. I was almost like sad about that. And I remember one of the guys who had worked there for like 20 years, one day he sort of came over to me and he was like, he had heard me sort of bellyaching, I think. And he just started like, he was like, you know, before this, like once every three months, I had to come into the office on a Friday at like 5 o\u0026rsquo; clock in the afternoon. I might be here until like 12 or 1 o\u0026rsquo; clock in the morning, right, because we\u0026rsquo;re deploying code. And then for the next week I\u0026rsquo;m having to like, get all these developers to fix things and I\u0026rsquo;m patching production and then I need to make sure that you\u0026rsquo;re reapplying those patches back to the main code base. He\u0026rsquo;s like, now at one o\u0026rsquo; clock in the afternoon, I can click a button and everything goes to production and it\u0026rsquo;s fine. At that moment, it was like a watershed moment for me. I was like, oh, I made it better for him. I made this massive stuff for him and now his job is more sustainable and he feels better about the work that he\u0026rsquo;s doing and that is going to have a huge impact on all the other software delivery that we do. And so that to me was like, I think, really important because now I sort of always. I\u0026rsquo;m always looking for the friction, for the pain points. I\u0026rsquo;m looking for those, the people who aren\u0026rsquo;t necessarily speaking up about it, but they\u0026rsquo;re sort of getting crushed by tech debt or all those other things. Because almost without fail, when I sort of make things a little bit better for the people who work in the system, it almost always produces better value for our. Whoever you\u0026rsquo;re trying to deliver value to. And so I think that\u0026rsquo;s an important part of being, as you move up in the IC ladder, just making sure that you\u0026rsquo;re looking at the humans in the system as well as the code and the tech and everything. And there\u0026rsquo;s lots of different ways to see that humanity in the system. But my way is to sort of make sure that no one\u0026rsquo;s getting sort of like incidentally crushed by it, that there\u0026rsquo;s no one who\u0026rsquo;s sort of feeling like, you know, that fight or flight instinct because of code, like, that\u0026rsquo;s just. We don\u0026rsquo;t have to be there.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, yeah. I think like one of the things you touched, touching on that is sort of really interesting to me about the technical leadership track is that, and this is sort of what I was curious about when we talked to Ashby about, about the relationship between staff engineers and product managers is like, so one of the things that comes up all the time when you sort of dig into what is a staff engineer is that there are people who are, like, identifying the work that needs to be done right rather than having it dictated to them. And how do you identify the work that needs to be done right? This goes back to sort of that ownership mentality, but it\u0026rsquo;s also. That\u0026rsquo;s combined with an empathy. Right. For all the users in the system. Right. All the humans in the system, as you put it. Right. And so to me, that\u0026rsquo;s like, that\u0026rsquo;s where there\u0026rsquo;s this overlap with product management, where product managers, the good ones, are thinking not just about sort of the end user, but like, what is the holistic experience of this product for anyone who interacts with it. Right. And I think the same is sort of true of good staff engineers, because that\u0026rsquo;s the only way that you can find the gaps in the system that needs closing is by. Is by. Under. Like, at the end of the day, all that really matters is the humans that are interfacing with the system. Right. Like, that\u0026rsquo;s. That\u0026rsquo;s what the system is. The technology is nothing in a vacuum. Right. And so. So, yeah, that\u0026rsquo;s. I think that\u0026rsquo;s sort of an interesting parallel that comes up again and again.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. So I\u0026rsquo;m curious, you know, moving on a little bit. One of my favorite questions that we ask our folks are like, you know, when you\u0026rsquo;re in an organization, how do you know that you\u0026rsquo;re in alignment with what that organization is trying to get done? And so I\u0026rsquo;m curious, how do you know that you\u0026rsquo;re in alignment with what your organization is trying to do?\u003c/p\u003e\n\u003cp\u003eDavid: One of the things that I don\u0026rsquo;t think we talked about as much in this show as I expected us to is some guests did touch on it for sure, but I\u0026rsquo;m having trouble thinking of specific examples is sort of the importance of, as you move up the IC ladder, the fact that the importance of your relationship with your direct manager and with your reporting chain increases. I think of my manager as a sort of critical partner in the work that I do. And that would be sort of the first sort of signal that I have as to whether or not I\u0026rsquo;m aligned with the organization. But that being said, my manager and I don\u0026rsquo;t always agree. Right. And so it\u0026rsquo;s also useful to have other signals and also useful to be able to look past that not in a sense of like working around my manager, but in a sense of like bringing more information to them. Right. Making sure that their view is holistic. And so the other things that I do, and this is all about sort of like how I gather information, which is different from sort of how I might try to influence the org. But the things that I try to do are, first of all, I try to maintain a personal relationship with other people in my reporting chain. So I\u0026rsquo;ll make sure that I like my, the managers above my manager all have office hours. And so I will avail myself of those, you know, not super often, but on enough of a basis that, that I feel like I know them and that I feel confident reaching out to them directly whenever I need anything. I also spend a fair amount of time. I forget some people have mentioned this, but it was, I think Stacy Gammon actually talked about this a lot. But the idea of sort of keeping a pulse on the org but having lots of one on ones with various folks, I have found the balance kind of hard to strike because I think it sort of depends what phase of work I\u0026rsquo;m in. Like sometimes it\u0026rsquo;s sort of. I really am trying to keep my ear to the tracks a lot. And so in those times I will sort of up the cadence of my one on ones or like just find more excuses to have more chats with more people across the the organization. And then sometimes I\u0026rsquo;m in more of a cadence where I\u0026rsquo;m sort of focused toward the team and toward execution. And in those modes I might sort of reduce the extent of one on ones that I\u0026rsquo;m having. But at any rate, one of the things that helps me is that I\u0026rsquo;m a little bit shameless. Like prior to working at Stripe, I was often sort of in founder or founder adjacent roles at startups and one of the hats that I had to wear a lot was sales. And so, you know, I\u0026rsquo;m a terrible salesman, but compared to most engineers I\u0026rsquo;m pretty good. And so, you know, that ends up being useful in terms of. Terms of sort of, well, like I said, kind of being shameless. Right. I have no compunction about reaching out to anyone in the organization for any reason and either making up some excuse to talk or just saying hey, like let\u0026rsquo;s chat. Right. And so that has been useful and, and I realize that there\u0026rsquo;s sort of like a bit of a. Some people are kind of self conscious about that approach and so there\u0026rsquo;s a bit of a barrier there which I sort of just got Rid of a long time ago, I guess, probably sometimes to my detriment, maybe. And I\u0026rsquo;m trying to think of what sort of. What other tactics there are, but I mean, honestly, it\u0026rsquo;s really just listening a lot. Oh. The other thing I do is I know people who lurk in a lot of Slack channels. To me, that\u0026rsquo;s too noisy. I can\u0026rsquo;t ever keep up with that. But I do work on a lot of mailing lists and Stripe uses mailing lists pretty heavily. And I have like a pretty intense set of filters in my inbox. And so I have sort of some systems set up for like, monitoring lots of email over time. And some days I just, like, I can\u0026rsquo;t get to it. I mark everything as red in, like, the. The labels where I\u0026rsquo;m not directly. Where I\u0026rsquo;m not directly cc, I\u0026rsquo;ll mark those as red and just like, you know, declare bankruptcy on them until the next day sort of thing. But a lot of days I end up sort of catching a lot of stuff that\u0026rsquo;s happening in the company. I definitely monitor all the. We have an incident channel. I definitely monitor all the incidents that happen across the company. We also have. There\u0026rsquo;s a cool convention at Stripe of sending shift emails, which is basically just like whenever you or your team does a thing, you send an email to the entire company. Really cool convention. And also a really neat way of having sort of a pulse on what\u0026rsquo;s happening around the org. So I always monitor those. They\u0026rsquo;re long and I don\u0026rsquo;t always read all of them, but I always sort of know what\u0026rsquo;s happening. And I also make a point, you know, along the lines of sort of maintaining relationships with people. If I ever see a Shift email from someone that I know, just a quick ping, like, hey, congrats, that\u0026rsquo;s awesome. Right? It\u0026rsquo;s very low cost to me, but it goes a long way towards sort of maintaining some of those relationships. I realize I\u0026rsquo;m rambling, rambling a little bit, but what I just said made me think of a conversation I had a little while ago where someone was asking. It was in a group context, but a small group. Someone was asking sort of why. Why would we spend, like, energy being nice to each other, right? And like, as I\u0026rsquo;m recounting it, it sounds like I\u0026rsquo;m maybe being uncharitable to that person, but that was like, basically literally what they asked. And I don\u0026rsquo;t think they were, you know, they were themselves a very nice person. I don\u0026rsquo;t think that there was sort of any malice intended in that question. But, you know, it\u0026rsquo;s a fair question, Right. I think in all seriousness, we\u0026rsquo;re trying to. The main reason that we\u0026rsquo;re at work is we\u0026rsquo;re trying to make value for shareholders or whatever you want to say. Right. And so, like, it\u0026rsquo;s a fair question, like, why do the shareholders care if we\u0026rsquo;re nice to each other? Right. But I mean, setting aside the fact that many of us are shareholders in the companies that we work for, I think, I mean, for one thing it just feels good. But also like besides feeling good, it helps with this, this thing that I\u0026rsquo;m talking about now, which is like, if you want to keep your ear to the tracks, if you want to make sure that people tell you when stuff is going on that\u0026rsquo;s relevant to you, maintain a relationship with them. And you know what, it\u0026rsquo;s a lot easier to maintain relationships with people when you\u0026rsquo;re nice to them. So I have found it just like have concrete value besides just making me and the people around me feel better.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that totally makes sense, you know, to sort of build on that. We\u0026rsquo;ll put this in the show notes. I can\u0026rsquo;t find it right off the top of my head, but there\u0026rsquo;s an amazing sort of class you can take, like an online class. It\u0026rsquo;s like the Science of Happiness. And one of the things that they talk about is being appreciative, sort of like appreciating certain things in your life brings you happiness. And I think that when we think about that in the terms of how we interact with other people, being nice is a way of showing appreciation, it\u0026rsquo;s a way of showing respect. And so it\u0026rsquo;s not just, you\u0026rsquo;re not just being nice for them, you\u0026rsquo;re not just being nice for shareholders. I think we\u0026rsquo;d be nice for our own happiness, which is a very important.\u003c/p\u003e\n\u003cp\u003eDavid: Part of being nice for shareholders. That\u0026rsquo;s going to be the title of my first book, Nice.\u003c/p\u003e\n\u003cp\u003eAlex: I like it. Yeah. The other thing that I really like that you touched on is I think you sort of are describing what some people might call networking. It\u0026rsquo;s like getting to know more people. And I have found that networking is the easiest thing that you can do that has the biggest impact on your long term career. Right. And it\u0026rsquo;s not like networking makes it sound like this foreign thing that it is. It\u0026rsquo;s just like just saying hello up.\u003c/p\u003e\n\u003cp\u003eDavid: At a weird convention of business cards and wearing like a suit that doesn\u0026rsquo;t fit properly. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s what\u0026rsquo;s funny is I think that I Think that some people see that. Right. And I think just being genuinely curious about people and, and introducing yourself and like being able to be able to call someone by name and say, hey, that\u0026rsquo;s what networking is, I think. And there\u0026rsquo;s a lot of science to prove that sort of like the loose connections in our life have some of the largest impacts on our long term outcomes. You know, you know, having close ties is very important too. But that sort of, that looser, that second order is really important. I think networking is a part of that.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. I talk to people, you know, on my team or people that, you know that are close to me at work who maybe have ask for advice. This is something that I touch on a lot. Right. I think it\u0026rsquo;s sort of underappreciated. The value of, of networking. Sure. Of building relationships and to your point about sort of having different degrees of networks. Well, I guess I actually have a lot to say on this stuff. So I\u0026rsquo;ll try to maybe summarize for networking overall. The experience that I had earlier in my career where I was like really isolated from groups of people with similar interests was actually really helpful because it forced me to get good at like being intentional about networking, you know, online and stuff like that. And nowadays everyone\u0026rsquo;s remote. But even before that, I always worked remotely. And so for me, like, you know, that ended up being really useful in terms of sort of being able to build relationships with my colleagues wherever they are in the world. And the other thing, like I mentioned earlier, that stripe was sort of like this, this like awesome opportunity for me to get connected to sort of an ecosystem of people that I previously didn\u0026rsquo;t have that much access to. I try to impress sort of like how valuable of a resource that is to folks who, to new folks that I talked to, especially remote people. Right. Where it\u0026rsquo;s like, you know, you might live in Winnipeg or in, you know, I don\u0026rsquo;t want to disparage any other city, so I\u0026rsquo;ll just say Winnipeg. You have access to, you know, a world class network of people in this company across the world and you can ping them on Slack, you can send them an email, like they would be happy to help you adopt you. Right. And so one of the things that I used to do religiously back when travel was allowed, I would, you know, I\u0026rsquo;d go to San Francisco every couple of months. But I would make a point of using that as an excuse to sort of reconnect with everyone across the company that I knew, not just people in my team. Right. It\u0026rsquo;s like, oh, hey, I\u0026rsquo;m, I\u0026rsquo;m going to be in San Francisco this week, like if you\u0026rsquo;re going to be there, right? Like oftentimes they were based there or sometimes they would also be traveling there around the same time, like, let\u0026rsquo;s make sure we grab coffee or whatever. Right. And that I would treat that as sort of my job while I was in town would just be to like, you know, don\u0026rsquo;t try to get any other work done, just make that social time. Right. And, and the other thing I would say is that like to your point about sort of the degrees of relationships that we have, I read a book a little while ago, Billion Dollar Coach. It\u0026rsquo;s about Bill Campbell, who is this like, you know, really impactful coach and Silicon Valley coached executives at Google and Apple and stuff like that. But one of the things that the book drove home for me is that like, I think I was maybe under investing in sort of the closer relationships, the closer professional relationships that I have. I was maybe like spending a lot of time on, of sort of the broader network, but under investing in the people that I work most closely with. And one of the things that that book prompted me to do is change the structure of my one on one. So rather than having, for people that I work really closely with, rather than having, you know, let\u0026rsquo;s say a bi weekly 30 minute, I am more likely to try to set up a monthly one hour because I can get way deeper with someone in an hour of like uninterrupted time every month than I previously could in sort of 30 minutes here, 30 minutes there. Right. And so anyway, all that to say that like, I think, I think those, those layers are worth thinking about. But that took me a lot longer to say than I meant to.\u003c/p\u003e\n\u003cp\u003eAlex: No, don\u0026rsquo;t worry about it, you know. Well, I think the last thing I contribute here, I think is the most powerful bit of networking I\u0026rsquo;ve ever done was that when I was working for the library company, I had a hard time finding someone who could explain to me the value proposition of what we were giving our customers. And I don\u0026rsquo;t think that\u0026rsquo;s uncommon in a lot of industries. Right. Like a lot of people sometimes find themselves writing software that they don\u0026rsquo;t always understand exactly the value proposition, especially in places where there\u0026rsquo;s huge domain knowledge that you may not have access to from the get go. And so I literally googled other companies that did what we did and I started trying to find people at that company and just sort of asked them. I was like, just could you explain to me what we do. And it was such. I was demonstrating such, like, a level of vulnerability because I was like, literally coming to them and being like, I don\u0026rsquo;t know what I do, but everyone was incredibly gracious every time I did that. And we hooked up with a whole set of organizations that I could then go to conferences and stuff and talk to the people, a lot of people who were doing what I did. And that was incredible. And so if I ever find myself working in an industry or whatever, or if you find yourself working in an industry that you don\u0026rsquo;t necessarily understand, conferences and other things like that are a great place to go and just sort of talk to people and learn more about what you\u0026rsquo;re doing. And I find that a lot of people are very gracious in those moments.\u003c/p\u003e\n\u003cp\u003eDavid: Yes, absolutely. And the approach that you\u0026rsquo;re describing of sort of being really vulnerable is exactly what I would recommend to anyone. And I know it doesn\u0026rsquo;t sound like it because I\u0026rsquo;m here pontificating, but in sort of my regular life, I really try to take a beginner\u0026rsquo;s mindset when I\u0026rsquo;m approaching problems. And I really try to be the person in the room who asks the dumbest questions. And back from my sort of startup days, there\u0026rsquo;s this sort of meme in the world of, like, startup founders who are raising money where, like, if you go to an investor and you ask for money, you\u0026rsquo;ll get advice. But if you go to an investor and ask for advice, you\u0026rsquo;ll get money. Right. And that is something that I\u0026rsquo;ve kind of taken to heart in my life in general, is that, like, most of the time, the best way to approach anybody is to ask them for their advice. Right. Because first of all, you\u0026rsquo;re likely to get advice. And advice is great. Right. I want to hear whatever people have to say, anyone out there, Right. Like, there\u0026rsquo;s always going to be a unique perspective. And secondly, you might even end up with more than advice. Right. So anyway, I\u0026rsquo;m really curious, though, Alex. Like I said, I\u0026rsquo;ve been hogging the mic for a bit here. I want to hear your answer to that question too. How do you handle organizational alignment?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I really like the themes of one on ones like that you touched on. And this is actually something I talked a lot about in the original staff engineer interview I gave for the staff Eng website. What\u0026rsquo;s interesting is, even since then, I\u0026rsquo;ve sort of like, I\u0026rsquo;ve seen a new layer to my one on ones, and I think you touched on this too, which Is like sometimes, especially when I\u0026rsquo;m in sort of like seeking mode, like what do I need to work on, what do I need to fix? That is something where I will do lots of one on ones with lots of people to sort of get my hands around this problem. Because I don\u0026rsquo;t see myself as the best reducer of problems. Like I can\u0026rsquo;t see a problem and then reduce it to its components. And so what I do is I\u0026rsquo;m asking people really, I\u0026rsquo;m just sort of seeking out perspectives and it\u0026rsquo;s usually through other people and talking to them that I can start to see things that I couldn\u0026rsquo;t see before. And I can start to get like a real good understanding of the problem that I\u0026rsquo;m trying to solve. But then once I have that understanding and maybe people have explained to me some friction, they\u0026rsquo;ve explained to me sort of what\u0026rsquo;s going on, then I want to go and I want to like do the work somehow. And that at the moment I might sort of like wind down my one on ones. But I think that in general, like, I think a lot of people refer to this as sort of like a product oriented mindset or putting their product hat on. When you are trying to solve a problem, you need to make sure that the people that you\u0026rsquo;re delivering the value to are the ones who are giving you the feedback, you know, and the harder thing is like sometimes they\u0026rsquo;re going to ask you for things that may not be the best, you know, it\u0026rsquo;s just you have to really understand what they want, what they need, what the pressures are on them. So that when they ask for things that don\u0026rsquo;t make sense, you don\u0026rsquo;t immediately write it off, you know. But just because they asked for it also doesn\u0026rsquo;t mean that you\u0026rsquo;re necessarily going to do it. But having the relationships, having the product oriented mindset I think is what allows even engineers to produce valuable things that are in alignment with organizations, like wherever you happen to work. I think the other thing is I know that it\u0026rsquo;s really important to me to be in alignment with my organization. And I just sort of like, I shamelessly will sometimes just be like with my boss, I\u0026rsquo;ll just be like, am I doing everything I\u0026rsquo;m supposed to be right now? Right. Do you feel like I\u0026rsquo;m meeting my requirements and all that? And it\u0026rsquo;s not like I need him to be the only person to give me that answer. But like with certain people it\u0026rsquo;s just very valuable to get like a direct answer like, yes, you are no you\u0026rsquo;re not, you know, and build that relationship over time so that when you\u0026rsquo;re not in alignment, you know, and I think it\u0026rsquo;s important sometimes to not be in alignment. You can hear what they\u0026rsquo;re saying and you can then make decisions. You can say, oh, I didn\u0026rsquo;t know that I wasn\u0026rsquo;t in alignment, and I agree with you. Or you can go the harder route and you can be like, I think it\u0026rsquo;s important for me to do this, and here are the reasons why. And even though we\u0026rsquo;re not in alignment, what can I do to move forward with this project? Right. Because that\u0026rsquo;s where I think the most value comes through, in where you\u0026rsquo;re. You\u0026rsquo;re not 100% sure what you\u0026rsquo;re doing is going to work. And so having a strong relationship with your manager, with your, probably the team that you work on, allows you to know where you\u0026rsquo;re going to put those. You don\u0026rsquo;t get so many of those. Right. So, like, you got to make sure that those opportunities come along that you\u0026rsquo;re in at least alignment with some group of people that. So I think that\u0026rsquo;s really valuable is being able to just constantly be asking the organization, am I in alignment? So that you can know when you\u0026rsquo;re not in alignment and you can do the work that you think is important.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think you touched on a couple of really interesting things there. Like, for one. So one of the things I\u0026rsquo;ve observed with, you know, engineers who I think are really effective at this, is that the colloquialism would be sort of choosing your battles or like, you know, choose which hill you want to die on. But I think a better way to think about it is like an alignment vector has sort of multiple components, right? There\u0026rsquo;s the magnitude of the vector, but there\u0026rsquo;s also sort of the. There\u0026rsquo;s the direction of the vector and there\u0026rsquo;s the magnitude of the vector, I guess, like where the magnitude might be sort of like the how strongly you feel about the alignment or lack thereof. And so I guess not just feelings, but also like sort of what the impact of that is.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eDavid: So there can be some things where I disagree really strongly with organizational leadership, but I also sort of can realize that really at the end of the day, the impact of them taking a different decision is not going to be, you know, I may strongly believe that it\u0026rsquo;s totally the wrong decision, but, like, it\u0026rsquo;s not going to affect anybody or anything. Or it\u0026rsquo;s like something that can be undone. And so in that case, it\u0026rsquo;s like, well, let\u0026rsquo;s not worry about that right now. Right. There\u0026rsquo;s other things, things to untangle. You said it really well. Like, we only have so many of those times where we can put up a fight. If you\u0026rsquo;re doing it all the time, no one\u0026rsquo;s going to listen to you. Right. And so you have to make your decisions. The other thing that you mentioned that I think is interesting is, like, the fact that it\u0026rsquo;s totally expected for people to be. Not be aligned. And not only is it expected in the sense of, like, oh, like people are going to be unaligned and then they\u0026rsquo;re going to talk and become aligned, but it\u0026rsquo;s also like, in a company, not everybody can be working on exactly the same thing, Right. So therefore, people are have to be heading in, like, different directions. Hopefully those directions add up to something. Right. You want to be going totally opposite directions, but you\u0026rsquo;re going to be pointing in kind of different areas. Right. And so, like, the analogy that a mentor of mine has used in the past is like, you know, people\u0026rsquo;s compasses are broken in different directions. Right. And, like, intentionally. Right. The company breaks people\u0026rsquo;s compasses in different directions. And so you\u0026rsquo;re going to have, like, you know, product people want to move, let\u0026rsquo;s say, really quickly. Right. Whereas infrastructure engineers move, might sort of have some concerns about how quickly the product people are moving because they want, you know, they\u0026rsquo;re very concerned about reliability. And then it\u0026rsquo;s possible that, you know, security engineers have a totally different perspective on this and they actually sort of would advise a different direction. Right. And like, all of those perspectives are valid and all of those are valuable for the company, but sort of how you combine them depends on a lot of factors.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, there\u0026rsquo;s this. I\u0026rsquo;ve been going down a rabbit hole for a couple of years into the sort of safety, reliability, resilience, set of knowledge that you can dig into. And someone who mostly runs sort of like classes and courses that you can take and not so much has written a book, is a practitioner. Her name is Martha Acosta, and she talks a lot about this thing called psychological capacity. And so it\u0026rsquo;s like built on sort of like psychological safety, but it\u0026rsquo;s also built on complex thinking. And what I love about a lot of the stuff that she teaches is that you have to find a way to hold all the perspectives and not find the one true perspective. And that ability to do complex thinking in organizations is how we build the capacity for the. As complexity grows, as it will in all organizations, holding all Those perspectives and making sure that they are represented, like there\u0026rsquo;s a full throated representation of them, and that you\u0026rsquo;re not just trying to wash them away is where you will gain the capacity for the next evolution. And so more and more that I sort of move away from, I think earlier in my career, I was naive in thinking that if you can get complete alignment, if everyone can be on the same page, that you\u0026rsquo;re somehow going to produce the best thing. And, like, sometimes that works in very short spurts, but, like, next year it won\u0026rsquo;t because you\u0026rsquo;ve created sort of like a monoculture. And so the work of incorporating different perspectives is difficult, but it\u0026rsquo;s necessarily difficult in order to produce a more strong outcome, you know, long term.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that reads true. Switching gears again, kind of continuing along the path of the topics that we\u0026rsquo;ve often covered in these interviews. How do you think about mentorship and sponsorship in your work?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I think, frankly, I think this is the thing I\u0026rsquo;m not as good at as, I think a lot of the people that we\u0026rsquo;ve talked to on the podcast. But I think the one thing I like to do is to make sure that I leave time for folks who have questions, who want to schedule time. I try to be very open, you know, with my schedule. So if someone has a question, you know, I let them know that they should always feel free to schedule time. But I, you know, frankly, I just don\u0026rsquo;t know if I\u0026rsquo;m that good at it yet. I want to be better at it. And that\u0026rsquo;s one of the reasons why I\u0026rsquo;ve been looking at things like the staff inch book. And the way I\u0026rsquo;ve really, really appreciated this podcast is that I get to talk to people who I think are better at it. And I think the biggest thing that I\u0026rsquo;m trying to do nowadays is focus more on what do they want, what are they looking for, what are their goals? And less like trying to be sort of like some pontificating professor trying to teach them some arcane bit of technology, which I think is a mistake I\u0026rsquo;ve made in the past. But you sort of, when they show up, I\u0026rsquo;d be like, what are you trying to get out of this? What goal are you trying to achieve? And just sort of work from that perspective, put them at the center. And I think that\u0026rsquo;s helped a lot, for sure. How about you?\u003c/p\u003e\n\u003cp\u003eDavid: I also don\u0026rsquo;t think it\u0026rsquo;s, like, really a strength area for me. It\u0026rsquo;s something that I\u0026rsquo;ve been working on. I\u0026rsquo;m fortunate that There\u0026rsquo;s. There\u0026rsquo;s a lot of people around me that, that I look up to and who have kind of filled mentorship roles for me. And so I think there\u0026rsquo;s, you know, I can learn a lot from how they\u0026rsquo;ve approached that and try to try to model that. I think one of the challenges that I have is that I\u0026rsquo;m a bit too quick to jump towards sort of suggesting solutions, and I\u0026rsquo;m working on sort of asking more questions and. And helping people that I talk to find their own solutions instead, which is really hard. So, yeah, I don\u0026rsquo;t think I\u0026rsquo;ve cracked that nut yet. So then, given that this has been sort of an opportunity for us to get mentorship, by the way, the other thing I\u0026rsquo;ll say is that I do think I\u0026rsquo;m a little bit better with sponsorship, and that\u0026rsquo;s a fun opportunity to sort of find areas where someone that I know in the organization could have impact and sort of recommend impact them for it. That\u0026rsquo;s a really fun one for me. I always enjoy doing that. I find it a little bit easier to do because it\u0026rsquo;s sort of less squishy than the mentorship. And so I\u0026rsquo;ve been able to do that and I try to do more of it. But anyway, moving on then. Since this has been sort of an outlet for us to receive mentorship from staff engineers that we respect, what are some of the takeaways from the interviews we\u0026rsquo;ve done that sort of were the most, you know, that had the biggest impact on you?\u003c/p\u003e\n\u003cp\u003eAlex: I think the number one thing that I learned while talking to folks is that there\u0026rsquo;s just a bunch of different ways that you can become a Senior ic. And that I think is really valuable because I think a lot of times we pattern match. We might, without even realizing it, have, you know, we have implicit biases. And so using this podcast as a way to sort of, like, remind oneself that there\u0026rsquo;s just a way, there\u0026rsquo;s a huge number of variations of getting to Senior ic, I think, is one of the ways that we can sort of combat any implicit bias that we might have around who we can and cannot become a Senior ic. So that\u0026rsquo;s really valuable for me. Is there anything any other takeaways that you have?\u003c/p\u003e\n\u003cp\u003eDavid: One thing that stood out to me, I don\u0026rsquo;t actually know if it came through in the interviews as much, but just the amount of humility that all these people have. Like, we talk to people who are extremely accomplished, and I look. Look up to a lot, and they would sort of be around the Interview sort of really be, you know, nervous about it or unsure, you know, that they\u0026rsquo;re the right person to be providing advice or like, you know, second guessing sort of the things they did say. And this would be sort of un. Often communicated to me privately before or after the interview or communicated to us. And you know, like, I think what that underscores for me is that, well, a couple things. So. So first of all, like, imposter syndrome is a real thing. Right. I also think, like, the pattern suggests to me that, that humility is in itself sort of an important attribute for senior technical leaders. And I think we don\u0026rsquo;t, you know, that\u0026rsquo;s not really celebrated in our culture. If I think about a lot of the most impactful staff engineers that I\u0026rsquo;ve worked with, staff plus engineers that I\u0026rsquo;ve worked with, they\u0026rsquo;re not really like very, very loud and outspoken. Some of them are. Right. There\u0026rsquo;s all sorts of different personalities out there. But it just sort of underscored for me this thing that I\u0026rsquo;ve talked about a couple times of like trying. And for me it\u0026rsquo;s kind of hard because my default is actually to be pretty self assured and sort of, you know, almost to the extent of being brash. And so one of the things that, that I\u0026rsquo;ve learned from the show and that I\u0026rsquo;ve tried to take away and try to sort of model in my behavior is like, take a step back, make more space, let more people talk, listen a lot more and just be humble.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. I think the other thing I was just thinking about that I feel like I\u0026rsquo;ve learned a lot is how many people focus on partnering and listen and like, not just sort of like giving folks approval, but actually listening and clarifying the value proposition and then using as many sort of like smart brains as they can to clarify the problem that they\u0026rsquo;re solving and to just continually push that and to make sure that they\u0026rsquo;re producing things that are in alignment with the organization, that the team is in alignment with, that their peers are in alignment with. And just sort of the high degree of cognitive complexity is involved, but you have to keep pushing through it in order to make sure that you\u0026rsquo;re actually solving problems that are valuable for the folks that you\u0026rsquo;re delivering them to. Sometimes it\u0026rsquo;s your customer, but sometimes that\u0026rsquo;s peers, sometimes that\u0026rsquo;s management. There\u0026rsquo;s all sorts of different groups that you\u0026rsquo;re delivering value to at any given point in time.\u003c/p\u003e\n\u003cp\u003eDavid: I think that\u0026rsquo;s actually a pretty core insight, is the idea of being able to recognize what\u0026rsquo;s valuable. Right. I think that\u0026rsquo;s sort of a theme that we\u0026rsquo;ve danced around a lot of times in these interviews. But you know, that\u0026rsquo;s not something that we learn in school, certainly not in computer science education. From what I can tell in my engineering degree we did learn, we did talk about sort of engineering economics, which is basically like understanding the ROI or the cost benefit analysis of a project. Right. But I think even that doesn\u0026rsquo;t really cover it because it\u0026rsquo;s not just about being able to do the analysis, but it\u0026rsquo;s about actually being able to recognize the areas in an organization or in a system where there is opportunity, where there is something that can be tweaked, where the cost is going to be less than the benefit.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eDavid: And so, yeah, I mean, I think that is sort of an under discussed skill set of technical leaders. We\u0026rsquo;re getting close to time and you know, there\u0026rsquo;s the two questions. Right. So let\u0026rsquo;s do it. What are some resources that you would recommend to folks listening?\u003c/p\u003e\n\u003cp\u003eAlex: Oh man. I think what I\u0026rsquo;d start with is like there is still a lot of amazing stuff being published in sort of like blogs and stuff. And something that I haven\u0026rsquo;t seen a lot of people mention yet is using sort of like a feed reader. I highly recommend. Twitter is good, but like long form is also good. And so I still subscribe to anywhere I think between 100 and 200 sort of feeds from various things that just sort of like I love seeing new projects and like new takes on things. And so like I subscribe to a lot of like tagged resources, like what are all the new Ruby links? What are all the new JavaScript links? And because like sometimes projects will get announced that are really easy to miss, but they have like a really novel impact on something that you do every day. I think the second thing, the second big resource is, and this is really more of a jumping off and it might sound odd, but like one of the most important documents I\u0026rsquo;ve read in the last few years was the Etsy Debriefing Facilitator\u0026rsquo;s Guide, which is like a guide to how Etsy does sort of like incident debriefs, some people might call them postmortems and other stuff. Read that doc and then sort of use the sort of like citations in that doc and just keep going. Because understanding what they\u0026rsquo;re trying to do through postmortems and through incident analysis I think is an incredibly important window into the future of our work because things are only going to get more complex they\u0026rsquo;re not getting more simple. And every single one of us needs to become a systems thinker, I think at some point in order to do our job effectively. And postmortems are a really interesting way to probe complex systems. So I highly recommend reading that and then just sort of like continuing to simmer those ideas always. How about you?\u003c/p\u003e\n\u003cp\u003eDavid: I mean, first of all, those are interesting resources. I\u0026rsquo;ve actually heard you mentioned the Etsy document a couple of times and I haven\u0026rsquo;t read it yet. So that\u0026rsquo;s going to be somewhere I need to start. I\u0026rsquo;ll take it in the other direction though. I mean, I think, I think what you said is great, but I like sort of dead tree books and especially sort of older ones. Like, I think it\u0026rsquo;s interesting, it\u0026rsquo;s valuable for sure to sort of look ahead at where industry is going, but I think there\u0026rsquo;s also a lot to be gleaned from from what came before. One that I always really recommend to people that are interested in the technical leadership track is High Output Management by Andy Grove. And on the face of it, it\u0026rsquo;s a management book. Right, But Grove talks about in the book, I think he calls them know how managers, which are, he describes them as people who, you know, hold knowledge and disseminate knowledge within the company and, you know, identify work that needs to be done. But they don\u0026rsquo;t have direct reports. Right. And this is, you know, this is From I guess 20 or 30 years ago that he\u0026rsquo;s talking about that. But he\u0026rsquo;s talking about staff engineers, right? Or whatever. Like there\u0026rsquo;s, you know, these people have taken different forms and different times. But I think there\u0026rsquo;s a lot to be gleaned from that book and I think that, you know, there\u0026rsquo;s some interesting stories in it as well. Similarly, I\u0026rsquo;ve always been really interested in the overlap between the idea of like non commissioned officers in the military and staff engineers. I think like the idea of thinking about it. I mentioned before sort of the close partnership that I have with my manager and I sometimes think that that\u0026rsquo;s analogous to like the close partner that, you know, a sergeant might have with a lieutenant or something like that. I don\u0026rsquo;t know if I got those ranks right, but like, I think that that history is interesting. I don\u0026rsquo;t have like a canonical resource there, but it\u0026rsquo;s something that I\u0026rsquo;ve been digging into and you know, that might be an interesting thread for other people to pull on. And then the other thing I would say is like, you know, there\u0026rsquo;s a whole body of knowledge around things that are adjacent to our work. So, for instance, I mentioned how, like, my small, quite not accomplished background in sales has helped me in engineering work, and I think it would help a lot of other engineers. And, you know, that\u0026rsquo;s a field where there\u0026rsquo;s. There\u0026rsquo;s a ton of stuff to read. Two that I might point people toward is like the, you know, Dale Carnegie, how to Win Friends and Influence People. It\u0026rsquo;s like, terribly annoying title, but. But it actually probably can help. Some people just don\u0026rsquo;t, like, repeat someone\u0026rsquo;s first name 12 times in a. In a conversation, please. And then also there\u0026rsquo;s a book called Influence by Robert Cialdini. I don\u0026rsquo;t know if I pronounced that properly. And it\u0026rsquo;s maybe a little bit like, malicious. It\u0026rsquo;s kind of like a social engineer\u0026rsquo;s guide to persuading people to do things. But there\u0026rsquo;s sort of some interesting tidbits there. And, you know, I think for people that are sort of wired, like we are thinking about human relationships in terms of systems isn\u0026rsquo;t necessarily the worst idea for sort of getting a head start there. Yeah, I think that\u0026rsquo;s my list for now.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Yeah, there\u0026rsquo;s always more books, so I.\u003c/p\u003e\n\u003cp\u003eDavid: Guess that brings us to the last one. You saved the percentage till now. How much time do you still spend coding?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I was thinking about this. I think it\u0026rsquo;s between 25 and 50% of my time, you know, and it just varies week to week. You know, like some weeks I feel like I\u0026rsquo;m writing a lot of docs, breaking projects down, trying to organize, you know, trying to talk about where we need to go in the future, try and influence where we\u0026rsquo;re going to go in the future. But there are still times where I\u0026rsquo;m getting down and writing code, and that\u0026rsquo;s still so satisfying when I, like when I fix a thing or I push some code out that I\u0026rsquo;ve been working on for a long time, I still find it\u0026rsquo;s like almost the easiest thing to get satisfaction from. And that\u0026rsquo;s maybe a problem. How about you, David?\u003c/p\u003e\n\u003cp\u003eDavid: No, I totally get what you\u0026rsquo;re saying. I have been in an unfortunate mode at work where the only coding that I do is like, is like when I\u0026rsquo;m hoisted by my own petard because I wrote something a long time ago that no one else can, can, can or wants to sort of take the time to fix. And so I have to fix it. I\u0026rsquo;m dealing with one of those right now. It\u0026rsquo;s been dragging on for weeks, so maybe I\u0026rsquo;m over indexing on that. But beyond that, I don\u0026rsquo;t really get to write a lot of code at work lately. And that fluctuates. Sometimes I write more than other times. I would say maybe averaged across the year, probably 10% of my time these days. And so I have a side project that I use just to, just to like, not only write code, but also sort of like remind myself that I can build things and ship them quickly and like, you know, sometimes inside organizations, you know, like the, like I said, the problems aren\u0026rsquo;t always technical problems and it\u0026rsquo;s, it can sort of be a little bit, it can bog you, it can feel a little bit like it\u0026rsquo;s bogging you down. Right. And it\u0026rsquo;s like, for me at least, my instinct is sort of then to sort of start second guessing what I\u0026rsquo;m doing. Right. Like, you know, why is this so hard? Am I approaching it wrong? And so it can. I get a lot of satisfaction out of like, you know, doing something in a weekend or whatever here and there when I can.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I. For what it\u0026rsquo;s worth, I\u0026rsquo;m the same way. I just recently wrote a whole bunch of code to like create a book layout from a bunch of all like, like extracting notes from my note taker and then like, oh, cool. Introspecting a private SQLite database and then converting it into markdown and then producing like a 1500 page PDF and it\u0026rsquo;s incredibly complex, but, you know, it was like one of those things where like the tools just didn\u0026rsquo;t do what I wanted and you know, so you break out the tool set. I know how to write code and you just start going down that path and it reminds you of like, what you. I think for some of us, not all of us, like what brought us to this space in the first place.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think now we\u0026rsquo;re kind of going on a tangent, but that\u0026rsquo;s okay for me anyway. Well, you mentioned like, that\u0026rsquo;s, that\u0026rsquo;s what brought some of us here. And I think it\u0026rsquo;s. I\u0026rsquo;m sure there\u0026rsquo;s people out there where. That\u0026rsquo;s not why. Why they\u0026rsquo;re here. And that\u0026rsquo;s fine. I don\u0026rsquo;t mean to disparage them, but like, the engineers that I get are the ones who sort of view programming as a superpower. And you know, that\u0026rsquo;s why in our industry there\u0026rsquo;s sort of a lot of concern about like filtering resumes by people who have side projects like that. I think that\u0026rsquo;s totally fair. I know I\u0026rsquo;m about to become a dad, I\u0026rsquo;m not gonna have a lot of side projects, right? Like, that\u0026rsquo;s. That\u0026rsquo;s expected, and people go through different phases of life. But, you know, I\u0026rsquo;ve never. And again, I\u0026rsquo;m not saying this is wrong, but I\u0026rsquo;ve never understood the mentality of people who, like, don\u0026rsquo;t want to find projects. Like, to me, it just. It\u0026rsquo;s just like, you have this amazing power at the end of your fingertips. Why wouldn\u0026rsquo;t you want to use it, you know? Anyway, I digress.\u003c/p\u003e\n\u003cp\u003eAlex: No, not at all. I. For what it\u0026rsquo;s worth, it\u0026rsquo;s one of the things that I think that I got the most wrong. I actually wrote a blog post a long time ago, and I wrote some title, like, you know how two kids in two years is, like, my superpower? And I wrote it and I read it last year, actually, and I was like, who is this person? I don\u0026rsquo;t know who this person this is. And I was like, I actually talked to my wife. I was like, do I delete this? Because, like, I don\u0026rsquo;t agree with this at all anymore. And, you know, I talked to some other people, and they\u0026rsquo;re like, you know, good URLs don\u0026rsquo;t die. And I also agree with that. But I was like, but I don\u0026rsquo;t want anyone to stumble upon this and to get the wrong idea. And so I deleted it. And it\u0026rsquo;s just. I think you have to. I think what\u0026rsquo;s really important to know when you\u0026rsquo;re doing side projects is are you doing them because of sort of, like, hustle culture, or are you doing them because you\u0026rsquo;re having fun? Right.\u003c/p\u003e\n\u003cp\u003eDavid: Yep.\u003c/p\u003e\n\u003cp\u003eAlex: And that, to me, is always the main thing. It\u0026rsquo;s like, if you\u0026rsquo;re having fun, great. If you\u0026rsquo;re doing it because you feel like this is the only way to progress forward, you know, fine, as long as you\u0026rsquo;re having fun. But, like, if you\u0026rsquo;re, you know, just, like. Just really pay attention to, like, why you\u0026rsquo;re doing that thing, I think, and make sure that it brings you value somehow.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think. I think that\u0026rsquo;s a really good point. And I mean, look, like, hey, I have lots of other hobbies, and I think other people have lots of other hobbies, but one of my core hobbies is programming. Right. And it\u0026rsquo;s just like, I kind of acknowledge that about myself. But I think you\u0026rsquo;re right. If folks out there are doing it because they think they need to, then that\u0026rsquo;s definitely no good.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Well, all right.\u003c/p\u003e\n\u003cp\u003eDavid: So with that. Oh, my goodness. This is. Oh, man. Tearful goodbyes.\u003c/p\u003e\n\u003cp\u003eAlex: Well, I really appreciate. Just like, you know, I really. You should put this in there. But, like, I, I think that this would not have happened without you. You put so much time and effort into this. You got all the guests like, well, most of the guests, and did all the work. So I really appreciate that you let me sort of hitch along for the ride. I really appreciate. I\u0026rsquo;m glad about what we\u0026rsquo;ve created, and I think it\u0026rsquo;s been a great experience.\u003c/p\u003e\n\u003cp\u003eDavid: I had a ton of fun. I\u0026rsquo;m really glad you came along for the ride. Thank you for doing that. And until the next podcast, Sa.\u003c/p\u003e\n","date_published":"2021-12-28T09:00:00-06:00","date_modified":"2021-12-28T09:00:00-06:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/peter-stout-netflix/","url":"https://podcast.staffeng.com/season-1/peter-stout-netflix/","title":"Peter Stout (Netflix)","summary":"The difference between context and control is not in the first sentence. The difference is in the paragraph that comes afterwards and in the fact that there's often a question at the end of that paragraph that draws the other person into the journey.","content_html":"\u003cp\u003eThe structures of an organization can often be self-reinforcing, and in a changing environment, this becomes a recipe for future vulnerabilities. That is why senior ICs need to play a slightly discordant role at times by alerting teams to issues conventionally outside of their bubble of concern. Peter Stout is a Technical Director at Netflix where he has a cross-functional role at the juncture of business and technology. He joins us on the show today to share some of the finer details around what inhabiting this position in the above manner looks like. We start by hearing Peter describe himself as a generalist, and share how this played out in the broad focus of his college degree as well as in his career pivot from Chemistry into Software Engineering. We discuss the rapid growth of the engineering team at Netflix, how this has led to less tightly-defined roles for junior and senior engineers, and how this factors into the way Peter approaches his place in the organization. Peter talks about the shift he made from technician to technical director and how much of the skills he learned from the former position he brings into the latter. He talks about his tendency to seek out the blank spots in the organization and how he tries to focus on a long-term vision, using that to guide him as he connects the dots between teams and influences decision making. Here Peter considers his role as a disruptor and how he gauges how much pressure to apply while still staying largely in sync. We also have a great conversation about Peter’s approach to mentorship and his philosophy around how he grew into the leadership position he occupies. Tune in today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/pds13/\"\u003ePeter Stout on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.netflix.com/\"\u003eNetflix\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Range-Generalists-Triumph-Specialized-World/dp/0735214484\"\u003e\u003cem\u003eRange\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Leadership-Pipeline-Build-Powered-Company/dp/0470894563\"\u003e\u003cem\u003eThe Leadership Pipeline\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9679803-peter-stout-netflix.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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\u0026rsquo;m joined by my co host Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Today\u0026rsquo;s guest is Peter Stout. Peter is a Technical Director at Netflix where he has a cross functional role at the juncture of Business and technology. He started out as a chemist but was drawn to the programming part of his work. So much so he eventually left the chemistry behind and started working as an engineer full time. This was an awesome conversation. I\u0026rsquo;m stoked for everyone to hear it. Let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Much for taking the time to join us today. If we could start by having you kind of just rather than me introduce you, why don\u0026rsquo;t you introduce you? What\u0026rsquo;s the story?\u003c/p\u003e\n\u003cp\u003ePeter: Hi, I\u0026rsquo;m Peter Stout. I am a Technical Director at Netflix, which is one of the two technical titles we have for ICs. I have a cross functional role there at the junction of business and technology. I report up to the VP of Platform Engineering, but operate across a broad swath of the organization. I\u0026rsquo;m a generalist by nature. I started out as a chemist as an undergraduate with a sort of a pseudo minor in Medieval history and Math cs. There was a bad course in each of them I didn\u0026rsquo;t want to take, so that\u0026rsquo;s why I didn\u0026rsquo;t actually have more majors or minors in them. After college I moved to Europe for a couple of years and worked doing a mixture of wet lab chemistry, computational chemistry, and computer programming. That led me to come to the realization that while I could do all of those things, I was more interested in having more fun doing the computer programming. So I went to graduate school. The program I ended up in was at the time as much a apprenticeship as it was a research program, and So I spent seven years there, nominally earning my PhD, but learning a lot about the craft of being a software engineer, after which I have spent 25 years in Silicon Valley working at a variety of companies, large and small. I\u0026rsquo;ve spent most of the last 12 years at Netflix in a variety of roles, so just two job titles while Distributed Systems and infrastructure. My background I have a tendency to aim towards the blank spots in the technical ecosystem at whatever company I\u0026rsquo;m working for. One of my co workers described me as being a dyke plumber.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. I\u0026rsquo;m curious, you know, in your organization at Netflix, you know, are there typical expectations for senior ICs like yourself? Is there?\u003c/p\u003e\n\u003cp\u003ePeter: There are not. We have largely hidden those roles in the sense that what a senior software engineer is is not particularly well defined. Lauren Hochstein, who you spoke with earlier, talked to some of this. And so what one person does with that title and what I do with my particular title can be very different from other people there. And it\u0026rsquo;s in some ways one of the challenges that I think we\u0026rsquo;re facing right now, now that we\u0026rsquo;re a company of 2,500 engineers or at least 2500 people in engineering. That wasn\u0026rsquo;t the case when it was a few hundred people and trying to understand how we maintain our culture, but figure out how to make it easier for people to figure out who\u0026rsquo;s doing what and why is an open challenge for us. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: So in absence of sort of like expectations for everyone, as a senior ic, you know, what expectations do you have for yourself as a senior IC at Netflix?\u003c/p\u003e\n\u003cp\u003ePeter: I am trying to connect the dots. Michael Saccati, in describing what he was doing at another company recently in a leadership community that I am in, talked about working on creating the organization that is solving the problems that while seven years ago I came back to work on a major cross functional technical problem, drove the program and the technical strategy for it. Today what I\u0026rsquo;m really interested in doing is creating a support network for the people who are doing those sorts of things today. That it\u0026rsquo;s not going to be a separate organization. But how do we create an interstitial fabric so those people can find each other, that the right connections get made, that we don\u0026rsquo;t miss the gaps due to knowledge or ignorance of something else going on in the organization. And it\u0026rsquo;s sort of that constantly looking for the gaps, trying to look forward, trying to look across the organization has been how I, in alignment with my boss of the time, have worked to figure out what\u0026rsquo;s the most valuable thing to do.\u003c/p\u003e\n\u003cp\u003eAlex: So one of the things that I, from your description is it didn\u0026rsquo;t sound very technical.\u003c/p\u003e\n\u003cp\u003ePeter: Well, so that\u0026rsquo;s one of the things. Well, yes, and that\u0026rsquo;s sort of one of the challenges that I have a small amount of imposter syndrome here. Am I really still a senior technologist? I mean certainly what I was doing five years ago absolutely will fit in with what Rich Lafferty or Mason Jones is doing today. I start to go, there are ways that I start to look more like a VP of engineering or something that I\u0026rsquo;m thinking about organizational structure. How do I enable these people to succeed? But I do come at it from a technologist perspective. Hey, I know that there are these business problems. How do we enable the technology and the technologists in our organization to help solve those business problems effectively or more effectively? And so I definitely am coming at this as being a technologist, but am I doing technology on a day to day basis? No. I mean, if I think about the question you like to ask people at the end of the day, at the end of the interview session, how much time are you spending coding? I\u0026rsquo;m not going to reveal my answer to that just yet, but how much time do I spend doing technology?\u003c/p\u003e\n\u003cp\u003eDavid: Even I was going to say spoiler alert.\u003c/p\u003e\n\u003cp\u003ePeter: Nope, I\u0026rsquo;ll save that for later. Everything in its own time. But the amount of time that I am doing, really technology versus hey, how are we having the right conversations around technology? That\u0026rsquo;s much more what I\u0026rsquo;m spending time on these days. Or it\u0026rsquo;s mentoring or it\u0026rsquo;s trying to enable the people who are learning how to do those things to do them more effectively. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: Do you feel like the people that you manage though, or influencer help, the goal is like good technological outcomes, at least in part, right?\u003c/p\u003e\n\u003cp\u003ePeter: Absolutely. It\u0026rsquo;s like, all right, we five or eight years ago, we started creating our own content. Three or four years ago, we started to get serious about building technologies to support creating tens, then hundreds, now thousands of pieces of content a year. Well, that\u0026rsquo;s different from distributing thousands of pieces of content to people in millions of places. Oh, but wait, if you stand back and look at that pipeline, you can kind of turn it around and creating content looks like you\u0026rsquo;re running that distribution pipeline backwards. Well, okay. Just like stream processing can be the same or different if you care about real time or not real time. If you stand back far enough, it\u0026rsquo;s all the same. If you get up closer, you can see really important technical differences about. Well, you maybe don\u0026rsquo;t want to have one system. So how do we take the valuable pieces of technology that we\u0026rsquo;ve spent years figuring out how to do really well, bring them over to the content creation side and leverage them there. So that\u0026rsquo;s the collection of things. How do I get the right pieces of people who think they may be just working on the tools to create content to understand what the people who are building infrastructure to support the delivery of content need to be talking to each other. Or maybe they don\u0026rsquo;t need to, but the company might have a better outcome if they did. I spend a lot of time thinking about optionality and if you think about the cone of probabilities of where the company is going to go into the future and what business problems it\u0026rsquo;s going to want to solve, what products it\u0026rsquo;s going to want to deliver, particularly coming from the infrastructure side of the organization. It\u0026rsquo;s about what are the things that I need to be thinking about now so that product managers next year can be making choices that aren\u0026rsquo;t going to take them out of what we\u0026rsquo;re relatively nimbly going to be able to support because it\u0026rsquo;s much more expensive for product manager says, hey, I want to go do this thing and you\u0026rsquo;ve got no building blocks to start with it. It\u0026rsquo;s like, okay, I can ship that for you in two years. And they\u0026rsquo;re like, whoa, that\u0026rsquo;s not going to work. All right, now we\u0026rsquo;re back to chewing gum and bailing the wire. And.\u003c/p\u003e\n\u003cp\u003eDavid: So Peter, I I want to follow that thread, but I have to circle back to something you said earlier, and this is maybe going to sound like a troll question, but it\u0026rsquo;s entirely sincere. Feel free to skip it if you want, though. What parallels do you see between medieval history and and the kind of work that we do in technology today?\u003c/p\u003e\n\u003cp\u003ePeter: One thing I would say is that I learned to be the writer that I am by going to school at a liberal arts college, and they didn\u0026rsquo;t care that I thought I was a computer scientist. You had to learn to write. And the fact that I didn\u0026rsquo;t even think I wanted to be a computer scientist then. So that ends up being one of the things. But fundamentally I\u0026rsquo;m curious. And so the way it\u0026rsquo;s relevant is I don\u0026rsquo;t exactly know how or why it\u0026rsquo;s going to show up. I am constantly trying to vacuum up information just because I don\u0026rsquo;t know what I\u0026rsquo;m going to do with it. And this actually leads into an interesting intellectual dichotomy or sort of oxymoron for myself between trying to only ask questions where I think it\u0026rsquo;s going to help move the conversation forward or affect how I choose to solve a problem. That just being that letting out that inner two year old and going why, why, why, why? Isn\u0026rsquo;t necessarily helpful. There was a manager in the organization who a year or so ago wrote in sort of his weekly update to his team about always trying to move the Conversation forward, think, how do you engage with this, with the expectations the other people trying to do this thing have the best of intentions and how can you help it move forward? So how do you think? Think in that way? And so I want to ask the questions that will help me to understand why I have a different opinion than this other person or whether they see the challenges that I saw or whatever it might be to help that project move forward. But that\u0026rsquo;s around where I have to understand, I have to take energy and effort from somebody else. If it\u0026rsquo;s my time I\u0026rsquo;m spending, I\u0026rsquo;ll read all sorts of things, I\u0026rsquo;ll look at all sorts of things where the cost to anybody else is relatively low because I don\u0026rsquo;t know what I\u0026rsquo;m going to do with them. And that. Can I tell you chapter and verse of something that I did in my medieval history course? I didn\u0026rsquo;t forget the question, no. But the, the things that I got out of that, because one of the other things that I did was a course on the history of space exploration and the science behind that. And in some sense that might be the things that\u0026rsquo;s closer because it got me to start to stitch together my interest in STEM fields with my interest in history. And you can start to say that that becomes valuable in understanding the history of a company, why these things go together, and learning to remember that what you may think about them, reading or studying them years later, gives you some ideas that you can draw conclusions about, but you do not necessarily know what those people were thinking about in those moments. And it\u0026rsquo;s seldom useful to try to second guess those things. It is useful to figure out what you need to learn from what happened and how it played out afterwards, because they were making decisions in the moment. And to tie this back into technology, in a sense, one of the last major decisions where I got to own the whole technical thing, we\u0026rsquo;re going to do it this way, not that way, was rebuilding a system that tracked our viewing history. A decade or so ago I made the choice to do it one way and one of the engineers was pushing back and going, eh, I\u0026rsquo;m not sure this is right. I still think at that moment in time it was the correct decision. The world changed six months later when a whole different collection of load came onto that system and it caused us to have to scale it up in a materially different way and basically broke the assumption that I had. That became a decision point where I in hindsight feel I failed in going, oops, wait, we violated what I had as an implicit assumption in my head. We need to now go back and re architect this now and we never did. We put all sorts of additions onto it and we\u0026rsquo;re still struggling with that decision six years later. Thankfully, many people no longer realized that I had been the source of it, or they might come cursing me a little more often. But it\u0026rsquo;s valuable to learn about that. Hey, could I have foreseen that that changed six months out? Because six months was too short. I thought that there was a couple of years. I think in hindsight that it would be stable and viable. And at that time the company, we were turning over lots of system on a couple of year timetable. So let\u0026rsquo;s not get another service tier. We have to operate right now. But there were lots of things that were different and they made very different choices six years later when they were replacing that system with the next generation of things.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. As a side note, I think it\u0026rsquo;s funny, sort of the technical decisions we make that come back to haunt us. Things can move so quickly that a decision that you make a year or two ago feels like, feels like a lifetime ago and feels like there\u0026rsquo;s totally different information, you know, a year or two hence, but so be it. One of the things I wanted to dig into a little bit and we\u0026rsquo;ve actually sort of organically touched on a couple of them. But sort of going back to your role, I\u0026rsquo;d be curious to know, you know, concretely what are sort of, you know, to whatever degree you\u0026rsquo;re able and comfortable to discuss sort of ongoing stuff at Netflix, but more just for the listeners to have context, what would be the sort of project that, that you\u0026rsquo;d be involved in driving these days?\u003c/p\u003e\n\u003cp\u003ePeter: Today, that\u0026rsquo;s an ambiguous question. Netflix is a bit, is in something of a generational shift. Having turned over a bunch of senior leadership in the last year or so and leaning more heavily into product management in a variety of parts of the company where it didn\u0026rsquo;t exist before. And so exactly what my role is and fit into that is ambiguous at the moment. But a lot of it has grown from seven years ago when I came back to the company driving a project we called at the time Global Cloud, which established the core structure of our operating practices to manage single region outages. At the time, different service tiers did different things to handle traffic. And that led to some very intriguing failure modes. Our European customers were served out of one data center. Our customers in the Americas were served out of a pair of data centers. And we could steer traffic between the two of them and with Europe growing, that wasn\u0026rsquo;t deemed to be sufficient anymore. And so I drove the effort to be able to serve any customer from any region. And the steering is done at the front door of the ecosystem rather than farther down. And so now services just they get a request, they do the best they can with the data that\u0026rsquo;s available and they do no steering internally. And that has been the core of the operating practices that we use to deal with either AWS issues, our own self inflicted problems within a region. And where does that go? All right, you\u0026rsquo;re telling me about what you did seven years ago, Peter? Well, I have been building off of that to think about big cross cutting problems that impact a variety of things. We went to three regions which we were already operating back there and that was partially a cost driven thing. I started laying the groundwork for going, hey, we should be looking at doing more regions for the size of our load in any given region, the ability to consider whether we care about doing N plus 2 rather than N plus 1, et cetera, et cetera, and all the other things that you might think of in those spaces and have been pushing on those conversations articulating. We have a technical strategy session forum, or at least we used to for discussing some of these things. About three years ago I laid out a vision for hey, how I thought we could go about doing this. Decided again at that point in time it wasn\u0026rsquo;t quite the right thing. Last year or two I\u0026rsquo;ve been pushing on that topic again with a bunch of seniors leadership and there\u0026rsquo;s now an engineer within the platform engineering organization who is driving that next thing that is looking to expand into more regions over the next several years. And so it\u0026rsquo;s those long play, very wide across the organization things that I try to drive. How are we going to do regional resiliency? How are we connecting the dots between seemingly disparate business units, if you will, to actually get leverage from our experience in various different ways? Are we aligned organizationally to achieve those goals? Do we understand how to have those conversations effectively? Are we tying technical decision making to staffing decision making?\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. A question that sort of occurs to me because I think the experience of a lot of engineers is that we\u0026rsquo;re always trying to do the best thing, the most valuable thing, you know, but it\u0026rsquo;s just, it\u0026rsquo;s really difficult to be sort of right all the time. And I think a lot of people beat themselves up when they don\u0026rsquo;t necessarily do the right thing. What I\u0026rsquo;m hearing from you is that you\u0026rsquo;re trying to do some really big things and lay out some really expansive visions, but they don\u0026rsquo;t always seem to land or they don\u0026rsquo;t seem to work or for various reasons. And I\u0026rsquo;m curious, you know, given, given your attempts, how do you, where do you find success? How do you remain positive about your work?\u003c/p\u003e\n\u003cp\u003ePeter: Because I work at several different layers. That\u0026rsquo;s the big picture. What I think is those are the home runs that I think have the or those are the things that I think have the potential to be major game changers for the business over time. And therefore it\u0026rsquo;s taking me years to get them to happen. But it\u0026rsquo;s why I keep working on them. At the same time, I spend lots of time being a sounding board for people working on all sorts of different scales of problems, jumping in and being a hands on engineer occasionally. Still, this is now three years ago on a team that was understaffed, trying to deliver some stuff that\u0026rsquo;s important that then turned into a way of bootstrapping a lot more information about that domain and then I could use that to plug into other projects. It\u0026rsquo;s mentoring lots of people because growing other people to do the things that I was doing seven years ago when the company was smaller, to do them now when the company is bigger and we need more of them across more places, that becomes the way that I start to feel that I\u0026rsquo;m delivering value today. I\u0026rsquo;ve also, using Will Larson\u0026rsquo;s terminology, spent a lot of my time functioning as a right hand for whatever leader, that archetype and helping them to understand the technical trade offs that were going on in the organization or internally or in peer organizations and how those would interact with other things. And so that\u0026rsquo;s a lot of the small scale stuff, but it\u0026rsquo;s this mixture of trying to grow people to do those things, but knowing that there\u0026rsquo;s this big macro strategy challenges that Netflix is, because of its loosely coupled, highly aligned strategy doesn\u0026rsquo;t necessarily lean into as much as other companies do, going, hey, we do need to pay attention to these big challenges over here and that\u0026rsquo;s why I keep doing them. Are there days that I get profoundly frustrated that I am I really doing something useful? Yes. But I think their potential value is high and so I keep trying to do that.\u003c/p\u003e\n\u003cp\u003eAlex: So switching subjects a little bit, something we like to talk a lot about is like, how do you, as a senior I see who, you know, has sort of like a looser set of expectations than maybe sort of a more junior or less experienced engineer. How do you make sure that the work that you\u0026rsquo;re doing is aligned with your organization? You know, what does that process look like for you?\u003c/p\u003e\n\u003cp\u003ePeter: Historically a lot of that has come out of being in that right hand role to some extent. And so spending lots of time collaborating with my peers, lots of time collaborating with my boss to understand what we locally think are the most important things to be doing. Other than that, it\u0026rsquo;s by being tuned in and attending a bunch of the product strategy discussions, talking to leaders in various other parts of the organization to hear what they are finding as the challenges that they\u0026rsquo;re having to deal with. Because sometimes companies will say one thing and then actually the action on the ground will be something else. And so sometimes it\u0026rsquo;s a matter of being able to surface back to the leaders that I\u0026rsquo;m working with or reporting to that, hey, I know we\u0026rsquo;re saying that this is a priority over here, but I can watch all the works going in a different direction. If you really want it going to the left, then you\u0026rsquo;re going to have to make some statements about this and or influence in different ways, trying to set direction, I guess, or sort of collaborate with people to understand where it\u0026rsquo;s going. I spend an immense amount of my time talking with people one on ones, groups, meetings, etc. Just often, more often these days trying to figure out a, how to make a connection and get myself out of the conversation. So that that\u0026rsquo;s the way I scale and that\u0026rsquo;s the way I scale my impact.\u003c/p\u003e\n\u003cp\u003eAlex: So once you feel like you sort of are headed in that direction and you\u0026rsquo;re like okay, I think I got this, I think I\u0026rsquo;m aligned. How are you sort of checking in and making sure that you\u0026rsquo;re continually in alignment with the organization?\u003c/p\u003e\n\u003cp\u003ePeter: By seeing where I\u0026rsquo;m getting pushback, by seeing where the organization is shifting. Because one of the things, because of my habit to go towards the blank spots, I am often a source of incongruence in the organization. And so what is it that happens out of that? Earlier this year read a book called Range by David Epstein and he talks about the importance in robust organization of incongruence that regardless of what strategy you have of highly sort of top down structure or highly diffuse structures, those tend to be self reinforcing in any direction and that will lead you to be more and more effective in that particular style. As long as the world that you\u0026rsquo;re operating in is relatively stable. If things change and more and more in the tech industry things are changing, that becomes a weakness over time. So Having people or systems that are pushing you in a slightly different direction is important or valuable. And I\u0026rsquo;ve often been that source. And so what I\u0026rsquo;m trying to do is walk the space of trying to lead the organization in the direction that I think is valuable for it without getting too far out of sync. There\u0026rsquo;s a concept in sociology and politics called the Overton Window that describes the range of accepted views that a politician can have to be elected or reelected in that community. And the edges of it are someplace out about acceptable. And then you get into radical or something. There\u0026rsquo;s a Wikipedia page that shows a picture of this. I think it\u0026rsquo;s very easy to fall off the edge from acceptable into radical. I think it is much harder to go from radical back to acceptable. And so a lot of what I\u0026rsquo;m doing because I\u0026rsquo;m trying to get people to think about things that aren\u0026rsquo;t necessarily their day job or to consider the ramification of this other team where their product managers are pushing them to deliver this feature. But, okay, you\u0026rsquo;re going to externalize a bunch of cost to somebody someplace else. How can I help you to have that conversation through the organization to go, well, maybe we shouldn\u0026rsquo;t do it exactly that way, or we should at least talk about the ramifications of doing that. And what starts to help me to understand if I\u0026rsquo;m in alignment is how strongly people are reacting. That starts to give me a hint that maybe I\u0026rsquo;m getting a little far, close to that edge and I need to back up a little bit. The signal that it\u0026rsquo;s really well aligned is when I start to hear people quoting back to me things that I have written or said in the past, and they don\u0026rsquo;t always know that they\u0026rsquo;re telling me things that I have written or noticed. I mean, I loved it when somebody was telling me about this paragraph of prose and explaining what the backstory was. And I was able to that. Huh. I wrote the original document that that was clipped out of because it was lifted wholesale from one place to another. It\u0026rsquo;s like, okay, cool, I\u0026rsquo;m doing my job.\u003c/p\u003e\n\u003cp\u003eDavid: I think that, like, along the same lines, one of the questions that I have is, and I mean, this is so the challenge that all of us, as we sort of become increasingly senior ICs, is like, you know, we\u0026rsquo;re expected to lead without being bestowed authority, at least not in the sense of having having direct reports. And it sounds to me like, you know, that ends up being a really big part of your job. So in addition to sort of Making sure you\u0026rsquo;re aligned with leadership. You also need to make sure that you\u0026rsquo;re influencing your peers and the engineers in your organization to sort of buy into the vision that you lay out. And what happens when. Well, okay, first of all, so is it correct to say that you don\u0026rsquo;t have any direct reports?\u003c/p\u003e\n\u003cp\u003ePeter: It is correct. I have occasionally been an interim manager at Netflix at various times when people needed to have something managed, but.\u003c/p\u003e\n\u003cp\u003eDavid: And so in that case, you\u0026rsquo;ve already outlined a little bit in terms of sort of how you propagate a vision. But I\u0026rsquo;m curious, sort of, if we get a little more nitty gritty, what happens when, when there\u0026rsquo;s a discrepancy between sort of your vision and the direction that, that a project is actually going, or between sort of two different teams that are both required to, to get aligned and who aren\u0026rsquo;t sort of aligned in the right way. Like, what are the tools at your disposal besides sort of like reiterating the document or whatever? Like, how do you do it?\u003c/p\u003e\n\u003cp\u003ePeter: Well, let me ask the two of you a question first. What\u0026rsquo;s the difference between context and control?\u003c/p\u003e\n\u003cp\u003eDavid: Context has to do with like the information that people have and control has to do with the agency that people have.\u003c/p\u003e\n\u003cp\u003ePeter: Alex, any thoughts? Does that work for you?\u003c/p\u003e\n\u003cp\u003eAlex: I think I would agree with everything that David said. I might add that context. So like helping people see the environment that they\u0026rsquo;re in and sort of see the surroundings that they\u0026rsquo;re in. They\u0026rsquo;re both mechanisms by which you can get people to make a decision, I think also.\u003c/p\u003e\n\u003cp\u003ePeter: Okay, I have spent a bunch of time this year reflecting on this and I have come to the perspective that the difference is not in the first sentence. The difference is in the paragraph that comes afterwards and in the fact that there\u0026rsquo;s often a question at the end of that paragraph that draws the other person into the journey. And so it was not an engineer any place at Netflix who made the decision, we are going to move out of our data center and deploy our systems in aws. A dozen years ago that was a top down decision, but it was then followed with a whole paragraph about we\u0026rsquo;re going to do this because we don\u0026rsquo;t think that there is value. Running our own data center helps us to achieve this business goal, which is what we actually care about as a business, trying to entertain customers around the world or around the US at that point in time. Can you help us figure out how to do this? Because while we know we want to be over there, we have no clue today how we\u0026rsquo;re going to get from here to there. And so that\u0026rsquo;s a way of bringing people into the journey, into the conversation. While in some sense, if you will, putting fences around the edge of the playground. We want you to play over here. Please don\u0026rsquo;t go run into the street. This is why we think that\u0026rsquo;s dangerous. Well, you don\u0026rsquo;t want to always have to be telling somebody over and over, don\u0026rsquo;t run into the street. So putting up a fence over there that says this is where you can play allows more effective or more freedom to play in unencumbered ways most of the time. Coming back to the question of how do I do this? It\u0026rsquo;s trying to talk about where we\u0026rsquo;re trying to go as a business, why that matters and offering up ways in which I think they can help to achieve that goal. And then as a bunch of other people have been asking you, start asking questions. So why isn\u0026rsquo;t this landing on your roadmap to start executing right now or whatever point in time another piece is? I try to go start having conversations with people this quarter about what I\u0026rsquo;d like them to be thinking about doing next quarter. Because if I can plant the seeds in advance and start to learn about what may be competing initiatives or demands on their time, I can start to get in front of that by finding out who else I need to talk to to adjust the priorities of incentives investments. And so that\u0026rsquo;s a bunch of the strategy. On the gee, I\u0026rsquo;d like to do that, but I\u0026rsquo;ve got these other things that are pulling on me and that\u0026rsquo;s how I deal with that. On the I think we should do it this way. Well, and some other team thinks we should do it another way. The longer I\u0026rsquo;ve been in this industry, the less convinced I am that there are really right answers to pretty much anything. And I am coming more and more about getting aligned answers. And one of the things I\u0026rsquo;ve been thinking about in some sense by listening through some of the recent podcasts preparing to do this interview is about little Endian versus Big Endian number representations in computers. And I spent more than a little time earlier in my career having to care about those things and going back and forth. I used to know a bunch of the arguments for why one was better than the other. I couldn\u0026rsquo;t recite any of them to you anymore with any confidence, but I don\u0026rsquo;t really think there is a fundamental truth that this one is better than that one, certainly under all circumstances. And at the point that you add that on how do you bring them together? It\u0026rsquo;s like, okay, how do we make a decision that allows us to effectively move forward? The comment that Nell made in the podcast that just dropped episode that dropped yesterday about the conversation with an NSA person where somebody pulled them aside and said, look, they just got to use that thing. It doesn\u0026rsquo;t matter whether you think yours is better or not. It is not constructive to do that. Well, how do we dig into why? Let\u0026rsquo;s just pick one and move forward in an aligned direction. If it\u0026rsquo;s my one opinion versus a whole team that may differ in a different thing, I\u0026rsquo;m awfully inclined to go, fine, you\u0026rsquo;re going to be doing the coding. You\u0026rsquo;re going to be making this happen. Let\u0026rsquo;s just go do it your way. We\u0026rsquo;ll move on. Will we have a retrospective perhaps later on to figure out? Did it play out the way they expected? Did it play out the way I expected? Someplace in between? How do we learn from it? Cool. One is two different teams that have different beliefs or perhaps different mental models for how to approach a design problem that gets to be a lot harder. And I don\u0026rsquo;t have as good a set of strategies for doing that. I think the idealist in me goes, I\u0026rsquo;d like to have the questions and ask why do you care so much about this and all of that? But sometimes at the end of the day, the answer ends up just being that they do. And I don\u0026rsquo;t really have a better answer than you have to pick one eventually, or you have a persistent dysfunction in your organization and you are trading off one challenge for another. And I wish I could give a better, more satisfying answer because I don\u0026rsquo;t really like that answer, but that is the lived reality that I\u0026rsquo;ve experienced.\u003c/p\u003e\n\u003cp\u003eAlex: Do you feel like this goes back to your previous statement about sort of incongruence? It\u0026rsquo;s like sometimes you sort of give everyone context. Maybe you even give some decision making. Eventually they\u0026rsquo;re going to make a decision, and if it\u0026rsquo;s different than your own, it\u0026rsquo;s almost like it\u0026rsquo;s a good thing because that means that we\u0026rsquo;re going to learn something by someone doing something different than I might have done it.\u003c/p\u003e\n\u003cp\u003ePeter: About a year ago, I read a blog post on Andy Grove\u0026rsquo;s book about Leading intel. And the blog post asserts, and I haven\u0026rsquo;t read the original book, so I\u0026rsquo;m a little hesitant, but I believe basically that Andy felt that as an executive did not have the responsibility to make a decision. They had the responsibility to set values and ensure that decisions were made. And more and more as I move up in the ladder, I have come to the view that, no, I\u0026rsquo;m not the one who should be making the decisions. I need to make sure that decisions are made, that they\u0026rsquo;re made soundly and effectively, that we think about them again afterwards. But no, and I had this as I was talking about the global cloud effort earlier and the fact that we\u0026rsquo;re finally starting to think about how to expand into more regions. This is a thing where somebody else needs to lead it today that they are closer to the conversations that are happening that will drive the nuances. They have more time to pay attention to those details than I do. I need to engage with them to make sure that they\u0026rsquo;re aware of the other things going on that it may touch on. Because there are more ripple effects on other parts of the ecosystem that we need to have debates and discussions about. Do we couple these two efforts? Do we leave them apart? Why? Well, if we\u0026rsquo;re making a multi year bet, is that even realistic? Or maybe we can ignore each other today, but by the end of next year we\u0026rsquo;re going to be stepping on each other\u0026rsquo;s toes. How do we plan for that reality? And so it\u0026rsquo;s much more of that stuff around it that, that I\u0026rsquo;m paying attention to. This is one of the things shows up both for people, leaders and technology. You have to learn to let go as you move up. First it\u0026rsquo;s letting go of writing a piece of code. Then it\u0026rsquo;s learning to let go of that piece of code that you wrote before that. Now some other people are taking in different directions. And in time it becomes about making the decisions about that product or piece of code that you used to be involved in or would have been really excited to have been involved in. If you were at a different point in your career, you\u0026rsquo;re not there anymore. So give other people space and grace to do those things.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Changing subject real quick. You said that mentoring is a big part of your job nowadays and I\u0026rsquo;m curious, do you have like an approach that you take to mentoring?\u003c/p\u003e\n\u003cp\u003ePeter: One of the things is I have the belief that I often get as much out of mentoring the other person does. Even when there are nominally significant differences in place on a career path that I will learn things either potentially out of the storytelling that I\u0026rsquo;m doing in the course of the mentoring or by the questions that they ask or whatever topics that they bring to the table, I\u0026rsquo;ll learn something out of it. A tangible example cropped up just yesterday. I was had a Virtual mentoring session with somebody I was introduced to by a mutual friend. And they\u0026rsquo;re just starting to sort of make the transition between senior engineer and staff engineer, doing it at a small startup. And had a bunch of questions around that. And I shared a whole bunch of perspective out of my career that I thought was relevant. They took lots of notes, was really excited about it, and I could tell by the end of the sort of half hour that we were chatting that there was a little bit of deer in the headlights, information overload, if you will. And it allowed me to go, okay, let me step back here and say, here are the things that I think are important for you today. Take the rest of those as being things that you\u0026rsquo;ll sort of noodle on. Come back to those notes some days. Here are the two things that I think are relevant for you right now. And I think that will help me to have a more effective mentoring conversation with the next person in their shoes that comes along. So learning and reflecting, seeing when you get an opportunity. Because some people might not have been quite as comfortable as that person was in revealing their sense of, geez, I\u0026rsquo;m overwhelmed. This is all really good, but nah, I. You\u0026rsquo;re teaching me to fish, but you\u0026rsquo;ve dropped a whole bunch of equipment on my table, and I don\u0026rsquo;t know which one to pick up first. And so it\u0026rsquo;s like that one and that one. Now go forth. We\u0026rsquo;ll either push the rest aside, you\u0026rsquo;ll get to that. But it\u0026rsquo;s a lot. It\u0026rsquo;s about conversation. Where are they trying to go? Asking questions to help them, to figure out they\u0026rsquo;re not having my journey, they\u0026rsquo;re going to have their journey, helping them to be comfortable in their own shoes and figuring out what is important to them. And it\u0026rsquo;s often about being a sounding board. My father many years ago asked me, have you thought about being a rabbi? What? I identify as being Jewish, but I have never been what I thought of as being particularly religious. And I was like, no. And years later, I ended up meeting a rabbi who, if I\u0026rsquo;d known them, they\u0026rsquo;re probably about my age, so maybe more. If I\u0026rsquo;d known who\u0026rsquo;d been ever was their inspiration and mentor, maybe I could have been a rabbi, because their way of doing it just sort of. I could see that. But I\u0026rsquo;ve also come to realize that a bunch of what I do these days is kind of like some of the aspects of being a rabbi that I will give somebody a safe space to have a conversation about what they\u0026rsquo;re interested in what they\u0026rsquo;re afraid of, what they\u0026rsquo;re challenged by, and then help them to think about how they would go about doing that for themselves. So maybe that\u0026rsquo;s the form and structure of how I mentor. It\u0026rsquo;s not to say here\u0026rsquo;s the list of things you must do, but here are the things that I encourage you to think about to figure out what will work for you.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. That\u0026rsquo;s a really interesting analogy. How many people at any given point in time do you feel like you\u0026rsquo;re, you\u0026rsquo;re mentoring?\u003c/p\u003e\n\u003cp\u003ePeter: That\u0026rsquo;s hard for me to count in the sense that I am always telling managers my calendar is public to everybody at Netflix. I try to keep it not too dense. That doesn\u0026rsquo;t always work, but it\u0026rsquo;s open to anybody. I\u0026rsquo;m telling managers that they can point people in my direction, so I\u0026rsquo;ll have one off. So with all sorts of people, maybe five to 20 in a quarter, I don\u0026rsquo;t know, it\u0026rsquo;s really variable. And then there\u0026rsquo;s a group of people that I am both collaborating with and mentoring on an ongoing basis, sometimes tied to projects, sometimes just checking in as part of my gathering information for other things. But part of our one on one conversations would be, hey, what\u0026rsquo;s going on? How do I, oh, what about thinking about this thing this way? Or did you know about this other thing over there? Which are aspects of mentoring in connecting and exposing them to other things or giving feedback. And that\u0026rsquo;s probably 10 to 15 people fall into that bucket. And then there\u0026rsquo;s probably handful or two who I\u0026rsquo;m more regularly meeting with in one form or another. Probably only a handful of those at any given time, which really feels like more of explicitly a mentorship relationship. But again, because I see them often as being valuable to me, differentiating who I have one on ones with from who I have mentoring relationships with is where I\u0026rsquo;m a little fuzzy up.\u003c/p\u003e\n\u003cp\u003eDavid: I want to switch gears a little bit, seems to me, you know, I understand Netflix doesn\u0026rsquo;t have any titles except for two, and definitely doesn\u0026rsquo;t correspond to sort of staff, senior staff, principal, etc. But from what you\u0026rsquo;re describing, if you were to be teleported into a company that did provide these levels, I think you\u0026rsquo;d be sort of in the, in the upper echelons of sort of the technical IC leadership track. And I\u0026rsquo;m curious sort of what the path to getting there looked like in terms of maybe a chronology and also sort of maybe if someone were to ask you, someone who\u0026rsquo;s a senior engineer or you know, A staff engineer and aspiring to sort of move up to higher impact levels, sort of what your advice would be or how you might.\u003c/p\u003e\n\u003cp\u003ePeter: Guide someone in that direction. I found Rich Lafferty\u0026rsquo;s comments in your interview with him about how he writes his documents to be just so relevant to me. I sit down in front. I started a career 20 years ago. I\u0026rsquo;ve gotten to where I am today. My inclination towards doing things that are valuable for the company and aiming towards blank spots is really how I\u0026rsquo;ve created this career. Very seldom have I explicitly been trying to move up some ladder that I understood. And it\u0026rsquo;s the first job I had in the Valley was at a company called General Magic and I started moving into technical pre sales as part of what I was doing there. And that was the first place I started getting exposed to the business side. Well no, not even that was as an employee. That was the first time I started to get exposed to the business side of technology. And at the time I very much remember having the reaction they\u0026rsquo;ll pry my keyboard out of my cold dead fingers. I wasn\u0026rsquo;t ready to let go of being a coder at that point in time. And writing specs to give to customers to explain how our products would help them solve things was not the right thing for me. And so my next job, next couple of jobs were just purely hands on engineers building things one at a really large company. And then at the first startup I went to and there it was just picking up the interesting problems that were important to the business and learning and watching what was going on around me but entirely about doing the things that were important to the business, trying to watch and reflect what worked well, what didn\u0026rsquo;t work well. I\u0026rsquo;m fairly introspective and so I reflect on what I\u0026rsquo;ve done and not done a lot. The other piece is during the dot com bust I interviewed a startup and had a conversation with the CEO in an interview segment with the CEO and he asked me the common question of sort of what do you want to be when you grow up? And as I was doing at the time, I said with great confidence and a fair lack of understanding of what it is really, really was I want to be a cto. And he gave me some really profound advice at that point in time which is don\u0026rsquo;t aim so carefully for a particular goal. Be open to a broad collection of experiences that may lead you to there but will allow you to see some other things along the way that will help you to be more effective with you get there and I had a conversation with a woman from Netflix who started out at Netflix as a senior software engineer, became a manager, became a director, and was leaving the company earlier this year to go be the founder of a startup. And because I have concerns about our lack of having an IC ladder at Netflix, and I was doing some quasi exit interviews of people who I respected who\u0026rsquo;d gone into management but had been technologists before, and asking them, would you have done things differently if we had a technical ladder? Would you have stayed in that? And she gave me what I found to be an unexpected but profoundly thoughtful answer of yes, I probably would have still done this, but I\u0026rsquo;d been more thoughtful about it. And so I think that this ties back to what that CEO was doing, is that if you\u0026rsquo;re looking around at those other things, what does that product manager doing next to you doing? What is that program manager that you\u0026rsquo;re engaging with sometimes doing? What is that people leader doing? You will have ideas that will be both allow you to figure out what\u0026rsquo;s the role that you want to be going after and how to engage with them. How I think it might have been rich, maybe it was Mason Jones was talking about doing code switching and how you have those conversations with different people. If you\u0026rsquo;re trying to be effective and move forward, those are the Being able to reach people where they are will help you to be more effective. And I think those skills also help you to move up. The more that you can come to people where they are will help them to understand and perceive your value in some sense. And so is it managing up? Is it politics? Is it just being a caring, engaging human being? You can interpret it different ways. Interesting.\u003c/p\u003e\n\u003cp\u003eDavid: I mean, I think that makes sense. I think that matches some of the feedback we had from other folks on the show, which is basically like it\u0026rsquo;s not that helpful to aim specifically for one target, but it\u0026rsquo;s more useful to sort of point yourself in a direction and then reevaluate as you move along.\u003c/p\u003e\n\u003cp\u003ePeter: Think about how we do software. We try to do experiments and do incremental development. We\u0026rsquo;ve moved away from waterfalls. So ultimately saying you\u0026rsquo;re going to be that one particular thing, a form of waterfall development. So how do you get to be agile in what you do for your career?\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s a fascinating analogy. I hadn\u0026rsquo;t thought of it that way. So we\u0026rsquo;re getting close to time. You alluded to the questions that we ask every guest. The first one is what are the resources? Whether that\u0026rsquo;s books, blogs, podcasts, a hymn, or anything else that you might refer folks toward if they want to sort of learn to be to be a better technical leader.\u003c/p\u003e\n\u003cp\u003ePeter: I love listening to this podcast. I found the collection and diversity of perspectives. I can listen to people and go, oh yeah, that\u0026rsquo;s familiar. Oh, that\u0026rsquo;s dinner. I need to think about how that would play out to be valuable.\u003c/p\u003e\n\u003cp\u003eDavid: I was fishing for that a little bit, but I do appreciate it.\u003c/p\u003e\n\u003cp\u003ePeter: I understand that. I wouldn\u0026rsquo;t have gone there if I hadn\u0026rsquo;t believed it. I find Rand\u0026rsquo;s leadership slack to be really valuable, particularly for me as someone who spent most of the last or more than the last decade at Netflix. And so that gives a bit of a monoculture for how to do be a senior leader. I mean I had a bunch of experience other places before that, but that ages out a bit. And seeing the way other people having more people to chat with for me, I found range to be profound Valuable by David Epstein I also think this was the book I was recommending the new leader or the person just early on in their career yesterday to read is go read the Leadership Pipeline by Ram Charan C H A R A N and in particular the first couple of chapters of it that talk about the transition from being an IC to a manager of ICs. Yes, the exact form of it will be different for a people leader than for a technologist, but this idea about that you have to be thinking about different things as you progress up this ladder is important to being a senior IC or a senior technologist. And I\u0026rsquo;m crappy about reading other things. I sort of hoover up whatever articles people at work point at me and then sort of absorb the pieces of information and forget exactly what it was that it came from shortly thereafter.\u003c/p\u003e\n\u003cp\u003eDavid: Fair enough. So it looks like we\u0026rsquo;ve lost Alex, but there\u0026rsquo;s one other question that we always ask, and this is the one you alluded to earlier. So how much time do you still spend coding?\u003c/p\u003e\n\u003cp\u003ePeter: I spend no time at work coding. The last piece of code that I wrote that landed in production was probably three years ago. I do spend time running my own server and doing sysadmin sorts of coding at home for myself, but as various other people have commented, that\u0026rsquo;s not where I get my leverage from. It\u0026rsquo;s getting other people to do it. Do I miss it? Yeah, but because I care about business value, that\u0026rsquo;s While I was uncomfortable with doing that 20 years ago, I\u0026rsquo;m absolutely comfortable doing it now.\u003c/p\u003e\n\u003cp\u003eDavid: Cool. Well, Peter, thank you so much for taking the time to chat with us today.\u003c/p\u003e\n\u003cp\u003ePeter: My pleasure. I really enjoyed it. Thank you for doing the podcast. As I said before, I really appreciate it.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to Staff Eng. If you enjoyed today\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n\u003cp\u003ePeter: Sam.\u003c/p\u003e\n","date_published":"2021-12-14T09:00:00-06:00","date_modified":"2021-12-14T09:00:00-06:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/james-cowling-convex/","url":"https://podcast.staffeng.com/season-1/james-cowling-convex/","title":"James Cowling (Convex)","summary":"Oftentimes the biggest dysfunctions in a team are a lack of alignment around a clear strategy and lack of values alignment.","content_html":"\u003cp\u003eOften the biggest impacts a Staff Engineer can make in their organization are not technical but rather people-related. When teams are value-aligned due to good leadership, they go on to make larger impacts than they would otherwise have. As Senior Principal Engineer at Dropbox for almost a decade, James Cowling learned a lot about how people think and work together, and he joins us today to share some of his insights. Joining this conversation, listeners will hear about James’ experience at the helm of numerous high stakes projects at Dropbox, such as migrating the company off Amazon S3 by building their own distributed storage system. For James, the main job of a tech lead is getting their team to have a firm grasp of the why behind a project, and to become completely values-aligned as a result. James takes us through his approach to diagnosing struggles within teams and how he helps groups to step back and course correct by drilling down on their purpose within the larger organization. We talk about the strong culture that gets built as a result of this approach and the power it has to keep teams robust. In today’s conversation, James also gets into how Staff Engineers themselves can stay in tune with the larger company, the single most important quality to nurture in Software Engineers who hope to grow into leadership positions, and a whole lot more.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/jcowling/\"\u003eJames Cowling on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/jamesacowling?lang=en\"\u003eJames Cowling on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://convex.dev/\"\u003eConvex\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.dropbox.com/\"\u003eDropbox\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://medium.com/@jamesacowling/stepping-stones-not-milestones-e6be0073563f\"\u003e\u003cem\u003e\u0026lsquo;Stepping Stones not Milestones\u0026rsquo;\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9604651-james-cowling-convex.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level, into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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 Ramos and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Today\u0026rsquo;s guest is James Cowling. James is currently the CTO and founder of Convex. Previously he was a senior principal engineer at Dropbox for almost a decade. We talk a lot about the unique impact that senior ICs can make. Often the biggest impact we make isn\u0026rsquo;t technical, it\u0026rsquo;s our impact on the team. And when that part is done well, our teams make an outsized impact. It was a real treat to hear how James works with teams and I think you all are going to enjoy it as well. So let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eJames: Awesome.\u003c/p\u003e\n\u003cp\u003eDavid: James, thank you so much for taking the time to chat with us today. If you could start by kind of in your own words, giving us a little bit of a rundown of like, who you are and sort of what your story is up till now.\u003c/p\u003e\n\u003cp\u003eJames: Yeah. Hey everyone. And nice to be in the podcast. So I\u0026rsquo;m James. I\u0026rsquo;m Australian. Maybe you can hear I\u0026rsquo;m kind of losing my accent. I\u0026rsquo;ve been in the states about 16 years and I came out here originally for grad school, ended up staying in the tech industry and I\u0026rsquo;ve been a software engineer for my career and I have a startup now where I\u0026rsquo;m a co founder the majority of the time. I think, you know, where I kind of developed, I guess, skills and technical leadership was at Dropbox that was there for eight years working on a variety of projects. I think the most notable ones were, you know, early in my time at Dropbox where I was the technical lead for product to migrate us off of Amazon S3 to build our own distributed storage system, which ended up being multiple exabytes, close to a million hard drives spread across the United States. So a very, very large project with a large budget and a lot of risks. I had the benefit of working with some really, really senior engineers who had been very influential. Other companies had gone on to do other things post Dropbox as well and ended up being ultimately the most senior engineer at Dropbox towards the end of my tenure, where I Kind of. I was not building a lot of of software directly anymore at that point. And mostly doing things like strategy and managery sounding, things like that. A lot of mentorship, a lot of direction setting, a lot of working with junior engineers to develop them and develop teams. So I went through this kind of transition of just building code, building systems, writing, writing code. I\u0026rsquo;ve been a manager a few times, but the sweet spot for me is more the technical lead area where I like kind of working with a team and getting stuff done.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. I definitely think we\u0026rsquo;re going to dive into a lot of that history. But first, given your experience, do you have a sense of what should a typical staff plus engineer do?\u003c/p\u003e\n\u003cp\u003eJames: Yeah. So to start with, there\u0026rsquo;s debate at what it means to be a staff engineer. And I\u0026rsquo;ll give my definition. I think when someone transitions from a senior engineer to say a staff plus engineer, there\u0026rsquo;s a shift in not just magnitude of how you work, but also the nature of how you work. So when you\u0026rsquo;re a junior engineer, you\u0026rsquo;re writing code, you\u0026rsquo;re building systems, and as you get more senior, you\u0026rsquo;re doing harder stuff and you\u0026rsquo;re working more and more independently. I think when you start shifting from say the senior engineer to staff engineer, a lot of companies have these same titles. It\u0026rsquo;s when you start getting involved in what I would call strategy. And that\u0026rsquo;s where you start doing actually long term direction setting and you\u0026rsquo;re acting far more independently. And so I think a lot of engineers make independent decisions on the how to do things, but maybe they\u0026rsquo;re not making decisions on the what to do. And if they are, maybe they\u0026rsquo;re not making decisions on the why. And when you become a particularly senior engineer, a lot of the work you\u0026rsquo;re doing becomes about the why. What are the problems facing this company, what direction should we go, and what have I observed as issues? And then there\u0026rsquo;s an accountability relationship that changes as well. So the thing I work with junior engineers who are very talented. I\u0026rsquo;ll tolerate them saying things like, oh, someone should do blah, or you know, complaining about things. But when you get to a certain level of seniority, the buck does kind of stop with you. There might be more senior people than you in the organization, but when you start transitioning to the staff engineer level, it\u0026rsquo;s where you stop looking around for guidance and stop looking around for someone to blame or someone to tell you what to do and start realizing that it\u0026rsquo;s on you to actually shape the direction of the company. And so that\u0026rsquo;s what I see. The engineers who adapt very well to being a staff engineer are those who are very comfortable with uncertainty, with strategy, with working with people, and with direction setting. And I do know, and I\u0026rsquo;m friends with some very, very good engineers who don\u0026rsquo;t get to that level, and that\u0026rsquo;s just fine. There\u0026rsquo;s some engineers who are just this super ICs, these super individual contributors who just are incredible at building stuff, but they don\u0026rsquo;t have an interest in trying to figure out what the company will look like in two to five years. They don\u0026rsquo;t have an interest in building a team or even dealing with technical leadership. Sometimes they just want to build stuff, which is fine. It\u0026rsquo;s obviously a huge contribution to the organization. But a company does need some group of people to actually decide what gets done and why. And I think that\u0026rsquo;s often the domain of people on this staff plus level. Awesome.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious. It sounds like a lot of your experience was gained working at Dropbox, but it feels like you have a very broad understanding of what a staff engineer plus does. How do you feel like you gained that experience while working, you know, for one company like that? Tenure seems. It\u0026rsquo;s odd in, in our industry, I think, and it\u0026rsquo;s interesting to see.\u003c/p\u003e\n\u003cp\u003eJames: Also, I\u0026rsquo;m a little bit older because I was in academia beforehand, so I did a PhD and I worked in distributed systems and I had worked previously in research and that kind of stuff. I think I benefit a lot from mentorship and working with engineers at other companies and inside the company. And so I\u0026rsquo;d have to pick a random number, but, you know, just say half a dozen to a dozen companies. I\u0026rsquo;ve kind of gone and done training sessions there where I\u0026rsquo;ve helped develop their senior engineers. And, you know, every company has idiosyncrasies. Every company has its own level system and its own, like, weird corporate dysfunctions. But there\u0026rsquo;s a lot of similarities that you start to notice. And oftentimes these come from kind of the discussions where I\u0026rsquo;ll go to speak to a senior engineer and they say, I just can\u0026rsquo;t get blah to have to happen. Why is that? And when we start chatting that, well, let\u0026rsquo;s just assume everyone in the room has good intentions. Let\u0026rsquo;s assume that no one\u0026rsquo;s out to get you. Let\u0026rsquo;s assume that we\u0026rsquo;re all smart people and that. And the people that disagree with you are also smart people. Why is it that, you know, you can\u0026rsquo;t get the thing done that you want to get done right and that could be because there\u0026rsquo;s a lack of empathy. It could be there\u0026rsquo;s a lack of understanding of what their priorities are. It could be that you\u0026rsquo;re not good at communication, which is a huge issue for senior engineers. Right. I mean, it\u0026rsquo;s all well and good for you to have the greatest idea in the world. If you can\u0026rsquo;t convince anyone that your idea is a good idea, it doesn\u0026rsquo;t matter, right? There\u0026rsquo;s no point of being the smartest person in the room if no one else agrees with you, right? At the end of the day, like, you know, maybe it\u0026rsquo;s not the nicest metaphor, but like, you know, this is capitalism here, right? All that matters is the value you\u0026rsquo;re producing, right. It\u0026rsquo;s not about whether you\u0026rsquo;re right or whether you\u0026rsquo;re wrong. And so when you start evaluating yourself based on am I getting good stuff to happen in a long term sense and that\u0026rsquo;s where you can hone these skills. So yes, you know, I was at Dropbox for eight years. I\u0026rsquo;m founder of a startup now. I happen to work with, you know, almost all the infrastructure teams of the company. And so I got a lot of experience working with literally hundreds of engineers at Dropbox or more, but also engines at other companies and just kind of picking up on the commonalities between, you know, the issues that everyone faces.\u003c/p\u003e\n\u003cp\u003eDavid: Very cool. There\u0026rsquo;s a lot of, lot of questions I want to dig into there. I think actually one of the things that I\u0026rsquo;m curious about, I\u0026rsquo;ll kind of work backwards. You mentioned now that you\u0026rsquo;ve moved into sort of founding your own startup, which is cool and a pattern that we remark on almost every episode at this point is that a lot of staff engineers start their careers in small startups. And sort of that attitude that you were talking about about sort of like not depending on other people to tell you what to do, but finding the things to do is I think something that often gets developed inside smaller organizations. I\u0026rsquo;m curious how you have found sort of going the opposite direction from, you know, a fairly established company like Dropbox into starting your own thing. I\u0026rsquo;m curious what motivated you to do it? And then you know, to whatever extent you\u0026rsquo;re comfortable sharing, I\u0026rsquo;m curious to also sort of know more about the startup.\u003c/p\u003e\n\u003cp\u003eJames: Yes. So there\u0026rsquo;s skills and anti skills you get from both directions and you can really hinder yourself if you\u0026rsquo;re not careful in both directions. So I think people probably understand that starting at the big company side, the skill is you learn how to do things properly. Just say you go work at Dropbox or Google or Facebook. You see, there\u0026rsquo;s something called a sev process. When things go wrong and you see good engineering practices and you see what code review looks like, you understand how to do things. The downside is you may never learn independence and you may never learn ownership. And ownership is just incredibly important. And the other thing that you may never learn is just say you go. And not to throw shade on Google here, but say you go work at a company like Google where their systems are incredible, right? And say you go work in infrastructure at Google, you can take things for granted. You can just say, oh, things look this way because that\u0026rsquo;s how things always work. And you didn\u0026rsquo;t realize the amount of effort and the amount of iteration and the number of mistakes that took to get to there, right? So that the 0 to 1 is really, really hard. And if you\u0026rsquo;re not someone who\u0026rsquo;s built something from the ground up, it\u0026rsquo;s very easy to criticize other people\u0026rsquo;s work. It\u0026rsquo;s very easy to not appreciate the complexity in building something from scratch. So starting a big company, yeah, oftentimes you learn, you\u0026rsquo;ll see how things get done well and you have access to high quality peers and high quality mentors. But you may not learn ownership the other way around if you started a small company. And so what\u0026rsquo;s the failure mode? The failure mode is you might just stagnate in your career because you might not. I mean, there\u0026rsquo;s nothing wrong with going and working at a big company and making a lot of money. And, you know, we\u0026rsquo;re very fortunate to work in this industry, right?\u003c/p\u003e\n\u003cp\u003eDavid: Absolutely.\u003c/p\u003e\n\u003cp\u003eJames: The flip side, if you start at a startup and try to go the other direction, is one, you will learn ownership straight away because you just got to grab a shovel. Now, when I started at Dropbox, I infrastructure was, I think, seven people, right? So it was, you know, and there was not really much management going on at the time, you know, so it was grab a shovel time then too. Like, there was no, like, someone should do bly. If you said that, that was on you to solve. But going the other direction, the big problem I observe is maybe we\u0026rsquo;ll call it hubris. Like every now and then I read a blog where someone\u0026rsquo;s opining with like these deeply held convictions about how you should design a system or, you know, how scalability works and. And they\u0026rsquo;ve run a system with seven nodes in it, right? And they\u0026rsquo;ve never, like, really tried something at scale and they\u0026rsquo;ve Never seen how things fail. It\u0026rsquo;s actually, it\u0026rsquo;s very easy to get to, hard to get from 0 to 1. But there\u0026rsquo;s a great subtlety in building systems that can scale to larger use cases, building systems that can be used by thousands of developers and not three. And I think it\u0026rsquo;s certainly possible that you can go work at a startup, learn the ownership, they kind of miss the developmental experiences of how to build things well, how to do things properly, and maybe get a little bit too much confidence in how hard it is to do things at scale. And so I guess what I would say is, you know, working at a high quality startup is awesome, right? If you go work at a startup where there\u0026rsquo;s really good people who are like top shelf, who know how to get things done, I think that\u0026rsquo;s the best case scenario. Right, because you\u0026rsquo;re going to have that ownership, but you\u0026rsquo;re going to have people around to learn from. Working at a really scrappy startup with a couple of friends from undergrad, hey, it could be ton of fun. You\u0026rsquo;ll learn a lot. But there is benefit oftentimes to being in an organization with some more experienced people that you can learn from. Not everything has to be discovered from first principles. Sometimes you can just absorb things organically by being around the right people.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, absolutely. One of the things I definitely want to get to is talking about the S3 project. I think any listener to the show, their ears are kind of going to perk up. That\u0026rsquo;s catnip, right? That\u0026rsquo;s the crazy kind of cross organization project that everyone wants to hear about. Before I dig into that, I guess I need to ask you, are there any other projects that you sort of wish you could talk about besides that one? Like, what are some of the other things that you\u0026rsquo;ve worked on that you think would be interesting to talk about?\u003c/p\u003e\n\u003cp\u003eJames: Yeah, there\u0026rsquo;s plenty and there\u0026rsquo;s plenty I can talk about that maybe are more controversial and maybe less unequivocally successful. Right. And so during my tenure at Dropbox, I worked on a lot of systems. I mean the big ones is the call out was this project called Magic Pocket, which was the building, the storage system there. We rewrote the SYNC protocol on the server side, we built new distributed databases and et cetera. And at one point I was the technical lead for persistent systems. So that was anything involving caching databases, multi homing data centers, that kind of stuff. Big data. Maybe one thing we can talk about is just coming onto teams where the culture maybe isn\u0026rsquo;t quite Good. Or things just aren\u0026rsquo;t working quite right and trying to figure out why that\u0026rsquo;s the case and then try and turn them around at a certain point at Dropbox, you know, my life was a little bit painful where, like, my job was kind of getting thrown into. Thrown into situations where things maybe weren\u0026rsquo;t going so well and I had to go and join a team and maybe help turn the team around a little bit, sometimes successfully, sometimes. You know, I think we always, always went pretty well in the end. But there\u0026rsquo;s oftentimes a lot more learning experiences from the stuff that doesn\u0026rsquo;t seem so smooth and glamorous in theory.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. I mean, so I\u0026rsquo;d love to hear about that a little bit more like. And I think we\u0026rsquo;ll kind of circle back to all these points throughout because I think we still want to get to the S3 migration. But when you\u0026rsquo;re kind of asked to parachute into a team, it sounds like a lot of the times the challenges that you identified were not sort of technical challenges, but they were people challenges. Right. And I think that\u0026rsquo;s something that\u0026rsquo;s going to resonate with other folks. So how do you approach that? What\u0026rsquo;s the playbook?\u003c/p\u003e\n\u003cp\u003eJames: Yeah, so I would say there\u0026rsquo;s two major. It\u0026rsquo;s such a huge topic. Right. But I\u0026rsquo;m going to say this. There\u0026rsquo;s two major things that I would call out common dysfunctions in a team. One is a lack of alignment around a clear strategy and lack of values. Alignment, I\u0026rsquo;d say. And one is just, I would say, improperly scoped, incremental deliverables for the team, where, you know, oftentimes people think that, hey, we built this giant distributed storage system, we just sat down one day with a napkin and drew the whole thing out and then just built it. Right. Rather than the fact that it was all scoped out into these little stepping stones along the way and delivered incremental value. So I\u0026rsquo;ll talk about the former first, the culture and values and alignment. So oftentimes people will voice these frustrations of, oh, that other team doesn\u0026rsquo;t care, or that other team doesn\u0026rsquo;t listen to me, or, you know, and I find it extremely implausible in most scenarios that engineers at a tech company who are working really hard don\u0026rsquo;t care or they\u0026rsquo;re not trying hard enough. Generally it\u0026rsquo;s the misalignment. And I\u0026rsquo;ll give you an example here, and I\u0026rsquo;ll try to sanitize this example, but I went and joined the metadata team at Dropbox. So basically the Distributed database team. At that point in time, the team was split between Seattle and San Francisco. And I think probably no one on the team would be bothered if I said that, you know, there was some tension between those two teams and the teams just didn\u0026rsquo;t seem to really click. And they either thought the other team didn\u0026rsquo;t care enough or, you know, didn\u0026rsquo;t listen. And there wasn\u0026rsquo;t a lot of productive work getting done across team because there was this kind of gulf in culturally between them. And the first step, I mean, in any senior engineer, when you try to get into problem solving is start with introspection and the why, like, try to figure out what\u0026rsquo;s going on before you try to fix it. And I spent a lot of time chatting with engineers there about, hey, what is the problem? And when you start asking around. Eventually we found out that one team thought the most pressing issue was the usability of the system, that it was not convenient to use, that it was didn\u0026rsquo;t have the right feature set, and as a result, it was slowing down product development at the company. And the other team felt the biggest pressing issue was that whether the system was going to scale and whether it was going to get too expensive and whether we were going to run out of space and all that kind of stuff. Stuff, existential infrastructure stuff. And when these two teams were not aligned on the why, the why we should do things, every other issue became a conflict. They never talked about this with each other. They were never like, hey, we think the biggest problem is the usability. We think the biggest problem is scalability. That was just taken as a given. And then they\u0026rsquo;ll have arguments about what the next thing is that has to get done. So the first task was just, let\u0026rsquo;s define for the team what matters right now. And ultimately what we had to say was, you know, in the short term, we\u0026rsquo;re going to neglect clients and we\u0026rsquo;re just going to get the scalability stuff sorted out, and then we\u0026rsquo;re going to have a definitive this is what matters to the team. These values exercises is something that can either go really well or really poorly, depending on how sincerely you take the process. I really, really hate value statements that say things like we care about correctness and performance and being nice to each other and just saying a whole bunch of virtues. A value statement that has a whole list of virtues is easy to come up with. It\u0026rsquo;s completely meaningless because it\u0026rsquo;s not actionable. The best value statements I\u0026rsquo;ve seen is stuff like, we care about like this when we build the Storage system. We had a set of values and they were. We care about correctness and not having data loss ever. So much so that we will push back on feature development and we will not build a feature if we think it might compromise correctness. Or any value where the opposite of the value would also be a legitimate viewpoint is a useful value. We care about, the teams might say, hey, we care about agility and we are going to move fast and we\u0026rsquo;re going to experiment. And as a result, we are accepting that we\u0026rsquo;re going to make some mistakes. That\u0026rsquo;s the value, right? You can\u0026rsquo;t just hack a bunch of virtues on. So, you know, getting teams together and talking about what the, you know, the values have to come from some kind of why statement. Why does this team exist? So, you know, once that why statement, why do we exist? Well, you know, we have to do whatever we have to solve this problem. Okay, what do we value? And once everyone\u0026rsquo;s aligned on the values, the conflicts you have tend to turn into what you call task conflicts. I think we should do it this way. You think we should do it that way. We debate it. No big deal. Engineering is all about arguments. But if the value alignment isn\u0026rsquo;t there, they become relationship conflicts. You want to do this, I want to do that. That\u0026rsquo;s because you don\u0026rsquo;t care or you\u0026rsquo;re not listening. So when people are not values aligned, when you haven\u0026rsquo;t got the why and the values sorted out, the what and the how just don\u0026rsquo;t follow. And because engineers were oftentimes so logical and so caught up in the building, you don\u0026rsquo;t take that step back to ask the why. And everyone\u0026rsquo;s debating the how without taking that step back. I had the. I guess I wouldn\u0026rsquo;t say, you know, definitely not privileged, but I had the burden a few times to kill some big projects at Dropbox. And these are projects that, you know, thousands of engineers had worked on for years. And one of the big ones that we ended up rescuing and turning around was a project that a lot of really talented engineers were working on, but just didn\u0026rsquo;t seem to be going anywhere. And I was looking at the project and thinking, you know what? I just don\u0026rsquo;t think this is going to succeed. And when I went around to the engineers on the team and I met them individually and some of these were my favorite people at the company, and I said, hey, why are you building this thing? And they say, oh, well, you know, the VP asked us to or something. Oh, that\u0026rsquo;s what the Sprint goals say. Et Cetera, right? And everyone individually was going and building this thing that when you ask the them to justify the why, no one could really justify the why. When we put everyone together, no one, apart from saying, oh, we\u0026rsquo;re doing it because the VP said we should, could justify why we were building this system. I went to the VP and chatted about this and he didn\u0026rsquo;t want them to do this thing that didn\u0026rsquo;t make any sense. So ultimately we ended up killing that project and replacing it with something that worked. There was a success story in the end, but these are situations where it\u0026rsquo;s so easy to get caught up in the status quo. It\u0026rsquo;s so easy just to do what happened yesterday. And I know I\u0026rsquo;m rambling a bit here, but it\u0026rsquo;s so easy to take your Sprint plans and think they\u0026rsquo;re the gospel and you take whatever was happening last month and make it happen this month and not step back and say, hey, what the hell are we even here? What is the point of this team? Are we doing a useful thing? Right? And anytime I see a manager like overly celebrating how many green checkpoints they have in their Sprint goals, I think this is not like necessarily senior leadership material. Right? That\u0026rsquo;s a very harsh thing to say. But you have to celebrate the value you create and incremental value too, right? Obviously, like if you have a big project, it takes a long time to deliver the end customer value, but celebrating just getting tasks done is not at all aligned with value. And I\u0026rsquo;m going to give you one more story here as I\u0026rsquo;m in storytelling mode. The original question before I went on a giant tangent here was what is something to watch out for to get teams aligned around actually turning a team around, getting value. So this is a self serving story, but we built this storage system, it was called Magic Pocket and that\u0026rsquo;s the silly code name for the storage system that we should have changed but we didn\u0026rsquo;t. Eventually once the system was up and running and working, I was like, hey guys, we have to go and change our team. Now we\u0026rsquo;re called the Storage team. And those decisions are actually really annoying to execute on because we have to go rename all these directories and mailing lists and Slack channel. I think it might be hip chat back then, you know, all these channels and everyone, oh my God, this is the terrible idea. James is being Mr. Manager again. It\u0026rsquo;s completely unimportant what the team is called. And my argument to the team at the time was that if there is a point in future where it doesn\u0026rsquo;t make sense for us to run our own storage system if economies of scale no longer work out, if no longer we have the competency to do so. If Google comes out with this really cheap storage system somehow that for some reason we couldn\u0026rsquo;t compete with, unlikely because our system was really quite efficient. And this team right here aren\u0026rsquo;t the first people in the company put up their hand and say, hey everyone, we\u0026rsquo;re moving back to this system. They\u0026rsquo;ve failed as a team, right? This is a team of the storage experts. And if their priority at the company is the continued success of the system they built, they\u0026rsquo;ve failed in their job as being the storage experts at the company, Right? Their job is to decide the best way to store data for Dropbox. And so it\u0026rsquo;s very important that the team mission is aligned around a task or a problem that has to be solved for the organization and not a system, not a sports team. And I would see this happen with teams called, like the Kafka Team. I think at one point we had this Chef versus Puppet debate and people were like, you know, like, if your priority is like managing Chef, it\u0026rsquo;s existential question for you whether or not we move to Puppet or Puppet, it was vice versa. If your priority is configuration management, no problems, right? You just pick the best tool for the job. So there\u0026rsquo;s a lot of this kind of theme here around this kind of, you know, hand, wavy managerial feeling can feel like bullshit, frankly, sometimes. If it\u0026rsquo;s not done right, you know, why does this team exist? What do we value? What matters to us? But if, if the senior engineers or the staff engineers or the tech lead or the manager don\u0026rsquo;t sort this thing out, the team will not succeed. They\u0026rsquo;ll get something done, but it won\u0026rsquo;t be the thing that you need to get done to begin with.\u003c/p\u003e\n\u003cp\u003eDavid: What\u0026rsquo;s the process for it? Because, you know, you hear people talk about value statements and mission statements and things like that, and most of the time it is bullshit, right? Like, and sometimes it\u0026rsquo;s not. But I guess what I\u0026rsquo;m trying to understand is how tactically did you approach that in the teams that you worked with in order to get around from sort of the vague or useless value statements or the ones that contain a list of virtues to ones that are actually actionable?\u003c/p\u003e\n\u003cp\u003eJames: I mean, I\u0026rsquo;ve gone through the exercise and written these things down on a piece of paper, right? It never feels great. It always feels like you\u0026rsquo;re doing some silly management exercise where you\u0026rsquo;re writing down these things.\u003c/p\u003e\n\u003cp\u003eDavid: Do you do that as a group with people or what\u0026rsquo;s the process?\u003c/p\u003e\n\u003cp\u003eJames: Oh, tactically, I think the first process is spend a lot of time talking in groups that what matters. Like before you get to value what are the problems we\u0026rsquo;re solving, what\u0026rsquo;s the point of this team? What matters? Let everyone have their say, right? Everyone\u0026rsquo;s going to have their own individual opinion at what matters, right? And it\u0026rsquo;s just so critical, it\u0026rsquo;s non negotiable that the team is aligned on what matters and like, you know what problem is getting solved. Because if people don\u0026rsquo;t agree that nothing else is going to follow, right? It\u0026rsquo;s absolutely non negotiable that everyone agrees. Should we build this system? Why are we building it? You know, how are we going to evaluate the quality of this system? Right? Does this need to get done really fast? Does it need to get done really correct? You know, how are we going to operate? So, you know, these things have to happen first. And personally, I mean this is not. I don\u0026rsquo;t have good tips on how to do this remotely. I am, you know, this is controversial right now. I\u0026rsquo;m more an in person, work person. That\u0026rsquo;s how I have worked remotely many times. But I prefer working in person. I prefer being around people. I\u0026rsquo;m sure there\u0026rsquo;s equivalence for remote work where you have these breakout sessions or video chat. I just think like these have to be very organic, very casual interactions where you just chatting like. And that\u0026rsquo;s why I don\u0026rsquo;t think you can have a single meeting where you\u0026rsquo;ll come in and write it and come out an hour later, right? It has to feel real. It has to be like developing a relationship, right? We\u0026rsquo;re developing an understanding understanding of what matters. Everyone has to say their thing and have to build shared empathy. Once we all agree on what has to happen, I think everything as follows. The other thing I\u0026rsquo;ll say other little catch is when doing planning, I always find it very helpful to first figure out what the problems are before we figure out how to fix them and especially before we figure out who does them, right? And oftentimes people go the other way around where you have a dri, the directly responsible individual for this feature. So if I make you the DRI for whatever, DRI for caching in whatever and we do sprint planning, you\u0026rsquo;re going to come up with 17 tasks around caching, right? Because that\u0026rsquo;s your job, right? That\u0026rsquo;s your fiefdom, right? It\u0026rsquo;s very important. Or if you\u0026rsquo;ve got too much to do, you might not come up with the tasks that have to get done because you\u0026rsquo;re thinking about your own time management. It\u0026rsquo;s very, very important. We start with what has to get done way before we get to who does it. So I don\u0026rsquo;t have a great tactical framework beyond that. Like, you have to talk to people, you have to be chatting. You have to, at lunch talking about, hey, what matters, et cetera, right? And then get down and write. Now, I hate the phrase North Star document or mission statement. And don\u0026rsquo;t be formal about it. I mean, you can if you want, right? But like, just, just make sure that we\u0026rsquo;ve written down somewhere, like, what is the team? What\u0026rsquo;s the point of the team? Everyone needs to know this, right? And then, you know, what I\u0026rsquo;ve done is you do these kind of all hands meetings with your team. If you had teams that end up being a couple hundred engineers, when they all kind of layer in, and it can be hard in those large groups because you\u0026rsquo;re not in one room, you have an all hands meeting and talk through the strategy, it generally doesn\u0026rsquo;t land right. You\u0026rsquo;ll say the strategy 17 times and then you\u0026rsquo;ve got to go and speak to people individually and see these ideas. The nice thing is, once you\u0026rsquo;ve done this work, culture is viral. And I call this stuff culture, like the team culture. Yes, team culture is about how you interact and stuff, but there\u0026rsquo;s also a team culture and how you develop code. Team culture, how you think about manually responding to operations versus building systems to handle it. I\u0026rsquo;ll give an example where I always realized that culture was really powerful when it came back to bite me. I remember once, early in development of the storage system, we had a lot of very strong culture around not being cavalier, not pushing code to production after it\u0026rsquo;s gone through this extended release process and being in a staging cluster, et cetera. I remember authorizing at one point this hotfix. We had to push this hotfix out and we ran the test locally. I knew the code was safe. I had looked at it, instead manufactured it and we pushed it to, to production. And our head SRE at the time, guys, Scott McViggin, who\u0026rsquo;s awesome, all he said to me was, that\u0026rsquo;s not cool, man. He said just like that. And I felt like shattered. Like. He didn\u0026rsquo;t yell, he didn\u0026rsquo;t like berate me. He just said, that\u0026rsquo;s not cool, man. And I just knew in that moment that like, I had violated the team\u0026rsquo;s culture, right? I had done something that was antithetical to how we do things on the team. So once these things are in place, they\u0026rsquo;re very powerful and they\u0026rsquo;re self sustaining because everyone around agrees with them. But yes, practically it\u0026rsquo;s hard. Take the time to talk, to interact, write it down and to solidify it. Every time you have a planning meeting, whether you do monthly planning or bi weekly or whatever, the first thing you should do in the meeting is like, hey, let\u0026rsquo;s recap. What\u0026rsquo;s the point of this team? What are the big problems facing us? I wouldn\u0026rsquo;t necessarily go through the values and let\u0026rsquo;s use this as a basis for what we\u0026rsquo;re going to do rather than let\u0026rsquo;s start with a big basket of tasks and see which ones we finished last month and which ones we didn\u0026rsquo;t and we can keep doing them. Always start with what\u0026rsquo;s the point of this team now? What should we do?\u003c/p\u003e\n\u003cp\u003eAlex: So I feel like there\u0026rsquo;s a lot we could keep talking about this specifically this sort of team building stuff. And I think that\u0026rsquo;s incredibly valuable point of discussion that I think we all love to dig into. But if I can oversimplify, I feel like we\u0026rsquo;ve sort of been talking about sort of like how you get team alignment. You know, maybe a senior or staff engineer\u0026rsquo;s role is in team alignment. I\u0026rsquo;m curious to sort of like maybe turn our direction a little bit in another direction. So how do we gain alignment as senior engineers with our organization? I think maybe the Magic Pocket is a really interesting example because there was a huge, as far as I could tell from the outside, that was a huge commitment of capital.\u003c/p\u003e\n\u003cp\u003eJames: It was.\u003c/p\u003e\n\u003cp\u003eAlex: I can\u0026rsquo;t even imagine, I can imagine some of the stakeholders in there. But I think for senior staff engineers, what is the role of a staff engineer in a project like that? How do you know that you\u0026rsquo;re working to further your organization goals?\u003c/p\u003e\n\u003cp\u003eJames: You know. Yeah. So Dropbox had this levels guide internally, which I think was great. I wonder if we could share it. I\u0026rsquo;ll see if we can share it out. But basically as you grow in seniority, the scope of your influence, you know, gets from like team to. Or, you know, eventually it\u0026rsquo;s the company and eventually your responsibility is to the company. I wish that was for every one of the company. But you know, when you\u0026rsquo;re junior it\u0026rsquo;s too much to think about. Right. But when you\u0026rsquo;re senior, your priority is not to your team anymore. Right? Your priorities to the organization. And if your team is not aligned with the organization, then you\u0026rsquo;re doing the wrong thing. And so the very first step is to understand your priority is to the organization, right? If someone else in the organization who is at a senior as you or more senior doesn\u0026rsquo;t agree with you, then you should be priority aligned, right? So then maybe there\u0026rsquo;s an information gap here, right? If someone says, hey, this product\u0026rsquo;s too high risk, and I\u0026rsquo;m thinking, well, no, it\u0026rsquo;s not right. Maybe I\u0026rsquo;m not thinking very careful about their priorities right now. The reality is I completely understand where they\u0026rsquo;re coming from, right? Yeah, it is high risk. So then you go start saying, cool, how can I architect this product in a way that brings confidence to the organization? And so what I\u0026rsquo;ve seen not work is engineers say, well, just trust us, we\u0026rsquo;re talented, we have a good track record. We\u0026rsquo;re just going to do some stuff for two years and then come back and just, you know, that\u0026rsquo;s asking a senior lead to like, you know, maybe make an existential company risking bet on a bunch of folks in the organization, right? Then yes, you have a good reputation, but maybe you\u0026rsquo;re going to fall through, right? And so I think it\u0026rsquo;s important to understand, you know, the CEO or the CTO or the SVP aren\u0026rsquo;t unreasonable people, right? They just have priorities that maybe you haven\u0026rsquo;t considered, right? Like to the shareholders, et cetera, right? So the first step is scoping the product in a way that does not risk the organization. And so I have this blog post, it\u0026rsquo;s a cheesy buzzword I made up, but it\u0026rsquo;s called Stepping stones, not milestones. And you can just search on medium for stepping stones, not milestones or search for my name. And it talks about how to break a product out into these stepping stones where each stepping stone. So the distinction I\u0026rsquo;ll make is a milestone is an sometimes you go into these projects and we\u0026rsquo;re going to do this giant two year project and the milestones are called M1, M2, A, B and C and M3 and this meaningless thing and achieves very little other than giving us some checkpoints. But how I would characterize a stepping stone is we have a giant, intimidating, open ended problem to solve the world\u0026rsquo;s most efficient distributed storage system and not lose our user starter. That\u0026rsquo;s too hard for anyone to do. And by the way, most of the system was built with a handful of engineers and I mean literally a handful. And so first step, well, let\u0026rsquo;s build something that we can understand, right? Let\u0026rsquo;s build a very cheap system that does like very simple replication. Right. Once we get to that point, the scope of future possibilities is narrow because now we understand the system better. Right now we have a deliverable that actually has value. Right. So scoping this program for these stepping stones, where each stepping stone brings some individual company value, right. Is understandable, has a clear deliverable and also allows us to scope uncertainty going forwards can really help in product execution. So I\u0026rsquo;m not going to go and say, hey, in two years time we\u0026rsquo;ll come back with the story system talk about, here\u0026rsquo;s the things we\u0026rsquo;re going to build and here\u0026rsquo;s how we\u0026rsquo;re going to make a decision whether this is a good idea as we proceed. Right? So we\u0026rsquo;re going to build this system first and it\u0026rsquo;s going to be not cost efficient, Right. But it\u0026rsquo;s going to be correct. For example, now this wasn\u0026rsquo;t the first stepping stone. This was like 75 stepping stones down, right. You know, maybe seven stepping stones down. At that point, the risk the company\u0026rsquo;s taking is much lower. Right now the risk is a profitability risk. Right. It\u0026rsquo;s not an existential risk. Right. You know, and here\u0026rsquo;s a stepping stone where we\u0026rsquo;re going to build this and here\u0026rsquo;s how we\u0026rsquo;re going to evaluate correctness. Right. And in a. One of the biggest kind of stepping stones or milestones in the Magic Pocket project was what we call the Dark launch, right. Where basically we built this system, we stored, I think 10% of all user data on it. And we saw that 10% on Magic Pocket and also on S3. And we ran the system for six months. And the contract we had with your. And we actually wrote a contract, which is very silly, but we wrote this kind of document and Drew and Arash, the co founders, kind of signed it. It was mostly a fun thing, but it was to also to prevent us moving the goalposts. Our commitment was we have to prove that we can run this system in production mode with no outages, no issues. Now, we knew that if the system failed, we could fall back to S3 and Dropbox would continue as an organization, but we would have failed the project. So we scoped out these kind of deliverables, right? Where at any point in time there was an ability to de risk the project. Now you have to take risks to achieve great things. And there was certainly risks in the project. But, you know, the product scoping was designed such that it\u0026rsquo;s speaking in the language of senior leadership, because you should be doing so too. It\u0026rsquo;s not like oh. What I really want to do is sit down and spend two years coding and then deliver it. But I\u0026rsquo;m going to pretend to have incremental deliverables to keep the CEO happy. Right. No, the CEO\u0026rsquo;s language is the correct language. There\u0026rsquo;s the correct language of how do we not destroy this company while we\u0026rsquo;re trying to do this big project. Right. So scoping it accordingly. I\u0026rsquo;ve always found that I\u0026rsquo;ve never run into irrational, unreasonable leadership. Once there\u0026rsquo;s empathy, once there\u0026rsquo;s education. Oftentimes you disagree. But that\u0026rsquo;s probably an example that you haven\u0026rsquo;t de risked the product enough. And I don\u0026rsquo;t mean de risk entirely, because if you de risk too much, you won\u0026rsquo;t get anything done. Right. It\u0026rsquo;s not about being conservative, but it\u0026rsquo;s about being wise.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. I know that you do a lot of work with. I\u0026rsquo;m totally changing tracks here.\u003c/p\u003e\n\u003cp\u003eJames: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: You do a lot of work with sponsoring and mentoring. And I\u0026rsquo;m curious, you know, one, what do you think the value of that is for a staff engineer? And I\u0026rsquo;m curious, do you have sort of an approach that you take to it?\u003c/p\u003e\n\u003cp\u003eJames: Yeah. Yeah. So, yeah, I\u0026rsquo;m going to answer the question insofar I think it\u0026rsquo;s obvious what the value is to the mentee. Right. It\u0026rsquo;s good to be mentored by someone because you learn some stuff from an experienced person. I\u0026rsquo;ll talk about the value to the mentor and also the value to the organization. Firstly, as you get more senior, you evaluate yourself based on the impact to the organization and what you have to wrap your head around. At some point, that can be hard to do. Your impact to the organization is not just your lines of code written or the things you build. It\u0026rsquo;s that you ask yourself the question, you know, over the past two years, if I was here versus if I wasn\u0026rsquo;t here, or if I was here versus someone else was here, what was the difference to the organization? Right. What value did my physical presence bring to the organization? And when you ask them that question, oftentimes the best thing you can do is level up the teams that you\u0026rsquo;re working with. The best thing you can do is develop the people around you because probably they\u0026rsquo;re faster, more agile than you anyway. In my case, they almost always better building stuff faster than me. I\u0026rsquo;m getting real slow at the coding. But also that\u0026rsquo;s how then they become and they mentor. So I think every senior engineer or most seniors have a responsibility to develop the people around them. That\u0026rsquo;s how you create a great ecosystem. Right. It\u0026rsquo;s like, I don\u0026rsquo;t know, it\u0026rsquo;s kind of like you have kids and raising them well. You know, like, it\u0026rsquo;s. If you\u0026rsquo;re a senior person and you mentor junior people, then they become senior people and then they mentor junior people. So it\u0026rsquo;s just good for the universe to do. Now, is it also good from a selfish perspective? I would say also, yes. Right. So I give some talks every now and then about technical leadership, and a lot of those ideas come from having to introspect and articulate things to engineers very explicitly in mentorship context. So actually meeting with someone, listening to their problems, giving some feedback on how they might solve those problems, really forces you to analyze your own perspectives on this stuff. Because, I mean, the number one skill you can have as a senior engineer is introspection. As a slight tangent here, but if I have an engineer in my team who has really good taste and really good introspection and they have values, alignment with me, I\u0026rsquo;m pretty confident they\u0026rsquo;re going to do good work. Because either they\u0026rsquo;re going to do good work by themselves or they\u0026rsquo;re going to screw up, but they\u0026rsquo;re going to realize it because they have introspection and they\u0026rsquo;re going to ask for help or, you know, if you have the introspection, you\u0026rsquo;ll be fine. So I find mentorship is a great tool to develop introspection when you have to actually, you have all these big jumble of ideas in your head. You have to articulate to people. You know, hey, maybe you should think about this. And I\u0026rsquo;ve had to do. There\u0026rsquo;s so many areas we\u0026rsquo;ve got to give advice to folks. You know, oftentimes it\u0026rsquo;s about leverage. Oftentimes it\u0026rsquo;s about, you know, you\u0026rsquo;re mentoring a tech lead and they\u0026rsquo;ll be just drowning in work and they\u0026rsquo;ll be saying, hey, the rest of my team isn\u0026rsquo;t doing the same amount of work as I am, and I\u0026rsquo;m getting stressed and everyone\u0026rsquo;s freaking out, and you have to say, okay, let\u0026rsquo;s stop for a second. Right? Why are you doing this work? Right. Don\u0026rsquo;t do that work. Right. Why is the rest of the team not pulling their weight? Well, it\u0026rsquo;s probably because you don\u0026rsquo;t have a very clear strategy. It\u0026rsquo;s probably because you don\u0026rsquo;t have very clear direction. Right. Your job is to do that stuff. If you don\u0026rsquo;t do it, no one will do it. So having these discussions, I felt, really helped hone my Perspective on leadership and being a senior engineer. Now, one thing I\u0026rsquo;ll say is there\u0026rsquo;s good people to mentor and there\u0026rsquo;s bad people to mentor. Right. Frankly.\u003c/p\u003e\n\u003cp\u003eDavid: Right.\u003c/p\u003e\n\u003cp\u003eJames: And the good people mentor the people who give a shit. Right. Anyone who really wants to put the effort in, you know, actually prepares for meetings. I love that. When people would come in and say, hey, I\u0026rsquo;ve been thinking about. We talked about last week. I\u0026rsquo;m having this problem. Let\u0026rsquo;s talk about how that. How that\u0026rsquo;s gone great. People who want to sit there and listen and just get, like a free education. That\u0026rsquo;s not mentorship, right? That\u0026rsquo;s just like listening to a talk. But, yeah, I mean, generally, you know, I\u0026rsquo;ve been involved in formal mentor programs where, you know, people sign up to get mentored. Most of the time, though, you know, it\u0026rsquo;s informal mentorship. It\u0026rsquo;s just finding. Looking around in an organization, that was the thing that brought me the most job satisfaction. You know, looking around the company and seeing the people who just, like, seem amazing, but they\u0026rsquo;re junior, but they just really give a shit. And, like, they really stand out and say, I want to work with that person. Go spend some time with them, help them develop. I guess I can take credit. I mean, two of my favorite people in this category I work with right now, one of my co founders, I started working with him when he was 20 and just started at Dropbox, and he became a very, very senior engineer. He became a principal engineer at the company. Incredible engineer. This is Sujay, my co founder. But, yeah, we worked together very closely when he was very junior. And our first hire, Braden, who\u0026rsquo;s off the charts talented infrastructure engineer. Similarly, these are folks I\u0026rsquo;ve had the real fortune of working with when they were junior and then seeing them turn to senior engineers, that\u0026rsquo;s the most satisfying part of the job. So, yeah, look, it\u0026rsquo;s, you know, it\u0026rsquo;s good for the universe because it increases the quality of talent in the industry. You know, it\u0026rsquo;s good for you personally because it helps you hone your skills, it\u0026rsquo;s good for your career progression, and it\u0026rsquo;s good for the organization because it gives you leverage. But it\u0026rsquo;s also, you know, it\u0026rsquo;s good for the soul. You know, it\u0026rsquo;s fun to work with talented people who care.\u003c/p\u003e\n\u003cp\u003eDavid: That resonates. I think your approach in general is going to be pretty interesting to a lot of listeners. We\u0026rsquo;re coming up on time, and I wish we weren\u0026rsquo;t. We could talk for hours. But there\u0026rsquo;s two questions that we try to ask everybody. One of them is kind of following the thread of mentorship. If you were to give advice to somebody who is coming up in their career and who wanted to sort of learn how to be a better engineer, and especially sort of in the areas where staff plus engineering differs from, you know, what they may have experienced before that in their careers, what are the resources or the blog posts or the people or the podcast or whatever that you would point them toward in terms of sort of areas where they can learn more about this stuff?\u003c/p\u003e\n\u003cp\u003eJames: Yeah. The first thing I\u0026rsquo;ll say to folks like that is the first thing to do is hone your craft. The first thing you do is get good at being a software engineer, get good at building stuff, because you don\u0026rsquo;t want to jump too quick into this leadership business before you have the skills to back that up. And there\u0026rsquo;s plenty of resources for that, but obviously there\u0026rsquo;s tons of blogs out there and distributed systems and stuff. The best way of getting good at building stuff is working on the best team in the organization. You know, I\u0026rsquo;ve had people say, james, I\u0026rsquo;m picking between two teams. One is doing really exciting work, but I\u0026rsquo;ll be junior on the team, so I\u0026rsquo;m not sure if I\u0026rsquo;ll look so good. And one is really boring, but I\u0026rsquo;ll be the senior person. I think I should do the second one. That is crazy. Go work on the coolest, most exciting thing with the best people. Right. And make sure when you\u0026rsquo;re doing anything, understand the why. Right. That\u0026rsquo;s the best advice I can give to a junior person. Right. If you\u0026rsquo;re not yet in the strategy setting phase of your career, understand why you\u0026rsquo;re doing stuff. Why do they do it that way? Why is that system designed where you\u0026rsquo;ll learn so much by doing that more than any blog you read? So the first thing is to hone your craft. And the best way of doing that is on the job and working with best people. Just find the best people you can find and be near them and watch how they work. The second thing I\u0026rsquo;ll say when you start to transition from, say, Senior Engineer to Staff/ engineer is understanding that the nature of the role changes. It\u0026rsquo;s far more about leverage. It\u0026rsquo;s far more about how can you empower other people to do stuff. It\u0026rsquo;s somewhere about how you can convince people of things and far more about how you can make high quality decisions by understanding perspectives of others. And this involves skills that we don\u0026rsquo;t necessarily naturally learn as software engineers. Right. These not the math and science skills, these are the touchy feely human being skills around communication and introspection. So personally, many people are going to disagree with me, but I think if you want to become really good at that, developing your eq, developing your understanding of others, right? Never saying the phrase that team\u0026rsquo;s an idiot or that person doesn\u0026rsquo;t care, then the time to understand why they\u0026rsquo;re thinking, hey, hey, if you want to do some reading, read about some psychology, read about how human beings work. This stuff is valuable. Understanding people is really, really valuable. Because we messy organisms, we\u0026rsquo;re human with emotions. And I\u0026rsquo;ve seen orders of magnitude difference in output of teams between teams that are happy and excited and rallying around a cause and teams that are drifting and lost. We\u0026rsquo;re not robots, we\u0026rsquo;re human beings. And spending time to understand motivation, understand how people\u0026rsquo;s, how people think. That\u0026rsquo;s what I think distinguishes the very impactful people in an organization.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. That\u0026rsquo;s a great rundown. So we have our last question here. Kind of tongue in cheek. How much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eJames: Oh, like a lot. I\u0026rsquo;m so glad you asked me this right now because if you asked me any time in the past two years, I would have said effectively zero. But now I have a startup, so I spend 80% of my time coding probably. And I\u0026rsquo;m warming up again. You know, I got rusty. I got rusty. And so I\u0026rsquo;m writing a lot of Rust code and writing some typescript now. And it\u0026rsquo;s fun. And look, one thing I\u0026rsquo;ll add is that like, yes, it\u0026rsquo;s good to get promoted, it\u0026rsquo;s good to get senior, all that stuff. The most important thing to you, everyone who\u0026rsquo;s a software engineer is probably getting paid just fine. The most important thing is that you enjoy your job, right? So find the stuff that you enjoy and do it right. If you really enjoy just building stuff, then just keep building stuff. It\u0026rsquo;s great. Now figure out ways to build things in more leverage, impactful ways, right? But I\u0026rsquo;ve seen a number of times people go into management and hate it because they got into this career because they\u0026rsquo;re a builder. Turns out I quite like the management stuff too. So I go back and forth and I\u0026rsquo;m just fine, right? But I\u0026rsquo;m enjoying the coding. There\u0026rsquo;s a reason we got into this industry is probably because we liked actually building systems and creating stuff. So yeah, I\u0026rsquo;m enjoying kind of getting back to the craft, as rusty as I am.\u003c/p\u003e\n\u003cp\u003eDavid: Well, that sounds great. I\u0026rsquo;m glad you\u0026rsquo;re having fun. And, you know, best of luck with the startup. Thanks so much again for taking the time to chat with us today. It\u0026rsquo;s really, really been fun getting to hear about your experience.\u003c/p\u003e\n\u003cp\u003eJames: No problems, guys. Yeah, like I said, I have a startup now where four people full timers, so it\u0026rsquo;s very small. All of US have built 6 million query per second systems and 3 exabyte systems and stuff. So come work with us at the end. We\u0026rsquo;re looking for really good folks and we\u0026rsquo;ll get a link posted up with the podcast where you can get in touch. So if you want to work on something scrappy and fun, but also, you know, based on good principles, come join us.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. Thanks, James. That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website Podcast Podcast staffenge. Com. The website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-11-30T09:00:00-06:00","date_modified":"2021-11-30T09:00:00-06:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/bryan-berg-stripe/","url":"https://podcast.staffeng.com/season-1/bryan-berg-stripe/","title":"Bryan Berg (Stripe)","summary":"The role to me is really about ensuring that everyone around me is successful, to try to make sure that the work that we are doing is aligned with what the rest of the organization needs. And really just to be out in front of things to try to think six to 12 months ahead of where we're going and make sure that that work is going to line up with what the rest of the Org needs from us.","content_html":"\u003cp\u003eStaff engineers may not get much time to code anymore, but this does not mean problem-solving and system design is not an integral part of their day-to-day. Today’s guest is Bryan Berg, Staff Engineer at Stripe, and he joins us to talk about the nuances of his position and his unique approach to the many challenges it entails. As a Staff Engineer, Bryan acts as Tech Lead of the Traffic team, and we begin our conversation by hearing about how he landed in this role. Bryan describes the ambiguous challenges he faced during earlier days at Stripe, and the knack he had for finding and working on processes and systems that were previously underinvested in. We then jump forward to the present and dig into what Bryan’s current role entails, hearing him describe a wide range of tasks from reviewing documentation, communicating between teams, writing vision documents, and ensuring the work he directs falls into the company and stakeholder requirements. We also explore the interesting concept of when to draw on past experience versus keeping an open mind when facing new challenges. On top of all this, our conversation covers how Bryan judges the success of his work, sustains faith in his ideas, pitches to colleagues, debugs difficult pieces of code, and finds inspiration to be a great technical leader.\u003c/p\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9539874-bryan-berg-stripe.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Sure. Today\u0026rsquo;s guest is Bryan Berg. Bryan is a staff engineer at Stripe working on the Traffic team. He\u0026rsquo;s worked for Stripe for over seven years now. Before that he was a founder and CTO of App.net where I had the opportunity to work with him. I\u0026rsquo;ve learned a lot from Bryan, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Bryan, thank you so much for joining us. I obviously know a bit about you, as does Alex, but for the benefit of listeners, can you tell us who you are and what you do?\u003c/p\u003e\n\u003cp\u003eBryan: Yeah. Cool. My name is Bryan Berg. I\u0026rsquo;m a staff engineer at Stripe and I currently lead the tech lead on our Traefik team. Traathik owns the vast majority of ingress from Stripe\u0026rsquo;s customers to our API and other properties.\u003c/p\u003e\n\u003cp\u003eDavid: Got it. And what, how do you think of like the tech lead role or what does a tech lead role look like at Stripe, or what does a tech lead role look like for you, etc.\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, I have been asking myself that same question for a very long time. It\u0026rsquo;s something I\u0026rsquo;ve always struggled with, to be honest. I have found that I spend a reasonable amount of time just sort of trying to. Trying to organize us as a group. The role to me is really about ensuring that everyone around me is successful, to try to make sure that the work that we are doing is aligned with what the rest of the organization needs. And really just to be out in front of things to try to think six to 12 months ahead of where we\u0026rsquo;re going and make sure that that work is going to line up with what the rest of the Org needs from us.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. Just to give people some context, I actually worked for Bryan almost a decade ago now. A decade? Oh my goodness.\u003c/p\u003e\n\u003cp\u003eBryan: Was it really that long ago?\u003c/p\u003e\n\u003cp\u003eAlex: I think so. But in the previous role you were the cto and now you\u0026rsquo;re a staff engineer at Stripe. And I\u0026rsquo;m really curious, what did you learn as a CTO that you apply as a staff engineer or a tech Lead?\u003c/p\u003e\n\u003cp\u003eBryan: Oh, that\u0026rsquo;s a great question. I think I learned just so much as a CTO about what\u0026rsquo;s required to get things kind of started. Right. So what I think is really interesting about being kind of a small company founder, CTO type person is that you just have to create almost everything from scratch all the time. And that\u0026rsquo;s. It\u0026rsquo;s really substantially, I think, different than what you have to do as a staff engineer, as a tech lead type person, where really you\u0026rsquo;re sort of taking this set of things that you have and applying it to the set of problems that the folks around you are coming up with. I guess that in a way is also kind of similar to being a CTO as you grow a bit. But it\u0026rsquo;s interesting in that the challenges that I think we were running into back at the little startup that you and I worked at, Alex, were sort of substantially different than the things that I think about every day. But at the same time, the job of kind of rallying and figuring out how to sort of wake up every day and be inspired and try to do our best work are really similar. So. Sorry, that wasn\u0026rsquo;t a particularly articulate answer, but it\u0026rsquo;s in a lot of ways just a very different thing, but plenty of similarities.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, no worries. So when you joined Stripe, was there a staff engineering role at that time?\u003c/p\u003e\n\u003cp\u003eBryan: No, no. So Stripe was really pretty flat at the time. So when I joined, the way our organization was laid out was that we just kind of hired a bunch of engineers, kind of threw them into an office, had them kind of organize around things to do, but there wasn\u0026rsquo;t a sense of, we didn\u0026rsquo;t have levels or anything like that or roles. We had folks on the ENG team and a whole bunch of other amazing sort of other teams, but sort of your kind of an engineer or like, you know, in very, very small number of cases, manager. And everyone was just sort of expected to kind of fit in and slot into the roles they needed to be in at any given moment.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Do you, do you remember at all sort of like what spurred the creation of the staff engineering role and any sort of like conversations around what those expectations were?\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, that\u0026rsquo;s a good question. I don\u0026rsquo;t actually recall when, when I think we were coming up with this sort of idea. It was long after we had internally. We\u0026rsquo;d internally sort of defined levels and ladders for engineering. And at Stripe, levels are private, so we don\u0026rsquo;t sort of publish levels. And I think there was a desire to create some gradation, some very coarse Distinction between sort of folks who are newer in their career and folks that were a bit more tenured and create some, I think, recognition and distinction there. But I don\u0026rsquo;t think they\u0026rsquo;re. I don\u0026rsquo;t have a ton of the context. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s really interesting to hear. So from your perspective, what do you feel like a staff engineer does at Stripe? What are sort of like the common expectations for a staff engineer?\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, yeah, I think it\u0026rsquo;s a. That\u0026rsquo;s a good question. I think as you sort of find yourself in one of those roles, there\u0026rsquo;s a lot more coordination across teams. We sort of expect folks to be more proactive at seeking out other folks and sort of building more connections across organizations, across teams. We do have, you know, an expectation that folks will sort of be, you know, running projects, doing more project management, sort of doing more design type work as opposed to, as opposed to sort of spending all day, every day coding. There\u0026rsquo;s, you know, an expectation around, you know, code reviews, around design reviews, around sort of document reviews, that sort of thing. Stripe, we have a pretty extensive culture of writing written documents for many, many, many things. And the text editor that I spend the majority of my time in is the Google Docs editor or the Dropbox paper editor, depending on what day of the week it is. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: And do you feel like you have a particular spin on being a staff engineer at all?\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, that\u0026rsquo;s another good one. I don\u0026rsquo;t necessarily identify too much with being a staff engineer. I think my early time at Stripe was largely focused on finding things that I thought we were under invested in and going and just sort of trying to get them off the ground. Right. So I think the way I ended up sort of at Stripe as a staff engineer was that I just found a bunch of things that it really seemed like were going to be strategic for us or we needed to invest in and, and that we just weren\u0026rsquo;t putting enough energy into. Right. So Stripe was pretty sort of focused in its early days on thinking about product. We sort of were working on building infrastructure. We had a few, like I said, very coarse sort of like segments of the company who were working on a few different large problems. But then there were these like this big collection of small things that no one was kind of working on. So early in my time there, I noticed that there was like one engineer in the corner kind of who was like spinning up laptops for everyone. Every time we hired someone, it\u0026rsquo;s like, I think we\u0026rsquo;re going to like hire a lot of people soon. We should probably figure out how to scale that process. And so this was not a novel thing for me to figure out, but it was something like, you know, okay, you know, I think I can be helpful here, given some of my past experience trying to figure out how we can like, build ourselves like an IT team, a corporate engineering team, to sort of build some of these things and automate this a bit more. I kind of was the sort of security mole in the product organization. So I like, you know, spent most of my time hanging out with the folks on the infra teams, on the security team. And I kind of was like just keeping an eye on what was happening in the product world at the time. I got sort of, oddly enough, deeply involved in sort of setting up corporate security. I helped us sort of dig into some of the, sort of, some of the infrastructure challenges that we were facing that were not sort of the. In the purview of like the specific org that I was in. And, and as a result, I think I did the bare minimum set of things to get those, those organizations, those functional areas going and get some momentum and sort of get the organization to understand their importance. And then, you know, for the vast majority of those things, like, they just, you know, there\u0026rsquo;s a team around them now. But instead of that team starting from absolutely nothing, I tried to make sure we started from a little more. So, yeah, I think one of the things that I try to do as a staff engineer is to just go find the things that in six months we\u0026rsquo;re going to be worried about and try to get something in some of those areas or get some things started. And so that may be potentially a bit unconventional because it\u0026rsquo;s not, oh, we\u0026rsquo;re going to run out of capacity on a primary database instance somewhere or something like that. It\u0026rsquo;s like, hey, we\u0026rsquo;re going to need this as a function. And no one here has experience integrating our corporate directory with a badge system or something like that, so someone should go learn about that. I think I\u0026rsquo;m a super sort of voracious learner. One of the reasons why I\u0026rsquo;ve been managed to stay at Stripe for sort of this long, they haven\u0026rsquo;t managed to get rid of me is that I just love reading documentation. And I spent probably way too much of my time going through and reading those big, long, meaty documents that Stripe writes and digging in on things and digging in on partner documentation and digging in on the vagaries of badge systems, things like that. And so I was able to use that context and create connections across the Org.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool to hear. I remember from my experience working from you, one of the things that happened a lot is that from some various previous position to the one that we were working together, you\u0026rsquo;d be like, oh, I know this one because I did it here. And I\u0026rsquo;m curious, do you feel like, besides your voracious learning, that your varied experiences of doing networking really early on and then doing one of the very early consumer music startups and then what we were working on really sort of gave you that understanding that you can then apply experientially.\u003c/p\u003e\n\u003cp\u003eBryan: So I think I had a set of skills and experience that were a little bit rare at Stripe. So I think we had a lot of folks at the time who were quite experienced at the sort of set of products that Stripe was building that we had folks who sort of knew the financial industry and were digging into that. But when it came to sort of networks, I was able to kind of be an expert or be a person that folks would lean on. So I was, interestingly enough, kind of listening to Will\u0026rsquo;s episode of this podcast not too long ago, and he was talking a bit about how one of the things that happens is when senior folks sort of show up and like kind of over index on their past experiences in terms of like solving the problems of their new employer. And I found that to be like, just absolutely true. I sort of went into Stripe with a. Having learned a little bit about how I kind of over indexed on my learnings two companies ago at the, you know, company that you and I work together on. There are plenty of mistakes I made there and I, I kind of reflected on those. And I made this sort of conscious decision when joining Stripe to say, I\u0026rsquo;m going to kind of table a lot of my past experience and say, you know, I want to learn a lot from the way these folks are doing things because they\u0026rsquo;re. It\u0026rsquo;s so different from the way in which I had operated in the past and the things I knew. And so I was just like, I\u0026rsquo;m going to, I\u0026rsquo;m going to sort of purposefully kind of turn the, turn the humble up to like, you know, 100 and just go in and learn as much as I can from these folks and not show up and say, oh, ha ha ha, you know, you\u0026rsquo;re like using this terrible database, we need to change this immediately or, or whatever. And the interesting experience that I\u0026rsquo;ve had at Stripe as well on that sort of thing is that, you know, there\u0026rsquo;s been so much change in our infrastructure in our sort of company culture. And I now find myself sort of sometimes being almost too fixated on the way things used to be at Stripe as my, you know, where like, sometimes I\u0026rsquo;m like, ah, you know, we\u0026rsquo;re relearning a bunch of lessons that we learned in the past or what have you. And in general, that\u0026rsquo;s good. Right? Like, I think the organization sort of needs to sort of not be scarred by the things that happened even in our own sort of recent past. We need to sort of continue to try new things and try some of the same things because they may work now. But I think that one of the places that I\u0026rsquo;ve been able to really sort of offer things to the company has been in places that I\u0026rsquo;ve had relatively unique experience.\u003c/p\u003e\n\u003cp\u003eDavid: Do you have a heuristic for deciding between the moments where past experience is going to be a useful shortcut versus the times where a useful shortcut and can avoid reinventing the wheel versus the times where, like, reinventing the wheel is actually warranted because the roads have changed?\u003c/p\u003e\n\u003cp\u003eBryan: I think that it comes back to reevaluating some of the, like, invariants that your model is sort of built on top of. Right. I think that one of the places that I often find myself sort of thinking about this exact thing is when some dependent component has changed. And I\u0026rsquo;m not kind of tuned into that. Right. And so it\u0026rsquo;s not necessarily a heuristic, but it\u0026rsquo;s really. It\u0026rsquo;s in sense of a tactic. Right. Which is like, I really sometimes force myself to like, you know, stop, pause, and sort of act a little bit more slowly in some of these situations. Right. Like, so much of communication at Stripe sort of happens on slack, and there\u0026rsquo;s always sort of can be a tendency to sort of jump in and help people quickly. And one of the things that I\u0026rsquo;ve really found myself trying to do more of is to sort of really pause and use my initial reaction to certain sort of questions and things where it\u0026rsquo;s like, oh, this is. This is obviously wrong. If I have an initial reaction that something is like, sort of obviously incorrect, I\u0026rsquo;m usually like, okay, this is a good sign that it\u0026rsquo;s time for me to like, pause and really be like, okay, is something changed? Because this person that\u0026rsquo;s coming to ask this question is obviously incredibly smart individual. Like, I should probably go and think a little bit harder about this. And so that\u0026rsquo;s not answering your question precisely. Right. It really sort of depends on, like, you know, how. What are the consequences of getting this Kind of thing. Wrong. Right. So, you know, there, there are the systems that I tend to work in. There, there\u0026rsquo;s. There isn\u0026rsquo;t a ton of margin for error, let me say. Right. Like in that. That\u0026rsquo;s not to say there are a bunch of systemic faults, but it\u0026rsquo;s the kind of thing where if you\u0026rsquo;re sort of bumping up against sort of some massive change in the threat model for a system or something like that, you have to be really explicit about evaluating what is changing and how any assumptions that are built on top of that are going to change. And so when I sort of am thinking about, okay, should we kind of go down the path of really reevaluating this or should we not? It\u0026rsquo;s like how much load bearing stuff is built on top of this assertion or assumption. And usually that\u0026rsquo;s a good place to say.\u003c/p\u003e\n\u003cp\u003eDavid: So when a component supports a lot of load bearing stuff, does that add to or detract from sort of the impetus to reevaluate it from first principles rather than sort of defaulting to your priors?\u003c/p\u003e\n\u003cp\u003eBryan: In the case of a load bearing component, when there is just a lot of infrastructure built on top of something, it tends to be. People tend to have an opinion about the thing, right? Like, is this doing a good job, is this doing a bad job? Is it meeting the requirements of what we have? Is it not? And I think that there are a number of places where you can sort of decide to throw something away or rebuild it because it\u0026rsquo;s not interesting, or it could be built in a more sort of interesting way or could do some more stuff. But if it\u0026rsquo;s a relatively simple thing and it does its job reasonably well, and it\u0026rsquo;s sort of meeting the set of metrics and things that you need, then it may work. And so you have to sort of decide whether to graft a new bit of functionality onto this thing to either completely slot a new thing in its place and either migrate old stuff onto it, or say, okay, this is a net new application, we\u0026rsquo;re not going to migrate anything onto it. I think that it\u0026rsquo;s very situationally dependent. If it\u0026rsquo;s a thing that no one owns and no one thinks about and it does its job, but, you know, no one really understands it anymore, that that can be like a good opportunity to either investigate or build something new. But I think we sort of often tend to, you know, look at those components and decide to build a new thing just because it. No one understands it. And in a lot of cases, like things that are, that exist in that space of like, maybe they aren\u0026rsquo;t super well understood, but they\u0026rsquo;re kind of quietly doing their job well, you know, those things can last a long time. Yep.\u003c/p\u003e\n\u003cp\u003eDavid: I want to switch gears a little bit. So you mentioned you gave some examples earlier of like the type of work that you did, especially early on at Stripe, where like you were sort of looking ahead and finding sort of the things that needed to exist or like the examples you gave were kind of teams that needed to exist. Right. And I\u0026rsquo;m curious how that maps to your work today. Like, are you, is that still a big part of the work is like, okay, this whole area is understaffed. Let\u0026rsquo;s sort of like make a case for staffing it. And if so, is that primarily like within the Traffic Org or is that like throughout all of Stripe? And then also what are some examples of other work besides that? Like how are you engaging with specific projects that are happening inside the Org and things like that?\u003c/p\u003e\n\u003cp\u003eBryan: All right, so that\u0026rsquo;s a two parter. So as far as the way that that has shifted over time is that I think we think about it less in terms of teams these days and more in terms of whether the things that we have built are going to meet the needs of like our future selves. So when I, when I\u0026rsquo;m doing that sort of exercise of like looking into the future and trying to, you know, take a, take a, sort of, take an eye at the systems that we have built and whether they\u0026rsquo;re going to stand up to, you know, either changing requirements or sort of future regulatory or security standards, that sort of thing. It\u0026rsquo;s not necessarily about, you know, okay, we need to do this thing and we don\u0026rsquo;t have a team for it. We haven\u0026rsquo;t funded that. Instead it\u0026rsquo;s like, is there some aspect of this system that\u0026rsquo;s just not going to hold weight because there\u0026rsquo;s going to be a functional requirement change somewhere down the line. The interesting thing about engineering at Stripe is that there are so many different stakeholders in many of the things that we build, Right. There\u0026rsquo;s like what the product teams want to deliver, but then we also deal with so many different audits and compliance type sets of requirements. And that environment is changing just so much. And so what is interesting about that is that it\u0026rsquo;s really about requirements changing and sort of going and finding the things that we\u0026rsquo;re going to have to contemplate 12 months down the line, six months down the line, 10 months down the line, what have you, and making sure that like, you know, if we\u0026rsquo;re making trapdoor decisions today that we are really sort of thinking about those future cases. It\u0026rsquo;s hard to look too much further out. But you know, it\u0026rsquo;s always, it\u0026rsquo;s always easier if we have a good understanding of what\u0026rsquo;s coming to be able to kind of build some flexibility in early on. And the challenge is just figuring out how to build enough flexibility in without building something that doesn\u0026rsquo;t actually solve for any particular use case. I dig into it pretty deep in terms of the projects that our team is doing. I\u0026rsquo;ve always found it\u0026rsquo;s best to have sort of strong partnership with the EMS in our organization. I know personally that, that I just don\u0026rsquo;t enjoy solving em shaped problems, but I think that, you know, the most valuable partnerships that I\u0026rsquo;ve had have been sort of with you know, the ems that that sort of support the teams that I work with. And so usually what, what sort of happens is I, I spend a lot of time working sort of directly with either EMS or ICs but kind of use the sort of signals that EMS are sort of sharing on the ground as to this person needs a little bit of help with this thing or they\u0026rsquo;re not sure who to talk to or it doesn\u0026rsquo;t feel like they are confident in their design or they\u0026rsquo;re confident in sort of one aspect of this or like they really can\u0026rsquo;t figure something out. And so we\u0026rsquo;ll sort of engage directly in a lot of cases. I also sort of spend plenty of time reviewing design docs and project briefs and things like that and trying to give both constructive feedback. And I think that\u0026rsquo;s where that forward looking stuff shows up, right? Where like the way that that feedback tends to show up is I\u0026rsquo;ll just sort of be like okay, hey, have you contemplated this thing that I think is going to happen? And maybe here are a few folks you can go talk to about that. I try to give constructive feedback on those documents in that way and dig in and help folks be rigorous in thinking about what they\u0026rsquo;re doing. I tend to get involved quite a bit in incident response and follow ups to incidents to try to help folks figure out gaps in the way they\u0026rsquo;re thinking about remediating certain, certain aspects of incidents. That\u0026rsquo;s sort of all lateral and downward, right? Like a lot of that is, is how traffics projects are organized. But we have a lot of sort of partner organizations, we work with a lot of other folks and I think engaging with, you know, my peers across those other orgs is something I spend a lot of time Doing do like a lot of one on ones. Like probably an excessive number of one on ones, but I find them to be just super helpful. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m going to change gears a little bit. One of the things you talked about is that your early time at Stripe, you were looking at projects that you felt like were under invested in and then you chose to start investing in it. I\u0026rsquo;m curious, from then until now, when you choose to work on something, how do you know that the work that you\u0026rsquo;re doing is aligned with the organizational goals? We\u0026rsquo;ve talked a lot about this, but I think there\u0026rsquo;s a lot of nuance in once you\u0026rsquo;ve chosen what to do, how do you make sure that you\u0026rsquo;re doing the work that is most valuable for the organization?\u003c/p\u003e\n\u003cp\u003eBryan: Gosh, I wish I had a good answer to that question. I check in with my manager a lot on that and try to make sure that he is aware of what I\u0026rsquo;m doing and gut check most of that stuff with him and say, hey, does this seem like the right thing to be investing in? I tend to kind of, I jump around a lot and so maybe I just sort of hedge my bets there in terms of where I dig in, work on just like a lot of different things all the time. I think in general, a lot of it goes to having sort of a vision and an understanding of what I think we should be working on and trying to sort of check it against that, Which I could say it was more methodical and intentional than that, but I think I\u0026rsquo;ve sort of managed to establish a reasonable amount of trust within our org and sort of with our sort of partner orgs and kind of can drive things with a reasonable amount of agency.\u003c/p\u003e\n\u003cp\u003eAlex: There\u0026rsquo;s cool, is there, when you look back on the investments you\u0026rsquo;ve made, are there any signals that you use to be like, oh man, that was a great decision. Is there a consistent set of signals that you can index on to know that you\u0026rsquo;ve done something valuable in the past?\u003c/p\u003e\n\u003cp\u003eBryan: That\u0026rsquo;s a great question and a really tough one to answer. I think in retrospect, one thing that\u0026rsquo;s sort of part of Stripe\u0026rsquo;s culture tends to be kind of writing these shipped emails where we kind of send out a note after completing a project that kind of describes the work that went into the project and the results. When you can write a great shipped email, you sort of know that the project went reasonably well. Some folks take that to go write the shipped email ahead of time and use that. I think that\u0026rsquo;s a common Tactic is to sort of write the celebratory press before you actually complete the project because then you sort of know. Not sure I believe in that approach just because I feel like no plan survives contact with reality. And I think that sometimes the initial sort of exciting draft can get sort of ratcheted down when you like, find out all the constraints that you run up against and that sort of thing. But you know, in my mind, like, the best things that I think I have built have been things that have been enduring. So they\u0026rsquo;ve sort of stood the test of time, not necessarily without augmentation. Right. So we\u0026rsquo;ve, I\u0026rsquo;ve, you know, worked on plenty of things at stripe that have been, you know, the basis of new things that we have built. But I\u0026rsquo;ve also worked on a couple of things that have largely survived intact, for better or for worse, since I sort of last worked on them. So I think that when you are able to build something that stands or survives or isn\u0026rsquo;t sort of immediately replaced, it\u0026rsquo;s a good signal. I guess that\u0026rsquo;s an obvious one. I think often, and this is maybe something that\u0026rsquo;s interesting, is that my sense is, my experience has been that it\u0026rsquo;s been sort of a counter indication of early interest. Right. Like, I think the best things that I have built people have not really been excited about until they shipped, which probably means that I\u0026rsquo;m terrible at marketing. I think that sort of many of the things that we\u0026rsquo;ve worked on, that I\u0026rsquo;ve worked on with other folks have just been. We\u0026rsquo;ve extracted a substantial amount of value from them, you know, sort of after they were delivered. But it was like upfront, it seemed. They seemed somewhat risky. So I don\u0026rsquo;t know, I don\u0026rsquo;t have a great idea of like what makes a project great. I think I have some intuition and, you know, I can get really excited about things and sort of how they can sort of nicely slot into systems. But, you know, I think that it\u0026rsquo;s unclear that that excitement is a leading indicator of success.\u003c/p\u003e\n\u003cp\u003eAlex: I think that totally makes sense. Do you feel like in a sense you feel like your batting average is what it should be?\u003c/p\u003e\n\u003cp\u003eBryan: Right?\u003c/p\u003e\n\u003cp\u003eAlex: Like not everything going to work, not everything\u0026rsquo;s going to fail, but you are going to do enough things right that things result in value over time.\u003c/p\u003e\n\u003cp\u003eBryan: I think I\u0026rsquo;m sort of bewildered by the fact that I managed to seem to manage to do that. I really, I think, struggle from pretty crippling imposter syndrome. I\u0026rsquo;m not sure why I\u0026rsquo;m on a podcast talking about the work that I do, like, I have no idea. And I think that getting some sort of validation after the fact is really helpful and useful. But I think if I were, you know, I think I come up with a lot of bad ideas and I\u0026rsquo;m wrong about a lot of things a lot of the time. And occasionally a good one sort of like comes out and we, we manage to do things. But I just, my batting average is probably pretty low. Like I, you know, I\u0026rsquo;ve been, I\u0026rsquo;ve had a lot of bad ideas. I think it\u0026rsquo;s just that I managed to like course correct very quickly when that happens.\u003c/p\u003e\n\u003cp\u003eAlex: I appreciate, I think we all understand that feeling of imposter syndrome, but I have to tell you, as someone who\u0026rsquo;s worked with you, you\u0026rsquo;re doing a pretty good job, dude.\u003c/p\u003e\n\u003cp\u003eBryan: I mean, that\u0026rsquo;s really nice of you to say, but you know, it\u0026rsquo;s, it\u0026rsquo;s a real challenge. I think at times I think it is, it is just one thing that I sort of do to combat that or at least do that is to sort of be explicit when I am like when I, when I take a position, I\u0026rsquo;m like, I like very much could be wrong about this, but like, here\u0026rsquo;s why I think this is a thing or here\u0026rsquo;s why I believe this to be true. I may be wildly wrong, but let\u0026rsquo;s talk it out together. And usually in a one on one situation, a key there is just sort of making yourself vulnerable and typically the person you\u0026rsquo;re talking to is sort of experiencing the same thing. I think that there are personalities that can loom large and I don\u0026rsquo;t believe that I\u0026rsquo;m one of those personalities. But I think my experience with other folks have been like, oh, you came into this meeting and I was really intimidated. I\u0026rsquo;m like, who am I? Like, I don\u0026rsquo;t know who I am, what I\u0026rsquo;m doing here. And you know, I try to spend a lot of time just when I work with folks just be like, okay, look like I don\u0026rsquo;t have, I\u0026rsquo;m not blessed with any magic understanding. Like I just read a bunch of emails a long time ago and so I\u0026rsquo;m happy to be able to like talk this out with folks. But yeah, I am just intimidated by a lot of the folks that I, I meet and work with because. And I try to just sort of make sure that I\u0026rsquo;m separating any reactions that I have to things and being rational as best I can. But it is a really hard thing to sort of overcome imposter syndrome and value your ideas. And your work.\u003c/p\u003e\n\u003cp\u003eAlex: Something that I am having this conversation, something that I\u0026rsquo;m struck by, sort of like an experience I had multiple times over our time working together, was that I was a fairly inexperienced engineer at the time. And so, like, sometimes I would run up against at the end of my technical knowledge and I\u0026rsquo;d be like, oh, I\u0026rsquo;m at the end here. I can\u0026rsquo;t see past this point. Like, there was a problem in the C code or there was a problem with the server that I was using, or the browser wasn\u0026rsquo;t working exactly the way. And the experience that I remember having is I would talk to you about it and you\u0026rsquo;d be like, oh, it\u0026rsquo;s cool, let\u0026rsquo;s just go look. Let\u0026rsquo;s dig a little bit deeper, let\u0026rsquo;s dig a little bit deeper. And I remember times we would end up deep inside some C code base and you\u0026rsquo;d be like, oh, here, this is where the problem is. And it really impressed upon me personally. I was like, oh, well, there\u0026rsquo;s always a level below this one. There\u0026rsquo;s always another level we can go. And as long as our problem is defined, we can keep digging and we\u0026rsquo;ll figure it out. And I was curious, is that something that you feel like you have learned over time? Is there a specific experience that taught you to do that? You know, or is that just, Is that just the Bryan Berg special?\u003c/p\u003e\n\u003cp\u003eBryan: I don\u0026rsquo;t know. I don\u0026rsquo;t know. I still do that today. Right. Like, that\u0026rsquo;s like. I think that one of the things I spend plenty of time doing is like, trying to figure out how to get folks unstuck by just being like, it\u0026rsquo;s just, there\u0026rsquo;s just some code there. Like, let\u0026rsquo;s just go dig a little bit deeper and find out what\u0026rsquo;s under there. Or, you know, I have this intuition about how the system on the other side of this, this, you know, network socket works, even though we don\u0026rsquo;t really, it\u0026rsquo;s not operated by us. But like, you know, here\u0026rsquo;s how I think it works. Let me, you know, dump some state on my mental model and like, maybe with, with some of that context, we can kind of figure things out together. I honestly, I think that is a skill. I think that some of the folks that I have seen possess that skill just like, astound me at how good they are. Like, I\u0026rsquo;m a rank amateur when it comes to that. Like, I can read code, it\u0026rsquo;s fine. But like, I, you know, when I, I think the stuff I\u0026rsquo;m inspired by there is like reading, reading Project Zero blog posts and things like that. When it\u0026rsquo;s like they build the sort of enormous exploit chain, you know, or something and like they\u0026rsquo;re like picking through assembly and like are able to make these amazing inferences and I am like nowhere near there, but I don\u0026rsquo;t know. That skill of being able to sort of just push forward and pierce through an abstraction and dig into the code underneath or spend a lot of time kind of trying to form a mental model of a system and reverse engineer it or whatever and then do that I think is very much a skill. It\u0026rsquo;s one I, that\u0026rsquo;s what fun in engineering is. That just entertains my brain and that\u0026rsquo;s why I gravitate towards that work. It\u0026rsquo;s gratifying to unstick people when you\u0026rsquo;re like, cool, let\u0026rsquo;s go figure this out. That\u0026rsquo;s fun. It\u0026rsquo;s a good nerd snipe. Really interesting thing to figure out, but I don\u0026rsquo;t know where I acquired that skill. For me, my early experience with computing was being on the other end of a really slow dial up link and trying to sort of piece together the world on the other side. And you know, I started using the Internet in like early 90s, right. And it was just a wildly different place. And there were, you know, if you sort of start your career today, you start your career sort of in the, in the near future or just in the recent past. There\u0026rsquo;s so much the world so welcoming, I will say, right? Like there\u0026rsquo;s so much open source out there where you can dig into things. And I feel like I started my career in a world where I didn\u0026rsquo;t barely had access to sort of dig through those things, you know, like there was a lot more proprietary software, there was a lot more sort of multi user systems where you like weren\u0026rsquo;t able to kind of see the, the sort of the bounds of what, of what was out there. And I think, you know, again there was that curiosity that I just found myself with a surplus of. And so that I think that\u0026rsquo;s where that skill came from for me was just having to sort of sort of tread, you know, survive in the world of like, you know, I\u0026rsquo;m being so, so fascinated by what was available out there, what was there and seeing so much potential in it, but also not really feeling like someone\u0026rsquo;s going to go explain it to me or whatever. I had this really interesting experience with someone at Stripe really early on when I was explaining that the first programming language I\u0026rsquo;d ever used was Logo. I remember pretty vividly Being in kindergarten, my school had these like little like TRS 80 computers, color computer 2, pretty exciting stuff. And there was like a little, you know, it was like a game cartridge, like a pack with like a logo interpreter on it. And you know, I just, I sort of knew and it clicked for me when I could draw, you know, a triangle or a square with the turtle. And they were like, oh wow, like you grew up writing logo. Like that\u0026rsquo;s just like Lisp. And I was like, that wasn\u0026rsquo;t like lisp to me as a six year old. That was like I draw a square. And there wasn\u0026rsquo;t a way to make that leap in terms of going from this is a thing that lets you draw squares or a star or a circle polygon on the screen to learning scheme or whatever. There wasn\u0026rsquo;t a way to make that jump at the time. And I feel like if you start today, the sort of abstractions you get are so powerful that you, you don\u0026rsquo;t necessarily have to kind of brute force your way all the way up. And I think again, that is a very long winded way of saying that. I think where I got that that particular skill was like just very early in my career having to, having to sort of figure it out without having a lot of manuals or documentation or whatever and you know, having to go sort of like figure stuff out from. Not from first principles, but without a lot of, of that to help. And it feels different today in a really cool way, honestly, but just different.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;m tempted to pull at the string of sort of the differences in generations of programmers, but I feel like, yeah, that might devolve. The question that I have is actually going back and this is sort of getting away from unfortunately the fun hacky bits and getting back to sort of like the organizational hacking. But you\u0026rsquo;ve mentioned a couple times now that like, you might not phrase it this way, but like you\u0026rsquo;ve identified these areas of ownership of like problems that exist that currently nobody is focused on and you think someone should be focused on. And like, it sounds like you\u0026rsquo;ve sort of solved that problem enough times or seen that situation like unfold enough times that I\u0026rsquo;m curious if you sort of have a playbook around it. Like, I think that ends up being something that staff engineers run into a lot in their organizations is like, there\u0026rsquo;s this thing that someone should be working on. No one\u0026rsquo;s working on it. And now what? I\u0026rsquo;m curious how you approach it.\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, in general, I think I just try to really present a consistent message There, right. If I\u0026rsquo;m going to go, I want to make sure that as many people as possible who are responsible for making a decision around that, hear the decision here. Advocacy for the creation of, of this thing. I think in the early days of Stripe, when I was finding a system or an area that needed sort of development, it wasn\u0026rsquo;t like I could create a team to work on it. It was like, okay, I just have to go like, make some progress on this thing. And you can\u0026rsquo;t own something if there\u0026rsquo;s nothing there. And so if we kind of created something, then it would be like, okay, well, it exists enough that someone has to take care of it. Now as far as doing this, I think that you can go and write Charter a vision for a team, create it kind of by fiat where you say, okay, well this team needs to exist. Because I think it needs to exist. And I don\u0026rsquo;t think tech leads typically have that power. I certainly haven\u0026rsquo;t acquired that power. There are managers that can do that, I think, but it\u0026rsquo;s not something that I\u0026rsquo;ve ever been able to snap my fingers and make that appear. But instead I think talking about the impact that that might have, building the sort of the narrative and really telling a good story, I think is really key to that. So if you can sort of have a pitch and have a focus for like, okay, this thing needs to exist. And here is why. That to me is like the most powerful tool. Is it a playbook? No, it\u0026rsquo;s very situation dependent, I think. But my sense is that if you can kind of whip together a compelling narrative for a team and then just tell it to anyone that will listen, it eventually kind of just becomes a thing. I think that there\u0026rsquo;s a big difference between saying we need to do something and writing down some metrics to optimistically talking about the impact and the, and the sort of good things that can come out of something like that existing.\u003c/p\u003e\n\u003cp\u003eDavid: So in the process of sort of like identifying an area of ownership, so to speak, there\u0026rsquo;s I guess this handoff that needs to happen where eventually, like, you know, there\u0026rsquo;s a new set of people that are going to take that concept and run with it. How have you seen that play out?\u003c/p\u003e\n\u003cp\u003eBryan: Yeah, so I\u0026rsquo;ve had an experience doing this a few times and one of the things that I\u0026rsquo;ve found, one of the tools that I\u0026rsquo;ve found that\u0026rsquo;s sort of most important is to kind of write this sort of like optimistic state of the team in X months. So usually it\u0026rsquo;s like 18 months and usually it\u0026rsquo;s wildly optimistic, but what I have done in the past is like sort of worked with folks on a given team and written this sort of like optimistic view of Team X in 2023. And you kind of write this document in the present tense. So you say you\u0026rsquo;re wildly optimistic, you write in the present tense, you say all of these great things that are going to be true about the way that it\u0026rsquo;s going to be. If this team was wildly successful at all the things that it was going to do, what is the state of the world? And that\u0026rsquo;s not necessarily writing a shift email that says, oh, we did this X, Y and Z. Said in the case of one of the teams I did this for was one of Stripe\u0026rsquo;s security teams. And so we were able to sort of lay out all of this beautiful sort of sci fi future where we understood or we are able to outline what was great about that world, what were the amazing things that we had accomplished such that the experience of the average person interacting with the system was so good. So we talked about managing credential storage and so here\u0026rsquo;s the flow that a typical user goes through to create a new credential that needs to be in our secret store as an example. And we were able to create this narrative in this thing that we were like, oh, wow, wouldn\u0026rsquo;t it be great if that actually happened? The document did not get the timeframe that I set on the document. Definitely didn\u0026rsquo;t meet it. But as I. It was this enduring sort of artifact of like, here\u0026rsquo;s how good these things that we could build would be. And I talked to one of the engineers who like, you know, two years later was kind of working on building some of this stuff and he was just like, yeah, we just kind of executed on that, that plan. We like kind of had this thing. And so, you know, it was something that we formed in with the team. It wasn\u0026rsquo;t something that I came up with on my own or anything like that, but I laid the framework and then we filled in a lot of details and we wrote a pretty detailed sort of description of the future state. And it was super helpful for us to kind of drive things along. So I would, I would recommend that to anyone as a way to sort of create vision and create like excitement towards, towards the future.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s very cool. And it\u0026rsquo;s a really good approach. I think people think about vision documents and it\u0026rsquo;s like hard to understand sort of what, what that concretely is. But I think it\u0026rsquo;s just as you Say it. Just zoom ahead a little bit into the future and write down what the best version of everything would be. And there you go. That\u0026rsquo;s your vision. I like that.\u003c/p\u003e\n\u003cp\u003eBryan: Yeah. Visioning feels very abstract, but if you can actually like, go and sort of concretely feel out some of the details of the thing that you\u0026rsquo;re going to build, what the state of the world is going to be, it just feels more real, like it feels attainable as opposed to being something that is. Is, you know, more abstract.\u003c/p\u003e\n\u003cp\u003eDavid: And it also simplifies every planning process until then because it\u0026rsquo;s like your roadmap is already there. You know, where you\u0026rsquo;re. You know, where. What your North Star is. That\u0026rsquo;s pretty cool. We\u0026rsquo;re rounding the bend on time here and there\u0026rsquo;s two questions that we generally ask everybody. The first one is, are there any resources? And this could be, you know, people, blogs, books, whatever, but any resources that you\u0026rsquo;ve encountered in your sort of path that you would recommend to other folks who want to be really good technical leaders.\u003c/p\u003e\n\u003cp\u003eBryan: So I\u0026rsquo;m going to answer this question in a weird way, which is to say these are not necessarily technical resources, but, you know, in my mind, being able to be persuasive and sort of convince other folks of the sort of merits of your ideas is an incredibly sort of important and powerful thing. And being able to take ephemeral conversations and make them sort of last and be shareable is really important. And so, you know, in my mind, being a good writer is like, sort of actually one of the most important things to do. And so I don\u0026rsquo;t have any, like, specific resources. There\u0026rsquo;s like a number of like, writers that I sort of really enjoy. You know, I don\u0026rsquo;t know. I really enjoyed Matt Levine, who\u0026rsquo;s a writer for Bloomberg, writes a great comic called Money stuff. I really enjoy some of the writing that sort of he has done in that it\u0026rsquo;s just like punchy and funny and like, sticks with you, like. And like, I sort of aspire to come up to be able to write like that. I think that Will Larson again, is like another person that sort of has managed to kind of. His blog is sort of great about finding like, he\u0026rsquo;s good at sort of capturing anecdotes is really supposed to be pretty fantastic. And, you know, just I think generally most of my things about like, find your. Find your voice and figure out how to sort of like, write well, I\u0026rsquo;m a much better written communicator than speaker, as everyone listening could probably attest, or at least attest that I\u0026rsquo;m not a great speaker. But. But yeah, there\u0026rsquo;s just a lot. I take inspiration from interesting writers rather than necessarily writers on technical subjects, if that makes sense.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, totally. So the last question we like to ask is how much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eBryan: What\u0026rsquo;s coding again? So I spend a little bit of time. I think what I tend to do is I will try maybe once a week to go find some sharp edge of a system that someone else is going to spend a ton of time trying to sort of figure out and then refactor and fix and clean up. And I still enjoy the dopamine hit of committing a change and deploying it. It\u0026rsquo;s second to none. And so the places where I try to deploy my coding time are on things that I can probably try to. That no one\u0026rsquo;s going to have to deal with ever again and try to sort of clean up things and fix small sort of annoyances. And so that\u0026rsquo;s where I spend most of my coding time. But it is pretty, pretty rare that I get to do those these days.\u003c/p\u003e\n\u003cp\u003eDavid: The number of services that we deploy to today versus what it was like when you started this stripe is probably different. So maybe it counteracts you maybe spend less time coding, but you get more of a rush when you\u0026rsquo;re done. I don\u0026rsquo;t know.\u003c/p\u003e\n\u003cp\u003eBryan: I find it particularly satisfying to just like kind of clean up, you know, tiny, tiny pockets of debt. I don\u0026rsquo;t know. I love that. It\u0026rsquo;s great.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. Well, Bryan, thank you so much for taking the time today. It\u0026rsquo;s really been fun to chat with you.\u003c/p\u003e\n\u003cp\u003eBryan: That\u0026rsquo;s it.\u003c/p\u003e\n\u003cp\u003eDavid: Thanks so much for listening to staff Inch. If you enjoyed today\u0026rsquo;s show, please consider adding a review you on itunes, Spotify or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value of this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast.staffing.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-11-16T09:00:00-06:00","date_modified":"2021-11-16T09:00:00-06:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/ben-ilegbodu-stitch-fix/","url":"https://podcast.staffeng.com/season-1/ben-ilegbodu-stitch-fix/","title":"Ben Ilegbodu (Stitch Fix)","summary":"As you go up higher, the idea of that's not my responsibility, like goes away. It's like in theory anything can be your responsibility. Like even if it's not in my domain of front end development, like it can still be my responsibility to try to at least get the right people in the room or what have you to get this problem solved.","content_html":"\u003cp\u003eToday we talk to Ben Ilegbodu, Principal Frontend Engineer at Stitch Fix, about how he manages to stay close to the code at a senior level. We hear how he arrived at Stitch Fix and what his first tasks were to identify the pain points in customer teams. From getting the IC\u0026rsquo;s on his side to learning the importance of marketing your ideas to upper management, Ben talks us through his exciting career. He describes how he handles urgent tasks, and why it\u0026rsquo;s crucial to do the important tasks first. We hear how giving an honest answer to where in the priorities list a task falls is key to inter-team efficiency, and why it\u0026rsquo;s so important to keep communicating throughout long-term projects. Tune in to find out Ben\u0026rsquo;s approach to mentorship, and how he plans on motivating high-school students to take the steps to become a developer. Don\u0026rsquo;t miss out on this must-hear episode filled with practical advice on being a Staff+ engineer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/benmvp/\"\u003eBen Ilegbodu on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://leaddev.com/staffpluslive\"\u003eStaffPlus Live Conference\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9464860-ben-ilegbodu-stitch-fix.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined joined by my co host Alex Kessinger. We\u0026rsquo;re both staffplus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Ben Alegbadu is a principal engineer at Stitch Fix, focusing on the front end platform. Ben has been working on the front end for more than 15 years and it shows, especially when we talk about encouraging alignment among other engineers. This is a great episode, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Ben, thank you very much for taking the time to join us today. I\u0026rsquo;m looking forward to chatting with you. Could you please tell us who you are?\u003c/p\u003e\n\u003cp\u003eBen: Sure. Thank you for having me as well. So my name is Ben Alegbadu. I\u0026rsquo;m currently a principal front end engineer at Stitch Fix. I\u0026rsquo;ve been doing front end development software development for almost 20 years now, but I\u0026rsquo;ve been focusing mostly on the front end side. And before working at Stitch Fix I worked at eventbrite for almost 5 years or so working on there now front end platform team and before that I was at a startup called Zazzle that does custom T shirts and stuff like that. And that\u0026rsquo;s kind of where I got into the industry basically. So I was there for nine years or so as well and started off on feature development and realized I liked platform development. That\u0026rsquo;s kind of where I realized that that\u0026rsquo;s kind of where my niche has been. So now it\u0026rsquo;s this fix joined our general platform team which then broke up into different pieces and now I\u0026rsquo;m on specifically our front end platform team currently.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. So this is a fun question for me to ask because I actually work with Ben on one of those assistor teams. So from your perspective, what does a staff or a staff plus engineer do at Stitch Fix?\u003c/p\u003e\n\u003cp\u003eBen: At Stitch Fix, it depends. So every time with staff plus engineers it\u0026rsquo;s always a different flavor. Right. So I can speak for myself specifically in that I have a pretty much an equal mix between I guess what I would just call software development, like actually writing code versus not writing code, I guess getting to work with people on various different ways. So there\u0026rsquo;s lots of code review, there is lots of, hey, I am Trying to figure this thing out. Can you help me? Or oh, we\u0026rsquo;re about to plan this project. Can you give advice? Or oh, we\u0026rsquo;re about to plan this project. Let me stop you from doing that gently, of course. Right. So there\u0026rsquo;s, there\u0026rsquo;s lots of that and then there\u0026rsquo;s meetings and all sorts of things around planning and things like that. So I am really interested in staying close to the code. Like I still enjoy it. I still think I have a lot of value to offer there. So I\u0026rsquo;ve really been trying to position my career so that I don\u0026rsquo;t all of a sudden find myself, you know, with 10% time coding as opposed to 50%. So I even block off my afternoon. So from 1 to 5:30, I block them off so that no one can schedule meetings during those times. So I have like focus time. Sometimes it\u0026rsquo;s not development, it\u0026rsquo;s sometimes it\u0026rsquo;s I have to do something but usually it\u0026rsquo;s. That\u0026rsquo;s the time that I have free to do development time.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really interesting. What do you think the value you derive from staying close to the code is as you become a more senior individual contributor?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I think the value I have is that I\u0026rsquo;m still in the code so I am able to understand folks problems in terms of actual development. Like take a specific case. I focus more on react. So I\u0026rsquo;m having this problem maintaining state in my reaction application. Like I won\u0026rsquo;t be speaking from theoretical like oh, this is what you kind of have to do. It\u0026rsquo;s like oh well let\u0026rsquo;s jump in the code, let\u0026rsquo;s look at it. You know, I was just working on something like that two days ago, so let\u0026rsquo;s figure it out. So it allows me to, instead of just being a technical resource that knows things, it\u0026rsquo;s like I am a coding resource that can specifically pair and help folks with. And then also it allows me, since I\u0026rsquo;m on the platform team to create capabilities to help others in their development. So I\u0026rsquo;m able to actually feel the pain as well myself so that I can build proper things for it prevents me from being, you know, get into an ivory tower syndrome and stuff like that.\u003c/p\u003e\n\u003cp\u003eDavid: Yep, yep, fair enough. Can you describe just to sort of make it concrete for the listeners, what are some examples of like projects or initiatives that you would have worked on in the past little while?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, so at Stitch Fix and as well as Eventbrite, one of the big projects was our design system or component library depending on how you define the term. So the project is kind of this long running, never ending project. And I think the key component is that what gets worked on wasn\u0026rsquo;t decided by a PM because I didn\u0026rsquo;t have one or even my manager. It\u0026rsquo;s like very self driven or team driven. So a big difference is like myself having to figure out either from talking to people or just intuition, like what are the next things that are important to work on, scoping my time to make sure that I get it done properly and the time that folks need it and things like that. So it\u0026rsquo;s very different than a typical feature development process where there are designers and PMs that come through and figure out what exactly is going to be built and then that gets scoped out and then now I just have to do the implementation. It\u0026rsquo;s kind of like the whole process of it to make it happen.\u003c/p\u003e\n\u003cp\u003eDavid: Since I\u0026rsquo;ve got you, I\u0026rsquo;m going to go on a little bit of a tangent here, but one of the things that I find interesting about design systems is managing versions or like updating design systems. Right. Because you\u0026rsquo;re potentially changing a whole bunch of UI across an entire company or whatever. How do you think about that? How do you approach that? What are like some of the. I realize that this is a little bit. Yeah, it\u0026rsquo;s a little bit getting into the weeds, but I\u0026rsquo;m curious to hear your thoughts.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah, it goes into the architecture aspect and this is things that I\u0026rsquo;ve learned over time from making mistakes in the past and running into issues and such. So the double edged sword of a design system is that, oh, you make a change and everybody gets it. Yes. But then you also make a change and everyone gets it and that can also be a problem. Right. So we try to do a lot of things backwards compatible so that you know, they\u0026rsquo;re not breaking changes as we make changes. Try to have the design changes usually are the ones that are okay. It\u0026rsquo;s like, oh, we changed the color of this or move these things around and such. But when it comes into functionality of things, that\u0026rsquo;s when problems are arise. So the benefit though is that by having a component library that\u0026rsquo;s versioned and having teams use specific versions that they want, then at least it\u0026rsquo;s an opt in when they want to move up and then be able to make the decision that, okay, I want version 2 of this component and how it works and I\u0026rsquo;ll take the time to fix my tests and make sure it integrates with my application correctly. So that way teams aren\u0026rsquo;t getting their apps broken without them realizing, which is Great for stability. But the flip side, the double edged sword is that now teams have to manually go in and make those changes. So if there\u0026rsquo;s something like, hey, we want to change the button color to be blue instead of red everywhere on the site, just like that, it becomes a multi team effort because we have to now get all the teams to update their apps at a certain time in order to get that to happen consistently. So still trying to figure out exactly what the right balance is of that. Consistency versus stability. Yeah.\u003c/p\u003e\n\u003cp\u003eDavid: You also mentioned that like you don\u0026rsquo;t have a product manager so you\u0026rsquo;re kind of responsible for understanding how to prioritize what I\u0026rsquo;m sure is a long backlog.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. And growing.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, exactly.\u003c/p\u003e\n\u003cp\u003eBen: What\u0026rsquo;s your approach there for figuring out what to prioritize?\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, exactly.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So it, there\u0026rsquo;s this kind of matrix that I keep in my head of what is prioritized. So I try to do what\u0026rsquo;s most important and most urgent first. So usually folks will let me know if it\u0026rsquo;s urgent. You know, you can tell by the Slack messages or the number of Slack messages and such. And then importance is like, what is the feature gonna be for how many people need it, et cetera, et cetera. So I try to do important first, then do urgent next. So lots of people think their thing is urgent. Right. Everybody wants their stuff done. But what I\u0026rsquo;ve realized over time is that someone can have something urgent and it\u0026rsquo;s urgent right now, but then four days later, like they never come back to me with the request anymore. And it\u0026rsquo;s like a month later and I was like, what happened with that thing that you need? So I\u0026rsquo;ve learned the kind of art of okay, I hear what you\u0026rsquo;re saying, I\u0026rsquo;m going to write this down to take care of next week. And if they never come back or never say anything, then I realized it actually wasn\u0026rsquo;t as urgent and okay, I can work on the other thing that I wanted to work on. So figuring that process out, you know, not trying to dismiss anybody or anything like that, but realizing that if I just jumped on everything that someone said, I would just always be working on the next thing and not completing things. So it\u0026rsquo;s most important than urgent, then I do the most important thing after that and then if time allows, which it really ever does, then I do the rest of the backlog. So. Nice.\u003c/p\u003e\n\u003cp\u003eAlex: Working on a platform team, we often have to sort of make decisions for a large group of people and we\u0026rsquo;re trying to always focus on like, what does the Organization need, What do the folks need? And I\u0026rsquo;m curious, what is your approach to making sure that when you\u0026rsquo;re doing the work, the important work, that it\u0026rsquo;s aligned with what the organization needs?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, so the thing about the platform is that our customers are the other developers. So it\u0026rsquo;s important to stay in tuned with what\u0026rsquo;s going on with everyone else. So if I\u0026rsquo;m helping everyone else solve their problems, then I\u0026rsquo;m helping the business basically. And that\u0026rsquo;s usually the type of projects that I end up working on. So at Stitch Fix in specific, like we have this front end working group, we call it so because we\u0026rsquo;re organized in based on domains, I guess, or features that teams are working on, all of the front end engineers, for instance, aren\u0026rsquo;t on the same team. So we have to have some way to kind of share knowledge between each other. So those sorts of meetings where people present things they\u0026rsquo;re working on, demo things they\u0026rsquo;re working on, challenges they\u0026rsquo;re facing are when my antenna go up to try to see, okay, what\u0026rsquo;s going on and people, I\u0026rsquo;ve realized now, unless it\u0026rsquo;s like really, really terrible, they won\u0026rsquo;t speak up and say, oh, this is a problem. I have to kind of read between the lines like, oh, wait a second, you have to do this and this and this to solve the problem. Okay. You know, that\u0026rsquo;s an opportunity to have some leverage to speed things up or to make it easier. And then also what I did when I started at Stitch Fix, which was really helpful for multiple reasons, was that I did a rotation between different teams to just sit with them and work on their projects, basically to get an idea of the domain they\u0026rsquo;re working in. So I can understand the business, but also try to understand the different problems that the teams have and build relationships. So now as a result, people will come to me with suggestions of small things or small problems they\u0026rsquo;re running into as well. So it\u0026rsquo;s really just having my tentacles and everywhere, I guess, to make sure that I\u0026rsquo;m understanding the needs and the problems of other developers so that myself and the rest of the team can solve their problems.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really interesting. So a lot of the efforts that you talked about, it sort of seems like one part of it is like going into the organization and trying to offer help in general. So creating the FE working group, doing a rotation with teams, but if I\u0026rsquo;m hearing you right, that\u0026rsquo;s also like the tool that you use to make sure that things are going well and making sure that you\u0026rsquo;re solving problems that people actually have.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, exactly. So the rotation especially was mutually beneficial because I was able to come in, offer code review, offer my expertise in any way I can. But then I was also learning a ton about the business and then also about the needs and a lot of those things end up becoming backlog tickets like, oh, we need to make it easier to configure all the different front end tooling and such so that teams don\u0026rsquo;t spend time, every time they update their dependencies fighting the tools and such because that was stuff that people were doing and not really complaining about because they just assumed, oh, this is the way things have to be. But it turns out it doesn\u0026rsquo;t have to be that way and we can do things to make that better so that teams can focus on the business logic and you know, their specific domain. So yeah, just trying to be as connected as possible I think makes platform work more effective and also more beneficial because the worst thing about a platform work is doing something and then no one uses it. Right. So I want to make sure that everything that I use is in high demand and very useful.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. So once you\u0026rsquo;ve sort of figured out what the organization needs, how do you sort of carry that through to make sure that the all the organization, not just the end users, but sort of like leadership management, they are on board with. You\u0026rsquo;re like, this is the problem I need to solve. I\u0026rsquo;m going to go do it now.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So I would say everything. Being a staff plus engineer, upward communication has been my biggest challenge and I\u0026rsquo;m very good at communicating with all of the other ICs and oh look, he here\u0026rsquo;s this cool thing you can use in order to solve your problem. But communicating the value of those things to upper management has always been something that\u0026rsquo;s just challenging to me. Not that I can\u0026rsquo;t speak to them or even speak in a way that they would understand it. It\u0026rsquo;s just like I\u0026rsquo;m so focused on delivering the thing that is and it just makes sense to all the ICs that I forget that I have to, oh yeah, managers, this thing is important because of this. So please give your reports time to work on it and to exercise this capability or director, if we can prioritize this, this is what it will unlock and let me try to figure out a way to quantify the value that you\u0026rsquo;re going to get out of it. Like all those things just seem like work that takes me away from my actual work, you know, so I don\u0026rsquo;t naturally want to do it. That\u0026rsquo;s where having someone like a technical PM or even a technical manager, I wish they would go in and, you know, do those sorts of things and tackle it. But as we get up, as I\u0026rsquo;m learning, is that that\u0026rsquo;s kind of part of the responsibility as well. It\u0026rsquo;s not just delivering the quality product, it\u0026rsquo;s also marketing it, for lack of a better term. So that\u0026rsquo;s still a work in progress for me, trying to figure out exactly how to do that best.\u003c/p\u003e\n\u003cp\u003eAlex: Is there any lessons that you\u0026rsquo;ve learned that you feel like that really helped you when you\u0026rsquo;re communicating up, so to speak?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I think just keeping folks aware of what\u0026rsquo;s going on and the value is really important, especially for something that\u0026rsquo;s going to take more than a couple of months. Right. So working on a design system, for instance, in the beginning, there\u0026rsquo;s not enough stuff in it for folks to use. So you really have to take some time in order to make it full enough for applications to be able to leverage it. Well, in that time, it\u0026rsquo;s all investment. It\u0026rsquo;s not being realized, I guess, the work. So being able to communicate the value, this is what it\u0026rsquo;s going to do. And things early on I think will really help leadership get on board and advocate for it and understand the value. Because when I haven\u0026rsquo;t done that in the past, then it\u0026rsquo;s like, wait, what are you working on? Is it as important as this thing that\u0026rsquo;s now on fire? Is it yes or no? And then I\u0026rsquo;m trying to fight and defend the work and stuff like that. So I\u0026rsquo;ve learned that in retrospect that communication helps the most. But I will say on a downside, what\u0026rsquo;s happened is that as I try to share, oh, this is what\u0026rsquo;s coming, this is this great thing. Now people are excited about it because it is a great thing and they want to use it a month before I actually want them to use it. And now it\u0026rsquo;s like this negotiation, like, please, no, wait, it\u0026rsquo;s going to be great. If you use it now, it may not be as great. And that dance is like, once I put it out there, then people want it yesterday. And it\u0026rsquo;s hard to find that balance of the right timing of it. But I guess I\u0026rsquo;d rather people be excited about it than not.\u003c/p\u003e\n\u003cp\u003eDavid: I was just going to say that sounds like not the worst problem to have.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, there are definitely worse problems that are worse than that.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. You mentioned that getting buy in from sort of ICs around you is something that\u0026rsquo;s, that\u0026rsquo;s been like easier for you historically.\u003c/p\u003e\n\u003cp\u003eBen: Yeah.\u003c/p\u003e\n\u003cp\u003eDavid: And that\u0026rsquo;s interesting because that\u0026rsquo;s, that\u0026rsquo;s not always easy either. So do you have any thoughts on sort of like how you approach that? What steps you take to gain buy in from the folks in your team and in the surrounding teams in terms of like getting them bought into what you\u0026rsquo;re doing?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah. I think the advantage is because I tend to focus. I don\u0026rsquo;t know if this is myself forcing it or this just happens to be the projects I work on. I tend to focus on things bottom up. So it\u0026rsquo;s like, oh, you have this problem, you have this problem and you have this problem. Well, let\u0026rsquo;s make something that helps solve that problem. So then there\u0026rsquo;s like no fighting for it. The fighting is actually, can I get this thing earlier than when you\u0026rsquo;re ready? Not that I don\u0026rsquo;t want to do this. Like everybody wants to not have to deal with some things that are a pain point. So if all of our projects are around solving pain points, then once I present like, oh, this is the thing, this is how it solves these five pain points you have, ICs are on board. As opposed to sitting back and saying, you know, we should work on this project because we want to, let\u0026rsquo;s say, make the site five times faster. And if we do things this way, it\u0026rsquo;s five times faster than this way. But it\u0026rsquo;s going to have maybe a slightly negative developer experience or a little be a little bit worse. So it\u0026rsquo;s going to be five times greater for the client, half times worse for the developer. Then that\u0026rsquo;s when the negotiation starts to happen because it\u0026rsquo;s like, it\u0026rsquo;s great for the client and it\u0026rsquo;s going to be great for the business, but then it makes our lives a little bit more challenging or even it\u0026rsquo;s just something different than the way I\u0026rsquo;m doing it now. That\u0026rsquo;s when it requires more negotiation. But I typically haven\u0026rsquo;t worked on those types of projects as much. The cases where I have are. One specific project was we were trying to add instrumentation to our apps to be able to know the impact of the client performance. So folks weren\u0026rsquo;t really all that interested in taking the time to put that in. And that\u0026rsquo;s where advocating upwards to management to let them know that this kind of information is important so we can know and make business decisions. So please allow your team members the time to do this. And that\u0026rsquo;s where it becomes more of the pulling teeth kind of experience.\u003c/p\u003e\n\u003cp\u003eDavid: So you mentioned that, like, a lot of your sort of planning inputs are coming from people around you. ICs basically are telling you about problems that they\u0026rsquo;re having. And you also mentioned that, like, the challenge then is basically like a timing one. How do you resolve sort of like, I don\u0026rsquo;t know if this is happening or not, but have there ever been cases where, like, multiple people are experiencing pain points that they think are urgent and you have to sort of convince them that you can only work on one urgent problem at a time?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah, that happens all the time, actually, a lot of it. If I use the design system as an example, the it\u0026rsquo;s like, okay, we want to have this new experience and this new component, let\u0026rsquo;s say, and they want it for their app. So what makes the most sense is that our team builds that component, makes sure it\u0026rsquo;s accessible, it\u0026rsquo;s high performance, it\u0026rsquo;s consistent from design, et cetera, et cetera. That\u0026rsquo;s like platform work and there\u0026rsquo;s platform thinking that\u0026rsquo;s required for that. And then now the feature team can use that to solve their business case. But if that component doesn\u0026rsquo;t exist now, we\u0026rsquo;re in a conundrum like, does the feature team go and build it themselves and go on a tangent and have to solve it, or do my team stop doing what we\u0026rsquo;re doing to build that thing for them so that they can again focus on their feature team work? So sometimes the answer is, we\u0026rsquo;ll stop what we\u0026rsquo;re doing because this thing is urgent or it is really complicated and it doesn\u0026rsquo;t make sense for you all to work on it. Sometimes it\u0026rsquo;s like, well, we can\u0026rsquo;t do it this month, but we will do it next month. Like, you can plan on that of us have it done next month, so then you can do your work, plan your work around that. And then other times it\u0026rsquo;s like, we don\u0026rsquo;t know when we\u0026rsquo;re going to get to it. You\u0026rsquo;re going to have to do it. So the thing I\u0026rsquo;ve learned is just clear communication, just be upfront and honest, like, yes, I can do it. No, I can\u0026rsquo;t do it. And if it\u0026rsquo;s the no and like, the no is unacceptable, then I will hear from my manager or from director, like, hey, this thing is really important. You got to prioritize it over this other thing you\u0026rsquo;re working on, and that\u0026rsquo;s fine. It\u0026rsquo;s like, if that\u0026rsquo;s the case, then it\u0026rsquo;s good to know that and share it. But do that instead of just like, oh, yeah, Maybe we\u0026rsquo;ll get to it and then we don\u0026rsquo;t, and then they\u0026rsquo;re kind of stuck for weeks on end. So a lot of it is just communication. Communication. Communication, yeah.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious. Something I\u0026rsquo;ve noticed sometimes about platform work is that you see so many different problems from different perspectives and over time you start to realize like, okay, I\u0026rsquo;m solving the problem, I\u0026rsquo;m solving the problem. But you\u0026rsquo;re sort of like approaching what some might call like a local maximum.\u003c/p\u003e\n\u003cp\u003eBen: Right.\u003c/p\u003e\n\u003cp\u003eAlex: Where you\u0026rsquo;re like, I\u0026rsquo;ve solved the problem my best that I can with the tools that we have at hand.\u003c/p\u003e\n\u003cp\u003eBen: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: But I think if we go over here and we try something a little bit farther afield, I might be able to solve people\u0026rsquo;s problems and then also make a really big impact on the business.\u003c/p\u003e\n\u003cp\u003eBen: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: But sometimes making that choice is a little scary for an organization. I\u0026rsquo;m curious, have you seen a problem like that and like, how. What\u0026rsquo;s your approach to sort of like moving folks towards this thing that could be a little scary, but could have a really big impact?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah, totally. We\u0026rsquo;re working on a project like that right now, which I\u0026rsquo;m sure is fine to share. So the way that we build front end apps now is we build them through Rails. So Rails is like our deploy mechanism to our production site so that we have operational excellence around deploying Rails apps and such. But all of our front ends basically are React apps now. So in a sense, our Rails apps are just shells around what really is a React app that we\u0026rsquo;re delivering. So we have done lots of different things to make that process easy and smooth from a front end development standpoint and having shared configurations for your React app and such. But we\u0026rsquo;re hitting that local maxima. Like you\u0026rsquo;re saying we only can deliver a certain type of front end application. So any kind of static app or the like is much more difficult to deliver now. And we\u0026rsquo;re wanting to have better performance and be able to more easily link between pages without having to hit the server. Like all of these different things, optimizations. We were wanting to build, but we\u0026rsquo;re having to do it manually. So there are other tools, React frameworks that exist that solve this next JS being one of them. And we believe that if we can build apps on that platform, the types of apps we will build will be easier to develop and be easier to build, features that we believe will be better for our end users as well as SEO and things like that. But going from an app that is a Rails wrapper Around a react app to a completely front end app only is a huge jump, right? And it\u0026rsquo;s a scary jump. And right when I got to stitch fix, folks were talking about like, why do we need to deliver stuff with Rails? Can we just do front end? And at the time I was like, whoa, we have bigger fish to fry. Like, we can improve what we\u0026rsquo;ve got now because that is a huge undertaking. We\u0026rsquo;re gonna have to completely change how we deploy things and all that stuff. But then, Alex, like, your point is, like, we kind of got to as far as we could. So now it\u0026rsquo;s like we got to take this big leap. So that\u0026rsquo;s where talking to upper management and pitching the idea and saying, well, this is the value we\u0026rsquo;ll get, not only will it improve developer experience, but it should improve our site reliability because we\u0026rsquo;re not going to be hitting web servers, it\u0026rsquo;ll just be static assets to serve the apps and stuff like that. So we did a whole. Myself and another principal engineer did a whole presentation about why we think it\u0026rsquo;ll be useful, the value behind it, and pitched it to all of the other ICs. They were on board with it, had a small working group to figure out, okay, what are the 50 different things we need to solve in order to make this possible? And just did a whole lot of due diligence because it\u0026rsquo;s like, once we tip over to, oh, we\u0026rsquo;re doing this, we\u0026rsquo;re signing ourselves up for nine months to a year of work. And that\u0026rsquo;s a huge investment for the company. So we got to make sure that it\u0026rsquo;s worthwhile. So I was really against it at first because of the amount of work that it would take, but then realizing that the huge jump we would get and that we could actually piggyback on some existing technology I think pushed me over. And now we\u0026rsquo;re working towards it and trying to get it up so that teams can use it. And to my point earlier where I said that teams want to use it yesterday, we pitched it to upper management two weeks ago. Last week someone was like, hey, can I be an early adopter of this thing? Like, I really want to use this now. We\u0026rsquo;re like, ah, I\u0026rsquo;m glad you do. Like, we were looking for people to use it, but just give us like one more month, please, so we can make sure that it can be successful for you as well. So, yeah, it\u0026rsquo;s challenging, but I think that\u0026rsquo;s also how we show our value, is delivering on those big things and having them be successful.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool. Just speaking from my own experience. I don\u0026rsquo;t often get to use the tools that you build because I work on the backend. But I can tell that you and your team have built a very strong communication tool and I can tell that all the front end engineers feel informed of what you\u0026rsquo;re doing. And it\u0026rsquo;s something I aim for in the work that I do to try and create the same experience.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I think if we can have the ICs on board, then they\u0026rsquo;ll advocate for their managers to have it and such. So it\u0026rsquo;s not this thing where, oh, this team is making us do this thing. Like that\u0026rsquo;s what I\u0026rsquo;m trying to avoid.\u003c/p\u003e\n\u003cp\u003eAlex: The most, switching topics a little bit. I\u0026rsquo;m curious, do you have like a specific approach to things like sponsoring, mentoring or leadership? Is that something that you do specifically? You know, and if so, like, what\u0026rsquo;s your approach?\u003c/p\u003e\n\u003cp\u003eBen: So I don\u0026rsquo;t do it as explicitly as I did before. Like, I used to speak. This is when we could go places physically. I used to speak at boot camps a lot and try to get connected to them and share my experience and things like that and be a resource that way. Now I mostly have one on ones with folks and it\u0026rsquo;s actually one on ones with more senior individuals. So I guess if you, I don\u0026rsquo;t want to call it staff minus, but you know, whatever is right below staff. Like folks trying to get to the position where I\u0026rsquo;m at kind of informal mentoring. So I\u0026rsquo;ve had people reach out to me and say, hey, can you be my mentor? I\u0026rsquo;m like, okay, sure. What are you trying to get out of this? Right? Like assuming that I\u0026rsquo;m just going to be this teacher that\u0026rsquo;s going to have all these assignments for them to do and things like that, that just doesn\u0026rsquo;t work. So I think what has worked best for me in terms of how I learn and then also how I share information is just like we\u0026rsquo;re working next to each other and we get to absorb information from each other. I think that works the best. Unless there\u0026rsquo;s something specific you want to learn or pick up, then I can guide you to different resources and things like that. So a lot of the way that I share is in our working group or front end working group. I like to present different things I\u0026rsquo;m working on or things I\u0026rsquo;ve learned that way. That\u0026rsquo;s more of the broad lots of people get influenced way. And then I do a lot of code review as well. And that\u0026rsquo;s how I can Maybe one on one, give advice about how different things in JavaScript work or react work, et cetera. And then in the times where folks want to pair on something and try to figure something out, then that\u0026rsquo;s also another opportunity there. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: Maybe we can call them staff, almost.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eBen: Soon to be staff, maybe.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eBen: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. And so is that something that you do, you know, where you work and outside of where you work, or is it just. I was unclear.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So right now it\u0026rsquo;s mostly through work, the mentoring and guidance and such. I think once there\u0026rsquo;s an opportunity to be in person with folks again, I\u0026rsquo;ll try to pick up meeting with others and such. So one thing I really want to get more involved in is the next generation of developers. So we\u0026rsquo;re talking about high school, maybe, and really focusing on minorities as well. Getting involved in coding because it\u0026rsquo;s a lot easier to think you can do something if you see somebody else like you doing it. Right. Even if I\u0026rsquo;m not specifically a mentor, just speaking at places and showing people that, oh, hey, someone like me, from my background can do this, has done this. Like, I think it can be encouraging. I know it has been for me when I\u0026rsquo;ve had those opportunities. So plan is to be more involved outside, but currently within helping those that I can.\u003c/p\u003e\n\u003cp\u003eDavid: So switching gears a little bit, we\u0026rsquo;re coming close to time. There\u0026rsquo;s two questions that we kind of ask everybody. You alluded to the answer to one of them earlier, but we\u0026rsquo;ll dig into that in a second. But the first question we always ask is, are there any resources that you would point folks toward who are sort of looking to improve their capabilities as a staff engineer, as an aspiring staff engineer.\u003c/p\u003e\n\u003cp\u003eBen: So this has actually been something that\u0026rsquo;s been challenging for me. It\u0026rsquo;s like. Which I\u0026rsquo;m glad this podcast exists and things. It\u0026rsquo;s like trying to see other folks who have been successful in this role who maybe are a step or two in front of me, right? It\u0026rsquo;s like, I know I don\u0026rsquo;t want to be a manager right now, and I know I don\u0026rsquo;t want to be, for lack of a better term, like a technical wrangler, right? It\u0026rsquo;s like, oh, there\u0026rsquo;s these projects going on, and I want to make sure that they are successful, right? I don\u0026rsquo;t want to be that. So it\u0026rsquo;s like, I know I want to stay close to the code, but who\u0026rsquo;s doing that at a higher level, you know, than myself? So I hadn\u0026rsquo;t really had that many experiences of people who were in those positions until the staff plus live conference that happened by. I forget the organization now, was it lead dev? Yeah, lead dev, exactly. Yeah. And that really just opened my eyes up to like other opportunities, what people have been doing and things like that. So if anybody\u0026rsquo;s looking for resources, I\u0026rsquo;m not sure if the videos are online for everybody to watch maybe. So I would highly suggest going through all of the talks and watching those because I learned lots of things that I\u0026rsquo;m already applying in my job right now. One of the main ones that jumped out to me was somebody, I don\u0026rsquo;t even remember who was saying that as you go up higher, the idea of that\u0026rsquo;s not my responsibility, like goes away. It\u0026rsquo;s like in theory anything can be your responsibility. Like even if it\u0026rsquo;s not in my domain of front end development, like it can still be my responsibility to try to at least get the right people in the room or what have you to get this problem solved and such. So I\u0026rsquo;ve been looking at it more from a technical standpoint, like maybe solving the fact that our mobile development always lags behind our web development. Like in theory that\u0026rsquo;s a mobile problem, but really it\u0026rsquo;s all of our problem and I can help solve that with maybe technology or rearranging people or whatever the case may be. So that understanding kind of has unlocked more opportunities for myself, even though there\u0026rsquo;s not necessarily hands on coding and such. So I would highly suggest yes. StaffPlus live conference checking out those videos.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. So our last question, it\u0026rsquo;s tongue in cheek. It\u0026rsquo;s supposed to be fun. How much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, so that is the part I\u0026rsquo;m excited about is I still get to spend probably 50% of my time coding. Coding is still kind of my litmus test of did I get any work done today? Right. So today is actually going to be, I\u0026rsquo;m in meetings today from 9 until 4. So it\u0026rsquo;s like, oh, I\u0026rsquo;m not going to get any work done today, but I still get to. And that\u0026rsquo;s kind of one of my requirements of whatever it is, that role that I take on is that I still get to do development because I find it still to be rewarding and such. So I try not to take on objectives that would pull me away from it. Even if, so to speak, it\u0026rsquo;s going to be what will get me to the next level or get me promoted. It\u0026rsquo;s like I\u0026rsquo;m all about job satisfaction and enjoying what I\u0026rsquo;m doing and staying close to the code is still what I enjoy doing so that I\u0026rsquo;m excited about. Still awesome.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Ben, thank you so much for taking the time to chat with us today. This has been a lot of fun.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, thank you for having me. I appreciate it. That\u0026rsquo;s it.\u003c/p\u003e\n\u003cp\u003eDavid: Thanks so much for listening to Staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcast or 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy..\u003c/p\u003e\n","date_published":"2021-11-02T09:00:00-05:00","date_modified":"2021-11-02T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/ashby-winch/","url":"https://podcast.staffeng.com/season-1/ashby-winch/","title":"Ashby Winch","summary":"I think a lot of this is just about talking to people. That's it. And when I say talking to people, I mean listening to people.","content_html":"\u003cp\u003eMoving from an architect role to a product-oriented one might seem like a big leap, but there are overlaps between the two roles. Today\u0026rsquo;s guest, Ashby Winch, has recently made this transition, and in today\u0026rsquo;s episode, they share what this has been like. Up until recently, Ashby was an architect, with their most senior role at a large logistics operation in the U.K. Now, they have shifted to a product management job, and they are using the skills from the previous role for this new position. We hear about Ashby\u0026rsquo;s diverse experience, how they came to work as an architect, and what inspired a career pivot. Ashby talks about the challenges they have had with having a loosely defined role and how they have made the best of this situation. Our conversation also touches on the relationship between architects and product managers, the importance of communicating context to developers, and advice Ashby wishes they knew earlier in their career. Tune in to hear it all!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/ashbywinch/\"\u003eLinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://medium.com/@ashbyw\"\u003eMedium\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9355859-ashby-winch.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staffplus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Sure. Today\u0026rsquo;s guest is Ashby Winch. Ashby, until recently was an architect and the most senior technical representative at a large logistics operation in the uk. Recently they transitioned into a product oriented role. I had a blast talking with Ashby, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Ashby, thank you so much for taking the time to join us today. Can we start by having you tell us, I guess, who you are and what you do?\u003c/p\u003e\n\u003cp\u003eAshby: Hi. So my name is Ashby Winch and I\u0026rsquo;ve been in software engineering related kind of roles for about 20 years now. I started off just as a software developer, but I\u0026rsquo;ve had a sort of procession of roles that have been kind of unusually poorly defined, where I\u0026rsquo;ve had to make it up a little bit as I go along and figure out for myself what I should be doing, and ended up working as an application architect in a big kind of a FTSE 100 sized retail company for about five years. And I\u0026rsquo;ve just two weeks ago left that role to go and work as a sort of technical product manager in another retailer. Cool.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;m actually like kind of really thrilled to hear that because one of the things that I\u0026rsquo;ve always been curious about, that I\u0026rsquo;ve always wanted to probe in this podcast but haven\u0026rsquo;t had a chance to do, is sort of like what should the relationship between staff plus engineers and product managers look like and, or what is the overlap, if any, between the responsibilities of a staff engineer and a product manager? So I think we\u0026rsquo;ll get a chance to dig into that quite a bit. But I think before we do, another sort of another question that I have is what are some concrete examples of things that you\u0026rsquo;ve worked on recently? I mean, I understand if you can\u0026rsquo;t give like specific details, but just sort of like to situate the listener in sort of like the type of work that you\u0026rsquo;ve been involved in over the past recent years.\u003c/p\u003e\n\u003cp\u003eAshby: So one of the things that happened then while I was working for Big Retailer was that they announced that they were building an enormous big new warehouse and they were going to invest a substantial amount then into their software capability that went behind their warehousing and their logistics. So at that point point, one of the things that I did with some of the rest of the management team there was spend a bit of time talking to the business. Really this business being warehousing and logistics for us, that was the part of the organization I was working in and asking them things like, you know, if our systems, if we could magically rewrite them all and give you anything that you wanted in n years time, when this whole new system comes live, you know, what would that look like for you? If we could give you the moon on a stick, what would that look like? And they were really engaged by that and gave us loads and loads of material, which was brilliant because until that moment, if someone said to me, how would you go about architecting some new warehouse system? I don\u0026rsquo;t really have answers. I\u0026rsquo;m like, to do what? Actually, what does that really mean? And the existing systems were so vast and so complex because it\u0026rsquo;s a very big business with a very complex distribution network that it\u0026rsquo;s very hard to know how to get into that. You know, where do you start? There\u0026rsquo;s too much. The level of complexity is completely astonishing. The amount of legacy is astonishing because it\u0026rsquo;s a very old company. So those people from the business gave us lots and lots of answers. And there was a very key kind of a theme around data. They wanted more information about was what was happening in their distribution network. And among many other things, I was kind of in a position to do something about that. So I sort of skunk worked some people into a lot of different departments into helping me out, building a more new style kind of data telemetry ingestion system that slotted in neatly with the kind of data architecture around their emerging warehouse management system, so that the application architecture and the data architecture could kind of fit together neatly. So we started producing some really interesting analytics, both analytic capability, actual analytics, business outcomes, and the data capability that fit together with the underlying application architecture, which had really not been the case before. I think that\u0026rsquo;s really commonly the case when you have a centralized business information department that\u0026rsquo;s not working for the same people as the people who are generating the data.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious, in this process, were you the most senior engineering representative in this sort of development process?\u003c/p\u003e\n\u003cp\u003eAshby: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Wow. So when you were doing that, like, how are you figuring out what your role was? Did you have a manager who was helping you figure that out? Were you sort of like just organically figuring out, you know, what was your process?\u003c/p\u003e\n\u003cp\u003eAshby: I always have figured it out for myself. It\u0026rsquo;s been most of those 20 years since I\u0026rsquo;ve ever had someone who could clearly say to me, this is what your role are. This is what outcomes we want you to achieve. These are the things we think you should be doing, which is a double edged sword in some ways. Like, I really like being able to shape my own role a lot, but at the same time it makes it harder in some ways to get buy in from the 60 million stakeholders if you don\u0026rsquo;t have a way to say to them, you know, this is, this is my space, this is my role, this is what I do. But I spent a lot of time both talking with people from the business about what they wanted from their future and talking with people in engineering then about what they needed and what the shortcomings were of their processes and kind of tried to build my own mental roadmap of where this could go and try to advocate for the kind of resources and investment that might be needed to get there, which was kind of not my business, but almost had to be my business. You know, you can\u0026rsquo;t be effective without some input into those things. And so it\u0026rsquo;s a lot of managing up and sometimes like managing up through multiple levels, which is astonishingly difficult. And I still haven\u0026rsquo;t figured it out.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, so when you\u0026rsquo;re sort of defining this for yourself, when you\u0026rsquo;re seems like you\u0026rsquo;re really going in there and figuring out what you need to do, how do you know that you\u0026rsquo;re successful? You know, what are you using as signals to make sure that you\u0026rsquo;re, you know, you\u0026rsquo;re doing your role in a way that\u0026rsquo;s valuable to the organization.\u003c/p\u003e\n\u003cp\u003eAshby: A lot of the time I don\u0026rsquo;t, Some of the time I see things sort of three years down the line from when I did something and I think, aha, you know, that happened kind of indirectly off the back of these things that I was trying to set into motion back then. It\u0026rsquo;s often really difficult to draw the line, especially if it\u0026rsquo;s been achieved by a lot of advocacy and a lot of tiny conversations. Would it have happened if I hadn\u0026rsquo;t been there? Maybe, I don\u0026rsquo;t know. I can\u0026rsquo;t tell with the analytics piece of work because it was more directly business facing that felt successful because I had a lot of happy, satisfied customers who said nice things about it. But that\u0026rsquo;s not the entirety of success. Right. I guess if I Talk to people from there. Three years down the line and that thing is still alive and delivering value, then I\u0026rsquo;ll feel happier about that. But in some ways, I really will never know.\u003c/p\u003e\n\u003cp\u003eDavid: That is one of the challenges about sort of trying to drive bigger initiatives is that oftentimes the trajectory sort of takes a while to materialize, and that can be daunting, I guess. I\u0026rsquo;m curious about the shape of your work until that point. Like, what got you to the point where you\u0026rsquo;re sort of architecting this entire system for retail warehouses. Especially from the perspective of someone who\u0026rsquo;s listening, who\u0026rsquo;s maybe sort of like working as a senior engineer and really interested in some of these sort of bigger picture projects, but doesn\u0026rsquo;t really know what the path would look like.\u003c/p\u003e\n\u003cp\u003eAshby: So I think my path was kind of wandering in a way. I think having shaped my own path in some of my previous roles definitely helped a lot. One of my previous roles was in a. I\u0026rsquo;m not going to say a startup, but in a very small company where the. The two owners of the company were very open with us all. Like, we all fit in one meeting room, so it was kind of easier for them to tell us everything that was happening. They were very open about their commercial decisions. They were making their strategic decision, making how they were thinking. You know, we always knew how much Runway there was. Everybody knew. The most junior person in the company knew all these things. It was very easy to get involved in some of the more commercial and strategic aspects of it. You were right there and you could make commentary on it and they could take it or leave it. So I think that\u0026rsquo;s where I learned a lot of the art of not thinking like you own the business exactly, but thinking from that perspective. Like it\u0026rsquo;s your responsibility to achieve some outcome. Like when you\u0026rsquo;re in charge of the business, you don\u0026rsquo;t get to say, oh, well, we\u0026rsquo;ve gone bust, but it wasn\u0026rsquo;t my fault. It was all these other things, like, it\u0026rsquo;s on you. There is no one else.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that that\u0026rsquo;s a pretty interesting experience and it resonates with the pattern that Alex and I have seen repeatedly as we\u0026rsquo;ve been doing these interviews, which is basically sort of like gaining that owner mentality at one point. And some of the other ways that we\u0026rsquo;ve seen people do it is either they, you know, are an early employee at a small startup, or they\u0026rsquo;re a founder of a early stage startup, or they, you know, lead an open source project that has lots of different contributors, but in all those cases, there\u0026rsquo;s sort of this. To go back to what you said, like sort of a mentality where you can\u0026rsquo;t just assume someone else is going to do it.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eDavid: You have. You have to treat the problems as your own and you have to assume that you. You have the agency to solve them and that. And that you\u0026rsquo;re actually expected to sol of them.\u003c/p\u003e\n\u003cp\u003eAshby: Yeah, there were a couple of other things I did that were relevant as well. So for a lot of my career, I\u0026rsquo;ve had like a succession of random side gigs going on, one of which was selling my own time to teach younger employees of manufacturing companies how to code. So I would go into their company for a week in my vacation time and deliver them some training course, which was. It was amazing because these people were always really, really hungry to learn. They\u0026rsquo;d been trying it on their own for so long and getting frustrated. And you just gave them a little bit of help and they weren\u0026rsquo;t stratospheric. It was brilliant.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s really neat. Sorry to interrupt, but what was sort of the impetus for that? What drove you to do that?\u003c/p\u003e\n\u003cp\u003eAshby: Just completely random. I think I was on some mailing list where someone posted going, does anyone know who could teach a training course in such a. And I thought, well, I could actually. So I tried it and I really enjoyed it. But because it was effectively me running that as a really tiny business and I had to sell the training courses then because I kept doing it, that really made me think about what value I was providing to the customers. Why would they pay me to come in? Because I was more expensive than an off the shelf C sharp training course where you might be one of 10 people on the course. Why would you get me in rather than someone else? So that was a lot of thinking about value to customers. And then I would get to work really directly with those customers for an entire week. So I got to find out quite a lot about them and what really did constitute value to them. And sometimes I saw them more than once because at least one lot of people came back for another course. So I got to learn what worked well about the first one. And that was really, really useful. Just as a life lesson.\u003c/p\u003e\n\u003cp\u003eDavid: I imagine that the teaching aspect would sort of be valuable as well. I find at least that there\u0026rsquo;s a fair amount of that in our work of sort of trying to bring up the folks around us. And I think I can imagine I have not done what you\u0026rsquo;re describing, but I can imagine that it would sort of build up your ability to identify, you know, higher leverage ways of bringing people along.\u003c/p\u003e\n\u003cp\u003eAshby: Yeah. For some part of my life I was also a ski instructor. And in order to qualify as a ski instructor, because there\u0026rsquo;s quite, you know, there\u0026rsquo;s. There\u0026rsquo;s a. There\u0026rsquo;s a ticket, you have to have it, you have to do quite a bit of teacher training. Not only, you know, they teach you to ski really tidily, but they also do a lot of the very association. It\u0026rsquo;s a British association of, I can\u0026rsquo;t remember. That\u0026rsquo;s not very helpful, is it? Something like that. Let\u0026rsquo;s say that in a more tidy way, the association that gives out these qualifications are very deeply into the art of teaching and training and how to do it well. They\u0026rsquo;re very reflective about that and it shows in the way they teach instructors. So I learned a huge amount of kind of teaching theory from that. I absolutely have reused just time and again in terms of not only teaching, but in terms of influencing people and thinking about the way I practice.\u003c/p\u003e\n\u003cp\u003eDavid: That sounds like a really fun way to become a better teacher.\u003c/p\u003e\n\u003cp\u003eAshby: It was.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. That sounds amazing. So I asked this question earlier a little bit, but I want to try and dig a little bit deeper about, like, when you do the job or do work, you know, how do you make sure that you\u0026rsquo;re sort of implementing something that the organization wants? How do you work with your business partners to understand sort of the value that you\u0026rsquo;re delivering? You know, is there anything. Anything specific that you do?\u003c/p\u003e\n\u003cp\u003eAshby: I think a lot of this is just about talking to people. That\u0026rsquo;s it. And when I say talking to people, I mean listening to people, which is not the same thing. You know, you have customers, whoever they are, and of course they don\u0026rsquo;t all think the same things and they don\u0026rsquo;t all agree with each other about anything. Sometimes they think opposite things, but listening to them is just hugely, hugely important. And not just once, but, you know, again and again. So I\u0026rsquo;ve always tried to have just regular meetings in the calendar with whoever I\u0026rsquo;m thinking is kind of the crucial stakeholders at any point in time. And I definitely think when I\u0026rsquo;ve done things that I think haven\u0026rsquo;t worked out well or where I\u0026rsquo;ve. Like, at least once I\u0026rsquo;ve done something where I stopped in the middle, I thought, this is not working. I should just stop doing this. It\u0026rsquo;s not a goer. And one of the mistakes I had made then was not spending enough time listening to the people who would have been the customers, because they would have told me that earlier.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, have you ever been in a situation where based upon your experience, you sort of, it seems like you have that understanding of like, we have to sell something of value that people want. Have you been in a situation where you feel like the organization is maybe pushing you away from delivering value or like there\u0026rsquo;s someone in the chain who may not have understood that and like, how do you help bring that sort of customer focus in, you know, back into alignment with the organization?\u003c/p\u003e\n\u003cp\u003eAshby: That is a really interesting question that I can\u0026rsquo;t answer in a tactful way in a way that the public can hear. Sorry, I don\u0026rsquo;t think you can put that story in anything. Yeah, you\u0026rsquo;re not wrong. Leave and go join a different company. Don\u0026rsquo;t. No.\u003c/p\u003e\n\u003cp\u003eAlex: I think there\u0026rsquo;s a difference between sort of being at places where that\u0026rsquo;s a minority of people versus the majority. And it can be a teachable moment, I think. But it is hard to talk about, that\u0026rsquo;s for sure. Maybe you could talk a little bit about the transition in roles that you\u0026rsquo;re making right now. It\u0026rsquo;s really curious to hear and maybe you could explain a little bit more about what\u0026rsquo;s going on.\u003c/p\u003e\n\u003cp\u003eAshby: So with this analytics piece of work that I\u0026rsquo;ve been doing, it was kind of increasingly noticeable that a lot of what I was doing in my day to day was product work. It really was. There was a lot of kind of roadmap thinking going on, a lot of analysis of what the customers really needed and what was a pragmatic way to get from it and how to make sure that I had enough buy in from everyone to keep delivering it. And I was mixing that up with technical work because we were a really tiny team and there was not any space for full time product work there. And I found it incredibly difficult to do both of those things. My brain does not switch fast enough. I find it hard to task switch anyway. But task switching between deep, technical. Basically it was data engineering at that point and thinking about products and talking to people and having a nice conversation with my chatty face on and not my. I\u0026rsquo;m thinking about something like face on. It was really difficult and I thought now is the point in my career where I kind of need to choose which of those things I would rather be doing. And it was an easy decision because I really like the strategic side of it very much, the kind of direction finding side of it. But I didn\u0026rsquo;t want to leave the technical world altogether. So I ended up in a product management position within a data organization. So it\u0026rsquo;s kind of the Same job, really awesome.\u003c/p\u003e\n\u003cp\u003eAlex: So you went from something very technical to something squarely in product. Right. Like you\u0026rsquo;re not going to. Are you going to be in your job role? Will you be writing code at all?\u003c/p\u003e\n\u003cp\u003eAshby: No, no code. But it still feels technical because ultimately a data product is technical. The customers are analysts. Utterly not the same as a B2C or even B2B product. It\u0026rsquo;s very internal and quite technical. I think my technical background brings a big advantage working in that space compared to someone coming from outside.\u003c/p\u003e\n\u003cp\u003eDavid: So is the product that you\u0026rsquo;re working on internal to the organization or are you just saying that the customers are quite technical but they\u0026rsquo;re outside the organization?\u003c/p\u003e\n\u003cp\u003eAshby: No, it\u0026rsquo;s an internal data product. So it\u0026rsquo;s. The customers are data analyst within that company and the data product is kind of focused around the finance part of their organization.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes a lot of sense. Something that I\u0026rsquo;ve sort of observed is that I think a lot of times, you know, traditional product orgs are sort of externally focused, at least in the organizations that I\u0026rsquo;ve been sort of involved with. And that sort of leaves a gap for these internal internal products. And product organizations would be sort of well served by hiring people like you to work on the internal facing products. But absent that, I have found that oftentimes that ends up falling into the purview of technical leaders like staff plus engineers, where there\u0026rsquo;s a fair amount of sort of requirement gathering that happens. And the best way to do that is to be talking to customers. And some of that work ends up looking pretty similar to product management work inside an org. First of all, does that sort of resonate with you? Does that sound similar to the experience that you\u0026rsquo;ve had?\u003c/p\u003e\n\u003cp\u003eAshby: Yeah, hugely. So, yeah, yeah. I mean it does feel like this job is kind of the identical job in a sense, except without the expectation I have to down tools and do half the data engineering myself.\u003c/p\u003e\n\u003cp\u003eDavid: Right, right. It\u0026rsquo;s like it\u0026rsquo;s, it\u0026rsquo;s sort of clearly defined, you know, one section of the work that you\u0026rsquo;re already doing and making that its own, its own role.\u003c/p\u003e\n\u003cp\u003eAshby: I think the one difference and part of the reason that I made the move then is that certainly in this product org, and I assume this is reasonably common, there\u0026rsquo;s a really clear, like a grid and there\u0026rsquo;s responsibilities, there\u0026rsquo;s a clear understanding of what outcomes you\u0026rsquo;re responsible for and there\u0026rsquo;s a much more in depth thinking about what it really means to work in product, what kind of activities that might involve what you might be doing. And there\u0026rsquo;s a mandate to do it. It\u0026rsquo;s not a question whether it is or isn\u0026rsquo;t my responsibility to make the roadmap for this thing that the team is working on. And if I don\u0026rsquo;t do it, someone will probably bring it up in my review. Whereas as staff plus or architect as I was, it was always, always a big question what the role should really be. Was I doing the right things? Not everyone in the organization would even have the same opinions about whether I was or wasn\u0026rsquo;t doing the right things. And there\u0026rsquo;s kind of politics around that in a sense. Inevitably, you know, if you have a role that\u0026rsquo;s ill defined like that, I\u0026rsquo;m not sure that means it\u0026rsquo;s a mistake to have a role that\u0026rsquo;s that ill defined, but I\u0026rsquo;m not sorry to be moving to one that has slightly more structure around it and expectations.\u003c/p\u003e\n\u003cp\u003eDavid: As a product manager, surely you expect to be collaborating with quite senior engineers and perhaps architects. How would you hope that, given your experience as an architect, how would you hope that the relationship or the interaction between product managers and architects or senior engineers or staff plus engineers should work?\u003c/p\u003e\n\u003cp\u003eAshby: That is a really interesting question. I would love to be in a situation where I\u0026rsquo;m able to say, okay, well this is the business context. Here is the kind of business roadmap where we might like to be and someone else is in a position to sort of bounce off that and say, right, well these are the, this is the sort of technical roadmaps that I think we would need to build to do this. And here are some trade offs and we could kind of bounce that back and forwards. And I can say, okay, well maybe this thing here doesn\u0026rsquo;t work in the light of that thing. So let\u0026rsquo;s work together then to build these two kind of parallel roadmaps that really fit together. I guess there\u0026rsquo;s a kind of engineering management resourcing roadmap that maybe goes with that. That\u0026rsquo;s very much like a three legged stool, isn\u0026rsquo;t it? Of engineering. And I never worked in a place that made that really explicit, but it\u0026rsquo;d be very, very interesting to try that out.\u003c/p\u003e\n\u003cp\u003eAlex: Something that\u0026rsquo;s interesting to me is in a number of organizations that I\u0026rsquo;ve worked in, there\u0026rsquo;s this very common theme where engineering is like we need to invest in this thing to make it easier to build product. And that oftentimes what you\u0026rsquo;ll hear is sort of engineers to cry like, ah, but product just wants new features, right? I don\u0026rsquo;t think that\u0026rsquo;s the case all the time. I\u0026rsquo;ve worked with plenty of product that don\u0026rsquo;t do that. But like that is a common theme. And I\u0026rsquo;m curious now that you\u0026rsquo;re going to have sort of experience on both sides of the fence, how do you hope to sort of navigate that sort of like investment feature balance going forward?\u003c/p\u003e\n\u003cp\u003eAshby: So what I have, I have been trying to kind of build this balance in a tiny sense in the, in the analytics sphere where it was previously where I had a really strong technical lead working with me and we were trying to kind of figure out between us what\u0026rsquo;s a reasonable proportion just within the tiny squad of kind of customer facing work versus kind of platform investing work, like at this stage in the life cycle of our product, what is a good balance in that sense? How does that change as we progress through it? And what would be lovely to see is a company where that happens not just on the kind of micro level within a squad, but then that happens at the higher level in terms of investment, then budgets and in headcounts and like a really thoughtful approach to what are our business priorities and what does that mean for the level of investment that we need to be making in the business facing work in the, in the various different kinds of not so business facing work. I think Mick Kirsten talks about this a bit in the, in the book Project to Product, talking about kind of networks of value and how the value flows through and what kinds of value there are and how you can take a thoughtful approach to varied investment in these different kinds of things.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So when I\u0026rsquo;m sure you did this as a senior engineer, you know, when it comes time to sort of help explain the business value of work to your team, do you have an approach that you take to that?\u003c/p\u003e\n\u003cp\u003eAshby: I always found the engineers seemed really kind of thirsty to know more about why they were doing what they\u0026rsquo;re doing. I talked to, I just had a random conversation over coffee with an engineer from a completely different team who said, oh, I\u0026rsquo;ve been assigned to do something, but I don\u0026rsquo;t really know why. And I knew why. So I gave him that kind of canned explanation of why from the 40,000ft, you know, in terms of what the business really needed. And he said to me, that\u0026rsquo;s the most useful thing that anyone has told me in the entire time I\u0026rsquo;ve worked here. Like people really want to know. And some of it\u0026rsquo;s about being able to tell the story, I think. So I kind of kind of cast around for not quite sound bites, but like coherent short ways to tell a story. Like a really Short thing that you can say about logistics is that a smaller company or historically speaking a company might have a distribution network that\u0026rsquo;s kind of a small straight line and you can build software around that. But in a more modern company, you\u0026rsquo;d expect to see quite a more complex and a more fast moving distribution network that changes its shape quite regularly. I can say that quite quickly. Someone who works in logistics goes, oh yes, that makes complete sense. And it explains a lot of engineering decisions that you might make then and it explains why you might want to change a lot of the engineering decisions that were made in the past in a world of a smaller distribution network. Stories.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious if maybe you could explain a little bit more in detail. I think it was at the top of our, earlier in our conversation you talked about how because of the warehouse development, you were building a project where the business wanted more data and so you put together a team to sort of build this product that allowed them to build more data. And I\u0026rsquo;m wondering, so like, was there a point in time where you were like, oh, you need this and I\u0026rsquo;m going to go build the team and I\u0026rsquo;m going to explain to them exactly what they need to do, you know, or was it more like of an organic process? And how would, how did you sort of maintain that as a, you know, you know, which kind of process was it?\u003c/p\u003e\n\u003cp\u003eAshby: I guess I think I was growing a capability in a sense. Like I had quite a good long range vision about what they needed because we had asked them this really kind of powerful question, you know, like if we gave you the moon on a stick, what would it look like? And that seems really good as a question. Getting people to kind of lift their eyes up from their feet and look into the distance and go, this is where we need to go. Not just what I\u0026rsquo;m concerned about today or yesterday. So I always had this kind of long range thing in mind, but very much I was building a data capability. So we knew that we wanted the analysts and the business customers to as much as possible to have access to their own data. So the sound bite around that was something like it\u0026rsquo;s, you know, it\u0026rsquo;s their data, it\u0026rsquo;s their warehouse equipment, they bought it, you know, they are operating it, their data, we should give them it back rather than hoarding it inside of SQL databases that they can\u0026rsquo;t have access to because it\u0026rsquo;s production. So I always, it felt a bit like gardening, a bit like I knew where I wanted the garden to end up roughly. But I was always Planting seeds and watering and taking advantage of what interesting situations cropped up rather than having an enormous kind of a structure around what he was doing. Like, I wasn\u0026rsquo;t in a position to have a massively detailed long range plan.\u003c/p\u003e\n\u003cp\u003eDavid: I think gardening is an interesting analogy. I think we all kind of find ourselves like maybe with a long range vision, but not so much a detailed path toward getting there. And I think trying to, trying to plan too many steps ahead is a recipe for disaster. I\u0026rsquo;m curious to dig into sort of something else, go back to something else that we were talking about. You touched on sort of your experience teaching and sort of your, the time that you\u0026rsquo;ve dedicated toward becoming a better teacher. I\u0026rsquo;m curious, sort of along the same vein how you think about mentorship and maybe also sponsorship. Like you mentioned, sort of that you worked with a, you know, a very talented tech lead. And you\u0026rsquo;ve also sort of alluded to the fact that you\u0026rsquo;ve brought up other people in the organization to take on bigger roles. And, and so I guess how do you think about, about growing the people around you?\u003c/p\u003e\n\u003cp\u003eAshby: Sort of broadly speaking, one of the things that\u0026rsquo;s always important to me, but also that comes naturally to me, like I find it hard not to do this, is sharing context. And that\u0026rsquo;s something that I don\u0026rsquo;t see a lot of. Like, across my career, it\u0026rsquo;s been relatively unusual that the people senior to me or, you know, in different positions than me have felt that that was important or that\u0026rsquo;s something they\u0026rsquo;ve done. But it\u0026rsquo;s really important for me that the people around me understand the broader context. And I universally find that when you explain to them what that is, or when you show them, or you put them in a room with people who are on the coal face and can tell them they level up, everyone can do better work once they understand better what the space is that they\u0026rsquo;re operating in. What are the considerations? What, what is your boss thinking? What is your boss\u0026rsquo;s boss thinking? What\u0026rsquo;s the CEO thinking? Like, I noticed this pattern where you\u0026rsquo;d see engineers being really frustrated at something and they would often say something like, you know, the people who are driving these decisions keep changing their minds. They don\u0026rsquo;t know what they want. Or these changes come really, really suddenly. And that makes it hard for us to do good work and hard for us to plan. But from the outside looking in, and because I\u0026rsquo;ve often seen more of the context of those decisions than they have, it\u0026rsquo;s not a surprise. It never was a surprise. It was often a sort of strategic inevitability that this thing would happen based on the things that happened before. And had people been more open about that context and spent more time explaining things that you think engineers don\u0026rsquo;t need to know, like a little bit about how the financing works behind a new warehouse or something, they wouldn\u0026rsquo;t have been surprised. And that would have made them potentially make better decisions, but also be less frustrated and annoyed just in their day to day.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, it\u0026rsquo;s a really interesting insight. It resonates with me, but I\u0026rsquo;ve never really thought about it quite that way before. I\u0026rsquo;m curious, sort of tactically, what does it look like to make sure that the engineers have enough context? And also, you know, I think one of the, one of the reasons why the business is often sort of not great at sharing that context is because they\u0026rsquo;re worried about sort of overloading the context. Right. Like, I think it\u0026rsquo;s, it\u0026rsquo;s easy to share too much. You can easily just share all the information that the business has and then that\u0026rsquo;s not helpful for the engineers either. And so sort of, what do you, what sort of approach do you take to filtering that context for the individuals?\u003c/p\u003e\n\u003cp\u003eAshby: I think so when I\u0026rsquo;m doing it, I\u0026rsquo;m often doing it. I\u0026rsquo;m going to say face to face. I don\u0026rsquo;t mean literally these days face to face, but in just a conversation that\u0026rsquo;s quite casual and that\u0026rsquo;s about something coherent. So I\u0026rsquo;m usually not kind of info dumping. It\u0026rsquo;s not just a random thing that I\u0026rsquo;ve decided to share everything I know about capital investment in warehouses or something, which isn\u0026rsquo;t a great deal as a context. There\u0026rsquo;s things that are actually happening on the ground. And I\u0026rsquo;m thinking, well, we\u0026rsquo;ll be able to understand this better if we\u0026rsquo;re all on the same page about why we are doing this. So then it kind of fits together more. It\u0026rsquo;s not, I think you have to connect the dots quite tightly actually, because it does take a significant level of seniority, I think, to take this kind of very disparate information about finance this and technical that and strategy the other, and actually connect it up and understand the relations between the things. Like you have to over explain how the things connect together quite a bit.\u003c/p\u003e\n\u003cp\u003eAlex: Okay, I had a question. So, Ashley, you said that you were doing this for like 20 years, which feels like you\u0026rsquo;ve probably gained a lot of experience. And I\u0026rsquo;m curious if you went back to when you started, if you could sort of like give your beginning Self, some advice, what would you, what would you give them?\u003c/p\u003e\n\u003cp\u003eAshby: That\u0026rsquo;s really hard. One of the things that I would definitely say, and I have said to other engineers since is you really have to be the person to look after your own career. I think people can get the impression because there are all these nice grids and people to tell you what the responsibilities are of different roles and all the rest of that. Easy to get the impression that it\u0026rsquo;s someone else\u0026rsquo;s responsibility then to make sure that your career goes in this nice tidy upwards trajectory that at that stage you can see mapped out on this grid thing. But of course that\u0026rsquo;s not true at all. And I think I would have done a lot better if I had really internalized that and not just thought about what really upwards might look like in a career, but also about what different industries you can be in. What different kind of roles exist that are not straight up software engineer, like where can my talents best add value? Which is something I feel like I really didn\u0026rsquo;t discover until quite late on. Partly maybe because the industry has changed so much right. In those 20 years, it\u0026rsquo;s completely unrecognizable. But I should have changed job a little more often. I should have not said, well, this job is a good enough job. Hey, they pay me, nobody shouts at me, that\u0026rsquo;s fine, then, you know, I should have been looking onwards and upwards more consistently.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that\u0026rsquo;s good advice and I think you\u0026rsquo;re right. It can feel, it can feel very soothing to have a grid like you described and regular performance reviews and sort of like, oh, everything, everything is actually going fine. But the idea to be more proactive about sort of where you want things to go, I think is, is a good one and a challenge too. I\u0026rsquo;m curious if there are any resources that you would point folks toward, whether that\u0026rsquo;s, you know, people that they should be paying attention to or blogs, books, etc. You know, especially things that you found helpful along the way that you would recommend to other, other people.\u003c/p\u003e\n\u003cp\u003eAshby: So I think I don\u0026rsquo;t want to recommend specific things because it changes too quickly and it so much depends what you\u0026rsquo;re interested in as a person. I think that the trick is to be interested, you know, as a person and to think, you know, what excites me, what interests me, how do I learn more about that, what do other people think about that? And then after you\u0026rsquo;ve read all these things, to kind of almost throw them away a little bit. Okay, these people said these things, but they said that in their context, they live in a different world, all of them. So what does that mean for my world? Like, you can\u0026rsquo;t just take the thing that you read in the book and transplant it just like Shazam. Into an alternative place or a different culture and expect it to work. So you have to figure it out for yourself in some way. You can\u0026rsquo;t read it in a book, but you should still read all the books.\u003c/p\u003e\n\u003cp\u003eAlex: So we have our last question and answer this however you want. I know that you\u0026rsquo;re sort of transitioning roles right now, but the question we like to ask folks is like, how much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eAshby: Up until I left the previous job, I had been doing quite an unusual, for me, amount of code. I\u0026rsquo;ve spent years at a time doing almost none. I really enjoyed that. It was lovely to get into some properly crunchy data engineering jobs and just crank out the code for a bit. In the upcoming job, I fully expect there to be no coding. Also, no being called out in the middle of the night. I\u0026rsquo;m looking forward to that one. And that\u0026rsquo;s good too. You know, if I spend all my day having nice chats with people and figuring out what they need and how to get it to them, that\u0026rsquo;s just equally satisfying, but in a different kind of a way.\u003c/p\u003e\n\u003cp\u003eDavid: Absolutely cool. Well, Ashby, thank you so much for taking the time to chat with us today. It\u0026rsquo;s really been a pleasure.\u003c/p\u003e\n\u003cp\u003eAshby: Thank you for having me. That\u0026rsquo;s it.\u003c/p\u003e\n\u003cp\u003eDavid: Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy. Sam.\u003c/p\u003e\n","date_published":"2021-10-19T09:00:00-05:00","date_modified":"2021-10-19T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/josh-kaderlan-lob/","url":"https://podcast.staffeng.com/season-1/josh-kaderlan-lob/","title":"Josh Kaderlan (Lob)","summary":"The thing that makes me a staff engineer is not that I have any particular knowledge, it's that I have a really wide breadth of knowledge.","content_html":"\u003cp\u003eToday’s guest is Josh Kaderlan, Staff Software Engineer at Lob, a direct mail and address verification API company that automates and simplifies direct mail and address verification, giving businesses greater flexibility, visibility, and accuracy of offline communications and data. There are so many different and non-traditional paths to becoming a staff engineer and, in today’s episode, you’ll hear a bit about Josh’s; starting in quality assurance, moving into development, and ultimately ending up where he is today, which he attributes to his wide breadth of knowledge and the valuable lessons he learned along the way. We discuss why Josh considers himself a generalist, the role that incident management plays in his work, and how he influences his peers by cultivating authentic relationships. Most important to Josh is how the work he does improves the experience of his colleagues and provides value to customers, and he shares some of his tips for staff engineers and organizations looking to have a similar impact. Tune in today to learn more and receive some practical advice and resources!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/porcineaviationengineer/\"\u003eJosh Kaderlan on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.lob.com/\"\u003eLob\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://staffeng.com/guides/staff-archetypes\"\u003e‘Staff Archetypes’\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://news.ycombinator.com/\"\u003eHacker News\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://randsinrepose.com/welcome-to-rands-leadership-slack/\"\u003eRands Leadership Slack\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9280791-josh-kaderlan-lob.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest. For sure.\u003c/p\u003e\n\u003cp\u003eAlex: Today\u0026rsquo;s guest is Josh Katerlin. Josh is a staff software engineer at lob. You know, there are so many different paths to staff engineer and Josh is no different. Starting in qva, he eventually moved into development and is now staff. This is a great conversation, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: All right, well, Josh, thank you so much for taking the time to chat with us today. Could we start by just kind of having you tell us who you are and what you do?\u003c/p\u003e\n\u003cp\u003eJosh: My name is Josh Caterland. I\u0026rsquo;m currently a staff software engineer at lob, a print and mail and address verification API company.\u003c/p\u003e\n\u003cp\u003eDavid: For listeners, it\u0026rsquo;d be helpful to sort of have some background on sort of where you\u0026rsquo;re coming from, how you ended up at Lob, and then we can dig into a little bit of like what you\u0026rsquo;re doing at lob.\u003c/p\u003e\n\u003cp\u003eJosh: How I got here is a very long and twisty story. I don\u0026rsquo;t have any formal background in software. I got my undergraduate degree in French language and culture, which actually did provide me with my entry into the software industry. I\u0026rsquo;ve been in the industry for more than 20 years at this point. Got in back in the. In the dot com days and a friend of mine was working at a company that had a contractual obligation to provide tech support, email tech support for its product in French. And he knew that I spoke French fluently and he knew that I had an interest in computers even if I didn\u0026rsquo;t. Like, I wasn\u0026rsquo;t a programmer at the time. I had never like taken any CS classes in college or anything like that. And it was the dot com boom. So like, right, you could pretty much show up and say, yes, I know how to turn on a computer and get into the industry. And yeah, so that\u0026rsquo;s how I got into the industry in the first place. Did not have any intention of making a career out of software. I was just kind of like looking for the next thing. Not really looking for a career, but I discovered that I really like the industry. I Like the freedom. I like not having to show up at work exactly at 9:00 every morning. And I was like, you know what? If I can work someplace where I can do that, then this is the right industry for me. And so over the course of my time at that job, I learned more about testing, about qa. When I left that job, I went in, I was like, you know, okay, the industry is like, clearly the right place to be right now, so go get a job as a QA tester. So started doing black box testing as I went through that. Like just kind of like learn more and more about technology, about computers. Basically started teaching myself more of the tooling that I needed to make my life easier as a tester. And that was basically kind of like my entree into. Into programming per se. And so, like just over the course of my career, kept kind of like teaching myself more stuff. Getting further and further and further away from customer qa, moving further closer and closer and closer to product development, a long, slow progression through the various roles, and closer and closer and closer to product work.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s fascinating. I think something that Alex and I have observed over the course of doing this podcast is that non traditional paths are actually. I don\u0026rsquo;t want to say that they\u0026rsquo;re common, but they\u0026rsquo;re not uncommon for staff engineers. And I think part of it is that it gives us a bit of a more holistic view. Right. Like, I\u0026rsquo;m sure that your path through QA and customer support gave you sort of a different perspective than folks that are coming up through the engineering organization entirely.\u003c/p\u003e\n\u003cp\u003eJosh: I\u0026rsquo;ve had this conversation with co workers and friends. The thing that makes me a staff engineer is not that I have any particular knowledge, it\u0026rsquo;s that I have a really wide breadth of knowledge at this point. I\u0026rsquo;ve worked in a whole bunch of different environments. I have built the habits of teaching myself and diagnosing problems on my own, teaching myself how to solve them, teaching myself how to program. I really do attribute where I\u0026rsquo;ve ended up now to having followed that path.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, and I like that you\u0026rsquo;ve got the French degree too.\u003c/p\u003e\n\u003cp\u003eJosh: We should stick to English. I\u0026rsquo;ll sound better.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, fair enough. I think we may is Alex. I\u0026rsquo;m not sure unless Alex has some hidden French skills somewhere as well. And the other interesting thing is, you know, a non CS degree. I also don\u0026rsquo;t have a CS degree minus electrical engineering, so, you know, at least kind of adjacent. Alex, do you have a CS degree?\u003c/p\u003e\n\u003cp\u003eAlex: No, I don\u0026rsquo;t have a degree of any kind I have 9/10 of a broadcast communications degree is what I.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. That\u0026rsquo;s what I thought. I mean, I didn\u0026rsquo;t know what you had, but I didn\u0026rsquo;t think that you had cs. And so this is sort of consistent with what I\u0026rsquo;m saying is that I think people come up through a whole bunch of different backgrounds and get exposed to a lot of different things and it sort of helps in that role. So all that to say, like, how would you sort of describe the staff role?\u003c/p\u003e\n\u003cp\u003eJosh: If you think about the archetypes, Will Larsen\u0026rsquo;s archetypes of staff engineers, I actually forget which one it is. I think that the one of them is generalist, right?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eJosh: That\u0026rsquo;s generally what the staff engineers at LOB fall into. That\u0026rsquo;s certainly not the only archetype that we expect people to fill. But if I were like characterize the people who are staff engineers now, that\u0026rsquo;s what I would say.\u003c/p\u003e\n\u003cp\u003eAlex: Cool.\u003c/p\u003e\n\u003cp\u003eJosh: The work really is basically. Honestly a lot of what I\u0026rsquo;ve done is been able to kind of drop into various projects and push them along either like through my own work or in working with other developers to kind of like get the projects moving along. So it\u0026rsquo;s in a lot of ways lately it\u0026rsquo;s been more technical work. That said, for the first period of time that I was at lob, really what the team needed was a lot of mentorship and a lot of guidance in learning how to be a developer and learning how to level up as developers. And so I wasn\u0026rsquo;t doing primarily technical work at that point. I was much more coaching and just kind of mentoring.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. When you approach your job, you talked about how lob, a lot of the staff engineers take sort of like a generalist approach. Is that how you feel like you also approach the staff engineering role at lab?\u003c/p\u003e\n\u003cp\u003eJosh: Oh yeah. It\u0026rsquo;s funny, like, if you talk about like the staff engineer should be T shaped, I wouldn\u0026rsquo;t even necessarily describe myself as T shaped. I\u0026rsquo;m more just kind of like flat. Even before I became a staff engineer, the way that I described myself was I\u0026rsquo;m a full stack engineer, which means that I\u0026rsquo;m equally incompetent at all levels of the stack. And that really is what it is. The way that I think about it is the value that I bring is that I can drop into any situation and come up to speed relatively quickly and make sense of a system that I haven\u0026rsquo;t necessarily seen before. I would never like present myself as the person who\u0026rsquo;s going to solve like the naughtiest technical problem. That the company has. But, and this goes back to what I was saying before about, like, the breadth of my experience being, like, the thing that makes me a staff engineer. I have the confidence that I can take a system that I\u0026rsquo;ve never seen before and figure out how it\u0026rsquo;ll work. Can\u0026rsquo;t necessarily guarantee that I\u0026rsquo;m going to do it quickly, but. Right. I will be able to figure out how it works. I know how to search slack. I know how to search notion. I\u0026rsquo;m pretty good at googling at this point. And so, like, some of the work that I do is like, sitting there and like reading through, you know, git histories and trying to figure out what was going on there. But honestly, a lot of it is just like digging back through the wikis and going like, okay, what were people thinking when they first started, when they first built the system? What breadcrumbs did they leave me so that I can figure out what this thing is supposed to be doing?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, when we talk about, like, the general scroll like you talked about, like, there\u0026rsquo;s just all sorts of things that you do and you\u0026rsquo;ve mentioned sort of like doing some technical work, but coaching and mentoring. Are there other kinds of work that you take on that you feel like wouldn\u0026rsquo;t fall into those buckets?\u003c/p\u003e\n\u003cp\u003eJosh: Absolutely. One of the big interests that I\u0026rsquo;ve fallen into over the last few years is incident management, incident reviews, incident analysis. I was very fortunate at my last job to work with some of the people who, like, helped bring the whole notion of incident management to the industry in the first place from the firefighting community. I was fortunate enough to be trained by people who have backgrounds in both IT and firefighting. And so I learned a lot about how that works. And it was one of those things where it\u0026rsquo;s like, when I had the training at my last job, I was like, where has this been my entire life? This has been. This has been the thing that I\u0026rsquo;ve been, like, looking for my entire career. So when I came to lob, we didn\u0026rsquo;t have a super formalized incident management process. And so a lot of my work there has been to evangelize that, to like, honestly, I\u0026rsquo;ve commanded a ton of incidents just because I am one of the most experienced engineers in the company. I\u0026rsquo;m one of the most experienced incident commanders in the company. And even though I\u0026rsquo;ve never formally worked in an SRE role, I bring a lot of that perspective to the work that I do. So that\u0026rsquo;s been a huge part of the work that I\u0026rsquo;ve done there.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting. I\u0026rsquo;m curious. I think a lot of folks, when you say I learned something from IT and firefighting, they might ask, what could you learn from firefighting that would apply to being a software engineer? Could you explain a little bit more about what you mean there?\u003c/p\u003e\n\u003cp\u003eJosh: Sure. The thing that I really like about the incident management system, which is a thing that was basically, it grew up out of the firefighting community in Southern California in the early 70s. It\u0026rsquo;s basically a lightweight structure and process for handling unexpected events. Not just unexpected events, but basically like emergent events. If you think about outages that you\u0026rsquo;ve been in or high priority bugs that have come in from customers or that sort of thing, in my experience, it really helps to have some sort of a structure to the response. Right. In exactly the same way that if you\u0026rsquo;re doing a sprint in an agile framework, you generally assign roles that people are filling. You have somebody who\u0026rsquo;s responsible for being the scrum master, you have all those sorts of things. It can be really, really beneficial to have that sort of structure in an incident process. You have basically the people who are responsible for the subject matter, experts, the responders, the people who are responsible for actually fixing the problem. Incidents are really stressful. Incidents are really cognitively taxing. And it makes sense to me at least to free up as many of their cognitive resources as you possibly can to focus on fixing the problem, not focus on things like making sure that the status page is updated, making sure that stakeholders are informed, making sure that like they\u0026rsquo;re driving the entire process forward. And that is very much what the incident management system is designed to do. It\u0026rsquo;s designed to break out the roles that people tend to normally fall into in that sort of a situation into slightly more formalized roles with defined responsibilities, and then just give people the support that they need to be able to work the problem without having to worry about all the other stuff.\u003c/p\u003e\n\u003cp\u003eDavid: Can you give some examples of an example of a typical thing that you might be involved with at lob? And I\u0026rsquo;m curious about that, but I\u0026rsquo;ll ask a twofer. Can you also sort of describe how in practice that incident response kind of plays out? Like, so, for instance, at LoB, to whatever extent you\u0026rsquo;re comfortable sharing, like, how is the incident response process defined? And like, what are the steps and who are the participants, etc.\u003c/p\u003e\n\u003cp\u003eJosh: There\u0026rsquo;s a certain amount of discussion around this, so I hesitate to speak for, like, how incidents work in general at lob.\u003c/p\u003e\n\u003cp\u003eDavid: Yep.\u003c/p\u003e\n\u003cp\u003eJosh: I can certainly like articulate what I have laid out the way that I tend to run incidents that I\u0026rsquo;m part of. I mean, I will say that one thing is I am generally way more aggressive than most people I\u0026rsquo;ve met about declaring something an incident. One of the things that I did take from the firefighting, like from having been trained by firefighters, is the notion that if you smell smoke, pull the fire alarm. Maybe it\u0026rsquo;s just like somebody burned something on their stove. But like, the firefighters are there, their job is to respond, is to respond to fire alarms. So if you\u0026rsquo;re not sure, pull the fire alarm. They\u0026rsquo;re used to running that process. So like, they\u0026rsquo;ll get their, their gear on, they\u0026rsquo;ll roll out, they\u0026rsquo;ll show up and maybe they show up and there\u0026rsquo;s, oh, no, wasn\u0026rsquo;t actually a fire. If it was a fire, though, better to have the firefighters on site right then rather than like, oh, wait, no, the entire building\u0026rsquo;s up in flames now. I did lay out, you know, basically like a relatively lightweight playbook for what an incident process looks like. Basically, we have a mechanism for getting each incident like a unique identifier. It\u0026rsquo;s pretty straightforward where you create a Slack channel, usually set up a zoom bridge so that people can coordinate in realer time than trying to do things in Slack, Just this higher bandwidth mode of communication. And I personally generally tend to take a more formalized, somewhat more structured approach to it than other people do. So I\u0026rsquo;m pretty anal about like appointing an incident commander, outlining who the responders are and what their roles and responsibilities are in the process of responding to the incident. And then it\u0026rsquo;s just, honestly just a matter of sitting down and working through the problem, like, right, sizing it up to figure out what the actual impact is, who\u0026rsquo;s affected by it, what the urgency of the issue actually needs to be, and then making sure that you\u0026rsquo;re propagating that information back out so that people aren\u0026rsquo;t sitting there going, wait, what\u0026rsquo;s going on? So part of the reason that this ties back into what I consider the work of a staff engineer is the way that I can consider the role of an incident commander is really, honestly, in a lot of ways, kind of a support role. The thing that I focus on when I\u0026rsquo;m an incident commander is reassuring people it\u0026rsquo;s important to have a sense of urgency because, right, like there\u0026rsquo;s a reason that you declared an incident because that means that something has, in this case, something has gone wrong. But these are also things that happen in software systems, like failure is inevitable, things will break. And it\u0026rsquo;s really important to me to let people know that they\u0026rsquo;re not alone and that there are other people who are there to support them, there are additional resources they can bring in if they need it, and to just keep pushing people along in a gentle fashion. One of the other roles that I see an incident commander fulfilling is like basically kind of herding cats, making sure that the conversations don\u0026rsquo;t rat hole, making sure that basically everybody\u0026rsquo;s keeping their eyes on, like, what we can do to mitigate the issue as quickly as possible, pushing people to consider alternative solutions. And that\u0026rsquo;s a lot of the work of a staff engineer is, in my view, it\u0026rsquo;s just the timelines are more compressed and as a result the pressure is a bit higher. But it\u0026rsquo;s fundamentally very, very similar to me.\u003c/p\u003e\n\u003cp\u003eDavid: Beyond sort of working toward instituting an incident response program or changing the incident response program at lob. What are some other examples of like, projects that you would drive or things that you might be asked to parachute into, etc.\u003c/p\u003e\n\u003cp\u003eJosh: At this point I probably have. I\u0026rsquo;m one of the people who\u0026rsquo;s got the widest range of knowledge about like the entire system. So honestly, a lot of what I do is just kind of answer questions on Slack. A lot of it really is just connecting people and being able to say, like, oh, hey, you\u0026rsquo;re working on this problem. This other person was working on this problem previously. You two should talk so you don\u0026rsquo;t duplicate work so that people get credit for the work that they have done in the past. If I think about like specific projects that I\u0026rsquo;ve worked on, honestly, a lot of it has just been reducing toil. We used to have some stuff that was a very manual process. Basically when things would fail, we would have to remediate them manually. And we had the framework to do that work automatically and redrive those things back through the system so that they would work again. And so a lot of it was like, I wasn\u0026rsquo;t even writing code. I was like teaching myself Docker files and like writing a Dockerfile, moving things from one environment to another.\u003c/p\u003e\n\u003cp\u003eAlex: I think it\u0026rsquo;s really interesting, the projects that we\u0026rsquo;ve talked about so far. So you\u0026rsquo;ve talked about sort of like driving an incident response and then also reducing toil. And both of those things are really curious because it\u0026rsquo;s hard sometimes to describe the value of reducing toil and incident response in a business context. And so I\u0026rsquo;m curious given sort of those things that you\u0026rsquo;ve chosen to take on how Are you making sure that the work that you\u0026rsquo;re choosing to do is aligned with your organizational goals? And how do you describe that to the organization?\u003c/p\u003e\n\u003cp\u003eJosh: To be honest, that is probably the part of the job that I\u0026rsquo;m weakest at. That is definitely something that I need to get better at. A lot of what motivates me is just wanting to make work better for my coworkers. Again, this is another one of those through lines throughout my career. When I think about the first software project that I ever built, built like really kind of on my own initiative. It was. I was working at Symantec. I was working on the anti spam product. At the time, we had a software package and then we also had an appliance that you could buy. So like back in the day when like, literally you buy, you would buy the hardware that had the OS installed on it, it had our software installed on it, and you could buy the full package from us. And so what that meant was that the nightly builds for testing were not just the software package, but like the full OS install. And when I got there, the way that you would install a build is you would download the build to your machine, you\u0026rsquo;d burn it onto a cd, you\u0026rsquo;d go into the server room, you\u0026rsquo;d stick the CD ROM into the drive, and then you\u0026rsquo;d stand there and you\u0026rsquo;d like, right, have to stand at the console and like, go through the whole installation process. And server rooms are not fun places to be. It meant that, like, if we had a build that a whole bunch of people needed to install, like, right? There was only one kvm. So you had to like, coordinate who was going to get access to the KVM when it also meant you couldn\u0026rsquo;t work from home. If we had to do a build on the weekend, like, you had to actually physically come into the office. So a lot of times what people would do is like, one person would go into the office and like, do a bunch of installs for other people. My girlfriend at the time was a large installation system administrator. She was working on like installing oss and software packages on thousands of machines at a time. And you don\u0026rsquo;t do that by burning installs to a CD and then going into a colo somewhere. In talking to her about how she was solving that problem at her job, I realized that I could take that same functionality, right, like it was pixie boot to machines and give a networked location that you was going to pull down the image from. And right, like the machines that we were using had the functionality Built in to do all of that. And so I taught myself how to write boot scripts to do that. And I built a little Django application so that you could like self serve, like subscribe your machine to the system and then go in and you know, like from the drop down, select which build you wanted to use, which machine you wanted to install it on. Right. Do all that sort of stuff. And you could do it all completely remotely. And it was really motivated by reducing toil, making everybody\u0026rsquo;s lives easier. Like, if nothing else, it was just a quality of life improvement for everybody at work. That really is the through line I\u0026rsquo;ve taken through like my entire career. And the problem is that, right, like, that is kind of a difficult thing to articulate to management and to leadership. It\u0026rsquo;s one of those things that everybody recognizes it when everybody\u0026rsquo;s happier and like, oh yeah, this thing works and it\u0026rsquo;s really great. But like, if you were to go to leadership and be like, I want to make everybody\u0026rsquo;s life 10% better, that\u0026rsquo;s not like a super easy sell. And so that is honestly something that I\u0026rsquo;m still working on is figuring out how to articulate that as far as the incident management goes. One of the things that I really do that I have a much better story for, because in my experience, leadership often gets every company that I\u0026rsquo;ve ever worked at, every company that I\u0026rsquo;ve ever talked to people who\u0026rsquo;ve worked at. When there\u0026rsquo;s an incident, leadership gets nervous, right? By definition, you were defending business value at that point. You were not growing business value. You\u0026rsquo;re either defending it or losing it. So that\u0026rsquo;s a stressful situation for leadership to be in. Also, a lot of times leadership doesn\u0026rsquo;t necessarily know what\u0026rsquo;s going on. They may not necessarily find out about the fact that there\u0026rsquo;s an incident from an internal process. They might find out about it because, you know, like, they\u0026rsquo;re trying to do something on the website and they\u0026rsquo;re like, wait, that\u0026rsquo;s not working. Or they see something go up on the status page. And so from my perspective, the way that I articulate the value of the incident management process is this is a way for leadership to get informed about what\u0026rsquo;s going on and to keep track of things while at the same time giving the people who are working on solving the problem the space that they need to solve the problem.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that\u0026rsquo;s really interesting. Is it safe to say that you, you sort of become like the interface by which the business speaks to engineering almost? And maybe that is like A function of staff engineering is that you can go both ways.\u003c/p\u003e\n\u003cp\u003eJosh: Oh, absolutely. That is, yes. Again, it\u0026rsquo;s the same thing. Like, right, if I\u0026rsquo;m commanding an incident, right. I need to talk to customer support because A, I need to find out like, what\u0026rsquo;s coming in from them, are they getting customer reports about these issues? And B, I need to work with them on like, what the messaging is going to be around a particular thing. And yeah, it\u0026rsquo;s exactly the same work that I need to do as a staff engineer. Right. Like, engineering doesn\u0026rsquo;t and can\u0026rsquo;t exist in a vacuum. Engineering exists to provide value to customers.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eJosh: And if you\u0026rsquo;re not talking to the other parts of the business, you don\u0026rsquo;t know how to provide value to customers.\u003c/p\u003e\n\u003cp\u003eAlex: Right. Yeah. Going back to your story about making things better for engineers, I find it striking because it\u0026rsquo;s, I think, an example I\u0026rsquo;ve heard a lot where it\u0026rsquo;s just like, this thing sucked and someone was like, well, if I take these three things that I just learned about and I put them together, I might make it better. And then you do. And then I think there\u0026rsquo;s like this collective sigh of relief, like, oh man, that\u0026rsquo;s so much better. But like, it\u0026rsquo;s just, no one really talks about it. And so sometimes in those situations, I wonder if it\u0026rsquo;s just like the affirmation that you\u0026rsquo;ve done something valuable is your continued employment at the company.\u003c/p\u003e\n\u003cp\u003eJosh: That is absolutely true. Yes.\u003c/p\u003e\n\u003cp\u003eAlex: Because you took a bunch of time, your time, company\u0026rsquo;s time. You did something, you know, you did an experiment, you took a risk and it paid off. And no one was like, wait, why did you waste three months or something? Because you didn\u0026rsquo;t, you didn\u0026rsquo;t waste three months. You made things better.\u003c/p\u003e\n\u003cp\u003eJosh: Right. That\u0026rsquo;s the other thing. When I think about how you take satisfaction as a staff engineer. This is a problem that managers face. This is a problem that you face. As you go further and further up any ladder. Your role in particular situations often gets more abstract and more indirectly. It gets increasingly difficult to articulate the value that you bring. And I personally fundamentally think that it\u0026rsquo;s a failing to take a lot of credit in a situation like that. And so the satisfaction that I take and the value that I take from my job is really like seeing that people\u0026rsquo;s lives have gotten better or seeing that things suck less for people, rather than like really explicit validation in the form of props in a public channel or like recognition at an all hands or something like that. I don\u0026rsquo;t think that it\u0026rsquo;s Realistic to expect that those sorts of things will get recognized in quite that way. And like I said, I also do think that like to the extent that you\u0026rsquo;re looking for that sort of recognition, it\u0026rsquo;s going to lead you to not work on the right things.\u003c/p\u003e\n\u003cp\u003eDavid: So what we\u0026rsquo;re seeing is that the extent of recognition the staff engineer should seek is to not get fired.\u003c/p\u003e\n\u003cp\u003eJosh: No, I will say I\u0026rsquo;ve had co workers say included incredibly like personally meaningful and touching things about the ways that I have helped them and the ways that I have like shaped the perspectives that they take on things that like that is really like the most gratifying thing to me just to. There is a message that one of my co workers, a little speech that she gave at my one year anniversary at the all hands last year that I still have saved because it was just like it was one of the most touching and gratifying things that anybody\u0026rsquo;s ever said about me.\u003c/p\u003e\n\u003cp\u003eDavid: Wow. To be clear, I\u0026rsquo;m of course being.\u003c/p\u003e\n\u003cp\u003eJosh: Facetious, but I get earnest about this stuff.\u003c/p\u003e\n\u003cp\u003eDavid: I do think that it\u0026rsquo;s interesting when I up level to staff and when I sort of started to get interested in discussing the staff level with other folks, I realized that like a frequent topic of conversation was sort of like performance reviews. And I thought that was sort of concerning. I\u0026rsquo;m like, is the reason that all these people have gotten to this level because they\u0026rsquo;re laser focused on getting good performance reviews? In fairness, maybe there\u0026rsquo;s an aspect of that, but I think there\u0026rsquo;s also or the causation might be reversed in the sense that I think what we\u0026rsquo;re touching on here is that it can be really hard, as you put it, Josh, to articulate the impact that we\u0026rsquo;ve had in the organization. Right. And in that case, especially for staff engineers that are joining a new organization or that have a new manager or something like that, the concept of performance reviews becomes pretty daunting. It\u0026rsquo;s like how do I show the impact that I\u0026rsquo;ve had? Right. So anyway, I think that\u0026rsquo;s kind of an interesting thread switching gears a little bit though. You\u0026rsquo;ve talked a bit about. It\u0026rsquo;s not your strength, but sort of how do you influence upward within your organization? But I think sort of the, the corollary is how do you influence your peers and the people that are in lower levels of the organization? Especially as a staff engineer, we\u0026rsquo;re not endowed with organizational authority. And so there\u0026rsquo;s to a certain degree we still get some of it, but I think there\u0026rsquo;s a lot that we have to do by just influencing people, convincing them that our ideas are good. And so I\u0026rsquo;m curious how you go about that.\u003c/p\u003e\n\u003cp\u003eJosh: Fundamentally, this is all about building personal relationships with people. That is really the key to me is being able to build an authentic personal relationship with someone and an authentic personal relationship in, like, the context of work. Right. Like, I\u0026rsquo;m not talking about, like, everybody\u0026rsquo;s got to be best buds outside of work or, like. Right. But within the context of work, it\u0026rsquo;s important to take people seriously as people and to respect them as. As humans, regardless of where they are on the corporate ladder, you know, like, how much experience or how little experience they have in the industry. Right. Like, you need to take everybody with that baseline level of respect and really be willing to listen to what they have to say. There are a few different ways that I approach that. One is when I present ideas, when I, you know, kind of talk through problems with people, I am very, very, very explicit that I don\u0026rsquo;t have all the answers, that there are cognitive blind spots that I have, that there are things that I don\u0026rsquo;t know about, and that to the extent that people are just like, oh, yeah, Josh is going to go off and do the thing and, like, it\u0026rsquo;ll be great. I\u0026rsquo;m like, no, it\u0026rsquo;s not going to be the. It\u0026rsquo;s not going to be that great. I can\u0026rsquo;t do the best work that I can do completely in isolation. Right. I depend on my co workers. I need their help to get us all to the best solution for the problem. That\u0026rsquo;s definitely a challenge with more junior people. A lot of junior people feel, in my experience, like, that they\u0026rsquo;re not necessarily qualified or, like. Right. They don\u0026rsquo;t feel comfortable with the idea of pushing back or even just articulating their opinions about something. But it\u0026rsquo;s constant work to reaffirm that. I want to hear what they have to say. Another part of it is I started up a n random channel in our company, Slack, because I wanted to. I mean, like, honestly, I just wanted a place to, like, share dumb jokes that wouldn\u0026rsquo;t make sense to people who, like, didn\u0026rsquo;t spend all their days programming, you know, like, technical articles that weren\u0026rsquo;t necessarily specifically relevant to the jobs that we\u0026rsquo;re all doing. Part of the way that I have leveled up over the course of my career is, like, I read about this stuff, like, for fun, you know, just like, kind of building that habit of, like, periodically, just like reading a blog post, even if. Even if it\u0026rsquo;s not about something, not about Anything that I ever expect to be dealing with in my current job. There are definitely been situations where it\u0026rsquo;s like years later I\u0026rsquo;m in a different job and I\u0026rsquo;m like, hey, wait a second, I remember I read a blog post in like 2013 about this thing. Let me go find it. So I started up the Enderandom channel so that I just have a place to put that sort of thing. I started up an engineering book club at work. It\u0026rsquo;s really, really, really valuable in my experience to have some sort of venue to share information that\u0026rsquo;s not in a like strictly task oriented fashion. Right. It\u0026rsquo;s not you are trying to accomplish this one specific thing. It\u0026rsquo;s just, hey, this industry that we work in is kind of cool sometimes and like people are doing some really interesting things. And like, sure. Like did I ever expect that I was going to necessarily need to know about like how databases were implemented at the file system level? No, not really. But it turns out that it\u0026rsquo;s actually kind of relevant to stuff that I\u0026rsquo;m working on now. Doing those things, like I said, that are not strictly task oriented. Being willing to just talk to people honestly. The other way that I do it is pairing. Pairing or mob programming is a really like, honestly, fundamentally the best way of teaching that I\u0026rsquo;ve ever found. It\u0026rsquo;s just really valuable to get on a zoom call sometimes with somebody and like just work through a problem together. Especially now in Covid times when like everybody is remote and like sometimes you need to see somebody else and like feel like you\u0026rsquo;re not alone working on the problem by yourself.\u003c/p\u003e\n\u003cp\u003eDavid: Cool. There\u0026rsquo;s lots that I would dig into there, but we\u0026rsquo;re getting close on time. Kind of two questions that we try to ask everybody. And the first one is for someone who\u0026rsquo;s sort of interested in either becoming a staff engineer or who is already a staff engineer but who wants to be better at it. What are like the resources that have influenced you or that you would recommend? So that could be like people or it could be, you know, blogs, books, podcasts, et cetera. Where would you point folks?\u003c/p\u003e\n\u003cp\u003eJosh: The places that I generally go. I do find hacker news. Hacker news is. I\u0026rsquo;m not personally wild about the community there, but I do find that like the like just as a link aggregator, it\u0026rsquo;s a really great source. That\u0026rsquo;s probably the single best place that I\u0026rsquo;ve found of finding useful links in terms of communities. Will mentions this in the Staff Engineer book. The Rans Leadership Slack has been like, honestly, a cheat code for me. It is the single most valuable resource that I have found anywhere, not just in my career. Like, I do not know of anything else like it. I always want to challenge the premise of the question, and I would say that if you want to be a staff engineer, well, you\u0026rsquo;re almost asking the wrong question. I don\u0026rsquo;t think that it\u0026rsquo;s something that you can necessarily set out to be. And then to the extent that you make that an explicit goal, I almost feel like it\u0026rsquo;s going to lead you in the wrong directions. Because the fact of the matter is that the things that really get, and unfortunately a lot of organizations, the things that get you promoted are not actually necessarily solutions to the problems that everybody have. They\u0026rsquo;re the things that are easiest to articulate. The value of learning the skills of figuring out where the pain points in an organization are, figuring out how to talk to people to figure out what the pain points are, in my experience are really the most valuable skills. And I mean, this is obviously also to a certain extent, self serving because it\u0026rsquo;s how I\u0026rsquo;ve done it.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s a really interesting response to that question. So the last question that we ask is how much time you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eJosh: That totally varies. There have been periods where I\u0026rsquo;ve spent days coding, much less frequent at this point. And there have been specific projects where like the work that I\u0026rsquo;ve been doing has been actual coding. But if I were to look at. So I\u0026rsquo;ve been at lob for a little over 18 months now. If I were to look at the amount of time that I\u0026rsquo;ve spent spent coding at this job, honestly, I\u0026rsquo;d be shocked if it even hit 33% of the time. Maybe not even 20% of the time. Like that is not the focus of my job at this point.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Thanks for being here.\u003c/p\u003e\n\u003cp\u003eJosh: Thank you for the invite. This is a really great conversation and I was really honored that you invited me to come on.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value of this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-10-05T09:00:00-05:00","date_modified":"2021-10-05T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/ben-edmunds-wayfair/","url":"https://podcast.staffeng.com/season-1/ben-edmunds-wayfair/","title":"Ben Edmunds (Wayfair)","summary":"I use the skills [of a manager] every day... as a staff engineer, you might not be managing people, but you're influencing people and working very closely with people.","content_html":"\u003cp\u003eDuring today’s conversation, we speak with Ben Edmunds, Senior Staff Engineer at Wayfair. You’ll hear all about his role at Wayfair, from his day-to-day active projects and how he goes about setting OKRs to the legacy and new deploy tooling he uses, and the method he has adopted to guide engineers. Ben shares ample advice for young engineers and stresses the value of learning more than one coding language. He reveals the finer details of life at Wayfair and the tools he uses to make sure that goals are reached, which include surveys, direct conversation, and partnership. We talk about the role of auxiliary engineering, the templates engineers build for application in partnership with an engineering team, and Ben points listeners in the direction of topics they should research, depending on whether they are looking to improve their software engineering or technical leadership skills. We hope you join us for an action-packed episode today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"http://benedmunds.com/\"\u003ebenedmunds.com\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/benedmunds\"\u003e@benedmunds\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9206703-ben-edmunds-wayfair.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Sure. Today\u0026rsquo;s guest is Ben Edmonds. Ben is a senior staff engineer at Wayfair where he works on the platform team. I appreciated Ben\u0026rsquo;s take on influence over authority. So let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: All right, Ben, well, thank you so much for taking the time to chat with us today. We\u0026rsquo;re really looking forward to it. If you could start by just kind of telling us who you are and what you do.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, thanks for having me. I\u0026rsquo;m Ben Edmonds. I\u0026rsquo;m a staff engineer at Wayfair. Yeah, so I mostly edit YAML and talk on Zoom most of the day, but every now and then there\u0026rsquo;s something more interesting.\u003c/p\u003e\n\u003cp\u003eDavid: How would you sort of describe your day to day? I mean, beyond editing Animal?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, it depends a lot on kind of what the currently active projects are right now. Leading a project to decompose our monolith. We have a older legacy PHP monolith that\u0026rsquo;s grown rather large, and we\u0026rsquo;ve had an effort for the past couple years to move people to decoupled applications and a newer ecosystem. And now we\u0026rsquo;re at the stage where we\u0026rsquo;re trying to really target getting rid of that monolith instead of just letting people kind of naturally migrate away. And so with that, I\u0026rsquo;m coordinating across a lot of teams, a lot of trying to source interesting projects that will help the effort or convince people to work on the project. So as a engineer, it\u0026rsquo;s a lot of convincing and getting people excited more than telling them what to do.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. When you say YAML, I\u0026rsquo;m curious, does that mean that you feel like you work more on the infrastructure side of things or the application side, or do you sort of like, straddle the divide?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, it\u0026rsquo;s a joke. We say because I\u0026rsquo;m in a developer platforms department. Right. And so a lot of our day is abstractions on top of abstractions to help people deploy or work with infra in some way. And so a lot of infra now is ran on YAML Configs and you know, love it or hate it, it\u0026rsquo;s kind of the world we live in.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, for sure.\u003c/p\u003e\n\u003cp\u003eBen: It gets torn, you know, some weeks I\u0026rsquo;ll code a bit, other weeks I don\u0026rsquo;t code at all.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So would it be safe to say that you sort of build products for engineers in your. In your organization?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah, definitely. So I\u0026rsquo;m on the PHP platforms team. We support the. I think we have about 1200 php engineers and then we\u0026rsquo;re inside the developer platforms and we have over 3,000 engineers total. And so we\u0026rsquo;re building tooling and systems for those engineers to use to make them more efficient and productive.\u003c/p\u003e\n\u003cp\u003eAlex: Is there a typical approach to being a staff engineer in your organization?\u003c/p\u003e\n\u003cp\u003eBen: I wouldn\u0026rsquo;t say so really. It really depends on your department and your team. We have competencies that we kind of align against in general Wayfair. And a lot of that is where your scope of influence is. So as a staff engineer, you\u0026rsquo;re expected to influence multiple teams working towards your department\u0026rsquo;s goals. And then as you go up the chain like a principal engineer, you\u0026rsquo;re expected to influence the whole company. Right. And so a lot of it\u0026rsquo;s based on that. And the day to day can change a lot based on the team and the projects. Really whatever\u0026rsquo;s the most leverage towards that scope. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: And do you feel like, are there any particular qualities of how you approach staff engineering? Like. Like when you moved from, you know, being more code for focused to being staff engineer, you know, what did you find striking about being, you know, the role being different? I guess.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. I\u0026rsquo;d say it\u0026rsquo;s a interesting challenge in like resetting your expectations for what a productive day is. Right. So before it was pretty easy. You get that dopamine hit of shipping something cool or how many commits you have or how many tickets you closed or whatever. So staff engineering, it\u0026rsquo;s really more about how can you make other people more productive or help their goals along. How can you unblock people? And so the goals change. But I do like that the kind of. The influence changes. Right. You can get more things done. Maybe you\u0026rsquo;re just not as deep into any one thing. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: When it comes to influencing other engineers, how do you feel like staff engineer is special in that regard? If any engineer could talk to any engineer, you know, they might have influence. But how do you feel like staff engineers use their influence specifically?\u003c/p\u003e\n\u003cp\u003eBen: Really? I guess you\u0026rsquo;re trying to use that influence for a broader problem. A lot of times that problem is something the engineer cares about, but not always. Right. And so you have to find a way to make that problem interesting to them or how does that problem help them in a certain way. And you have to really just like find the people that need the thing that would like to work on the thing and help them do that. A lot of times they don\u0026rsquo;t even know about it yet, especially as a platforms team. Right. Like we\u0026rsquo;re building a lot of things and you know, there\u0026rsquo;ll be tons of engineers just don\u0026rsquo;t know about the things yet. And you can send out all the releases you want and they might not see it. So a certain part of it is really connecting people.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. I\u0026rsquo;m curious to sort of pin this back to some concrete projects just as examples for folks to keep in their head as we\u0026rsquo;re, as we kind of continue to talk through abstractions. So one project you mentioned is, I think you said untangling the monorepo or was it decoupling the monolith? I think oftentimes those happen at the same time. Can you, if you\u0026rsquo;re comfortable giving more details on that project or if there\u0026rsquo;s sort of another project that, that would make a better example. But I\u0026rsquo;m curious to sort of know more about projects that are cross cutting and where you\u0026rsquo;ve sort of had to, had to coordinate with a lot of different stakeholders to make it happen.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, sure, I can get a couple. One other example is we build templates for applications, right. So I want to generate a new application and so I want to start with all these things that automatically work with our intro. The mistake a lot of platforms teams make is just kind of making that in a silo and then pushing that out for people to use. What we really try to do is partner with an engineering team that\u0026rsquo;s already doing something in that space. And so like last year I was working on a new template for Kafka and so we partnered with an engineering team that was working with Kafka a lot. And we worked very closely with them. I worked with them to build out that template, to test it with their teams. And then we published that for more teams to use. That\u0026rsquo;s one way we work with other teams. But at the same time we\u0026rsquo;re accomplishing our goals of shipping a template for more people to use. If we weren\u0026rsquo;t involved in that mix, maybe that team would have built a template, but it would probably only stay inside their org or their pot of teams. It probably wouldn\u0026rsquo;t go out to the rest of the engineering org.\u003c/p\u003e\n\u003cp\u003eDavid: And in that example, once the template is available. What\u0026rsquo;s the process for driving adoption?\u003c/p\u003e\n\u003cp\u003eBen: A lot of it. We go for organic adoption. We try to follow the diffusion of innovations model, which means you can have early adopters and then you go through a cycle until eventually you get the adoption you\u0026rsquo;re going to get. Different things call for different amounts of us driving that. Right. Like the Kafka template. It\u0026rsquo;s kind of, if you need it, it\u0026rsquo;s there for you to use. We have the central location you can go to build new applications and you\u0026rsquo;ll have it as an option there. There\u0026rsquo;s not much we need to drive that for the other project dimension, like the monolith, there is a lot of driving of that. It\u0026rsquo;s a lot of convincing teams that they should do a thing and then helping them be successful doing the thing. And it\u0026rsquo;s a big problem. So I kind of bash my head against the desk sometimes trying to figure out what the next step is for that. I\u0026rsquo;ve been describing it as like, it\u0026rsquo;s a Gordian knot. And so I\u0026rsquo;m just pulling threads all day. I don\u0026rsquo;t exactly know which thread\u0026rsquo;s going to lead to a bigger section of the knot coming undone. And that\u0026rsquo;s what a lot of it is.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. You mentioned the diffusion of innovation model, and I think oftentimes that\u0026rsquo;s, you know, that makes sense. And that\u0026rsquo;s the. That\u0026rsquo;s sort of the only thing past a certain scale. That\u0026rsquo;s sort of the only option that works inside organizations. But drawback that I\u0026rsquo;ve observed with that approach is that you can end up having sort of lots of different versions of the thing in use at the same time. Because, you know, you\u0026rsquo;ve got. You got some early adopters and you\u0026rsquo;ve got some late adopters, and they\u0026rsquo;re all kind of using different versions of the thing that you\u0026rsquo;re trying to improve. Have you faced that? And like, is that just sort of the cost of doing business in your mind, or do you have sort of some thoughts around how to mitigate that?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, we\u0026rsquo;re still figuring that out in a lot of ways. So we\u0026rsquo;ve been very much a growth company and we\u0026rsquo;ve gotten larger and larger. Right. So that problem became bigger in probably the last year or two than it was previously. Right now we\u0026rsquo;re doing a lot of work to automate the process just to make it easy to do the right thing. So if you\u0026rsquo;re on an outdated version, you\u0026rsquo;ll get an automated PR that upgrade you to the latest version of the thing. You\u0026rsquo;ll probably get a notification via Slack or email that tells you to upgrade the thing. And we\u0026rsquo;re just trying to really make that just easy to do. And then we are starting to define some rules for, like, for this subset of things like, say, Docker images. We\u0026rsquo;ll support two versions back or X versions back, just to gain a little control over that.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So I feel like you\u0026rsquo;ve talked about this a few times, or we\u0026rsquo;ve touched on it, like, sort of like making it easy to do the right thing. You talked about a Gordian knot. You talked about, you know, you want to. The diffusion model. All of these things feel a little amorphous. They\u0026rsquo;re not like one plus one equals two, or like, I can\u0026rsquo;t judge my success by how many PRs I\u0026rsquo;ve submitted and stuff like that. So I\u0026rsquo;m sort of curious, in that sort of amorphous space, how are you making sure that the work that you do is aligned with your organizational goals?\u003c/p\u003e\n\u003cp\u003eBen: Right. That\u0026rsquo;s a great question. And I guess it differs. So we\u0026rsquo;re in a process right now where we go through every six months and we kind of evaluate what our department\u0026rsquo;s goals are, and then we feed that down to teams and we set goals against that. So we use OKRs on my team. Different teams and Wayfair use different things, though. And so we\u0026rsquo;ll set okrs that say, you know, we want to drive. Let\u0026rsquo;s say we\u0026rsquo;re driving adoption of a template. We would say we want 10% of users, for example, to be using that template. And then throughout that quarter, we would have projects that target that. So one project might be some kind of automated system to move people from their old thing to the new template. And then we would track our progress against that. A lot of times that doesn\u0026rsquo;t work. Right. And so that\u0026rsquo;s. That\u0026rsquo;s where the data is helpful. So we might say, oh, well, we\u0026rsquo;ve only got 5% of users, and we\u0026rsquo;re not really ticking up from there. That means either our goals are bad, you know, we need to rethink it, or it means that we need a new approach towards that goal. So we might throw out a new project that tries to tackle it in a different way.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So in an example like that, where you set a 10% goal, is that a moment where you might say, why do the engineers not? Or, how could I make this something that an engineer would find more valuable? What\u0026rsquo;s interesting is that sometimes it feels like our goals are pretty static or number driven. But the model, by which we achieve our goals is super amorphous. How much do you think about a developer, the value the developer sees from the things that you build as the means to achieve your goals?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, that\u0026rsquo;s almost the only means. Right. We have a very strong culture. We don\u0026rsquo;t tell people what to do. For the most part, engineers have full autonomy to choose their tools in their stack. So as a platforms team, if our tools aren\u0026rsquo;t the best tools, they\u0026rsquo;ll just use something else. And they\u0026rsquo;re free to do that most all they want as long as it works in our infrastructure. So that\u0026rsquo;s really the ultimate goal. We have a few tools for that. We have surveys, we have talking to people directly. We have the partnership aspect. Then one other thing we do a lot is called auxiliary engineering. And so that\u0026rsquo;s where we\u0026rsquo;ll take an engineer, we\u0026rsquo;ll embed them on a team that\u0026rsquo;s doing a thing, and they\u0026rsquo;ll work with that team for maybe a quarter or set engagement to make that thing. Right. So we\u0026rsquo;re saying templates. They\u0026rsquo;re making a new app using that template. We would embed, embed an engineer on that team to work on that new app. And then that gives us a ton of feedback that we wouldn\u0026rsquo;t usually get because you\u0026rsquo;re actually in the weeds working with them on that thing. And then they will come back to us and we\u0026rsquo;ll take all that feedback and use that to feed our next approach.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s cool. Have you ever been in a situation where your team has identified that some set of tools or some infrastructure is continually delivering less than awesome outcomes? You would really love to help people use a new kind of infrastructure. How do you close that gap between, if anyone can choose anything, how do you help make sure that folks are using the best stuff or the stuff that produces the best outcomes?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, a lot of it goes back to making it easy to use those best things and then if they\u0026rsquo;re good enough, people will migrate there. Right. So like deploy tooling, for example, we have some legacy deploy tooling, as most companies do. We have newer deploy tooling. The newer deploy tooling obviously saves you time. We have data on the velocity it gains to teams. Right. And so just by making sure we\u0026rsquo;re publishing that information, keeping out there about how much better this new deploy tooling makes your life, teams migrate more and more and then it\u0026rsquo;s a snowball effect. Right. So you get the first several teams to use the thing and if they\u0026rsquo;re finding value from it, they tell other people about it. Then the snowball continues, they tell other people and then adoption tends to go from there. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious, does your team ever have to take the last 5% over the finish line?\u003c/p\u003e\n\u003cp\u003eBen: Yes. So a lot of that comes down to just setting a deadline. Right. We\u0026rsquo;re not supporting this thing after X date and I\u0026rsquo;m really sorry, but it\u0026rsquo;s going away and then it becomes a rather manual process of, hey, you\u0026rsquo;re getting a bunch of notifications or maybe we\u0026rsquo;re reaching out one to one to those teams that are left on there saying, hey, you need to get off, we\u0026rsquo;ll help you. We got to do this by this date.\u003c/p\u003e\n\u003cp\u003eDavid: Something that strikes me about that is that in order to identify the teams that are using like the old version of the thing, you need probably a programmatic way of identifying usages of the thing and you probably also need some way of tying those usages back to the owning team. Can you describe a little bit about how that works at Wayfair?\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So we have different approaches for our Monorepo and our decoupled apps. I\u0026rsquo;m working through that a bit. So the Monorepo, it\u0026rsquo;s actually part of the project we\u0026rsquo;re working on now, is tooling to help identify those things and alert you and then escalate those alerts to make sure the proper teams see it. There\u0026rsquo;s a bit of an ownership issue there. Right. So it\u0026rsquo;s something that\u0026rsquo;s so large and has grown over time that it can be a more difficult problem to sort through. In the decoupled space of my team owns this one repo with this one app. It\u0026rsquo;s a bit of an easier problem because you know who the collaborators are on the project and then you can notify them. We\u0026rsquo;re utilizing a lot of GitHub for that, so we\u0026rsquo;ll have automated issues that are published. If you\u0026rsquo;re out of date, we might have an automated PR that gets sent to upgrade you. Yeah. And so in the newer ecosystem we have a lot more automation around that and we\u0026rsquo;re constantly building more.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting when it comes to sort of this type of project, like introducing the Kafka templates or starting to untangle a Monorepo. You know, there\u0026rsquo;s obviously we talked a little bit about sort of how you achieve alignment with your organizational leaders, things like OKRs. But how do you get buy in from the teams that are actually going to be doing the work?\u003c/p\u003e\n\u003cp\u003eBen: A lot of that is through the partnership and the value. Right. Like for the most part we don\u0026rsquo;t push things down. There\u0026rsquo;s very few projects that come top down. Most all of them come more bottom up. So if we can\u0026rsquo;t convince you to do it just because it adds more value to you, then you\u0026rsquo;re probably not going to do it and you\u0026rsquo;ll have to do it. So it really comes down to that. We try to think of our development platforms team really as a startup and the engineers as the customers. You don\u0026rsquo;t have to go use Heroku. That doesn\u0026rsquo;t make your life better, but if it makes your life better, you\u0026rsquo;ll use it.\u003c/p\u003e\n\u003cp\u003eDavid: And what\u0026rsquo;s the process for sort of making sure that you\u0026rsquo;re doing that, that you\u0026rsquo;re making your customers lives better?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, a lot of feedback. I spend hours a day talking to people, right. Like getting feedback or working with them on projects. A lot of partnering with teams. So someone\u0026rsquo;s struggling with something, we\u0026rsquo;ll jump on and help them do the thing, or they\u0026rsquo;re doing something new. That\u0026rsquo;s a constant process of iterations. Working with teams do a lot of workshops as well, on my team in particular. So we\u0026rsquo;ll have, let\u0026rsquo;s say, through the template building process. Back then we had weekly workshops, so we\u0026rsquo;d pick a different team each week and just sit there with them while they tried to boot up a new template and get it working and take feedback the whole time. And so we did probably five to 10 user workshops for the first version of that template just to get it smoothed out. A lot of times that smooths out our docs as much as it smooths out the actual code or the actual template. And we found that pretty helpful because it\u0026rsquo;s really easy to skip things in docs, especially if you know how something should work. But when you have someone with fresh eyes coming in, it\u0026rsquo;s immediately apparent what\u0026rsquo;s missing from the docs.\u003c/p\u003e\n\u003cp\u003eDavid: So that workshop approach sounds really interesting. Can you say more about, like, how it works?\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So the, the hardest part of it usually is finding the, the teams that can dedicate time. Right. And so we\u0026rsquo;ll try to line up several teams over several weeks. We usually do one per week because.\u003c/p\u003e\n\u003cp\u003eDavid: And what\u0026rsquo;s, what\u0026rsquo;s the ask there like, when you\u0026rsquo;re looking for teams that can dedicate time, Are you, first of all, are you talking to their managers? Are you talking to engineers in the team? And then is it like, are you trying to find people that have a use case that lines up with the thing, or are you like, fine with sort of pretending to do the thing just to sort of get them working.\u003c/p\u003e\n\u003cp\u003eBen: Through the paces, it mostly depends on the project, ideally is someone that would actually use the thing at the end of it. Right. And so we\u0026rsquo;re almost always talking straight to engineers. So with that Kafka template, we looked for engineers on teams that had a Kafka app or would maybe be making one in the near future. The ask of them was really to devote at least an hour a week, maybe a couple hours if there was some follow up, to sit on a video call with us while they tried to boot up the app, be very detailed and very, very much a critic of the software. Just be brutally honest with everything happening so that we could take that feedback away. Usually we would have a workshop with them one week and then we have a follow up the next week where we fix the issues they found, have them try it again. So you\u0026rsquo;re looking at probably a couple hours for each person that commits to depends on what it is. Right. If you can even do it in an hour. So the templates, they take 20 minutes to boot up a new app with a template and really poke around and try it out and all that. So an hour was enough time to get some feedback in the process, work through a couple of things and really see it through. And then we tried to line up several teams to do that. So you get a lot of different perspectives on that. We consider our customer the senior engineer at Wayfair, not necessarily a manager, even another staff engineer. So we try to really target those senior software engineers.\u003c/p\u003e\n\u003cp\u003eDavid: It\u0026rsquo;s interesting that you mentioned sort of the follow up session a week later and showing that you fixed the problems that came up in the first session. I imagine that as you sort of do this with multiple teams, the number of fixes sort of compound one of the challenges that I found working in platform teams has been sort of closing that loop and informing users of all the improvements that have been made over time or whatever. Like, especially if you have sort of some folks that are carrying preconceived notions about a thing that was, you know, suboptimal a few iteration cycles ago and now it\u0026rsquo;s great, but they don\u0026rsquo;t know that it\u0026rsquo;s great. And like, do you have a strategy for sort of that marketing side of the job, like promoting improvements that have been done without getting too noisy?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I don\u0026rsquo;t know what to do other than just follow ups. Right. So we tend not to do more than the one follow up with the same team. Sometimes we will based on all the feedback. It\u0026rsquo;s probably a problem if we\u0026rsquo;re giving you something that has so much feedback that we can\u0026rsquo;t fix it in a week or two though. Right. So that maybe means we weren\u0026rsquo;t quite ready for the workshops then. Usually we\u0026rsquo;ll go through several workshops. We\u0026rsquo;ll see the feedback kind of diminish over time. And we don\u0026rsquo;t wait for it to have zero feedback or zero issues. We wait for it to be at a real MVP kind of place. And then we\u0026rsquo;ll keep it rating on at release. But then we\u0026rsquo;ll release it and we\u0026rsquo;ll follow up with everyone that workshopped it. We\u0026rsquo;ll usually include them in the release, you know, as someone that contributed to it by being a part of the workshop. Just a bit of the kudos for being a part of the process. And then ask them to reevaluate it. And, you know, maybe they do, maybe they don\u0026rsquo;t. Hopefully they do.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. You focused a lot on sort of this idea of like organic adoption by virtue of providing value. And I think that sounds really great. Like in the ideal case, you also mentioned that sometimes you have to sort of take away support for things and let folks know that their approach will no longer be supported. I can imagine that sometimes, like, it\u0026rsquo;s even a stricter case than no longer supporting something. Like, sometimes you actually need teams to actively move away from something. Let\u0026rsquo;s say there\u0026rsquo;s like a security or reliability drawback to the previous version of the thing. Is that something you\u0026rsquo;ve encountered? And if so, what\u0026rsquo;s the strategy there? Like, how do you sort of impose these asks on other teams?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, so we\u0026rsquo;re still actively working on tooling for this in some of our environments. But what we\u0026rsquo;re working on now is a process to where you have a deadline. So let\u0026rsquo;s say the deadline is end of year. You would start getting warnings on your PRs if you use the thing. And then as the deadline approaches, we escalate that up. So the next level would be you start getting warnings if you use a thing that uses the thing. Right. So, like, if it\u0026rsquo;s in your dependency tree at all, you\u0026rsquo;ll start your warnings in your PRs. The next step after that is your PRs start getting blocked so you can\u0026rsquo;t merge. We work on a system, so we really care a lot about not gatekeeping. Right. Giving teams their own autonomy. And so the way we do that is you can unblock yourself the first time by just pressing a button in your GitHub PR the next time, that escalates up to your manager. And then the next time it escalates to their manager. And so the idea there is to apply pressure on a team and to keep there being a cognitive cost to ignoring this thing and also to apply that up to eventually department level. So the departments have to set aside time to take care of that. We haven\u0026rsquo;t hit it too often yet, but you know, there is an eventual step where you\u0026rsquo;re just blocked until you fix the thing at some point.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s, that\u0026rsquo;s a fascinating approach. Is that that tooling all custom built, like sort of the, the various escalations?\u003c/p\u003e\n\u003cp\u003eBen: Yeah. So it\u0026rsquo;s kind of the hard problem just we don\u0026rsquo;t have great ownership data in one place. Right. And so we have custom APIs that really like pull that information from various places and then feed that into a GitHub check on the PR and then that\u0026rsquo;s where it shows up.\u003c/p\u003e\n\u003cp\u003eDavid: Cool. So if I guess another sort of version of the same question is like, what\u0026rsquo;s the. Well, actually, do you maintain some sort of global visibility on this? Like do you have a way of tracking versioning for the things that you maintain across different teams? Sort of like the admin view of the, of the, of the view that individual engineers would see on pull requests?\u003c/p\u003e\n\u003cp\u003eBen: No, but we are working on it. So I don\u0026rsquo;t know if you\u0026rsquo;ve seen Spotify\u0026rsquo;s Backstage, which is kind of like a dashboard for your platform, as a service solution. Right. And so we\u0026rsquo;re working to integrate Backstage and we\u0026rsquo;re building that out. We have it now, but we\u0026rsquo;re limited on what we offer through there. But we\u0026rsquo;re slowly but surely building more and more into it so that you would actually have both a global dashboard maybe for your, your org, and then you could drill down to your team, could have a dashboard and we would track things like what\u0026rsquo;s out of date, what\u0026rsquo;s maybe being deprecated, what\u0026rsquo;s coming up that you need to update, things like that, that you would track across.\u003c/p\u003e\n\u003cp\u003eDavid: Very cool. This is, this is not, this is just out of curiosity. This is kind of a non sequitur. But are the separate repos that folks are sort of spinning up at Wayfair, is it still all the same tech stack? Like, is that all consistent? But it just sort of the code ownership is spread out between different repos.\u003c/p\u003e\n\u003cp\u003eBen: So we have four languages that we support officially and so that\u0026rsquo;s C Sharp, Java, PHP and Python. And then we have other. We just used here and there, but they don\u0026rsquo;t get official support. The, the overall stack stays the same. Right. So like we\u0026rsquo;re deploying to Kubernetes for all of those apps. But, you know, the. The actual implementation details might change based on the language. So, like, every language uses a different.\u003c/p\u003e\n\u003cp\u003eDavid: Framework, and so different teams own different repositories. But presumably there\u0026rsquo;s like, a way of sharing code between repositories. Is that like, by publishing packages or how does it work?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, so we use just libraries. Right. And we have an internal artifact server, and we share them through that.\u003c/p\u003e\n\u003cp\u003eAlex: Earlier you were mentioning that, like, you know, we talked a lot about delivering tools as a product. Right. That you see your team as a product builder and that you have users which are your senior engineers, and feedback is the mechanism by which you make this stuff better and you make it more valuable to your customers. And I was curious, do you have, like, an approach that you take to cataloging feedback? You know, do you have an approach for that?\u003c/p\u003e\n\u003cp\u003eBen: No, not really. I think H team does it slightly different. For the most part, I just use a Google sheet and try to somehow categorize and find patterns. But a lot of that falls back to my lack of organization skills a lot of times.\u003c/p\u003e\n\u003cp\u003eAlex: I mean, you know, like, I think a lot of people might not even keep Google Sheets. So there you go. That\u0026rsquo;s awesome. It\u0026rsquo;s interesting because it falls into an area of research. It\u0026rsquo;s like you\u0026rsquo;re doing qualitative research. You said there\u0026rsquo;s a survey which is quantitative, but I think we all recognize that surveys don\u0026rsquo;t give you that sort of clear understanding of why a person doesn\u0026rsquo;t want to use a thing. Or, like, you know, like, they\u0026rsquo;ll be like, no, I don\u0026rsquo;t use it. And you\u0026rsquo;ll be like, but why? Like, why don\u0026rsquo;t you want to use it? And so qualitatively, someone can say like, well, it doesn\u0026rsquo;t deliver this, this, and this. And so it\u0026rsquo;s really interesting. Have you found yourself using the sort of experience, you know, the stuff that you\u0026rsquo;re collecting in this feedback mechanism? How are you feeding it into your sort of, like, prioritization process to understand what you want to work on next?\u003c/p\u003e\n\u003cp\u003eBen: A lot of that comes from looking for patterns. So if we\u0026rsquo;re getting the same feedback very often, then that\u0026rsquo;s a, you know, good signal that we should probably focus there a little more. And then a lot of times we try to just feed the next thing, and then we\u0026rsquo;ll. We\u0026rsquo;ll put together potential projects for our next planning cycle, and then the team votes on and picks those projects. So I\u0026rsquo;m not exactly telling anyone to do It, But I will, you know, if I feel strongly about it, I\u0026rsquo;ll try to. To write a nice pitch for it, assuming that someone will pick it up if it\u0026rsquo;s compelling.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. And do you ever, like, compare the feedback that you get with other teammates of yours? How do you compare and contrast the sort of feedback that you\u0026rsquo;re getting from teams?\u003c/p\u003e\n\u003cp\u003eBen: Oh, yeah, mostly when we do that, we\u0026rsquo;ll do that as a team. Right. So, like the template workshops, I wasn\u0026rsquo;t just running that. I ran several of them, but there\u0026rsquo;ll be at least two members of their team on each one. And then we\u0026rsquo;ll trade out so that we all get experience running them and get the feedback and we\u0026rsquo;ll collect that feedback in one place.\u003c/p\u003e\n\u003cp\u003eDavid: Nice.\u003c/p\u003e\n\u003cp\u003eAlex: And do you. Earlier you mentioned that some of your engineers are embedded and it sounds like they\u0026rsquo;re sort of augmenting a project, but is that also like a feedback gathering experience where they get to have that in the trenches view of the work?\u003c/p\u003e\n\u003cp\u003eBen: Oh, yeah. It\u0026rsquo;s mostly feedback for us and then for the team, it\u0026rsquo;s really kind of culture changing. We don\u0026rsquo;t do those engagements just to augment a team. We won\u0026rsquo;t go in just to help a team do a thing. Our goal when we go in really is to. To affect a lasting culture change. So for the longest time, we had a team set aside that only did this for testing. So they would embed with the team to help them work on their testing processes and then they would lead that team in a better place, hopefully where they now have a culture of testing and they have the tooling and everything set up to do that better. Yeah, and they would, of course, take feedback back for the next one and to smooth things out. But that was really their goal in that process, was to change the culture of that team, not necessarily to help the team write the app or whatever the team cared about.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that\u0026rsquo;s cool. That sounds like a really big investment from the company\u0026rsquo;s perspective. How did the company decide to invest so much in testing that they actually started augmenting teams with more engineers? Do you know a little bit about how that happened?\u003c/p\u003e\n\u003cp\u003eBen: Not really. That was before I got here. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. No worries.\u003c/p\u003e\n\u003cp\u003eBen: In general, that process, I believe it was started as kind of an experiment, and. And that\u0026rsquo;s how we do a lot of things. We\u0026rsquo;ll have a hypothesis, we\u0026rsquo;ll try to do an experiment, we try to really coach it around. We think this thing might work. We\u0026rsquo;re going to try it and we\u0026rsquo;re going to collect data and see what happens? That was one of the things where we had data that this actually moves the needle. This actually works on affecting change. And so we\u0026rsquo;ve done more of it and it\u0026rsquo;s just grown from there.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. So if I understand what you\u0026rsquo;re saying is when you want to help move a team in a direction, you have lots of tools at your disposal, but actually putting an engineer into the team is a highly effective way of helping teams adopt new practices.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, exactly. And it kind of feeds back into the snowball. Right. So like if we do one team in say a super pod of 10 teams. Right. And so we embed and change the culture in that team, that will tend to spread out. So that team\u0026rsquo;s doing testing, you know, they\u0026rsquo;re happier, they\u0026rsquo;re enjoying it, their app\u0026rsquo;s working is more stable. Right. Assuming we meet those value props, then they\u0026rsquo;ll kind of evangelize that for us to the teams around them and spread that even further so we don\u0026rsquo;t have to embed with every team to do that. We just have to embed with select teams across the org and then watch that spread.\u003c/p\u003e\n\u003cp\u003eDavid: Cool.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really interesting. So, changing topics. One of the things we like to talk about is sort of like sponsoring and mentorship. Is that something that you do with engineers and you\u0026rsquo;re organization or outside of your organization at all?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I wouldn\u0026rsquo;t say it\u0026rsquo;s not structured, but it\u0026rsquo;s definitely something you do and are expected to be. As a staff engineer, a lot of my sponsorship lately has been around helping other engineers get started with public speaking and speaking at conferences or meetups and things like that. It\u0026rsquo;s something I\u0026rsquo;ve enjoyed doing for a long time and it\u0026rsquo;s nice to help other engineers get started doing that.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. How did you. What led you to help start sponsoring people around this topic specifically?\u003c/p\u003e\n\u003cp\u003eBen: It\u0026rsquo;s really something I\u0026rsquo;d like to see us do more of as Wayfair. Right. So like, when Wayfair recruiter originally reached out to me, I had no idea that Wayfair is one of the largest PHP shops around. Right. And it seems like a shame that more people don\u0026rsquo;t know that. And I assume they don\u0026rsquo;t if I didn\u0026rsquo;t. Right. So like, we\u0026rsquo;re solving a lot of really cool hard problems and I would just love for more people to know about that and, you know, hopefully come work on cool problems with me or, you know, at least we can have better conversations if there\u0026rsquo;s a little more knowledge out there of what we\u0026rsquo;re doing.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. I didn\u0026rsquo;t know that. And when I think of php, I think of Facebook and I think of Etsy and that\u0026rsquo;s. That\u0026rsquo;s in Yahoo.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, yeah, I was. I was the same way. You know, I don\u0026rsquo;t know the numbers, but we probably have more engineers than Yahoo now.\u003c/p\u003e\n\u003cp\u003eAlex: Yes. Do you mentor or sponsor people outside of sort of like public speaking at all? Is it always just public speaking or do you have like a range of stuff that you help folks out with?\u003c/p\u003e\n\u003cp\u003eBen: Yeah, that\u0026rsquo;s really just been the kind of my focus these past few months where I\u0026rsquo;m trying to help people. Being in this project I\u0026rsquo;m in right now, I don\u0026rsquo;t have a ton of time. Right. Like, I\u0026rsquo;m kind of stretched thin with what I\u0026rsquo;m doing. So that\u0026rsquo;s. I have to be careful where I\u0026rsquo;m spreading my focus in the past though, for sure. Mentoring a ton just throughout working on projects. Or maybe there\u0026rsquo;ll be an engineer that. Trying to grow in a certain area. It\u0026rsquo;s been a lot of like, an engineer wants to grow their career in a certain way. So we\u0026rsquo;ll help mentor them and then through the process, sponsor them for projects. Might help them along that path. Right. So, like, if an engineer is trying to grow from, say, senior to staff, really kind of work with them on what skill sets they need to do that, help them. If I see an issue that they should focus on, and then really just like, as a project comes up that might help them along that path, suggest them for it, talk to them about it, and try to put them up for that.\u003c/p\u003e\n\u003cp\u003eAlex: I have sort of like a random question. Maybe this won\u0026rsquo;t make the podcast.\u003c/p\u003e\n\u003cp\u003eBen: We\u0026rsquo;ll see.\u003c/p\u003e\n\u003cp\u003eAlex: I started my career in php. I actually worked at Yahoo. And I remember for a long time languages like PHP had this, like, negative connotation. Right. But when you look around, people were productive. They were productive in these languages. They made value with them. And I\u0026rsquo;m curious if a person was entering sort of like technology today and they were worried about the language that they choose. And I don\u0026rsquo;t think really anyone should ever worry about that. Think about producing value for your customers. It seems though, like, there\u0026rsquo;s lots of organizations that have senior engineers that have lots of experience and they\u0026rsquo;re building really big systems. What would you say to a person just starting out, like, you know about, like, don\u0026rsquo;t worry about the stereotypes or whatever.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I really don\u0026rsquo;t think you should. I\u0026rsquo;ve been doing PHP for, I don\u0026rsquo;t even know what, 12, 15 years now. It\u0026rsquo;s. People were Concerned about that when I first started using php and now, you know, it\u0026rsquo;s still going pretty well, you know, still plenty of jobs out there for it. There\u0026rsquo;s ebbs and flows. It\u0026rsquo;s very easy to start working something and then it just kind of dies off and then maybe it comes back later. I would probably shy away from choosing something super niche, right? So like, probably don\u0026rsquo;t pick something that\u0026rsquo;s like a third transpiled version of a language. Probably actually dive into the language itself and you know, like if you\u0026rsquo;re going to start with something, Maybe start with JavaScript instead of TypeScript for example. But again, I don\u0026rsquo;t think it really matters. Once you know one, it\u0026rsquo;s easy to pick up another. I don\u0026rsquo;t even know how many languages I\u0026rsquo;ve used over the years, but. But you know, I\u0026rsquo;m sure it\u0026rsquo;s a dozen, right? Like PHP could completely go away tomorrow and that would be fine. I would mostly advise people to like, don\u0026rsquo;t become just a single language engineer, really be a software engineer and pick up a few languages along the way. Be comfortable jumping around and that\u0026rsquo;s how you get real longevity in your careers. You\u0026rsquo;re not just stuck in that one niche. Cool.\u003c/p\u003e\n\u003cp\u003eDavid: Ben, we\u0026rsquo;re kind of wrapping up on time and there\u0026rsquo;s a couple of questions that we always want to ask folks. One of them is sort of if there are any resources and that can be like blogs, podcast, books, people, etc. That you would point other engineers toward if they want to sort of dig into some of this stuff.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, I\u0026rsquo;d say there\u0026rsquo;s probably two areas to focus on, right? Like if you\u0026rsquo;re trying to build your technical knowledge, I would focus more on things that won\u0026rsquo;t be short lived. So I would focus on like system design patterns, maybe some algorithm basics, you know, how a database works, rather than focusing on like what the newest, hottest framework is. There\u0026rsquo;s still room for that. But I would try to focus a little more underneath and then through trying to build up maybe your communication skills, your people skills in order to work towards staff engineer, I would actually recommend reading up on some management books. The time I spent in management has been invaluable to my work as a staff engineer because you just become a lot more comfortable with people and kind of jumping around more broadly and maybe at a shallower context. Whereas an engineer, I always like to dive very, very deep in things and that can be almost a detriment. So I would focus on those two rungs of the skills letter. As far as Actual resources for that rans and repose. Michael Laupp is. He\u0026rsquo;s got some great books and a lot of great articles. I found that pretty valuable. And then, you know, Will Larson have to throw out his name. He\u0026rsquo;s got some really great material. And then another one is manager\u0026rsquo;s path. I think that applies pretty well to the engineering side as well. You know, maybe slightly different, but it\u0026rsquo;s still very up.\u003c/p\u003e\n\u003cp\u003eDavid: That one\u0026rsquo;s Camille Fournier, right?\u003c/p\u003e\n\u003cp\u003eBen: Yeah. Cool.\u003c/p\u003e\n\u003cp\u003eDavid: So one thing that we didn\u0026rsquo;t touch on at all today, and, you know, I can\u0026rsquo;t. Can\u0026rsquo;t just drop it in at the end and then not. Not touch on it. Tell us about your time as a manager and tell us about how that has influenced your work as a staff engineer.\u003c/p\u003e\n\u003cp\u003eBen: Yeah, sure. So I was a manager for, I want to say, like, eight years. It was a while. I was a CTO of the last company I was at, and I was a director before that there. And so it was a dual role. Right. I was still very technical, but I was managing people. And there were times where I was coding and there, you know, there were months where I didn\u0026rsquo;t touch code at all, which is kind of scary as someone that considers themselves an engineer. Right. But really over that, I learned to focus on what matters to the business. And that\u0026rsquo;s not always, like the coolest project. Right. And a lot of times moving something else along is more valuable than just getting in and doing something yourself. I really learned to help unblock people and to focus on it as helping others instead of just getting things done myself. And that is where a lot of that change happened, between valuing the things I shipped that day versus buying the things other people ship that day that I helped them with. And, yeah, I enjoyed it. I defined it a bit emotionally taxing for me personally, you know, it\u0026rsquo;s. You have to judge that line between providing value to the business, but also making it, you know, a happy place to work and helping people through technical problems and all that. So I\u0026rsquo;m. I\u0026rsquo;m finding the switch to IC a little relating right now. It\u0026rsquo;s kind of nice to be able to focus in more on the technicals and dive a little deeper and not the people problems. But I. I do use the skills every day. Right. Like, as a staff engineer, you might not be managing people, but you\u0026rsquo;re. You\u0026rsquo;re influencing people and working very closely with people.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool to hear. Sort of along the same lines, you sort of dropped in there that you were the cto, which I think is even like. Is another thing on top of being a manager. Like, from my outsider perspective, it\u0026rsquo;s like, it\u0026rsquo;s about strategy. It\u0026rsquo;s about making sure you really understand what the business is, is trying to do. And I\u0026rsquo;m curious, have you taken away any skill sets from being the CTO and applied them as a staff engineer? As a senior? I see.\u003c/p\u003e\n\u003cp\u003eBen: Yeah. I think my focus on providing value definitely comes from that. Right. Like, as the CTO of the startup, if you don\u0026rsquo;t provide value, you\u0026rsquo;re out of the job. And I think a platform team is pretty similar. Right. Like, if we\u0026rsquo;re not providing value, people will build it themselves or go somewhere else for it, and then we\u0026rsquo;re out of a job in a way. So I think that\u0026rsquo;s where a lot of that real focus for me comes from. The other thing is probably just being able to jump around between different problems. It\u0026rsquo;s a large company. There\u0026rsquo;s a lot going on. And as a cto, you have to solve multiple problems for your users, usually. It\u0026rsquo;s helped me kind of have that dual focus.\u003c/p\u003e\n\u003cp\u003eAlex: So we have our final question, which is funny, we\u0026rsquo;ve actually kind of talked about it a couple times now, but, like, how much time do you find yourself coding nowadays?\u003c/p\u003e\n\u003cp\u003eBen: That\u0026rsquo;s a good question. Should I put this in, like, a month and a week and a day?\u003c/p\u003e\n\u003cp\u003eAlex: Whatever makes sense to you.\u003c/p\u003e\n\u003cp\u003eBen: So I have coded zero this week. I probably coded four hours last week. Yeah, a lot of the depends on the project. You know, last week I spent probably half my weeks coding most of the year. And then just as the projects change and I started working across different teams, that\u0026rsquo;s. That\u0026rsquo;s just not where my time was the most valuable. I do tend to, like, still go back to, like, this itchy feeling that I need to be coding, and then I have to remind myself, like, oh, that\u0026rsquo;s just not the best thing I could do today. These other things are more leveraged or better. And then if coding is the best thing to do that day, I\u0026rsquo;ll definitely do it. Nice. Well, thank you.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, thanks, man. This has been. It\u0026rsquo;s been lots of fun. That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy, Sa.\u003c/p\u003e\n","date_published":"2021-09-21T09:00:00-05:00","date_modified":"2021-09-21T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/nell-shamrell-harrington-microsoft/","url":"https://podcast.staffeng.com/season-1/nell-shamrell-harrington-microsoft/","title":"Nell Shamrell-Harrington (Microsoft)","summary":"There's three key words to always say when it feels like someone is objecting to what you're proposing: Tell me more.","content_html":"\u003cp\u003eToday’s guest is a principal software engineer at Microsoft who works at the interface between external and internal elements of the organization. Nell Shamrell-Harrington works on the ClearlyDefined open source project, which tracks open source licenses across open source ecosystems, and is also part of the Rust Foundation\u0026rsquo;s Board of Directors. In today’s episode, you’ll hear about the “field commander” role that Nell plays in both of these organizations, and some of the major learnings they have had along the way (with particular emphasis on the importance of ensuring that technical interventions are responding to the needs of the business and the community). Nell also shares their experience of mentoring veterans through Operation Code, their approach to mentoring in general, and how this impacts their day-to-day job. \u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/nellshamrell/\"\u003eNell Shamrell-Harrington on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://clearlydefined.io/about\"\u003eClearlyDefined\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://foundation.rust-lang.org/board/\"\u003eRust Foundation\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://operationcode.org/\"\u003eOperation Code\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/whereistanya?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor\"\u003eTanya Reilly on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/dbsmasher?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor\"\u003eSylvia Botros on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9116183-nell-shamrell-harrington-microsoft.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the staffenge podcast where we interview software engineers who have progressed beyond the career level, into staff levels and beyond. We\u0026rsquo;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 Nguylromis and I\u0026rsquo;m joined by by my co host Alex Kessinger. We\u0026rsquo;re both staff plus engineers who\u0026rsquo;ve been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Totally. Today\u0026rsquo;s guest is Nell Shamrill Harrington. Nell is a principal software engineer at Microsoft and Microsoft\u0026rsquo;s representative on the Rust Foundation\u0026rsquo;s Board of Directors. It was a treat to talk with Nell about all their roles and I think you will appreciate it as well. Let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eNell: Well Nell, thank you so much for.\u003c/p\u003e\n\u003cp\u003eDavid: Taking the time to chat with us today. If you could start by just kind of telling us who you are and what you do.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Sure thing. I\u0026rsquo;m Nell Shamrell Harrington. I\u0026rsquo;m currently a principal software engineer at Microsoft. I am split between working on a product called Clearly Defined. I lead engineering on it and that is a project which tracks open source licenses across open source ecosystems. So if you are using an open source project, want to check that the license is in compliance with the licenses that you can use, or if you\u0026rsquo;re getting conflicting information about what the license might be. We have Data Store where we store information about licenses. We have some automated ways we determine what the license is most likely to be, as well as having human curators who come in when needed. The other thing I work on at Microsoft is the Rust programming language. I am Microsoft\u0026rsquo;s representative on the Rust Foundation Board of Directors and prior to Microsoft I was at Mozilla. I was a senior staff engineer there working on the Rust language full time. And prior to that I was a principal engineer at Chef Software.\u003c/p\u003e\n\u003cp\u003eAlex: Wow, that\u0026rsquo;s like a lot of senior engineering roles. I\u0026rsquo;m curious, when you came to Microsoft, was the principal role explained to you? Like, did they have a set of expectations for principal engineers at Microsoft?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: They do. Microsoft is one of the first places I\u0026rsquo;ve worked at where they do have the role clearly defined and they do. I just use clearly defined the sense and that\u0026rsquo;s the name of the open source project I use. But where they do have it is a nice thing about big tech companies. They have clearly defined expectations for the levels. At least they do at Microsoft, which is nice.\u003c/p\u003e\n\u003cp\u003eAlex: Nice and I\u0026rsquo;m sure that if they\u0026rsquo;re well defined, there\u0026rsquo;s probably a lot of text there. But are there highlights that you could surface about what the expectations are of a principal engineer at Microsoft?\u003c/p\u003e\n\u003cp\u003eNell: Sure.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: The way I understand it, and of course my understanding might be different from other people\u0026rsquo;s because even though it\u0026rsquo;s written down, the way you can interpret it is a lot of subject to interpretation. So what I think of as a junior engineer, intermediate engineer role is you\u0026rsquo;re focusing on one part of one product or maybe just two or three products. That\u0026rsquo;s how I define a junior intermediate engineer, senior engineer. You\u0026rsquo;re focusing on the entire product or the entirety of two or three products. Once you get to staff principal, you\u0026rsquo;re focusing on an entire architecture, so an entire suite of products. Obviously at Microsoft, no one architects the entirety of Microsoft\u0026rsquo;s products. There\u0026rsquo;s way too freaking many of them. But you do, you are in a engineer, a technical leadership role over several products. And the cool thing about clearly defined the open source product I work on is it deals with, I like to say deals with ecosystems of ecosystems because we are analyzing and tracking license information across all sorts of language ecosystems. And it\u0026rsquo;s the same thing with Rust. It\u0026rsquo;s used in so many different contexts. So it\u0026rsquo;s, you know, you\u0026rsquo;re not laser focused on one thing. Like even though I do still do quite a bit of coding in my day to day role, it\u0026rsquo;s not laser focused all the time. I am more focused on where does this piece, this product fit in a larger architecture and larger ecosystem. And part of my role as principal is to keep that big picture within my head at all times and not indulge in my engineering tendencies of wanting to dive down deep on one specific part for days at a time. I have to stop myself from doing that because that\u0026rsquo;s not my role anymore. So that\u0026rsquo;s loosely how I would interpret how it is.\u003c/p\u003e\n\u003cp\u003eAlex: And it sounds like you\u0026rsquo;ve had senior engineering roles across multiple organizations. And I\u0026rsquo;m curious, does that understanding of principle, do you feel like that\u0026rsquo;s held similarly across all the places that you\u0026rsquo;ve worked or is it different across all the different places that you\u0026rsquo;ve worked?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: I\u0026rsquo;d say it has been different. I was at an org where they weren\u0026rsquo;t sure what a principle was, but they needed something to promote people beyond senior. So they had, you know, principal role in the, the career ladder, but it was more of a very, very senior coder role. Whereas other orgs, it\u0026rsquo;s, you know, there are some orgs where principals don\u0026rsquo;t code very much and it\u0026rsquo;s much more of an overall architecture role. And you know, at Microsoft I\u0026rsquo;d say it\u0026rsquo;s a combination. So there are some differences. Not every org I think understands what the role is or how it fits into their particular a small startup. I did three startups in a row before I went to Mozilla over nine years. Great experience but oh man was I tired at the end of it. But in that case there\u0026rsquo;s so few people that it\u0026rsquo;s a much more hands on technical role versus you go to a big tech company where it might be a hands on technical role or you might be in meetings all day. Again, keeping the big picture in mind and making sure all teams understand what that big picture is and know how they fit into it.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. And obviously given any sort of general description of a role, there\u0026rsquo;s probably the way that an individual practices that role is a little bit different. Have you thought at all about how your practice of being a principal is different from maybe the written down expectations that Microsoft has?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Right. I\u0026rsquo;d say in the role I\u0026rsquo;m in working with Rust, also working with Clearly Defined, which is a very much an open source project, I\u0026rsquo;m pretty public facing. I\u0026rsquo;m 99% sure that is not part of the written description of the roles at Microsoft. And again, you know, Microsoft 10 years ago had a kind of a toxic relationship with open source. I can tell you it has improved dramatically. It is not just hype, they have made a transformation. But yes, in my case it\u0026rsquo;s a very public facing role. So it\u0026rsquo;s not only internal engineers that I\u0026rsquo;m working with and leading the technical work of, it\u0026rsquo;s also community members, some from other customers, some from people who are interested everything from new boot camp grads who want to get their feet wet and open source to very senior staff principal engineers at Microsoft or at other big tech companies. So I\u0026rsquo;d say that\u0026rsquo;s the major difference for me in my role. From what\u0026rsquo;s written down.\u003c/p\u003e\n\u003cp\u003eNell: Cool.\u003c/p\u003e\n\u003cp\u003eAlex: And I\u0026rsquo;m curious, does being a principal engineer at a company inform your role in the Rust community and does your role in the Rust community inform how you practice being a principal engineer?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: It does what I said when I started on the Rust foundation board, which only started back in February or March. My job as a board member there is to represent the interests of Microsoft to the Rust community. That I am Microsoft\u0026rsquo;s representative, that is part of it. But more importantly it\u0026rsquo;s to represent the interests of the Rust community. Back to Microsoft. A part of that, the Rust community has a RFC or request for comments process. That is how we figure out changes in the language and changes in the ecosystem. And a lot of what I\u0026rsquo;ve been doing internally at Microsoft is, you know, coaching people through the RFC process. You know, this is how you write it, but more importantly, if it stalls, this is how you get conversation going and you want to do it with, with nudges. The Rust community responds much better to nudges than someone trying to come in and push their, their will or push their way on it. So I\u0026rsquo;d say it informs both of them. And that honestly has made it a little easier to advocate for changes within Microsoft is knowing how to define what the technical changes are, but also knowing just because we can doesn\u0026rsquo;t mean we should not. Trying to quote Jurassic park, but there it is. And it\u0026rsquo;s understanding that not everyone has the understanding. I can tell you this was public. We were looking at adding another source of Go components to clearly define or not GO components, maven components. And it involved crawling one of Google\u0026rsquo;s Maven repositories. I said, all right, we need to talk to Google first because if we\u0026rsquo;re crawling their thing, they don\u0026rsquo;t like it, they could conceivably block it from us. The response I got internally at Microsoft was, well, we can get around it through this way, this way, this way, this way. I said, I know we can, but that\u0026rsquo;s going to put a bad relationship in place and we don\u0026rsquo;t want to do that. Yes, we can technically do that. Should we do that? We probably should. I don\u0026rsquo;t think they\u0026rsquo;re going to say no, but we need to talk to the people, the technical people first before we actually do it. And that\u0026rsquo;s what we did and it worked out beautifully.\u003c/p\u003e\n\u003cp\u003eDavid: Out of curiosity, where is Rust used within Microsoft these days?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: All over the place. I can\u0026rsquo;t keep track of it. It\u0026rsquo;s very much still an experimental mode, I can say that. But there are several teams that publicly, I can say there are teams that are experimenting with using it where they would normally use C or using it to interact with old C. Windows is a giant code base. Office is a giant code base. Rewriting all the C. And Rust is not going to happen. But there are places where we can write new components in or even rewrite certain parts of old ones that have a lot of memory vulnerabilities. That\u0026rsquo;s one of the things Rust does best, is it prevents you from doing common memory insecure things. And so I\u0026rsquo;d say it\u0026rsquo;s still an experimental mode. The enthusiasm is there, which is fantastic, but now we need to make sure it translates into technical value, which I think we\u0026rsquo;re going to be successful in.\u003c/p\u003e\n\u003cp\u003eDavid: Okay, so jumping back into it, Nell, can you tell us a bit about sort of tactically what it looks like, what your involvement in the projects you\u0026rsquo;ve described looks like? So you\u0026rsquo;ve talked a little bit about your involvement with the Rust foundation and really curious to hear sort of what your day to day looks like with Clearly Defined.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Certainly. So part of it is through creating new features and a big thing I did when I came in, when I started at Microsoft in October, Clearly Defined had not had a full time engineer on it for about a year. It had been in maintenance mode and there was a lot of cruft that had built up and that happens. So a big part of my job I worked at Chef, I\u0026rsquo;ve worked as an infrastructure engineer, was figuring out what the infrastructure of Clearly Defined was, documenting it. And then we were having problems with bottlenecks, so was identifying where those bottlenecks are. What do we do infrastructure wise to make it better? Mostly Clearly Defined infrastructure runs on Azure. So that was my first project which was make the infrastructure that runs the sites and the crawlers and such work better. A lot of what I do is code review. We do have contributors both from within Microsoft and from external to Microsoft. So I am const scanning for pull requests. I review those. What I see as the role of code review is to make sure one, I mean the code is functional, which it usually is, and 2 there\u0026rsquo;s no security vulnerabilities that are introduced. 3, it\u0026rsquo;s repeatable or it makes sense to look at it. And there was a fourth one, but I can\u0026rsquo;t remember what it is off the top of my head. But it\u0026rsquo;s not trying to impose my personal preferences for how code should be. If it\u0026rsquo;s not something that\u0026rsquo;s going to affect the functionality or the security or the maintainability of the code. That was the fourth one, maintainability. So code review is a big part of it. Also defining architectures for new features or new additions to it and then also talking with the key users of Clearly Defined, which again includes engineers at other big companies. It includes people within Microsoft figuring out how they use it and how we can make it work better for their processes. Often that\u0026rsquo;s kind of the role of a product manager. I do a little bit of that, but it\u0026rsquo;s very much an engineer to engineer kind of communication and I do have a fantastic PM who does a lot more of the business to business communication, but it\u0026rsquo;s figuring out how to make it work better within the ecosystems that it functions in. That was a pretty long winded answer.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. No. So when you joined Microsoft and you knew that you were going to start working on clearly defined what was sort of like the mission that was described to you at the beginning.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Big part of it was so clearly defined is not technically owned by Microsoft, it\u0026rsquo;s owned by the Open Source initiative but Microsoft sponsors it in part by paying my salary to work on it. And one of the part of the mission that was handed to me was, you know, Microsoft is the primary user of this project. We don\u0026rsquo;t want it to be just a Microsoft used project. We need someone who yes, can work internally with Microsoft engineers on making it work better for their needs. But we and lead engineering with regard to other Microsoft engineers but we need someone who can also work with a community and make the project work better for the needs of our customers, other big users of it, and also make it work well as an open source project. I mean when I came in I would say at that point it was open code, the code was out there. But there wasn\u0026rsquo;t really a. And there hadn\u0026rsquo;t been for a long time due to nobody\u0026rsquo;s fault. I mean things change. But there hadn\u0026rsquo;t been a nurturing is how I put it of a technical community around it. So that\u0026rsquo;s not just the role of a traditional community manager. I\u0026rsquo;m not a community manager. I\u0026rsquo;ve been a community manager before, but that\u0026rsquo;s not my role at Microsoft. But they needed someone who could work on a technical level with other people who wanted to contribute to the project and also wanted to use the project. So that was the mission as it was laid out to me is make it work better for Microsoft but also critically form a technical community around it and make it work for their needs as well.\u003c/p\u003e\n\u003cp\u003eNell: Cool.\u003c/p\u003e\n\u003cp\u003eAlex: And help me connect the dots a little bit here. So what\u0026rsquo;s interesting is that I feel like you described something that was about sort of the code as it is in the repo, building partnerships across, you know, with outside partners. But earlier you were talking about how, you know, the code was a little bit. There was cruft, there were bottlenecks you had to run inside of Azure. So how did you go from community building aspect to optimizing it and making it run better in Azure? Or did I misunderstand that part?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: It was both. Both at the same time. Some community building we do bi weekly community meetings. We have a discord where people chat about the project and how to use it. And then it was also doing that in depth infrastructure work as well. So doing both simultaneously.\u003c/p\u003e\n\u003cp\u003eAlex: Okay, cool. So when you were working on the project, how did you ascertain that like infrastructure work was needed? And how did you explain to your stakeholders that like, this is something that we need to do?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: The first thing I always ask someone when I come into a project, whether it\u0026rsquo;s a contributor, whether it\u0026rsquo;s a user, et cetera, is what\u0026rsquo;s causing you pain. And often it\u0026rsquo;s a variety of things. And I talk to 10, 15 people or possibly even more and see where the common pain points are and then figure out, all right, what\u0026rsquo;s a quick. What\u0026rsquo;s something that we can make work better right away? One was enhancing the way that the curators, the way clearly defined interacts with GitHub. GitHub is where the curators do their work. Okay, quick win, we can do that. But what are common pain points that are not necessarily quick wins? And one was that the infrastructure was falling over occasionally and that was causing data to be corrupted or to be unreliable. And that took a couple of months. A lot of observation of it. Diving into logs. Nice thing about Azure is they have, I mean, well, I guess every cloud has really good log parsing software, but Azure\u0026rsquo;s I particularly like and looking for patterns. That\u0026rsquo;s one of the key things you do as a. When you\u0026rsquo;re trying to figure out, all right, we know there\u0026rsquo;s bottlenecks, we know this is falling over for some reason. This is distributed microservices architecture. We\u0026rsquo;ve got. They\u0026rsquo;re not called lambda functions in Azure, but now I can\u0026rsquo;t remember what they\u0026rsquo;re called. We\u0026rsquo;ve got serverless functions going, we\u0026rsquo;ve got a variety of databases, we\u0026rsquo;ve got several different containers going all at once. All right, this is falling down somewhere. Where is it falling down? And observability. I learned a lot from the people at Honeycomb about it. I didn\u0026rsquo;t use Honeycomb in this case, but I learned about the principles from them, which was let\u0026rsquo;s find the bottlenecks by observing how the application behaves. Again, nice thing about having a community was I put in discord. All right, if anyone sees this specific behavior, because this was something that\u0026rsquo;s happening in the middle of the night my time, please add something to this GitHub issue or just put something in Discord. So we have a timestamp on it and I can go back and observe what was happening at that particular time. That was a way to. Number one, I found out our MongoDB database. We were doing some very expensive queries on it and it was timing out. We had Cloudflare in front of it. Cloudflare. The request, understandably, can only take a certain amount of time. So cloudflare was timing out, but the user was seeing the cloudflare timeout error. They weren\u0026rsquo;t seeing the actual error in the application. That indicated the MongoDB query was taking too much time. So that was a big one. Other one was we found we had to scale laterally as well as. Or horizontally, excuse me, as well as vertically. And there were different problems that each of those solved. So again, long winded answer. But observing the application, tracing it to where people\u0026rsquo;s pain points were, what they told me about, and then devising solutions based on that, which often involve changing things in multiple places, which is something I\u0026rsquo;d like to improve over the year, which is ideally microservices. When you change one, you don\u0026rsquo;t have to change a bunch of them. That\u0026rsquo;s not the reality right now, but it\u0026rsquo;s something we can work toward.\u003c/p\u003e\n\u003cp\u003eNell: MongoDB performance issues, say Natsu.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Yeah, it\u0026rsquo;s very powerful, it does great things. But, oh my God, you did not want to query it the way you would query a relational database. And that\u0026rsquo;s some of what was going on.\u003c/p\u003e\n\u003cp\u003eNell: Yeah, exactly.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eNell: No, I don\u0026rsquo;t want to cast aspergens. I\u0026rsquo;ve used mongodb in anger many times, but it does a good job for what it\u0026rsquo;s made for. So one of the things that we often ask folks, and I\u0026rsquo;m curious, given that the sort of core of your work is involvement in open source. I don\u0026rsquo;t know how this will differ for your role, but a lot of the, you know, staff, plus folks that we talk to, a big part of their job is sort of gaining alignment with the organization. Right. I mean, I\u0026rsquo;m sure that\u0026rsquo;s a factor in your role too. I just don\u0026rsquo;t know what it looks like as much because you\u0026rsquo;re not necessarily working on Microsoft products. You\u0026rsquo;re, you know, you\u0026rsquo;ve been sponsored by Microsoft to participate in open source projects for the most part, from the sound of things.\u003c/p\u003e\n\u003cp\u003eDavid: And so I\u0026rsquo;m curious to get your take on that.\u003c/p\u003e\n\u003cp\u003eNell: How do you think about sort of organizational alignment? How do you make sure that, that the work that you\u0026rsquo;re doing aligns with what Microsoft expects from you?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Right. It is challenging because I\u0026rsquo;m not working on a piece of Windows. But I do know my work ties into Windows in that clearly defined is used by an internal Microsoft product called Component Governance, which is used, as far as I know by all products at Microsoft to ensure that the licenses in the open source software we use are compliant with Microsoft standards. Like we don\u0026rsquo;t really want to use gpl. Yes. Microsoft builds commercial software. It always has. So my work is more of an interface to the rest of the organization. And it took me a little bit to figure out that\u0026rsquo;s what it was. That said, when you\u0026rsquo;re a principal at Microsoft, after you\u0026rsquo;ve been on the job six months, they have you go through a Microsoft Leadership 365 evaluation thing. It\u0026rsquo;s basically not 365. There\u0026rsquo;s too many Microsoft 365 products. Microsoft.\u003c/p\u003e\n\u003cp\u003eNell: It would be perfect if it was called Leadership 365.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: I know, I know. Three hundred and sixty. Why do we call 365 but 360 principles. So there\u0026rsquo;s a survey of your co workers, other people who work with you, your manager basically trying to figure out where your strengths are and where the things you need to work on. What I found, what I need to work on most is to use a military analogy, I do volunteer work with the U.S. marines. I work the veterans nonprofit. I know some people have some visceral reactions to using a military analogy. But I do think it\u0026rsquo;s appropriate in this case, which is I\u0026rsquo;m very used to being a field commander kind of role, which is I am working with one team or maybe three or four teams. Someone else has set out the vision. But it\u0026rsquo;s my job to figure out how we execute it and use the strengths of my team. I set goals for the team or the teams themselves. But to use those strengths to execute this other person\u0026rsquo;s vision. However, what I need to work on is being the person who sets that vision and understanding how it fits into the larger overall story of the organization. Again, as I said, Microsoft giant company, 150,000 people. That\u0026rsquo;s a challenging thing to do. But there are clear lines in what I do to nearly everything else that. Not clear lines, dotted lines in what I do to nearly everything else that Microsoft does.\u003c/p\u003e\n\u003cp\u003eAlex: Does.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: So it\u0026rsquo;s a challenge. It\u0026rsquo;s something that I\u0026rsquo;m working on and it\u0026rsquo;s something I have a fantastic manager, Stormy Peters, who is the director of Open source at Microsoft. I\u0026rsquo;m learning how to do that. So it\u0026rsquo;s a work in progress, I would say.\u003c/p\u003e\n\u003cp\u003eNell: Yeah, that\u0026rsquo;s fascinating. I Hadn\u0026rsquo;t really considered the aspect of clearly defined being used so heavily internally. But it makes a lot of sense. And I haven\u0026rsquo;t contemplated sort of the impact of like all these licenses kind of leading through all the open source code that we all depend on every day for our work. But that\u0026rsquo;s interesting, kind of along the same, well, the flip side to that coin. So if you\u0026rsquo;re not seeking alignment from above you in the organization, the other thing that we all sort of find ourselves needing to do is getting the teams that we work with aligned on the work. Right. And I think yours is an extra interesting challenge because in addition to people that share sort of reporting chains with you, there are also people that you work with or that you want to, that you seek to influence, who are, you know, open source contributors from elsewhere. And so what approach do you take to sort of gain alignment? You know, you talked about sort of executing a vision, whether it\u0026rsquo;s your vision or a vision that you\u0026rsquo;ve inherited, but like you sort of need to market that to the troops, so to speak, to continue the analogy and sort of what does that look like for you?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Right. That is a challenge. It was a big challenge when I was working at Chef. That was one of the key things or one of my last big projects my last year there was all right, how do we make these products? We had several open source products work for our internal business needs while not alienating our community and making sure that it works for their needs as well. And I\u0026rsquo;m going to first off say that is hard. And I don\u0026rsquo;t think anyone has figured out how to do it perfectly yet. That said, the absolute best thing that you can do is listen a lot. I have again, engineer tendency. I have to stop myself from getting caught up in trying to, in saying this is what we\u0026rsquo;re going to do and this is technically superior because of this. Because ultimately, from a business standpoint, technical superiority does not matter if it doesn\u0026rsquo;t meet the business need. Technical superiority does not matter if it doesn\u0026rsquo;t meet the community need need. And that is a hard tendency to overcome. Since I moved into staff and principal roles several years ago, that was one of the first things that I had to work on a lot and make a lot of mistakes in figuring out how to. You learn through your mistakes and you will make a lot of them. It\u0026rsquo;s okay as long as you learn from them and they help you grow. So a lot of it is listening. Something I did find I had to do, especially in the open source world when I Bring something to someone, whether it\u0026rsquo;s an RFC or whether it\u0026rsquo;s a GitHub issue, whether it\u0026rsquo;s internally or externally. And I say, I want some feedback on this. There\u0026rsquo;s two ways people can interpret a request for feedback. One, and this is the way I usually intend it, is assuming I do this, how will this affect your workflow? And if it\u0026rsquo;s going to negatively affect the workflow, I might, you know, maybe not change exactly what we\u0026rsquo;re going to do, because there\u0026rsquo;s a compelling need for it, but I\u0026rsquo;ll change the way we execute it. There\u0026rsquo;s so much more. There\u0026rsquo;s so much flexibility in the execution, much more than I think we realize, again, when we\u0026rsquo;re getting into our little engineering laser sights or tunnel vision. And the second way, however, people can interpret a request for feedback is that I\u0026rsquo;m requesting their permission to do something. And that is where a lot of the drama happens. And it\u0026rsquo;s setting that expectation first, saying, there is a compelling business need for this, but I want to know how this would affect you, to inform what we do and how we do it, and setting that expectation up front. I keep using those words, but it really is critical. That helps a lot. So the best product manager I\u0026rsquo;ve ever worked with, Tasha Drew, she\u0026rsquo;s at VMware now, but she used to be at Chef, I called her. And she knows this, the benevolent Hannibal Lecter. Because what she would do is she would have conversations with all these stakeholders, including community stakeholders, including business stakeholders, et cetera, and suddenly plant ideas in their mind about how the product should work or how it would improve their needs for the product. If it worked in this way, and two months later, they\u0026rsquo;d all magically be in alignment. Maybe not magically, but they\u0026rsquo;d all be in alignment without realizing that that\u0026rsquo;s what happened. So I\u0026rsquo;ve tried to learn a little bit from that, in that sometimes you need to push. Yes, sometimes that happens more often. It\u0026rsquo;s good to start with a nudge and connecting it to showing that you understand that stakeholder\u0026rsquo;s need and connecting it to that need helps a lot. I don\u0026rsquo;t know if that answered your question.\u003c/p\u003e\n\u003cp\u003eNell: No, I think it does. And I think, I mean, one of the key takeaways that I\u0026rsquo;m hearing there is that, like, there\u0026rsquo;s an element of sort of patience that\u0026rsquo;s required. Right.\u003c/p\u003e\n\u003cp\u003eDavid: I found in my role, it\u0026rsquo;s very tempting to show up and be like.\u003c/p\u003e\n\u003cp\u003eNell: Okay, you know, we have this problem. I have come up with this grand solution. Here it is you\u0026rsquo;re welcome, everybody.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Right, I\u0026rsquo;ve done that and they shouted me down.\u003c/p\u003e\n\u003cp\u003eNell: Yes, that is not usually a path to success. And I think like the harder approach is to be patient and to sort of, as you suggest, like sort of nudge and also listen a lot. Like genuinely listen. Not just nudging people toward the grand solution that you have in mind, but also sort of like understanding, making sure that it really does meet the different use cases and asking lots of questions and sort of like gradually moving toward a solution.\u003c/p\u003e\n\u003cp\u003eDavid: I have found that really difficult.\u003c/p\u003e\n\u003cp\u003eNell: But you know, there\u0026rsquo;s, there\u0026rsquo;s a lot of things in there. It\u0026rsquo;s partly about properly understanding people\u0026rsquo;s needs and it\u0026rsquo;s partly, it\u0026rsquo;s, it\u0026rsquo;s largely about just making sure that everybody is brought along. Right. Like it, it\u0026rsquo;s, it\u0026rsquo;s really hard to get everybody on the same page as you right away. It takes some time.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: There. There\u0026rsquo;s three key words to always say when it feels like someone is objecting to what you\u0026rsquo;re proposing. It\u0026rsquo;s tell me more. Because that once you understand more of the problem, that is when you can, and this sounds manipulative, maybe it is a little bit, but that\u0026rsquo;s when you can connect their personal needs, connect, even make an emotional connection. Again, it\u0026rsquo;s what\u0026rsquo;s causing them pain. Connect to what\u0026rsquo;s causing them pain and then you can show how what you\u0026rsquo;re proposing will potentially make that better. If it will make it better, of course. And if it isn\u0026rsquo;t, you can, you know, alter your approach.\u003c/p\u003e\n\u003cp\u003eNell: You mentioned sort of this learning from a product manager. We actually just. A recent interview that we did was with a staff level person who\u0026rsquo;s moving into product management. And I\u0026rsquo;m kind of fascinated by the overlap between staff plus technical leadership and product management, because I think there is some. What are some other lessons that you\u0026rsquo;ve taken from product managing folks?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: A big one is I\u0026rsquo;m not going to give many details about this, but I was on site with a national security contractor and one of the engineers on my team was getting into a pretty intense nerd fright, nerd fight with one of their security engineers over encryption algorithms and which was superior. And the product manager who I worked with finally took aside our engineer and said, no, you don\u0026rsquo;t understand. They have to check a box that it uses a specific encryption algorithm. It\u0026rsquo;s not about which one is technically superior. It\u0026rsquo;s about these are their needs.\u003c/p\u003e\n\u003cp\u003eAlex: Needs.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: They have to check certain boxes, especially in national security kind of spaces. Stop arguing and start listening to them. And figure out what we can do to meet their needs. Because they have needs that we can\u0026rsquo;t change. They can\u0026rsquo;t change them either. They change through acts of Congress or other things. And that takes a long time. So that was a big one. Second one is understanding the overall story before getting into the implementation. And again, as engineers, that\u0026rsquo;s hard. We want to dive right into the implementation when we hear about a problem. All right, this is how we make it better, making sure we understand the overall problem first. Number one, you\u0026rsquo;ll build a better product. Number two, you\u0026rsquo;ll know how to talk about it. And that\u0026rsquo;s something I\u0026rsquo;ve learned from wonderful product managers who I\u0026rsquo;ve worked with.\u003c/p\u003e\n\u003cp\u003eAlex: As an engineer here, do you do any form of, like, sponsoring or mentorship?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: I do. I am on the board of a veterans nonprofit called Operation Code. Brief story. Both my parents were 20 year U.S. air Force officers. Grew up in military culture. Very much wanted to go into the military. I had a medical disqualification that developed when I was in high school. So I went to small liberal arts school and then I went into the tech industry. But I always felt, I mean, military culture is home to me. It\u0026rsquo;s what I grew up in. And I always felt a strong draw to it. And as the wars in Afghanistan and Iraq began to wind down a few years ago, a lot of veterans were leaving the service and trying to come into the workforce. And that is a big transition to make. Going from somewhere where you had a very clear mission, knew exactly, for the most part part where you fit into that mission, to coming into the civilian world, which is very different, particularly the tech industry. In the military, it\u0026rsquo;s we. In the tech industry, it\u0026rsquo;s I. So I literally put out a call on Twitter and said, is anyone doing work with teaching veterans technical skills? Someone responded, directed me to the founder of Operation Code, David Molina. The organization was still in its early stages at this point and he said, why don\u0026rsquo;t you come on board and be a mentor? So I did that for several years. That experience showed me how, how I knew how important open source was to the tech industry and engineers. But I didn\u0026rsquo;t realize how important it was for engineers who were very early in their career because it gave them a clear profile, a GitHub profile that they could bring to potential employers and say, this is what I\u0026rsquo;ve done on these open source projects and this is what I can do for your organization. So I\u0026rsquo;ve done a lot of mentorship through there. I eventually became their cto, which results again, a lot and that was a very tactical hands on CTO role. Again, mentoring people through their first open source contributions, teaching them kubernetes. While I was learning Kubernetes, that was interesting. But that\u0026rsquo;s a very in demand skillset. A lot of open source projects, they\u0026rsquo;re not just projects, less products, they\u0026rsquo;re also teaching devices. And kubernetes was an extremely in demand skill. So I\u0026rsquo;m now on their board which is less of a hands on role, it\u0026rsquo;s more of a again, setting overall direction. But I still do a lot of listening. One of my favorite things in the world to do is sitting next to someone or sitting on a zoom call with them because of COVID and guiding them through their first open source contribution and seeing their eyes light up when they hit that submit pull request button and then seeing it get merged. That is such a wonderful, wonderful feeling. So yes, it\u0026rsquo;s one of my favorite things to do. And you do not really know something. It\u0026rsquo;s true. You do not really know something until you can teach it. And it has improved my abilities as an engineer massively as well.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. When you are sort of working with someone, you know, side by side or sort of coaching them, you know, do you take. Is there an approach that you take with them? You know, is it different than say what you would do with a less experienced engineer? Or is it the same? What are the qualities of that?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: It\u0026rsquo;s pretty similar. I had when I was at Chef, I had an intern for six months. She was a delight to work with. She had just come out of boot camp and one of the things we did, I am not someone who can pair all the time. It just, I\u0026rsquo;m an introvert. It just. I can pair some of the time, I can\u0026rsquo;t do it all the time. But what we did was we set up two hours every day where we would pair together. And that let me still do other work that I needed to do in the time we were not pairing. It gave her some time to try some things on her own, but she always knew we were just a few hours away. Also, she sat across from me in our office back when we went into offices and knew there would be a time when we would be working together on it. And a lot of what I liked to do was we didn\u0026rsquo;t stick this religiously, but when I\u0026rsquo;d start, I would write a line of code. She would write a line of code. This is a Ruby on Rails application. I would write a test, she would write the code. To pass the test. She would write a test, I would write the code to pass the test. And it was interesting to see. I mean, boot camps, they do teach people a lot, but there\u0026rsquo;s so many subtleties of git that I forgot were there because they live in my fingers and it helped me understand it better. So that\u0026rsquo;s one approach. The second approach is if someone has done a few pull requests but is worried that if they open it on the project they\u0026rsquo;re going to be raked over the coals, which I usually steer them to projects where that\u0026rsquo;s not likely to happen. But I understand that fear. I had that fear immensely when I was a junior intermediate engineer is I said, okay, open it as a draft or even just tell me where the branch is, I\u0026rsquo;ll pull it down and I\u0026rsquo;ll do a private code review to start off with and catch anything that is obvious to me that might be a security issue or might just not quite work in the way you expect it to. Or there might just be a more. I love regular expressions. I overuse regular expressions. I\u0026rsquo;ve learned the hard way that no, it\u0026rsquo;s science is better just to substitute slice the string or something and figure out where you need looking for little bits like that, which gives them confidence when they do open the pull request. Okay. There\u0026rsquo;s nothing obvious that someone is going to immediately latch onto and tell them that they\u0026rsquo;re wrong. And if the project they\u0026rsquo;re opening the pull request request does that, I will be having a private conversation with them that that is not how you interact with a contributor. So that\u0026rsquo;s another approach that I take.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. And I\u0026rsquo;m curious, do you find that you learn stuff from sponsoring your mentorship that like impacts your, you know, day.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: To day job immensely? I learn how to communicate a technical concept to someone who doesn\u0026rsquo;t have the same experience that I do. And I need to be reminded of that a lot funnier example from this intern. We were in our standup and I was talking about something I don\u0026rsquo;t remember it was. And I said yeah. And it turned into an epic yak shave, not realizing she had no idea what that meant. So she later told me, yeah, I had to ask someone else, what is she talking about? And it\u0026rsquo;s an example of there\u0026rsquo;s little bits of vocabulary that make no sense to someone who doesn\u0026rsquo;t have the same context. And, and that\u0026rsquo;s been very helpful for me in communicating things to stakeholders who don\u0026rsquo;t necessarily. I don\u0026rsquo;t like saying non technical. If you can use Excel, you\u0026rsquo;re technical. But Maybe with less of a coding background than I have. And that\u0026rsquo;s a key way to get business stakeholders in alignment with what I\u0026rsquo;m executing or what my team is executing on a technical level. So, yes, it helps a lot.\u003c/p\u003e\n\u003cp\u003eNell: That\u0026rsquo;s interesting. We have challenges with terminology in our industry, both in terms of the jargon, things like the act shave, but also. So the technical, non technical distinction is not a bright line.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: No, not at all. I can\u0026rsquo;t do Salesforce programming, but I know a lot of business people who can do great. It\u0026rsquo;s like blood magic in Game of Thrones to me. But they can do amazing things with it, so. Yep.\u003c/p\u003e\n\u003cp\u003eNell: Oh yeah, yeah. No, there\u0026rsquo;s all sorts of interesting. You know, Excel is a really great example, but there\u0026rsquo;s all sorts of DSLs like that that exist in the world that someone is basically a programmer if they can use them. They\u0026rsquo;re just not the same kind of programmer that other people are. Switching gears a little bit. There\u0026rsquo;s a couple questions that we try to ask everybody who comes on the show. And one of them is what are some of the resources that you would point other folks toward who are interested in technical leadership and moving into the staff plus and principal levels, especially if there\u0026rsquo;s books or blogs or people that you would, that you would point others toward.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: There\u0026rsquo;s two people and I\u0026rsquo;d point you to their Twitter accounts. They both do a lot of blogging. Speaking about principal engineer, the differences from being, you know, intermediate or Even senior level IC1 is Tanya Riley. Her Twitter account is whereistanya spelled T A N Y A. She was so helpful to me. So I, I mean, some of you might know, I was laid off from Mozilla last year. They laid off 25% of the company. And I got caught up in that and that intellectually I knew it had nothing to do with my abilities. When they have to make a cut that blunt, it can\u0026rsquo;t just. I happened to be working in an area where they decided they were no longer going to invest in it the way that they had been investing in it. So I knew that intellectually learning, knowing that emotionally took a lot longer. And in particular, I am freaking terrified of interviewing still. Ten plus years of experience. I hate it. And she took me through a non judgmental systems design interview reminding me how it worked and what people. And she\u0026rsquo;s been through a lot of them herself. What people will be looking for in a staff principal role in a system design interview. And I think that played a large, large part in me getting the role I got at Microsoft. Also, she has lots of good information about, you know, what does being a principal mean? How do you become a principal, particularly if you\u0026rsquo;re, you know, more of an underrepresented person. Tech. Highly recommend her.\u003c/p\u003e\n\u003cp\u003eNell: The other one is fantastic.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Yeah, we\u0026rsquo;re gonna have.\u003c/p\u003e\n\u003cp\u003eDavid: We\u0026rsquo;re gonna have her on the show at some point.\u003c/p\u003e\n\u003cp\u003eNell: She\u0026rsquo;s fantastic.\u003c/p\u003e\n\u003cp\u003eDavid: We\u0026rsquo;re just trying to figure out when.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Yep. And then the other is Sylvia Botros. I\u0026rsquo;m not sure if I\u0026rsquo;m saying her last name correctly, but her Twitter account is dbsmasher, I guess, for database Smasher. Also, lots of good blog posts, lots of good thoughts on Twitter, et cetera, on what it means to be a principal engineer. So highly recommend that Twitter account as well.\u003c/p\u003e\n\u003cp\u003eNell: Awesome. Awesome.\u003c/p\u003e\n\u003cp\u003eAlex: So we have our last question, which is sort of tongue in cheek. How much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: It\u0026rsquo;s about 50.\u003c/p\u003e\n\u003cp\u003eNell: 50.\u003c/p\u003e\n\u003cp\u003eAlex: 50. 50. Wow.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: Yeah. Which I realize is unusual for a principal engineer. And perhaps when, you know, if we get more headcount, there\u0026rsquo;s more senior intermediate engineers under me, there will be less. But right now it\u0026rsquo;s about 50, 50. And part of that is, again, I\u0026rsquo;m interfacing with community members who are doing contributions, and I do consider code review coding work.\u003c/p\u003e\n\u003cp\u003eAlex: Sure. That makes total sense.\u003c/p\u003e\n\u003cp\u003eNell: Awesome. Well, Nell, thank you so much for taking the time with us today. It\u0026rsquo;s really been a pleasure.\u003c/p\u003e\n\u003cp\u003eSPEAKER_D: It\u0026rsquo;s been a pleasure, too. Thank you so much for having me.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this.\u003c/p\u003e\n\u003cp\u003eNell: So that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy, Sam.\u003c/p\u003e\n","date_published":"2021-09-07T09:00:00-05:00","date_modified":"2021-09-07T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/rich-lafferty-pagerduty/","url":"https://podcast.staffeng.com/season-1/rich-lafferty-pagerduty/","title":"Rich Lafferty (PagerDuty)","summary":"The highest leverage stuff here is communicating. Because if you make if make it really clear to people why we decided X or why we want to keep this in mind, then we basically kind of empowered them to understand where the business is coming from and where the technical leadership is coming from, but still make the right decisions on their own.","content_html":"\u003cp\u003eOscillating between the roles of individual contributor and management has been a recurring theme on this show. Our guest today, Rich Lafferty, has some special insights into this pattern that can help anyone looking to improve their work. Rich works as a Staff Site Reliability Engineer at PagerDuty and has spent many years interfacing with various departments and building projects and proposals. In our conversation with Rich, we discuss how his past roles have informed his work at PagerDuty and how he gets the most out of his teams without exploiting the authority that comes with his more senior role. We delve into Rich’s process for building proposals and learn some of his tips and tricks for ensuring the best possible outcome by investing in the foundation and design phase. We also explore the importance of early feedback, why you need to include a diverse group of individuals, and how to gradually grow your feedback group. Tune in as we discuss everything from risk management to high and low context culture, and much more!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.lafferty.ca/\"\u003eRich Lafferty\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.programmingtalks.org/talk/being-glue\"\u003e\u003cem\u003eBeing Glue\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Behind-Human-Error-David-2010-09-30/dp/B01FEKER5E\"\u003e\u003cem\u003eBehind Human Error\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897\"\u003e\u003cem\u003eThe Manager\u0026rsquo;s Path: A Guide for Tech Leaders Navigating Growth and Change\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.johnallspaw.com/\"\u003eJohn Allspaw\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/9043003-rich-lafferty-pagerduty.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romis and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Rich Lafferty is a staff site reliability engineer at Pagerduty, where he builds platforms in the clouds to make Pagerduty reliable and his development teams happy. He calls Toronto home with his wife and two tortoiseshell cats. In his copious spare time, he can be found enjoying craft beer, staring at a wall, or playing bass in one of Pagerduty\u0026rsquo;s two office bands.\u003c/p\u003e\n\u003cp\u003eDavid: All right, Rich, thank you so much for taking the time today. If we could start by having you tell us who you are and what you do.\u003c/p\u003e\n\u003cp\u003eRich: Yeah. So my name is Rich Lafferty. I\u0026rsquo;m a staff site reliability engineer at Pagerduty working out of the Toronto office, although no one\u0026rsquo;s working from an office right now. I\u0026rsquo;ve been at Pagerduty for about four years now. Started there as a senior engineer and managed to get myself into the staff title about a year ago. I think I\u0026rsquo;ve been doing it for a while. Before that I\u0026rsquo;ve worked tech companies here and there. I was at a. I did a little tour of management for a while, decided that wasn\u0026rsquo;t for me, and when I joined page duty, it was explicitly to switch back from management into an individual contributor role. And the great part about, you know, where I\u0026rsquo;ve kind of ended up now, why I\u0026rsquo;m excited to talk to you guys today is that this whole staff thing has really hit the sweet spot of what I loved about being in a management role and the sweet spot about what I love being in an IC role all at the same time.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. What does a typical staff engineer do at Pagerduty?\u003c/p\u003e\n\u003cp\u003eRich: Yeah, so at Pagerduty, a staff engineer reports to a director. So the idea is that even though I might be co located with a particular team for this project or that project, I don\u0026rsquo;t have a like a permanent home team necessarily. The idea is that. So for instance, I\u0026rsquo;m a staff engineer in the whole infrastructure department, even though I tend to work with our cloud infrastructure team right now so staff engineer, it does depend kind of individual by individual, but it\u0026rsquo;s a mix. It\u0026rsquo;s less spending time in the editor and more time working on the high leverage stuff where I keep going by. Tanya Reilly, who is a staff engineer at Squarespace, has a fantastic presentation that\u0026rsquo;s pretty well known called Being Glue. And if you haven\u0026rsquo;t seen the talk or gone to the, you know, if you Google Tanya Riley Being Glue, you\u0026rsquo;ll find it. And it\u0026rsquo;s framed in terms of here\u0026rsquo;s a warning for underrepresented groups in junior roles. But you can really turn the talk around and go all of the, the stuff that Tanya talks about in that this glue work, this bringing things together is really high leverage work for senior engineers. And the amount, what I can deliver in terms of sitting in front of an editor and writing code is nothing compared to what I can do by bringing people all onto the same page, finding the highest leverage opportunities and that kind of thing. I have a lot of freedom in my role to figure out, well, what should I be doing? Obviously, sometimes I\u0026rsquo;ll be asked like, hey, please go solve this particular problem, or please, you know, we\u0026rsquo;ve got this initiative coming up, we\u0026rsquo;d like you to kick it off. But really, I\u0026rsquo;ve got a lot of freedom to go, okay, so where what needs my attention and where can I be the highest leverage and that might be. I mean, I\u0026rsquo;ve joked before that my editor of choice is Google Docs. Because, you know, a lot of what I\u0026rsquo;m doing is just, well, let\u0026rsquo;s just write it all down so that everyone\u0026rsquo;s got a place to start from, whether that be a, you know, a process proposal or a technical proposal, or taking a whole bunch of stuff that a bunch of people throwing at me and trying to put it in one page so that I can go to people and leverage Cunningham\u0026rsquo;s Law and say this, what I think you\u0026rsquo;re saying, so that they can come in and say, no, no, no, that\u0026rsquo;s not what I\u0026rsquo;m saying at all. And eventually get everyone on one page. So it\u0026rsquo;s a very gluish kind of role. I\u0026rsquo;ve definitely noticed before that we\u0026rsquo;ve had some folks that made it to staff and found that they don\u0026rsquo;t get to write code as much anymore and had a little bit of trouble with that, but it really is. It really is. It\u0026rsquo;s kind of like almost a not quite director without proposal. I think principal pagerduty would be director without reports. So it\u0026rsquo;s kind of a senior manager without Reports that still stays in touch with the technical stuff, which is really a sweet spot for me.\u003c/p\u003e\n\u003cp\u003eAlex: Is there anything specific about your approach to the staff role that you think might be different from other staff engineers at your organization or just more broadly?\u003c/p\u003e\n\u003cp\u003eRich: I think the main thing, you know, I mentioned that I spent some time in management and I feel like I leverage that all the time. I use that all the time. And that\u0026rsquo;s kind of sort of my, one of my, one of my little superpowers. Before I was at PagerDuty, I was at a company called FreshBooks. I was there for nine years, which was a little too long, but I started there as one of the early employees in the startup and when I left there I was their director of production operations. And having spent that time in senior management and being exposed to all the parts of the business that aren\u0026rsquo;t the engineering work I use all the time, it\u0026rsquo;s code switching. If I need to talk to senior management of the executive team or if I need to talk to legal or finance and stuff like that, then I have had to do that. And I can switch into finance language, I can switch into code. Switching into manager is really useful. But also I can kind of imagine what the really, if you have a problem and it\u0026rsquo;s not a purely technical problem, then there are feelings involved. And having been on the management side of things, I can kind of have some empathy for what those problems might be and what those feelings might be and really kind of emphasize that. So I think my role, my approach to this is very much being able to leverage kind of that past experience in management towards being glue between engineers and management engineers and product engineers and other engineers and so forth. And a lot of the things that I do that I find high leverage are things like, you know, I notice this is going a little off the rails. I\u0026rsquo;m going to unblock it more so than I\u0026rsquo;m going to go into, you know, I\u0026rsquo;m going to sit down for a day and I\u0026rsquo;m going to come up with a top to bottom new proposal for a thing. That said there\u0026rsquo;s some of that involved as well and it\u0026rsquo;s not, it\u0026rsquo;s not all glue.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s really interesting. I think we\u0026rsquo;ve talked a couple times on the show already about like the idea of the pendulum between management and IC work. And I think when we have senior ICs that have management experience that ends up being kind of a superpower. I do want to circle back to that. I think there\u0026rsquo;s a lot to kind of unpack there in terms of how it changes your relationship with the teams that you work with and with the leaders above you. But before doing that, maybe to just sort of paint a picture for people. What are some examples of, like, concretely, it doesn\u0026rsquo;t have to be specific things that you\u0026rsquo;ve worked on recently, necessarily, but like, what\u0026rsquo;s the type of work that you would be doing at Pagerduty on a regular basis?\u003c/p\u003e\n\u003cp\u003eRich: Yeah, so we actually, we just wrapped up a project that went into general availability on this past Monday, June 28, which was to launch our presence in the EU. So used to be at Page of Duty, if you wanted it, you could, you know, one color black, you get it in one place, which is the us And a bunch of our European customers are saying, well, you know, that\u0026rsquo;s not quite what we want to do. We\u0026rsquo;d much rather host our data in the EU for their own, for not for any compliance reasons on us, but because it was important to them for their own risk analyses to keep their data in the eu. And so I\u0026rsquo;ve been involved with that through and through. And the way that that project kind of unfurled is a really good example because at the very beginning of it, there were a lot of fundamental technical questions about how we\u0026rsquo;re going to do this, how are we going to set up our networking, how are we going to set up deploy, how are we going to manage our AWS accounts and just kind of like core architectural bits. And so part of, at the very beginning, part of what I was doing was writing proposals for that. I think we should do it this way. A lot of what I was doing was finding the people that know those particular areas best, because that\u0026rsquo;s certainly very rarely me, not just asking their opinion, but also kind of coaching them through having an opinion sometimes in terms of like, okay, so here\u0026rsquo;s what I\u0026rsquo;m hearing from you. Here\u0026rsquo;s a bunch of constraints that we\u0026rsquo;re going to have to work under. Here\u0026rsquo;s what the business needs. How can we shape this into a decision? Once all that kind of was out of the way, then we kind of moved on to, well, we need to actually deploy and implement all this stuff that we came up with there. I switched from being a proposal writer and idea gatherer towards being a bit of a project manager, in that I was taking care of making sure that all the teams in the infrastructure department were executing and delivering all of the bits they needed in the right order. And if things got blocked, I would go down to that Runway level and figure okay, well, where\u0026rsquo;s the block? What if we do this? Have we tried that? And then once it\u0026rsquo;s back on the road again, back up to altitude to kind of get an idea of the whole thing going on. Once that section was done, then we started running into getting, we had to actually get our services deployed and stuff like that. At which point I really wanted to leave just for scalability, I needed to leave that up to the folks responsible for the deployment tooling and the teams that needed to do the deploying. But there\u0026rsquo;s a lot of just kind of keeping an eye on things and making things are going smoothly the best, you know, the sign of success there is that I don\u0026rsquo;t have to get involved at all. But that wasn\u0026rsquo;t always true. Just kind of, you know, dive down and clear this bit up here, clear this bit up there. While this was all happening, there was also, of course, other things going on. So I was having conversations with, you know, the management and the infrastructure group and senior management about how to balance these, the stuff we\u0026rsquo;re doing in the EU with the other priorities that come up and incidents that come up and so forth to make sure that stuff kind of all got balanced. And then towards the end there was a lot of situations where for instance, now that we have two hosting locations instead of one, we have a concept of global services that we never had before. And so we need to step kind of carefully around those. How can we minimize them, how can we make sure we implement them correctly so that when we do this another time in the future, it\u0026rsquo;s going to keep working there and so on. One of the best things that I did just in kind of terms of that staffy kind of work was at the very beginning I worked with a couple people to come up with a set of architectural principles which were very high level things like not bringing legacy. Like if there was two ways to do things, we wouldn\u0026rsquo;t support the legacy way, we would only support the new way in the new service region. It was really useful to have that at the very beginning because there were a lot of decisions we kind of went ran into throughout where we were able to go, okay, so here\u0026rsquo;s two options. Either of them will probably work, but way back at the beginning we laid out these principles to say, look, this is the kind of the reasoning and the philosophy or how we\u0026rsquo;re doing this. Can we look at this decision through that lens? And I mean, again, I\u0026rsquo;ve been talking about leverage a lot here. That was again a high leverage thing that I can Write up and socialize and get buy in on these general principles. And that can be like a decision making engine, meaning that I don\u0026rsquo;t need to get folded to things later on through the whole thing. There were also tickets to do and you know, it was a combination. I was still embedded with the team while I was doing all this. The cloud infrastructure team that maintains kind of the underlying infrastructure and platform. And so, you know, take some of the tickets that are maybe a little bit more challenging, but make sure there\u0026rsquo;s still enough challenge for the team. Take some of the tickets that are kind of grindy, not so fun work so that the rest of the team can take the interesting stuff. So there\u0026rsquo;s still technical work underneath all that as well.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;m really fascinated by the idea of defining architectural principles up front. I\u0026rsquo;m actually kind of fascinated by the idea of trying to distill sort of any reasoning process into like a list of guiding principles or like strategy docs, vision docs, these sort of things. It seems really nebulous to me. What\u0026rsquo;s the process that you follow to put that together?\u003c/p\u003e\n\u003cp\u003eRich: I would love to say, oh well, here\u0026rsquo;s the process. But I mean, a lot of the times it\u0026rsquo;s funny, sometimes I\u0026rsquo;ve had, you know, some folks I\u0026rsquo;m mentoring or whatever say like, well, how do you come up with this proposal? And my answer is like, well, I start with an open editor and when I\u0026rsquo;m done there\u0026rsquo;s a proposal on the page and I don\u0026rsquo;t know what happened in the middle. And it\u0026rsquo;s the same kind of thing with this. I mean, it\u0026rsquo;s certainly not my idea. Heavily influenced by Amazon\u0026rsquo;s leadership principles, which I\u0026rsquo;ve always liked more than sort of your typical company values because they\u0026rsquo;re extremely specific and they\u0026rsquo;re written to be a decision making filter. And so I kind of did the same thing here. I think what was happening is basically I had a bunch of ideas for things that we would have to do as we started this project and what kind of decisions were going to be coming. And I never explicitly sat down and went, oh, I better write out some principles so that people can make these decisions easily. But I realized that there was a bunch of stuff that I kind of knew where the right thing was in my gut. You know, for instance, to use this, I wish I had them in front of me because I could reference more than one of them. But to use this no legacy processes thing for as an example of a legacy process. Current infrastructure at Page of Duty is terraformed, but PagerDuty has been around for 14 odd years now. And so there is kind of, we haven\u0026rsquo;t migrated everything over. So in the US there\u0026rsquo;s still a bunch of stuff that had been created by hand. And so we drew a bright line in the EU to say no, that you can only create infrastructure using terraform. But that was kind of like a gut thing to me. I didn\u0026rsquo;t have to sit down and reason it out. It\u0026rsquo;s like, well, if we\u0026rsquo;re going to do this, we need to do it this way. Another one, now that I think about, another one was around global services that by default you\u0026rsquo;re not allowed to talk between the US and EU service regions because once we start doing that, we can\u0026rsquo;t really make promises to our customers about where their data is going to reside. But at the same time I recognize that, well, there\u0026rsquo;s going to be some places where we have to do that. All of this, I don\u0026rsquo;t know, it\u0026rsquo;s just from experience. And you go into a project like this and you go, okay, well here are the things that are going to bite us. And you kind of get a gut feel for what all those things are. And it\u0026rsquo;s like, well, how can I communicate that gut feel to everyone else? Well, I can write down the ideas that I think led me to those gut feel decisions and those in turn with a bunch of wordsmithing and running past my peers and the folks on the teams that are going to be impacted by this most, refine them into things that people can actually use for decision making.\u003c/p\u003e\n\u003cp\u003eAlex: One of the things I think I hear you talking about is you\u0026rsquo;re working on a lot of things that have business value. I\u0026rsquo;m curious, how do you go about understanding the work that has the most business value or value to the people that you serve?\u003c/p\u003e\n\u003cp\u003eRich: Oh, that\u0026rsquo;s a tough one. That is a tough one. My instinctive answer to that is the same thing about how I write proposals is that there\u0026rsquo;s an empty editor and then it\u0026rsquo;s got a proposal in it and something happened in the middle and I don\u0026rsquo;t know what it was, but a lot of it. One model that I really liked is from what Larson\u0026rsquo;s book tie this back to that is the idea of snacking. I am terrible for snacking. I can lose an entire day on slack just helping a bunch of people get unblocked in a bunch of places. And all of those little places are really helpful things. But I\u0026rsquo;m probably not. Even though I\u0026rsquo;m probably, I\u0026rsquo;m in a good Place to help unblock people and answer questions and stuff like that, or jump into a conversation when I know that it\u0026rsquo;s going kind of like, you know, if I. If I jump into the slack conversation, then I can probably save them half an hour of going off in the wrong direction. But that\u0026rsquo;s not necessarily the highest leverage thing for me to do. So it\u0026rsquo;s really a matter of looking at. And I\u0026rsquo;m saying this, I\u0026rsquo;m not good at it, but it\u0026rsquo;s really a matter of not answering what, you know, is this something that I could be good at? But rather, what are the things that only I. Or, you know, the things. It\u0026rsquo;s the. Again, it\u0026rsquo;s the highest leverage things. And how do you know what they are? You\u0026rsquo;ve done them a lot. I know that\u0026rsquo;s a terrible answer for people listening to this going, well, how do I become a staff engineer? Well, you do it a lot, but it\u0026rsquo;s really, you know, it\u0026rsquo;s really looking for the things where the smallest amount of work can have the biggest impact. And to bring it back to what we were talking about a second ago, that\u0026rsquo;s where writing up a set of architectural principles that the other 300 people in engineering can use to make their own decisions amongst themselves without having to talk to me at all, without having to run through any big process. Especially since we want teams at pagerduty to own their own things, writing out those is a lot higher leverage than walking a bunch of engineers through those decisions one at a time. So it\u0026rsquo;s really just a case of finding the things where, like, how can we align people? You know, how can we give people the tooling to do the right thing? It\u0026rsquo;s like the architectural side of having a sort of a golden path for deployment or something like that. You know, one of the things that our delivery team who focus on deployment, tooling and processes, one of the things that they do is they always try to make it really easy to do the right thing. Teams fully only serves as a pagerduty, so if a team wants to deploy their software slightly differently, they\u0026rsquo;ve got the autonomy to do that. But unless they have a really good reason, it\u0026rsquo;s probably going to suck because we\u0026rsquo;ve made the default path so easy. And for instance, we\u0026rsquo;ve got a thing called the. We just started using Backstage, which is really cool, to make it easy to spin up a new microservice using our elixir skeleton. Press a button, receive, repo with the skeleton in it, and it\u0026rsquo;s got some basic Terraform. It\u0026rsquo;s got your deployment stuff in there, it\u0026rsquo;s got everything that you would need to get a hello World running in production. And then all you have to do is write your service around it. So having that makes it really easy for a team that wants to deploy a new service to have all of the things that we as a company have decided are the best way to do things. They can then go in and change it. They don\u0026rsquo;t have to use a skeleton at all, but it\u0026rsquo;s so easy. And the same kind of thing for architectural stuff, if you make the reasoning behind it really obvious. The highest leverage stuff here is communicating. Because if you make if make it really clear to people why we decided X or why we want to keep this in mind, then we basically kind of empowered them to understand where the business is coming from and where the technical leadership is coming from, but still make the right decisions on their own. And again, it\u0026rsquo;s a leverage thing. Being able to take the time to get those, those principles just right is a lot higher leverage than having to look at the individual decisions underneath. Of course, I still look at the individual decisions underneath. In case something needs, you know, a little poke in the right direction or stuff like that. I wouldn\u0026rsquo;t want to come in and say, no, look, I wrote these principles. Why aren\u0026rsquo;t you following the principles? But I might come in and say, hey, so I noticed you\u0026rsquo;re thinking about doing it that way. That surprised me because given this principle, I would maybe sign this other way. Let\u0026rsquo;s talk about. So let\u0026rsquo;s talk about kind of what direction that should go in.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, the thing that strikes me about what you\u0026rsquo;re saying is that there\u0026rsquo;s a lot of upfront effort that gets put in. It seems like it delivers a great result. But one of the things that I\u0026rsquo;ve experienced is that upfront effort isn\u0026rsquo;t always seen as valuable as it should be. How are you communicating up and talking to them about the value of doing that upfront effort?\u003c/p\u003e\n\u003cp\u003eRich: I remember learning this from someone else, a really good agile coach that I worked with at a previous gig, explaining that a project is a thing that has a beginning and a middle and an end. And everyone\u0026rsquo;s tendency is to start at the beginning of the middle and end at the end of the middle. Which is to say even if you\u0026rsquo;re doing agile, even if you\u0026rsquo;re trying to be as non waterfally, as non planning advanced as possible, you still need that beginning and end. You still need to make sure everyone\u0026rsquo;s on the same page about what you\u0026rsquo;re doing and at the end you still need to figure out what you can learn and people tend to skip that so they can get on to the next thing. Because once you start cranking the ticket handle then people start noticing the work a lot more than when you\u0026rsquo;re doing the preparation stuff that would make cranking the ticket handle go even faster. A lot of it is just demonstrating that it works. One of the things I like about the team that I\u0026rsquo;m embedded with right now, the cloud infrastructure team, is that we\u0026rsquo;ve had it come up that we started in the middle a little too often in the past. It\u0026rsquo;s a really good intent. It\u0026rsquo;s, you know, this other team is counting on us for getting this thing done and or the company is counting on us for getting this thing done. We want to get done as quickly as possible. So let\u0026rsquo;s go straight to implementing. And of course, really, you know how this turns out. This means rework later or we\u0026rsquo;ve gone through some, you know, closed door decisions that we wish we could revisit and we can\u0026rsquo;t because it now remaking that decision is actually going to turn into a migration and so forth. So the great part about that is that anyone on the team can remind anyone else on the team, hey, as a team we agreed to make sure we take time to design up front. And that doesn\u0026rsquo;t necessarily mean at the beginning of the project, that just means there\u0026rsquo;s a design phase and there\u0026rsquo;s an implementation phase at any level written a little wider where you don\u0026rsquo;t kind of have that working agreement in place to just remind people from, hey, we learned from previous things that this is a bit of an anti pattern. And here\u0026rsquo;s the language we use to remind ourselves of the anti pattern. It really is just kind of demonstrating being staff does have a little bit of role authority that comes with it. And I use it as little as possible and I would never want to use it. Like using that for a technical question is an absolute last resort because every time you use it, you lose a little bit. Using that for a process philosophy, how to think about things thing is a lot less, it\u0026rsquo;s a lot easier to do. Especially since I can kind of take on the responsibility for taking the time I can say to, you know, I can say to someone, hey, I think we should take some time to write this out first, make sure we\u0026rsquo;re all on the same page. And if someone comes to you, and that\u0026rsquo;s why it\u0026rsquo;s taking too long, you can point them at me. So that gives them a little bit of space and it\u0026rsquo;s kind of using that role authority as a bit of an umbrella rather than using it as a stick. And yeah, I think teams, it\u0026rsquo;s pretty. It doesn\u0026rsquo;t take too long for teams to notice that when they write things down and they share it with their team or they share it with, we\u0026rsquo;ve got an architecture working group they can kind of get input from that, that people ask questions that they hadn\u0026rsquo;t thought of and they can tell at the end of it that they come up with a more refined, a more bulletproof, just a better design. Or worst case, they end up exactly where they started. But now they\u0026rsquo;ve got confirmation that they\u0026rsquo;re on the right path and they\u0026rsquo;ve got an artifact that someone else can look at six months from now to figure out why on earth we did it this way. So it\u0026rsquo;s a little bit of take it on faith at the beginning. I think it\u0026rsquo;s kind of self evident how it can work. And everyone kind of knows that making sure you have a design doc and write down decisions and stuff like that are good practices. So giving people room to actually do it so that they can see that it worked so that they want to do it next time.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, sounds like what you\u0026rsquo;re saying is there\u0026rsquo;s sort of like a golden spiral where it\u0026rsquo;s like, you know, people feel good when they do it, then they deliver good work. I think that makes sense from an engineering perspective. I\u0026rsquo;m curious though, like when you talk to someone who\u0026rsquo;s more business minded, are you like, well, the reason why we\u0026rsquo;re doing this because the engineers think that it feels good, you know, like, is that how you\u0026rsquo;re describing it? How are you demonstrating it to the business side?\u003c/p\u003e\n\u003cp\u003eRich: So, you know, a lot of it is just that we\u0026rsquo;re lucky in that one of the nice parts about working for a company whose customers are engineers and engineering departments and IT departments and stuff like that is that it\u0026rsquo;s a very technical group across, like even the folks that are in product, the folks are in their management and so on, have if not technical backgrounds, a good understanding of the space in which we\u0026rsquo;re working. And so I kind of get it easy, like compared to, you know, a lot of more traditional companies and so forth. I have it easy in that respect. That said, I think a lot of it is you can really put in terms of this is risk management. One of the things I\u0026rsquo;m actually just kind of starting to get my head around at PagerDuty is the value that we would have in having a more explicit framework about how to think about risks and just training, you know, small t training individual engineers and teams on how to really methodically think about risk. Because when you go to the business, I find especially senior management loves talking about risk and that\u0026rsquo;s really what they wanted to think of it in terms of is if engineers like to talk about trade offs, management likes to talk about risks. And if you can go to management and say, look, we need to take a little bit of time to do the design on this and just to refine that. Because I think there are some closed door decisions whereby closed door decisions, I mean once you go through that, once you make the decision, you start implementing it. It\u0026rsquo;s a considerable effort to redo the decision. The opposite is open door where after you make it, it\u0026rsquo;s relatively easy to redo it if you need to. We\u0026rsquo;re going to make some closed door decisions. If we decide those wrong, then the costs are going to be quite high. Might be ongoing maintenance cost, it might be rework, it might be that we\u0026rsquo;re not meeting some of the non functional requirements like performance and availability and security and so forth. It might mean that the whole project is going to be delayed because it\u0026rsquo;s going to slow us down forever. And so the way that we\u0026rsquo;re going to mitigate cat that word that\u0026rsquo;s very important. We\u0026rsquo;re talking about the way we\u0026rsquo;re going to mitigate these risks is by doing this design phase, writing up these dogs. That\u0026rsquo;s also going to mitigate some risk later. When we hire new people, we\u0026rsquo;re hiring like always, hiring like crazy. When we hire new people, they need to understand where we are coming from. And we want to make sure that there\u0026rsquo;s documentation that they can read as to not only what the decision was, but what the process was going into the decision like the value. You know, if you write up a proposal in Confluence, you can Google Docs and it fills up with comments. Keeping the comments around is really important because it\u0026rsquo;s not just what did we decide, but it\u0026rsquo;s also well, what objections did people bring up and how did we satisfy those objections. All that history is really important. I can\u0026rsquo;t remember where I learned what the idea between high context and low context engineering cultures was, but the idea a high context culture is where you find out how things were done by talking to people. And there\u0026rsquo;s a lot of oral traditions that get passed along and so forth. And a low context is where on your own you can basically figure out how we got here, whether it be from, you know, the design, like the architecture or the, you know, the design of particular code or the documentation that\u0026rsquo;s around it and so forth, where you can really sit down and look at something and it\u0026rsquo;s like it\u0026rsquo;s clear why it was done this way. That\u0026rsquo;s a low context culture. Ideally most, I\u0026rsquo;m sure a lot of the people listening to this are in high growth companies bringing a lot of people in all the time. Just the nature of the business is that people stay in a role, you know, two to four, six years, which means there\u0026rsquo;s always going to be some turnover. And the being able to have all those documents and so forth around and records of past decisions and the reasoning that went into things means that onboarding those new people into a low context culture is going to be a lot easier than the one where in high context culture where it\u0026rsquo;s all oral knowledge passed down and so forth.\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned something, the idea that engineers talk about trade offs and managers talk about risk. That\u0026rsquo;s a fascinating framing. I\u0026rsquo;m going to keep that and think about it a little while. Another thing you mentioned was that you have an architecture working group and that\u0026rsquo;s one of the ways that changes, I guess, get reviewed. Can you say more about how that works? Those forms have not always seen them function effectively and so I\u0026rsquo;m curious how you do it at pagerduty.\u003c/p\u003e\n\u003cp\u003eRich: Ours has not functioned that effectively. It\u0026rsquo;s hard to pull off with these.\u003c/p\u003e\n\u003cp\u003eDavid: Kind of projects when you\u0026rsquo;re organizing across a big group of engineers. You\u0026rsquo;ve already talked a little bit about sort of how you get buy in from management, but how do you get buy in across that, that group of engineers?\u003c/p\u003e\n\u003cp\u003eRich: Yeah, that\u0026rsquo;s often the hard part. Right. A lot of it is like my ideas have to, I talked about role authority before and that\u0026rsquo;s one thing that you, you really can\u0026rsquo;t use. It\u0026rsquo;s really tempting to go, you know, I\u0026rsquo;m, I\u0026rsquo;ve got this title, I\u0026rsquo;m a staffer, principal engineer. And I\u0026rsquo;m saying this is how it is and here\u0026rsquo;s how it is. And there are probably some processes in place where that happens. Especially, you know, as an organization gets larger and larger. You really do need to kind of come out and say like, look folks, this is how we\u0026rsquo;re going to do things around here because we need to be consistent. But even if you\u0026rsquo;re doing that or when you\u0026rsquo;re doing it, the smaller the ideas kind of have to stand on their own merits. I\u0026rsquo;d say the main thing there is, first of all, you have to be right. And the best way to be right is to get a ton of input ahead of time. And I think one of the things that maybe some folks in the middle of the career miss is how much conversation happens before something sees the light of day. If I\u0026rsquo;m going to make a proposal for. I think it doesn\u0026rsquo;t matter what the proposal is. If I\u0026rsquo;m going to make a proposal for a technical thing, an architectural thing, a process thing, whatever, I kind of know up front who might object to it. And I also kind of know what people might not necessarily object to it, but would have really good input on the things that I\u0026rsquo;m missing. And so what I\u0026rsquo;m probably going to do is I\u0026rsquo;m going to make sure, not because of politics, but because actually figuring out why people are objecting to things is important. I\u0026rsquo;m going to start informal and talk to kind of those key people that I can think of to get their input and refine it and make sure that people are on the same page. And, you know, it\u0026rsquo;s funny what, even when I\u0026rsquo;m saying this, I going like, oh, people that are listening, they\u0026rsquo;re gonna be like, oh, no, that\u0026rsquo;s. That\u0026rsquo;s, you know, back off backroom politics and stuff like that. But it\u0026rsquo;s really not. It\u0026rsquo;s that if you want to. If you want an initiative to succeed, you need to have people on side. And a terrible way to get people inside is to put it out to 200 people and say, what do you think? Or worse, to put it out and say, hey, we\u0026rsquo;re doing this. And then you start getting their feedback and you need to walk it back. It\u0026rsquo;s a lot less formal than that. It\u0026rsquo;s more of, you know, you go out and you go, okay, well, these two or I know these two or three people have been really involved with this. And so I\u0026rsquo;m going to make sure. I loop them in to make sure it\u0026rsquo;s, you know, it\u0026rsquo;s not my initiative, it\u0026rsquo;s our initiative that they\u0026rsquo;ve got not only their thoughts put on it, but also their name on it. So that it\u0026rsquo;s coming from. It\u0026rsquo;s not just kind of one person coming and saying, hey, it\u0026rsquo;s going to be this now. And then once you get that, those people probably also know some other people who needs some input on it. And you can kind of just sort of work this sort of informal. Who has opinions about this? Who would it benefit to have on Board in terms of the messaging behind this from the very beginning. The other nice part about that is that it\u0026rsquo;s all really informal stuff. You can have Slack conversations, you can do an email thread, you can have a really low key meeting to just kind of go, hey, this is where I\u0026rsquo;m going with this. Is this, is this gonna flop? You know, what things can you folks think of might go wrong with this? And then as it gets refined and refined, then you can start opening the thing a little bit wider, make it a little bit more public, invite public. But by the time you\u0026rsquo;re doing that, a lot of the really obvious things were wrong. Because whatever you came up with is full of obvious things that were wrong. All the obvious things that were wrong will be taken care of. And you got kind of a mix of people will see it and go, yes, this makes sense. But also the wider audience confined to things that were way out there that no one thought of.\u003c/p\u003e\n\u003cp\u003eDavid: There\u0026rsquo;s a couple really interesting themes in what you\u0026rsquo;ve described. So first of all, I think you\u0026rsquo;re right to call out that this is something that is sometimes invisible to people in the middle of their careers. And I think it\u0026rsquo;s actually maybe one of the important keys to unlocking the next step of someone\u0026rsquo;s progression. But there\u0026rsquo;s sort of an unfortunate dichotomy there because given that it\u0026rsquo;s like the process can sometimes be sort of invisible by design, I think there\u0026rsquo;s a challenge in making sure that people understand how the process works and have their own opportunities for growth. So that\u0026rsquo;s, that\u0026rsquo;s sort of one thought that I have. You also mentioned the idea. Oh, okay, yeah.\u003c/p\u003e\n\u003cp\u003eRich: Just before you move on, just quickly on that one thing that\u0026rsquo;s important is what the thing that I\u0026rsquo;m talking about doesn\u0026rsquo;t have to happen all at the senior staff principal level. Often the folks that are subject matter experts on one specific thing will be all over the org. And being able to pull them in and expose them to this is really good. For that matter, being able to pull them in and expose them to how things work like this is just good in general. And even though, you know, if you\u0026rsquo;re kind of thinking, well, I\u0026rsquo;m not sure about the value of bringing in so and so on this, sometimes it\u0026rsquo;s worth doing it just so that they have exposure to how the process works, I 1000% agree.\u003c/p\u003e\n\u003cp\u003eDavid: I think there\u0026rsquo;s still sort of a risk of bias there where the people that we choose, we might not be creating a sort of equitable environment. I want to circle back to that. I think we\u0026rsquo;ll have an opportunity to talk about sort of how we help bring folks up. But you also touched on organizational politics and sort of the ickiness of that. One of my favorite quotes from someone who taught me a few things is that politics are the way that groups of people make decisions. That was an interesting insight for me because it\u0026rsquo;s like, yeah, if I really think about it, you know, big groups of people, the only way that they can kind of move forward is by forming coalitions and making decisions in smaller groups and then, and then hopefully propagating their ideas or decisions to bigger groups. And there\u0026rsquo;s still good and bad ways to do that. But I think the interesting thing is that after a certain point, it\u0026rsquo;s hard to avoid sort of the idea that there is going to be a certain degree of quote, unquote, politics happening inside an organization as it grows. I\u0026rsquo;ve seen that happen as organizations transition through. And actually the other thing that we\u0026rsquo;ve been talking about of having ideas that start out within small groups and then get broadcast to the whole org later is when an organization gets big enough that you can\u0026rsquo;t just do everything, you know, inside one room, that\u0026rsquo;s like an interesting transition that happens, right, where people start to feel left out. And that sort of, I think, breeds the beginning of this feeling of like politics happening in an organization. What are your thoughts there? I don\u0026rsquo;t know if mitigating organizational politics is the right way to think about it, but like basically how to. What are some ways that you\u0026rsquo;ve found to navigate this both in terms of a leader, in terms of creating culture around it, and also when you\u0026rsquo;re sort of like when you\u0026rsquo;re finding yourself in a political decision making process and surely not a pager duty, but maybe in previous organizations that you\u0026rsquo;ve been a part.\u003c/p\u003e\n\u003cp\u003eRich: Of, we have our stuff as well. But yeah, no, you mentioned bias and it\u0026rsquo;s really important. Awareness and intention is a huge part of it. When I mentioned that it\u0026rsquo;s useful to pull people in, if you\u0026rsquo;re only pulling in the people that you think are going to agree with you, or if you\u0026rsquo;re only pulling into the people that are just kind of like you, then you\u0026rsquo;re actually not going to get the, the kind of input that you want. The idea of starting with a small group and then enlarging the group as things get more refined, it\u0026rsquo;s really a scalability thing. You can\u0026rsquo;t get input from a lot of people right at the very beginning. And so I think the big thing about bias, I\u0026rsquo;m very lucky at pagerduty. I think we\u0026rsquo;re doing quite well in the diversity and equity side of things. I mean, I\u0026rsquo;m saying that as a straight, white CIS male, but compared to some other companies I\u0026rsquo;ve been at, I think we\u0026rsquo;re doing all right still, obviously a long way to go just by virtue of being a company in tech. But having some intention in who you bring in is definitely important in that respect. And again, that\u0026rsquo;s having the sense of who to bring in is one of those skills you kind of develop. I mean, fundamentally, if you\u0026rsquo;re trying to bring in people that agree with you, you\u0026rsquo;re wasting your time. Because what you want to do is you want to bring in the people that are going to disagree with you so that you can end up somewhere in the middle. You know, you can figure out together what the best way forward is. And as you start to enlarge that circle, bring in more people that will be able to, in a healthy, friendly, kind way, tear things apart and you end up with a better proposal and you end up with a better kind of foundation for that proposal. As an example, you know, there\u0026rsquo;s one of my peers at PagerDuty who is also named Rich. I call him my nemesis because he is the Rich that\u0026rsquo;s on the security team. And I figured that people on a security team would like having a nemesis. And I was right. He and I have some different opinions on how to do things in AWS sometimes. And so one thing I could do is I could go, well, I\u0026rsquo;m going to write a proposal and I\u0026rsquo;m going to find a bunch of people like my way, and I\u0026rsquo;m going to get them all on side, and then I\u0026rsquo;m going to go talk to Rich. And that\u0026rsquo;s not going to work. But right from the beginning, I know that look, I can go to Rich and I can say, hey, I\u0026rsquo;m thinking of doing this. I know you\u0026rsquo;re not going to like it. Let\u0026rsquo;s talk about it. And we do. And we end up coming, like maybe we, maybe we completely disagree and can\u0026rsquo;t get anywhere on it, but then we can talk about, okay, how are we going to get past this? Who else do we need to bring in? What are we missing? Or maybe the way that I was headed and the way that he would head on, whatever the decision was, we\u0026rsquo;ll find, I don\u0026rsquo;t want to say a compromise. Compromise is the wrong thing, but we\u0026rsquo;ll be able to use both of our positions to come up with an even better solution. From there, you take it to the next step, and you use the same function to figure out who to bring in and so forth. Really just the idea being you\u0026rsquo;re finding people who will have a perspective, whether it be a technical perspective or a, you know, a diversity perspective or both, or to really look at the idea and go, okay, like, tear this apart, please. Tear this apart. One thing that I very. I consider myself very lucky at PagerDuty is that it is an extremely kind place. People are very intentional, even. Even in disagreement, and especially in disagreement. Everyone understands that the reason that the disagreement is happening is because we want to make. Want to find the best outcome and produce the best results and so forth. And, yeah, we can get grumpy sometimes about discussing things, but it\u0026rsquo;s a very healthy kind of grumpy where, you know, if someone\u0026rsquo;s kind of not moving from the spot, then other people will not ask, hey, look, you\u0026rsquo;re. You know, you\u0026rsquo;ve really dug in here. Let\u0026rsquo;s talk about. Let\u0026rsquo;s stop talking about the proposal. Let\u0026rsquo;s stop. Start talking about why and really kind of dig in to see, well, what\u0026rsquo;s underneath all that? What are you worried about? What\u0026rsquo;s keeping you up at night? What\u0026rsquo;s making you uncomfortable here? And having an environment where you can have those kind of conversations is really nice to have.\u003c/p\u003e\n\u003cp\u003eAlex: That sounds awesome. Changing subjects a little bit. You mentioned earlier that you mentor folks, and I was wondering, what\u0026rsquo;s the process for you for doing that?\u003c/p\u003e\n\u003cp\u003eRich: Yeah, it\u0026rsquo;s funny, I\u0026rsquo;ve got at pagerd a bit of an outsider opinion on mentoring. So we do have a formal mentoring program. I participated in it. I love participating in it. We kind of divided up into technical and leadership mentoring, But I don\u0026rsquo;t know. When I\u0026rsquo;m talking to folks that are technically mentoring, I\u0026rsquo;m often giving them kind of leadership coaching. When I\u0026rsquo;m talking to people that I\u0026rsquo;m leadership mentoring, then there\u0026rsquo;s always technical stuff that comes in. So it\u0026rsquo;s all very blurry. And the reason I say I have a better outsider opinion is that I find that formal mentoring relationships isn\u0026rsquo;t quite what I think of as mentoring. And what I think of mentoring is definitely spans, jobs, you know, having a mentor to me. And it\u0026rsquo;s probably just a case that the word means a couple different things. But there are a couple people that I have had the opportunity to mentor in my career, and I\u0026rsquo;ve watched them go, you know, job to job, and we keep in touch and it\u0026rsquo;s pretty informal, but, you know, someone will check in with me and go like, hey, you know, you were a lot of help to me way back when. I\u0026rsquo;m thinking, moving to this other role. Tell me what you think, or I\u0026rsquo;ll see that they started a job somewhere, and I\u0026rsquo;ll reach out and go, hey, you know, congratulations. It\u0026rsquo;s really great to see. To see their trajectory take off. And it\u0026rsquo;s a very different framing than the sort of formal mentoring programs that places often have in organizations. One of the challenges I have with the sort of the formal mentoring programs is that I don\u0026rsquo;t always have a ton of introspection for how things. How my brain works. I mentioned this back when I was talking about writing proposals that I don\u0026rsquo;t have a process. I just write shit down and eventually a proposal comes out of it. And I hope other people don\u0026rsquo;t do it that way because I\u0026rsquo;m sure it\u0026rsquo;s really inefficient. But I\u0026rsquo;ve been doing it that way for a couple of decades, and that\u0026rsquo;s just what I know. But, yeah, one of the. You know, one thing that I find a little bit difficult is having started at sort of the beginning of the beginning of the web, I started my career in 1994. I had opportunities for learning that just aren\u0026rsquo;t available these days because no one knew what they were doing back then. And I have a really hard time sometime working with people that have started their career in the last few years. And they\u0026rsquo;re saying, well, you know, like, how can I learn about all of this? Like, how do I learn how to learn things that I\u0026rsquo;ve never seen before? And it\u0026rsquo;s like the environment is so much different now with uptime, you know, availability requirements and compliance regimes and just the general complexity of things as well. And that a lot of cases, especially on the infrastructure side, are more about gluing things together than they are building things from scratch. And so sometimes I really have a hard time putting myself in the shoes of someone that started very recently and going, well. You know, one of the things that I consider myself pretty good at is approaching something that I have never seen before and kind of figuring out just enough about it to help someone solve a problem and to be able to kind of coach someone through developing that skill is hard. I do it all the time. Pairing is huge. I have a monkey brain right in the middle of my prehistoric brain. Aversion to the sort of these social parts of pairing. I\u0026rsquo;m going to sit down and I\u0026rsquo;m going To talk to this person while I do the work and I\u0026rsquo;m going to explain and they\u0026rsquo;re going to drive and stuff like that. I know that it\u0026rsquo;s a really useful technique, but in the middle of my brain there\u0026rsquo;s something saying, no, no social, go away. What you do is you go and you set a terminal. So I kind of push myself through that and I find that really useful to actually do stuff rather than have a, you know, a half hour discussion on, you know, so what\u0026rsquo;s on your agenda today? Type of things. That said, I find that the mentoring that I do at HDRT does tend to be the half hour meeting type thing. And one of the things I\u0026rsquo;m going to take away from having this conversation is that I\u0026rsquo;m going to try to stop doing that and start doing more hands on stuff with the people that I mentor. The other thing, of course is a lot of this stuff, especially again from the infrastructure side, is a little opportunistic in that the developing that ability, the technical ability to bring yourself into something you\u0026rsquo;ve never seen before and understand it, or on the leadership side to find yourself in a sticky situation doesn\u0026rsquo;t lend itself to a recurring meeting. And it\u0026rsquo;s a lot more. I just need to make myself available so that if the person that I\u0026rsquo;m mentoring in the formal mentoring program needs to pull me in, then they can.\u003c/p\u003e\n\u003cp\u003eAlex: One other thing that strikes me is I\u0026rsquo;ve been reading a lot about lots of things around resilience, but something that comes up a lot is that experts are very rarely good at explaining their expertise. Like, that\u0026rsquo;s just, it\u0026rsquo;s hard. And so one of the things that they, if you, if you\u0026rsquo;ve ever read the Etsy postmortem facilitation guide, they do a really great job at describing how having that first person account of the situation, the incident, can sometimes allow a less experienced engineer to live that experience through the retelling. And so it\u0026rsquo;s a way of exposing your expertise in a really interesting way. And I found that really interesting. I too have the same issue where it\u0026rsquo;s like, I didn\u0026rsquo;t know. I learned this 15 years ago. It\u0026rsquo;s hard for me to explain it. But when someone says, well, why did you type that command at that moment? Be like, oh, because I saw these 15 thingamabobbers and that led me to do this thing.\u003c/p\u003e\n\u003cp\u003eRich: Yeah, that\u0026rsquo;s it. You get a weird feeling. It\u0026rsquo;s like that old joke about the repair person that places the X and invoices the company chalk $2, knowing where to place the X9998. And yeah, no, that really is a big deal. And one of the things that I\u0026rsquo;ve been pushing at PagerDuty for the last little while is moving from a prevention approach in incident review and postmortems and so forth to an adaptive capacity approach. And I think that\u0026rsquo;s exactly what you\u0026rsquo;re talking about there. The power of narrative is huge. It\u0026rsquo;s important of course, to record some facts in a timeline. And this many customers were impacted and this is how they were impacted. You can\u0026rsquo;t not do that just because you need to communicate that stuff out to the rest of the organization. But if you really want staying power, then you need to tell a story. And hearing those stories, and especially when you get those stories. The idea comes from David woods about being inside versus outside the tunnel, where the tunnel is kind of the viewpoint of the person in the middle of the incident. What they can see is very different than what you can see when you\u0026rsquo;re reviewing what happened afterwards. And staying inside that tunnel of a few different participants in an incident has such bigger learning opportunities. There\u0026rsquo;s definitely to be said that you know a lot of what builds up, especially again especially in sre, what builds up that experience is experience and incidents because you can read a lot about how things go wrong. But it\u0026rsquo;s something else to be inside the tunnel yourself and have that very limited view of what\u0026rsquo;s happening and develop that capacity for hunches. One thing that actually occurred to me a little while ago when we were talking about trade offs and risk and stuff like that is that I think folks that haven\u0026rsquo;t been in management or at least haven\u0026rsquo;t been exposed to working with senior management as peers in staff or principal role, is that they think there\u0026rsquo;s some decision making power that senior folks have, whether on the management side or the engineering side, less senior folks don\u0026rsquo;t have. When you\u0026rsquo;re an intermediate engineer, you\u0026rsquo;re going, well, I think this is going to work, so I\u0026rsquo;m going to try it. But if I were more senior than I would just know it was going to work. And I don\u0026rsquo;t think that\u0026rsquo;s true at all. All the way up to the CEO. What really comes with that seniority is comfort with uncertainty and being able to think about risk. And yes, also you have a lot of experience. So you\u0026rsquo;re right a lot. One of the Amazon principles we were talking before is right a lot of. One of the things about being in the tunnel in an incident is that you have a ton of uncertainty and you have to make all the decisions in that context of uncertainty. You can only see what you can see, even though in hindsight a whole bunch of other things will have become obvious. If you\u0026rsquo;re going to learn how to operate resilient systems and design resilient systems, then really understanding where those limits are is critical.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that realization of, like, sort of all the way up the chain, everyone is making decisions with uncertainty, and there\u0026rsquo;s no sort of superhuman. There\u0026rsquo;s certainly people that have either more experience or more capacity than others, but broadly speaking, everyone is pretty similar, actually. At the end of the day, we\u0026rsquo;re all, you know, struggling with the same things. And so I think that\u0026rsquo;s an interesting realization to make as folks get further into their careers, is that, like, some people may be initially viewed as disconcerting, but I think it\u0026rsquo;s actually empowering. Right. It\u0026rsquo;s like you are capable of doing all the same decisions, of making all the same decisions as everybody else. You have access to the same information as everybody else. And that can be an empowering feeling once you sort of accept it. We\u0026rsquo;re almost at time. I do want to quickly. There\u0026rsquo;s two questions that we tried to ask everybody that comes on the show, and one of them is you already mentioned Tanya Reilly\u0026rsquo;s blog, and I think you mentioned a couple other resources throughout. But are there books or blogs or people that you have learned from and that you would recommend people check out who are listening to the show?\u003c/p\u003e\n\u003cp\u003eRich: Oh, boy, that\u0026rsquo;s. That\u0026rsquo;s a good question. There\u0026rsquo;s a lot. A lot of the stuff that kind of shaped my thinking about things is probably considered a little bit old at this point. But in terms of more recent stuff, we didn\u0026rsquo;t spend a ton of time talking about incidents. But I do think a lot in terms of, you know, in terms of adaptive capacity and resilience and stuff like that. I wish I had a book list in front of me right now. I could name particular titles. Dava Wood\u0026rsquo;s the Field Guide to Human Error is great in that respect. There are other ones that are in my ebook library that I can\u0026rsquo;t think of right now in terms of working with people and that uncertainty and stuff like that I could probably do. I could do better with some names maybe, than particular things. John Alspaugh, obviously, if you would like.\u003c/p\u003e\n\u003cp\u003eAlex: To just, like, send us an email, what we can do is, like, in our posts, we can put it and we can make sure that people get it.\u003c/p\u003e\n\u003cp\u003eRich: One specific thing I will call out there, though. Camille Fournier\u0026rsquo;s the Manager\u0026rsquo;s Path. Even if you\u0026rsquo;re not going into management, especially if you\u0026rsquo;re not going into management, is a must read just to get a flavor of what it\u0026rsquo;s like at each level of management. To tie this back to, we were just talking about uncertainty, really. The understanding that everyone is winging it the same way that you\u0026rsquo;re winging it is really like terrifying and comforting at the same time. People that are in senior roles didn\u0026rsquo;t get promoted there because of superpowers. They\u0026rsquo;ve got experience, they\u0026rsquo;ve got frameworks and stuff like that, but they\u0026rsquo;re still winging it. We\u0026rsquo;re all winging it. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Okay, so the last question, and this is tongue in cheek fun, how much time do you find yourself coding nowadays?\u003c/p\u003e\n\u003cp\u003eRich: Very little. The flip side of that is, you know, as a site reliability engineer that comes at it from the systems perspective. I didn\u0026rsquo;t code a lot before, but in terms of just individual work in front of a terminal, you know, it\u0026rsquo;s almost to the point where outside of proof of concepts and taking on honestly taking a lot, a lot of the stuff to help out the team rather than lead the team in terms of writing code, like taking on that toil is a great way to build build rapport. Very, very little. There\u0026rsquo;s not a ton of leverage I can have in a code editor compared to what I can have in Google Docs or in talking to people and stuff like that. And that\u0026rsquo;s even though I know a lot of people are going, no, not coding. That\u0026rsquo;s perfect for me. Being able to kind of do the technical management stuff that I loved when I was in management, but staying closer to the technology and not having people report to me, which I found extremely stressful, is perfect. Awesome.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Rich, thank you so much for taking the time today. It has really been a pleasure. That\u0026rsquo;s it. Thanks so much for listening to Staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, Podcasts staffenge. Com. The website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-08-24T09:00:00-05:00","date_modified":"2021-08-24T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/mason-jones-credit-karma/","url":"https://podcast.staffeng.com/season-1/mason-jones-credit-karma/","title":"Mason Jones (Credit Karma)","summary":"Leading without authority. Ideally, having everyone step back and reminding them of the goals of the project is the best first step.","content_html":"\u003cp\u003eCredit Karma is a company that helps people understand their credit. Today’s guest, Mason Jones, was brought onto the Credit Karma team to move the company from a monolith to microservices. The company has grown almost four-fold since he joined, and Mason is now a senior staff engineer whose role swings from engineering to project management to technical writing, depending on the project he is working on. Prior to working at Credit Karma, Mason was involved in a number of small start-ups, and he explains how these experiences have translated into very useful skills in his current job. He also explains how he shares these skills with other engineers in the company, and some of the challenges that have arisen during mentoring sessions. Security, velocity and reliability are core values at Credit Karma and Mason shares how he, as a leader, upholds them, and how he continually expands his knowledge in order to have the maximum positive impact on the company. \u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/masonjones/\"\u003eMason Jones on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.creditkarma.com/\"\u003eCredit Karma\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8967649-mason-jones-credit-karma.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, today\u0026rsquo;s guest is Mason Jones. For the last 25 years, he\u0026rsquo;s been working for mostly early stage startups around San Francisco. For the last five years he\u0026rsquo;s been at Credit Karma. He\u0026rsquo;s had a wide variety of roles, from being the first engineer to a chief architect and a VP of engineering. It\u0026rsquo;s always awesome to talk with someone who\u0026rsquo;s had a wide variety of roles. So let\u0026rsquo;s jump in.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Mason, thank you so much for joining us today. It\u0026rsquo;s great to have you on. I think it would be helpful for listeners if we could start by having you tell us a little bit about who you are and what you do.\u003c/p\u003e\n\u003cp\u003eMason: Sure, yeah. Thanks very much for having me on. Been looking forward to having the discussion. So I am a senior staff SRE at Credit Karma here in San Francisco and I\u0026rsquo;ve been with the company for about five and a half years, a good while. And I probably came to the sort of staff engineer role here a little bit differently than some folks do. Coming from my previous startups where I was generally I often started as the first engineering person, the first engineering type, and then at a very early stage would be involved in building the initial thing, whatever that thing was, and then end up getting progressively less hands on as we were able to hire up a team. And so I\u0026rsquo;ve done that repeatedly over the years. And then kind of joining Credit Karma, I purposely wanted to join a company that was farther along the journey and just get that different sort of experience. And it made sense at the time for me to come on as kind of a staff engineer type to help with a bunch of the interesting work we had going on here.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, it\u0026rsquo;s funny you mentioned sort of this path of progressing through smaller organizations. It\u0026rsquo;s actually not something that unusual. Alex and I have kind of noticed a pattern that a lot of people we talk to end up either having like a lot of experience leading projects in the open source community, or a lot of experience as like leaders in small startups And I think a lot of the stuff that staff engineers end up doing in bigger organizations is kind of shaped by, by the same sort of experience where oftentimes it\u0026rsquo;s, it ends up being useful to have, have some exposure to influencing folks and also sort of maintaining, at least in the small startup case, maintaining context on like a lot of things that are happening in parallel for context as well. You know, I\u0026rsquo;m obviously familiar with Credit Karma and I think a lot of listeners are, but I\u0026rsquo;m curious, like what size organization are we talking about?\u003c/p\u003e\n\u003cp\u003eMason: Sure, yeah, good question. So when I joined here, the company as a whole was a little under 400 people and engineering was about half of that. And we\u0026rsquo;ve, we\u0026rsquo;ve maintained that ratio for the most part over the years. Now engineering is somewhat over 800 and the company as a whole is I think last I saw, not quite 1400. So we\u0026rsquo;ve joined a lot, grown a lot since I joined and people are often surprised to hear how many engineers we have. Right. But we\u0026rsquo;ve grown from originally offering credit scores and helping people kind of understand their credit history to now adding management for insurance, mortgages and most recently savings and checking accounts even. So now we\u0026rsquo;re really helping people manage their money as well as just understand what it means. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: Are there other staff engineers at Credit Karma?\u003c/p\u003e\n\u003cp\u003eMason: Yes, we, we have I think 10 levels in our engineering framework and they\u0026rsquo;re sort of the pre senior stage. There\u0026rsquo;s the senior stage and then there\u0026rsquo;s staff, staff to senior staff and principal. Until very recently we had never had a principal engineer and staff engineers tend to be kind of working within a couple of teams and senior staff tends to work within a director\u0026rsquo;s organization. So for me, for example, I\u0026rsquo;m the senior staff engineer in our infrastructure org, which encompasses cloud engineering, observability, database management and other infrastructure stuff. Kubernetes, those pieces of it. We have now only four senior staff engineers at the company, a couple in product, couple in platform, and then one principal. Just recently one of our senior staff folks is now principal.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So I feel like you sort of described like the scope at which you would expect a staff engineer to work at. But is there like a typical approach or a set of like expectations for staff engineers at Credit Karma?\u003c/p\u003e\n\u003cp\u003eMason: Sure. For staff engineers the expectation is really being able to lead a cross cutting project that requires collaboration across multiple teams. And that\u0026rsquo;s sort of what differentiates it in our framework from a senior engineer who\u0026rsquo;s expected to lead a project within their team. So it\u0026rsquo;s very Much an expectation of just increased scope and responsibility. And with that, of course, comes more expectations for communication, collaboration and all those fun non technical pieces.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that makes sense. I\u0026rsquo;m curious, within what you see as the expectations for staff and the scope, is there something that you feel like you bring especially to the role? Is there a way that you practice it that might be different than other staff engineers?\u003c/p\u003e\n\u003cp\u003eMason: I think we\u0026rsquo;re all a little bit different. Sure. And that\u0026rsquo;s going to be based on our previous experience. Right. I think going back to kind of what you were saying earlier about people working at smaller startups and then bringing that experience with them, I think there\u0026rsquo;s a lot to that. Because being an engineering leader, no matter what your role and title is at a small startup, pretty much necessitates having your fingers in a little bit of everything. And when you bring that experience to being a staff engineer at a larger company, you\u0026rsquo;re bringing with you that experience and those skills for bringing together a mess of stuff and making something sensible out of it. Right. Which is I think, probably a weird description of project management with anything of significant import to a company. You\u0026rsquo;re going to have to understand the technical aspects of it, of course, but you\u0026rsquo;re also going to need to be ready to bring other people along for the ride, communicate the idea, sometimes sell the idea. Right. But then organize it all and there is inevitably a little bit of project management, program management work to it and management, pure management work to it, you know, pretty much everything except the personnel management. You know, I\u0026rsquo;m thinking back to one of our, any of our big projects here and at different times along the lifespan of the project, I would find myself feeling like, you know, oh, I\u0026rsquo;m an engineer today. And then, oh, no, I\u0026rsquo;m a project manager today. Oh, I\u0026rsquo;m a tech writer today. And it\u0026rsquo;s all of those pieces that come to it and to your original question of what I bring to it, all of that previous experience is really what I bring to it. And because of that, different people will approach the same work in a different way based on how they\u0026rsquo;ve managed to successfully do it in the past.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;m sure we\u0026rsquo;re going to circle back to a lot of the things that you touched on there. But before we do, I\u0026rsquo;m curious if you could sort of frame the context for a little bit in the sense of concretely, what does work at your scope look like? Maybe if you could think of some example projects that you\u0026rsquo;ve been involved in or that you\u0026rsquo;ve driven. Yeah, basically what would you sort of aim to accomplish over a day or a week or a month or a quarter or whatever?\u003c/p\u003e\n\u003cp\u003eMason: That\u0026rsquo;s an interesting question, because they\u0026rsquo;re all so different. And thinking back over a number of years here, different projects have looked very different. And oftentimes I will work on a particular project for a quarter or two and then move on to the next one. But some projects last a year and in some projects I\u0026rsquo;m almost managing a group of people, and on other projects I\u0026rsquo;m managing a piece of the project and just making sure that it\u0026rsquo;s going along in, in the right way. On the biggest projects, I have typically partnered with a TPM technical program manager here to kind of help with the organization and a lot of the bookkeeping pieces of it. And also that way we can kind of double team on other groups that need to be pulled along, convinced to join in, or just tracked as part of the project. Going back to, as an example, several years ago, we moved out of our data centers into cloud. And so we were literally mapping out all of our systems, living in our data center, figuring out what we had, discovering things we\u0026rsquo;d forgotten we had, and figuring out what do we do with this stuff, mapping out the route to get it into the cloud. And that of course, required all of engineering to participate. And so having a TPM on that was essential. And I focused on a piece of IT and other staff engineers focused on other pieces of it. So my role in that went from early on archaeology, looking through our systems and figuring out what do we have, identifying things that we\u0026rsquo;d all forgotten about and figuring out what it meant. Then the design part of it. We have this thing and here\u0026rsquo;s what cloud looks like. How do we pick this up and drop it into the cloud? And so that\u0026rsquo;s the technical work of it. Then once we had that sort of figured out, it was wrangling all of the teams who then inevitably needed to be involved, communicating to them what we expected from them, figuring out what we could expect from them and what we were going to have to do on their behalf as platform engineering. And that spanned technical writing, collaboration, communication, and then just partnering with them. So from the start of the project to the end of the project, my role shifted constantly. And that\u0026rsquo;s, you know, honestly, that\u0026rsquo;s also what makes the work fun.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. I\u0026rsquo;m curious now, diving into something specific that you mentioned there. Speaking personally, I don\u0026rsquo;t always find the right sort of layer of abstraction to interface with tpms effectively. I\u0026rsquo;m Curious if you have advice on that or sort of what you\u0026rsquo;ve seen work, what you haven\u0026rsquo;t seen work.\u003c/p\u003e\n\u003cp\u003eMason: Yeah, that\u0026rsquo;s definitely a personality based situation. Depends on both sides of the partnership. Some TPMs are more technical than others for one thing, so that will inevitably shift the boundary one way or the other between us. So the best thing that I\u0026rsquo;ve found is to really sit down early on and sort of talk through expectations and think about where that boundary makes sense. Because I actually think it\u0026rsquo;s going to be different every single time. And so it pays to sit down together and work that out. And it\u0026rsquo;s not like you\u0026rsquo;re going to sit down and say, okay, each day I\u0026rsquo;m going to take things to this line and then you\u0026rsquo;re going to pick it up. It\u0026rsquo;s going to be more loose than that. But it\u0026rsquo;s a matter of understanding where handoffs need to happen, where someone\u0026rsquo;s strengths and weaknesses are. I for one can do sort of project management type work. You know, looking through the JIRA epic and figuring out where are things at and who needs to do what next. It\u0026rsquo;s my least favorite part of it. And there are other people who are way better at it than I am. So that\u0026rsquo;s the sort of thing where I\u0026rsquo;ll keep it in mind and realize, you know what, if I have to do this, I will, but if the other person is going to be good at that and can take it on, that\u0026rsquo;s going to be better for the project and everything. So just understanding and really getting to know the person and you know, if this is going to be a year long project, we\u0026rsquo;re essentially going to be married for a year. We need to get on really well. We need to understand each other and we need to be in constant communication. So putting effort in early on to build that relationship and just understand what the relationship looks like will really pay off.\u003c/p\u003e\n\u003cp\u003eAlex: Shifting gears a little bit. I. One of the things you mentioned is that on any given day you could do one thing. You could be a technical writer, you could be an engineer, you know, and it sounds like so you have a lot of range. There\u0026rsquo;s a lot of things you could do in a day. Given that you have that choice and that leeway, how do you make sure that you\u0026rsquo;re always sort of aligned with what your organization needs from you or what your organization is trying to do? Do you have a process for understanding that alignment?\u003c/p\u003e\n\u003cp\u003eMason: That\u0026rsquo;s a huge good question. If we\u0026rsquo;re deep in a project, then that makes it kind of Easier because you\u0026rsquo;ve got your priorities laid out already. If we\u0026rsquo;re in between projects, or if I\u0026rsquo;ve just got a few different things in the air, a bunch of smaller projects going on, then that\u0026rsquo;s definitely tricky. When something has just finished, or ideally actually as something is finishing, that\u0026rsquo;s where I\u0026rsquo;m talking to my director and talking to other people and trying to understand what\u0026rsquo;s going on and what could be useful as the next thing for me to focus on. So there are different phases in my world where I might find myself. The key is just prioritizing. I find satisfaction when I\u0026rsquo;m working on something challenging that I know will benefit the company. It\u0026rsquo;s easy to actually find some technically challenging thing and kind of work on it for several weeks and discover that it actually didn\u0026rsquo;t really move the needle. It didn\u0026rsquo;t make a big difference. So it\u0026rsquo;s probably not the best thing for me to spend my time on. So that\u0026rsquo;s where the communication really enters into it as well. Trying to be in contact with lots of people and lots of different teams, see what\u0026rsquo;s going on, see what\u0026rsquo;s coming up and be able to hopefully kind of bring my head above water occasionally. Look around, see what\u0026rsquo;s coming and think about what\u0026rsquo;s going to be next. Because if I finish a big project and then I start to look around, it could be a good month before I find something useful and important to work on. So trying to see ahead a little bit really pays off. It can be tough. There\u0026rsquo;s. In a company our size now, there are dozens of things going on, most of which I don\u0026rsquo;t even really know much about other than hearing a word here and there. So trying to see where a difference can be made over the next couple of quarters, over the next year is challenging, but interesting. And I think that\u0026rsquo;s the important thing for me.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. One of the things you mentioned is that when you\u0026rsquo;re trying to understand the next project, find it. You mentioned that like communicating is really important. Is there like a concrete way that that communication takes place? Like, is it, are you doing one on ones? Are you doing status meetings? You know, what does it look like when you actually go to seek out that new opportunity?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, I do semi regular one on ones with different people. It tends to shift. I\u0026rsquo;ll go through like a couple of months of, or a couple of quarters even of meeting with a certain group of people and then some of them will drop off and others will add on. And so it\u0026rsquo;s constantly evolving. And I think that\u0026rsquo;s pretty natur. So I will try to meet with other staff engineers pretty regularly. We have a couple of organized regular meetings. For example, within platform engineering, we\u0026rsquo;ve got a platform architecture group that is sort of a group of people available to review designs and proposals, not as gatekeepers but as hey, if you want to show this to us, we\u0026rsquo;ll get together with you, talk through it and help you identify potential problems, answer questions, and it\u0026rsquo;s a great way of disseminating knowledge about what\u0026rsquo;s going on within within the team. I\u0026rsquo;m obviously doing regular one on ones with my manager who\u0026rsquo;s the director of our infrastructure department. I also have periodic one on ones with our vp, so I\u0026rsquo;ll pretty much use those to ask, you know what, what\u0026rsquo;s concerning you these days? What\u0026rsquo;s coming up? What should we be thinking about? What wakes you up in the morning? Because those are the sorts of things where, hey, if this is worrying you, then hey, I should at least think about it, should at least know about it. So it\u0026rsquo;s those sorts of conversations on a regular, semi, regular basis. Then there\u0026rsquo;s a certain amount of time spent each day watching and thinking about what\u0026rsquo;s going on. Like probably everybody else these days. We use Slack heavily, we hardly use email anymore. You know, it\u0026rsquo;s weird, but because of that I lurk in lots of Slack channels. And being in the platform engineering organization I\u0026rsquo;ve found really helps me because everything sort of touches us eventually. My very first big project here, the reason I joined the company, was to move us from a monolith to microservices architecture. And in the process of doing that and kind of getting that going and then the later migration to the cloud, I ended up touching almost every single product engineering team, which is great for feeling the pulse of what\u0026rsquo;s going on and kind of seeing what\u0026rsquo;s slowing people down, what\u0026rsquo;s getting in the way, what\u0026rsquo;s not scaling, you know, all of these things. So watching commentary, reading Slack channels, seeing what people are chattering about, and sometimes noticing patterns like, oh, you know, someone\u0026rsquo;s complaining about this thing and someone else was complaining about it last week, so maybe that\u0026rsquo;s something that, you know, we should be thinking about. I like to just spend a little bit of time each day catching up on various Slack channels and seeing what\u0026rsquo;s going on. And that\u0026rsquo;ll sometimes point me to someone and say I should schedule a one on one with this person and learn more. Learning what\u0026rsquo;s going on is essential.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. A couple times. So you\u0026rsquo;ve mentioned A couple projects like moving from monolith to microservice. Moving from. What am I saying?\u003c/p\u003e\n\u003cp\u003eMason: Right, from our data center.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, you\u0026rsquo;re sorry, data center to the cloud. Right, sorry, brain fart. But then you also mentioned things that are a little bit more soft, like watching friction in slack being like, oh, I\u0026rsquo;m noticing a pattern of friction here, you know, on those things that I, that might be a little less concrete, like there\u0026rsquo;s friction, like people are having a slightly hard time doing a thing, you know. How do you find yourself articulating the value to your organization that you, you or someone should go and fix those things?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, that\u0026rsquo;s the sort of prioritization question and impact question. We have a few particular values, I guess, one of which is velocity, but one of which is reliability as well. So from platform, from the platform engineering perspective, we\u0026rsquo;re looking at both the reliability of the systems, but also the efficiency of our internal tools. We\u0026rsquo;re responsible for keeping the site up and going, but we\u0026rsquo;re also responsible for managing and building and maintaining the tools for all of the engineers to get their work done. So that\u0026rsquo;s good because there\u0026rsquo;s always this balance of, hey, we could loosen things and people could move much, much faster. But then reliability goes down the tubes. So we have to find that balance. We are in a, you know, in the fintech space, we manage incredibly sensitive data. Security is the first thing we think about before we do anything. So that also puts some restrictions on what we can open up. Right. What tools we can provide, what we can let people do. So again, that impacts the velocity of things. So the value of a particular piece of work in my area will often come down to either this is going to improve our reliability or MTTR or all of these things, or it\u0026rsquo;s going to improve development velocity because those are the two things that we have the biggest impact on. So if I\u0026rsquo;m sort of seeing something going on and I\u0026rsquo;m thinking, hey, this should probably be worked on, someone should spend some time on this. It might not even be something that I\u0026rsquo;m going to spend time on, but I might be the person to bring it up and go and talk to a manager or director and say, I\u0026rsquo;ve been seeing this, I think we should dig in more and more. Here\u0026rsquo;s the benefit that we might get out of it. Let\u0026rsquo;s figure out how to measure that potential benefit and then we can prioritize it and decide whether it needs to get done or not.\u003c/p\u003e\n\u003cp\u003eDavid: Do you think that there\u0026rsquo;s any inherent tensions between Some of the priorities that you mentioned being security, reliability and developer productivity. And if so, like, how do you think about resolving them?\u003c/p\u003e\n\u003cp\u003eMason: It\u0026rsquo;s almost one of those cases where, you know the old saying, a compromise is when both sides walk away unhappy because you can\u0026rsquo;t satisfy everybody. So it\u0026rsquo;s finding a balance. That balance is going to depend on the company\u0026rsquo;s culture, I think, and the company\u0026rsquo;s values. For us, security is first, if there is a security concern about something that trumps all other concerns, we\u0026rsquo;re not going to say, hey, if we let everyone just SSH to production and debug, then they can move way, way faster. Not going to happen, Never going to happen. So we find that balance, like, okay, if you can\u0026rsquo;t do that, then how do you get your job done? So for me, as a senior staff engineer in our infrastructure area, I\u0026rsquo;m looking at, okay, cloud stuff. We can\u0026rsquo;t let everyone just terraform away because they might destroy production. So where do we draw the line? What tooling do we provide so that they can get their job done? And how self service can we make this? We realize the more self service the better. But we have to decide where that line is drawn based on stability, reliability and security. So it\u0026rsquo;s balance. It\u0026rsquo;s to some extent pushing things as far as we can to achieve that reliability and velocity. But as you say, they are going to be in conflict and security is going to enter into the mix as well. So when I\u0026rsquo;m looking at a potential project, when I\u0026rsquo;m for example, reviewing someone\u0026rsquo;s tech design document, I\u0026rsquo;m there to help them think about those things, bring my experience to it and say, you know, I\u0026rsquo;ve seen this pattern before and if you try to do this, then security is going to say, nope. So let me help you think about another way to achieve this. Or hey, did you realize that if you do this and open it up, then it might have this impact on our reliability and just help ask those questions and figure out what we can do.\u003c/p\u003e\n\u003cp\u003eDavid: This is maybe going to sound like I\u0026rsquo;m repeating myself. It\u0026rsquo;s a variation on the same question. But when there are sort of these priorities that are intention, like we just talked about, oftentimes what you\u0026rsquo;ll find is that different groups within the company or different teams within the company sort of are favoring one one angle over the other, right? And then what, what starts out as sort of like, you know, maybe a rational process like you described actually becomes a process of two groups of people that disagree because their compasses are slightly Askew. Right. They\u0026rsquo;re pointing in different directions. So when it becomes a problem about getting people aligned, then how do you think about it?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, and this enters into the, you know, leading without authority. Right. Leading without explicit authority. And ideally that happens. Ideally, if I\u0026rsquo;m maybe the one leading this project and I\u0026rsquo;ve got these two teams and I\u0026rsquo;m asking both teams to participate in the project and they\u0026rsquo;re not able to come to an agreement, then that\u0026rsquo;s certainly where I need to step in and realign everybody. Generally, having everyone step back and reminding them of the goals of the project is the best first step. We\u0026rsquo;re all there to do the same thing. In the end, we\u0026rsquo;ve got the same goal. So let\u0026rsquo;s step back, remind ourselves what the desired outcome is. Because often, more often than not, the conflict is about how to reach that goal. It\u0026rsquo;s not about the goal. And so let\u0026rsquo;s think about that goal again and then let\u0026rsquo;s think about the constraints that we\u0026rsquo;re under, and then let\u0026rsquo;s find that balance together. A very common example is a team needs to get this thing done, and they\u0026rsquo;re getting pressured to hit their schedule. And I\u0026rsquo;m helping them with the design and security is saying, no, you can\u0026rsquo;t do it that way. And then, you know, the team that\u0026rsquo;s under pressure, of course, is going to get stressed and I need to help them understand security is not a bad guy, they\u0026rsquo;re actually the good guy, and we need to help them. And maybe I can help them imagine a different way to get this done, because I\u0026rsquo;ve been doing this a while and I\u0026rsquo;ve been in this role for a while. I may have seen other examples of teams doing similar work, but I can also call on staff engineers in other areas of the company to say, have you done something like this before? Do you have some ideas? And then I\u0026rsquo;m just sort of helping be an information gatherer for them, which is a really valuable thing to do if I can. So arming them with the information and helping them understand that nobody\u0026rsquo;s trying to prevent them from getting their work done. They\u0026rsquo;re doing their part for the company to protect our users, protect our systems and so on. And it\u0026rsquo;s sometimes a bit of a, like a marriage counselor role. And because I\u0026rsquo;m not the manager, I can\u0026rsquo;t say, no, you\u0026rsquo;re going to do this. It\u0026rsquo;s more my part to help them understand their possibilities.\u003c/p\u003e\n\u003cp\u003eDavid: Yep, that makes sense. Switching topics a little bit, I\u0026rsquo;m curious about sort of, and maybe this fits Back in with something we were talking about earlier. But when you think about sort of quantifying the impact that you\u0026rsquo;re having, are there, you know, does credit karma do like okrs or anything like that? Is there some kind of framework that you\u0026rsquo;re using to sort of like measure what\u0026rsquo;s happening?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, we do quarterly okrs. They\u0026rsquo;re sort of top down meets bottom up. A team will have some things that they would like to get done this quarter. The company has things they want to get done this quarter and we meet in the middle. I say that, but it\u0026rsquo;s not. Truthfully, it\u0026rsquo;s not entirely in the middle because company goals trump individual team goals. That\u0026rsquo;s fair, we all understand that. But that\u0026rsquo;s the general idea is that the company has some needs, team has some stuff they want to do, and we figure out how it all meshes together. And we do typical OKR measurements. The OKRs are to identify the big chunks of work and to get everyone aligned. More so than like a project management tool. Right. I think the biggest benefit of okrs is that we publish them all in a place where everyone can go see them. If you\u0026rsquo;re curious what is another team\u0026rsquo;s priority for the quarter, go and look at their OKRs. They\u0026rsquo;re right there and they help us identify the dependencies. And that\u0026rsquo;s oftentimes where I\u0026rsquo;ll be a little bit more involved, I guess because of how I work kind of across our department. If I see there\u0026rsquo;s a dependency, I can help potentially call that out. When you\u0026rsquo;re first starting a project, you don\u0026rsquo;t necessarily know all the dependencies at the beginning. And so helping identify those. When a design document or a PRD or something comes along, I can ideally help notice things and say, have you thought about this? No. You better probably go talk to that team over there and make sure that they know you\u0026rsquo;re going to do this because I think it\u0026rsquo;s going to impact them in this way.\u003c/p\u003e\n\u003cp\u003eAlex: Switching topics again, I\u0026rsquo;m curious, do you have any particular practices around sponsorship or mentoring of folks in your organization? Is that something that you do and if you do, what\u0026rsquo;s your approach to it?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, there\u0026rsquo;s informal and formal. Actually, informal comes in two forms. One is that sometimes people will get in touch and ask if I\u0026rsquo;d be available to start doing one on ones with them and sort of mentor them and help them along. And that\u0026rsquo;s great. That feels good. There\u0026rsquo;s also just during a project when I\u0026rsquo;m working with other people, I will try to Help them out, obviously. And sometimes that turns into informal mentoring where I\u0026rsquo;ll be helping maybe a senior engineer on a big project and helping them kind of up level and start thinking about things at that larger scope. We also do a formal mentorship program at Credit Karma. We\u0026rsquo;ve done it sometimes twice a year, sometimes once a year. And it\u0026rsquo;s just an optional thing where people can sign up to be mentors and then other people can sign up as mentees. And I\u0026rsquo;ve done that regularly, and it\u0026rsquo;s really fun. One of the neat things about that one is that the folks who organize our internal education efforts run the mentorship program and they connect people. So we\u0026rsquo;ll do a quick sort of mentorship program. Start where people will go around and just ask various questions and learn about the mentors and then they\u0026rsquo;ll kind of indicate what they\u0026rsquo;re looking for and who seemed potentially like a match. And then our organizers will connect everybody. And the result is that I\u0026rsquo;ve often gotten connected with people in other parts of the company that I wouldn\u0026rsquo;t really have gotten to know otherwise. It\u0026rsquo;s the best kind of mentorship where we\u0026rsquo;re learning from each other. I\u0026rsquo;m learning what their job is like and helping them understand how engineering operates potentially, or just an engineer in another part of the org that I haven\u0026rsquo;t really worked with before and kind of helping them. So mentorship is a terrific thing. And I\u0026rsquo;ve done it outside the company as well through other mentorship programs. I figure, what\u0026rsquo;s the point of having a bunch of experience if you\u0026rsquo;re not going to share it?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. I\u0026rsquo;m curious if you\u0026rsquo;ve ever had an experience where mentoring or sort of informal or formal wasn\u0026rsquo;t as easy as you. Not easy. It\u0026rsquo;s, you know, like things aren\u0026rsquo;t supposed to be necessarily easy, but like where it was maybe more challenging than you thought it would be, you know, and how you responded to that.\u003c/p\u003e\n\u003cp\u003eMason: Yeah, couple of examples, I think. A couple of different types of. In one case, it wasn\u0026rsquo;t an internal mentorship where the mentee legitimately had a real management problem that they needed to work through. And I was acquainted with the head of their department, but not their manager. And that\u0026rsquo;s a challenge because, you know, it\u0026rsquo;s not as if I\u0026rsquo;m going to break confidence and go step in and go talk to the head of their department and say, did you know that this is going on? So I\u0026rsquo;m like, okay, how do I really help them and understand them? And I\u0026rsquo;m not their manager. So is the manager the problem or is my mentee the problem? I need to figure that out first and really guide them. Thankfully, that one worked out really well, but it. It did throw me for a loop initially because I kind of left the first. The first meeting thinking, wow, okay, how am I actually going to approach this in the context of my company and privacy and everything else? Like, how do I work with them to get them through this? So it\u0026rsquo;s like being a manager without being a manager. In other cases, I think the challenge has more been how do I. How do I make myself useful to this person? I\u0026rsquo;ve had the occasional one where kind of start talking and realize, all right, I\u0026rsquo;m not sure that what you\u0026rsquo;re looking for is something I can give you, but let\u0026rsquo;s just do the best we can, learn from each other, and at the very worst, we will come away knowing more than we did. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: When you take a step back and you look at all the different kinds of work that you could do. Engineering, project management, team, sponsoring, mentorship, you know, do you have like a. You know, like a pie and the percentage of the pie that you like to hit on each one of those, you know, or is it more fluid for you?\u003c/p\u003e\n\u003cp\u003eMason: It\u0026rsquo;s fluid, but there are certainly pieces of it that I want to make sure I check off from time to time. One of the. One of the things that I like about this particular role of being a staff engineer is that it is inevitably part management, part leadership, part technical. And those are really the three big pieces where the management is in guiding what we\u0026rsquo;re doing and why we\u0026rsquo;re doing it. The technical is sort of how we\u0026rsquo;re doing it, and then the leadership is just helping put the pieces together and make it easier for everybody to do the best work they can. All the other pieces of this that float around are less important than those three for me.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. Do you have, like, your favorite mentorship story? Like, you mentored this person and then they became like, the, you know, the next CTO or something?\u003c/p\u003e\n\u003cp\u003eMason: Yeah, yeah. Through an outside mentorship program that I\u0026rsquo;ve been part of for a little while, I got connected with kind of senior engineer, small startup, who was trying to find his place in the inevitable startup chaos. They were growing fast, and there were all these things going on, and he was thinking about where to go and what he wanted to do. And just over time, I was able to help him kind of think through the possibilities. And he\u0026rsquo;s now a manager there, and they\u0026rsquo;re growing, and he\u0026rsquo;s growing with Them and seeing that happen is always terrific. I had a similar one recently as well where this lead engineer, we were going through the mentorship program and I was talking with her about what she was working on and then she became manager and then the COO left the company and suddenly she was reporting directly to the CEO and trying to figure out, well, what does this mean now? And being able to help her think through how to make best use of the opportunity, but also not sink and figure out how to prioritize everything. And now she\u0026rsquo;s VP of engineering at the place as it grows. And yeah, it\u0026rsquo;s just awesome to see that sort of thing happen.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s very cool. Actually, on that note, sort of this idea of like growing a leader inside a growing organization and kind of maybe going full circle. Like I know that you touched a little bit on sort of how you think that your experience inside smaller organizations influenced your work at Credit Karma, but I\u0026rsquo;m curious if there\u0026rsquo;s anything sort of like any one specific trait that you think has translated sort of most effectively from those earlier experiences to your current work.\u003c/p\u003e\n\u003cp\u003eMason: Communication is, I think, what I would point to. And that\u0026rsquo;s, that\u0026rsquo;s due to having spent time leading engineering at companies with lots of non engineering people, which slowly got me good at being able to translate technical into non technical. And as a staff engineer, you might think that that\u0026rsquo;s not as important. What it helped with is leading me to be able to take technical proposals, technical ideas, and connect them to the business value and connect them to the reason why we should do this thing thing. And I think that\u0026rsquo;s probably the biggest thing that I learned over the years at early stage startups is, you know, if I\u0026rsquo;m thinking, oh, we should build this thing, and I go to the founder and I say, we should build this thing. And the founder looks at me and says, why should we build this thing? And early on I would just look at them and say, because it needs to be built. Duh, that\u0026rsquo;s not very helpful as it turns out. So learning that, no, I need to step back, provide context, provide an explanation of the value for it, and why should we build this thing instead of these other 10 things? Because we\u0026rsquo;re at an early stage startup and we need to build all 11 of them no matter what. Can\u0026rsquo;t we build them all at once? Working out all of that and understanding how to communicate it I think has probably been the most valuable lesson I\u0026rsquo;ve learned.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. That makes sense. Kind of. It rings through it, it fits with other patterns that I\u0026rsquo;ve seen are there some resources, books, blogs, people like that you follow, etc. Who have sort of influenced the way that you think about this stuff?\u003c/p\u003e\n\u003cp\u003eMason: Let\u0026rsquo;s see. It\u0026rsquo;s interesting because for the idea of operating as a staff plus engineer, there\u0026rsquo;s been a lot more information sort of percolating out of the industry over the last year or so, literally, I think. And we all have to point to Will Larson for some of that, of course. Got the book here, got his new book upstairs. That\u0026rsquo;s been really interesting. I\u0026rsquo;m in a Slack group that\u0026rsquo;s got a channel of staff plus engineers talking about this stuff and so any community of people trying to tackle the same problems is super valuable, I would say. Find build your community exactly like you\u0026rsquo;re doing here. We all need to learn from each other because nobody has this figured out. We\u0026rsquo;ve only been doing this computer thing for 60 years or so compared to other industries that have been doing it for hundreds of years. I feel like I\u0026rsquo;ve been doing this forever and yet every day and finding countless things that I have no idea how to do, whether technical or non technical. So having other people to bounce ideas off of, no matter what, is super important inside your company, but also outside your company. I find talking with the other people inside the company, we all are tackling similar problems, but we\u0026rsquo;re also coming at it from a similar perspective. And when you describe the same problem to someone at another company, that different perspective is immediately going to unlock some ideas that you\u0026rsquo;re not going to come to yourself. You get locked into your day to day and it\u0026rsquo;s hard to get yourself out of it sometimes without other people to help you do that. Since I\u0026rsquo;ve been working in the infrastructure and platform engineering area for several years here, I\u0026rsquo;ve accumulated a good list of people to follow on Twitter and people at conferences and so forth. So within whatever area of practice somebody is in, building up that library of people and resources is really important. And that\u0026rsquo;s going to be very different for someone who\u0026rsquo;s doing React and Typescript all day long versus someone who\u0026rsquo;s doing Kubernetes and Docker all day long like I do. The tech world has gotten really, really big and so specializing is good and bad. I\u0026rsquo;ll spend my time struggling with React in my spare time just to stay in it, stay on top of other things. That\u0026rsquo;s what side projects are for. But I also have to keep myself from going off tangent and saying, well, I\u0026rsquo;m working on this side project and I could kind of figure out how to do this thing in react. Or I could just go and build a whole CI and containerized system and minikube for it. And that\u0026rsquo;s what I do day to day. So learning all the time ultimately is the key there. There are lots of books out there, lots of blogs out there. I subscribe to probably too many weekly emails on various different topics from infrastructure to front end work. Even if I don\u0026rsquo;t read that stuff in detail again, it\u0026rsquo;s pattern matching. I\u0026rsquo;ll see. Hey, I\u0026rsquo;ve seen a mention of this project several times in the past few weeks. I should probably go and take a closer look at it because if that many people are talking about it, it\u0026rsquo;s something I should at least be familiar with. And continuing to learn all that sort of stuff is absolutely what makes this job fun after so many years.\u003c/p\u003e\n\u003cp\u003eAlex: So we have our final question, which we hope is fun and lighthearted, not incriminating. How much time do you spend coding nowadays compared to, you know, all your other responsibilities?\u003c/p\u003e\n\u003cp\u003eMason: Yep, yep. It varies hugely from month to month, quarter to quarter most recently I\u0026rsquo;d say I\u0026rsquo;ve actually you\u0026rsquo;ve caught me at a point where I\u0026rsquo;m probably coding about 15 to 20% of the time. It occasionally goes above that, but not for an extended period of time. Honestly I will more commonly contribute a few lines here and there to something or you know, put together a terraform module and put it out there, but then go days without coding. At the moment I\u0026rsquo;m actually testing out a bunch of APIs and building a tool around them that\u0026rsquo;ll turn into a Slack bot that people will be able to use and that\u0026rsquo;ll be cool. So I\u0026rsquo;ve been doing a little bit more coding and that\u0026rsquo;s nice, but that\u0026rsquo;s also why I work on side projects in my my spare time. Try to stay in that work on something that I don\u0026rsquo;t do day to day. I do mostly infrastructure ish stuff and then coding and go on tools right now. So my spare time project is Ruby on Rails app again. Stay on top of that.\u003c/p\u003e\n\u003cp\u003eDavid: What\u0026rsquo;s the project? Can you share?\u003c/p\u003e\n\u003cp\u003eMason: Not yet.\u003c/p\u003e\n\u003cp\u003eDavid: Fair enough, fair enough.\u003c/p\u003e\n\u003cp\u003eMason: Someday I\u0026rsquo;ll get it to where people can try using it. Yep.\u003c/p\u003e\n\u003cp\u003eDavid: Well Mason, thank you so much for taking the time today. It\u0026rsquo;s been a pleasure.\u003c/p\u003e\n\u003cp\u003eMason: Absolutely. Thanks very much and really enjoyed it.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website Website Podcast staffenge. Com. The website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-08-10T09:00:00-05:00","date_modified":"2021-08-10T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/lorin-hochstein-netflix/","url":"https://podcast.staffeng.com/season-1/lorin-hochstein-netflix/","title":"Lorin Hochstein (Netflix)","summary":"No one ever made a decision based on a number. They need a story.","content_html":"\u003cp\u003eToday’s conversation is about resilience, and as today’s guest, Lorin Hochstein, notes; “Resilience is about the stuff that isn’t visible through the metrics.” Lorin is a senior software engineer at Netflix who is on a mission to improve the company’s engineering department through creating a culture within which peer-to-peer learning and the process of reflecting on past mistakes are foundational. Lorin is responsible for the development of a few grassroots programs at Netflix which address the company’s lack of deliberate knowledge sharing, which he talks about today. We also discuss the value of close calls as opposed to incidents, and how Lorin works around the challenge of measuring the negative outcomes which didn’t occur. Although he makes sure to point out that he does not bear a \u0026ldquo;staff\u0026rdquo; title (Netflix does not have them), he is certainly doing some interesting staff-type work, and his passion for value creation is inspiring. \u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://lorinhochstein.org/\"\u003eLorin Hochstein\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8930850-lorin-hochstein-netflix.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level, into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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 Romos and I\u0026rsquo;m joined joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff bus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Loren Hochstein is a senior software engineer at Netflix, where he works on the managed Delivery team. And you might also know him from Twitter as no Root Cause. I\u0026rsquo;m excited to share this episode with you all because we touch on the topics of resilience and reliability, which I really think underscores probably most staff engineering roles. So let\u0026rsquo;s dive in.\u003c/p\u003e\n\u003cp\u003eDavid: All right, Lauren, thank you so much for taking the time to join us today. I\u0026rsquo;m looking forward to chatting with you. Could you please start by just sort of telling us who you are and what you do?\u003c/p\u003e\n\u003cp\u003eLorin: Sure. So, I\u0026rsquo;m Loren Hochstein. I work at Netflix. I feel like a little bit like a fraud here because I am like, I am not a staff. I am a senior software engineer at Netflix because Netflix doesn\u0026rsquo;t really have levels like that. Pretty much everyone, Almost all the ICs are seniors. So I work in the delivery engineering part of Netflix these days on a project called Managed Delivery. So we\u0026rsquo;re working on a sort of declarative delivery system that is easier to reason about than traditional pipeline stuff. So there\u0026rsquo;s a lot of interesting problems around automation and a system that\u0026rsquo;s automatically doing things that I found really interesting. And so I kind of convince that team to take me on. I like to jump around a lot. It\u0026rsquo;s like my third team at Netflix now, since I\u0026rsquo;ve been here for about six years. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, and we totally understand. I think that the title is. It\u0026rsquo;s not as important as, like, you know, the work that you do. So really don\u0026rsquo;t worry about it. I think we\u0026rsquo;re going to talk about some really interesting things. So I\u0026rsquo;m curious, you know, regardless of sort of titles, you know, what do senior software engineers do at Netflix? Is there a typical set of expectations or does everyone sort of have their.\u003c/p\u003e\n\u003cp\u003eLorin: Own spin on the role? Yeah, so one of the really interesting things about Netflix is that historically they\u0026rsquo;ve only hired seniors, so there is not a mix of juniors and seniors. On the teams. So everyone on the team is a senior and also we do. You build it, you run it. So everyone on the team who\u0026rsquo;s doing software development is also doing operations. So in a sense, kind of like everyone is expected to be a leader and do leadership stuff. And so in addition to doing, everyone does development, right? So I do, you know, definitely a lot of coding. Everyone does design work. Everyone does, you know, coordination with other teams. Right. To do cross functional kind of cat herdy stuff. Right. Everyone has to do a little bit of cat herding and so you can sort of choose how much of that you want to do. And it\u0026rsquo;s sort of up to you based on your particular interest on like where you\u0026rsquo;re going to spend your time, right. Like, are you going to spend your time thinking about like, what is the long term design stuff with this project that we\u0026rsquo;re working on so that we don\u0026rsquo;t, you know, hit a whole lot of pain in a couple months because it\u0026rsquo;s too hard to change. Maybe you\u0026rsquo;re interested in. Okay, I want to coordinate with this other, you know, we\u0026rsquo;re all, we say, what is it? Loosely coupled, highly aligned, right? Is the. Is the way we talked about it. Although, you know, often it\u0026rsquo;s loosely coupled. Loosely aligned, right. Like it\u0026rsquo;s. When you\u0026rsquo;re, when you\u0026rsquo;re loosely coupled, you\u0026rsquo;re sort of optimized for moving quickly individually, but not necessarily for alignment. That\u0026rsquo;s much harder to do. And so there are a lot of engineers now who work more around cat herngy kind of stuff, trying to get the teams to move in the same direction, trying to coordinate like all these different teams are doing different efforts and you want to make sure things are coherent. I work under the platform engineering Org, so all our customers are internal Netflix engineers. And historically it\u0026rsquo;s been very sort of disjointed experience for them. Like all the tools are totally different and so there\u0026rsquo;s a bigger push now to make that more cohesive. But that means better coordination. And since there\u0026rsquo;s no architects or anything, it\u0026rsquo;s sort of tricky to move things forward and get big things done that way. I actually personally don\u0026rsquo;t do as much of the cat herdingy kind of stuff. The stuff that I personally do that crosses teams is like me crossing teams. The way I think about it is I like to spread knowledge around by moving around the org. And one thing that we have, I think not been as good at as other companies at Netflix is historically people have not moved around as much. It\u0026rsquo;s gotten A lot better recently. But when I started there was no internal mechanism to let you move around. It was almost taboo a little bit. And now there\u0026rsquo;s an internal job site and it\u0026rsquo;s more of a thing. But that was definitely something that was quite different when I first got there.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So it sounds like you talked a little bit about how you sort of approach your job maybe a little bit differently than necessarily the broad expectations. Is there anything else that you feel like you do that\u0026rsquo;s special to the way that you practice being a senior software engineer?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah, so I mean, I\u0026rsquo;m personally kind of interested in grassroots Y kind of stuff like bottom up things, working with the engineers, not necessarily on larger initiatives, but improving things. So I, for example, run Systems Reading, which is a paper reading group inside of Netflix where people get together and talk about interesting papers. It\u0026rsquo;s funny, when I got there I saw there was a group that had existed at one time, there was like a Google group, but it had lay fallow, like everyone involved had gone and it had stopped. And so we started that up again. I did something called, I tried to do something called Oops where I get people to talk about sort of near misses that have happened inside of Netflix. Not just the big incidents, but the stuff that didn\u0026rsquo;t necessarily have customer impact. But there\u0026rsquo;s interesting things to learn from there. So that\u0026rsquo;s another example. I brought in Hillel Wayne. He teaches on tla. One of the first workshops he did was at Netflix. I brought him in there. So there\u0026rsquo;s interest in that. So these are things that are not like we\u0026rsquo;re going to move a big rock up a hill to accomplish this, but it\u0026rsquo;s trying to kind of upskill the engineers inside the organization.\u003c/p\u003e\n\u003cp\u003eDavid: This is a really interesting aspect of what I would sort of think of as staff level work. And obviously Netflix, that label exist, but this idea of knowledge sharing, one of the challenges that I think a lot of organizations face is that they don\u0026rsquo;t sort of. A lot of organizations fail to incentivize that properly or fail to reward it properly. First of all, would you agree with that? And do you think that there\u0026rsquo;s like that Netflix does things better in that regard? Is there sort of like, you know, beyond sort of thinking it\u0026rsquo;s the right thing to do? Are there any incentives nudging you in the direction of sort of helping the folks around you level up?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah. So this is another area where I think Netflix has gotten better in the past few years. When I first started, the expectation was we are going to hire Seniors and we\u0026rsquo;re just sort of assume that you\u0026rsquo;re going to be at that level and we\u0026rsquo;re not really going to invest in upskilling you. We\u0026rsquo;re hiring you to be high skilled. Now there is a developer education Org. So it\u0026rsquo;s changed over time and now there\u0026rsquo;s more investment in, you know, I would say like improving the education, the skills of the people inside the org. A lot of that is around like, you know, sort of like classes and training y kind of stuff. But the stuff that I\u0026rsquo;m more interested in is like learning from other people inside the organization. Right. I find like I have always personally learned best by like you know, looking over someone else\u0026rsquo;s shoulder, working next to someone who\u0026rsquo;s really, really good. And you know, if you\u0026rsquo;re not deliberate about that, so I mean that happens organically on teams but if you\u0026rsquo;re not deliberate about sharing that, it doesn\u0026rsquo;t happen. And I don\u0026rsquo;t think there\u0026rsquo;s a huge organizational push for that. That\u0026rsquo;s just sort of something I\u0026rsquo;m trying to push from the bottom. I mean one of the challenges is that there\u0026rsquo;s not enough time to do anything. Everyone everywhere has more work than they have capacity. You always have issues. So it\u0026rsquo;s always hard to make space for stuff that does not obviously have a near term impact. And so spending the resources to do stuff like that is hard to justify. And so I find you sort of like kind of have to do it on the side a little bit. Right. Like one of my motivations for doing the oops work, for getting people to do write ups of near misses is because I want them to teach other people how to deal with operational stuff. So one thing I do with my team, so before I was on this team I was so actually I started Netflix on what\u0026rsquo;s called the Chaos Team. I applied from the website, I was like, oh, I\u0026rsquo;ve heard of Chaos Monkey, that\u0026rsquo;s really cool. And so I got on the team and I thought that was really interesting. And what happened though when I was on that team building tools that were intentionally causing failures in production is that I found that it was actually more interesting. Like the real failures are more interesting than the sort of like synthetic ones we were injecting. And I just sort of got like sucked into that world of incidents. And I\u0026rsquo;d always look over at the incident management team, which was our sister team and I was like, oh, that\u0026rsquo;s really cool. And I ended up moving on to that team because I just wanted to spend all my time studying Incidents. And those folks are super good at operations. That\u0026rsquo;s all they do. Then I did that for about a year. I was on the incident management team, and I\u0026rsquo;m like, okay, I want to be a regular software engineer again. And then I came onto this team and this team did not have as much operational expertise. And so because I had been that on other team for a year. So what I did on my team is I run a meeting called this week in Manage Delivery Operations, where we talk about all the things that have happened this week that are interesting operations wise. And the goal of it is to have people talk through, okay, what did you see at this time? Okay, what were you thinking? Where did you look? And to try to teach people from the experiences of other people to understand how they were debugging in the moment, which is not typically the way people think in terms of talking about what happened after an incident. So you have to kind of be deliberate about that. You have to have that as a goal that you want people to walk through, to see through other people\u0026rsquo;s eyes, to learn from their experience. It\u0026rsquo;s hard to scale something like that. I\u0026rsquo;d say it\u0026rsquo;s working pretty well on my team. People have gotten much better. It\u0026rsquo;s a lot of fun. But the trick is to sort of infect the rest of the org so that people start doing that and sort of spread it that way. But that\u0026rsquo;s not quite a process thing, but it\u0026rsquo;s sort of like a habit that has to be developed. Right. And so building better habits across an org is, I would say, sort of the kind of interesting staffish level work that I\u0026rsquo;m trying to do in some small way.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that idea of really trying to change culture. So first of all, the only way you can change culture is by influence. Right. You can\u0026rsquo;t mandate a change to culture. Right. And so one of the things that Alex and I talk about a lot in the podcast and otherwise is that, like, the main distinction between, or sort of the interesting distinction between staff, engineers and like, more traditional types of leaders within organizations is that we\u0026rsquo;re like, explicitly handed, you know, we\u0026rsquo;re explicitly expected to influence folks, but we\u0026rsquo;re not handed in the authority to do it. Right. And that might seem like a handicap, but I think when you\u0026rsquo;re thinking about changing culture, it\u0026rsquo;s sort of the only way that you can do it. And so it\u0026rsquo;s fascinating that you sort of like intentionally set out, you\u0026rsquo;ve realized this area where, like, the business obviously would get a lot of value if you were able to change the culture toward one that approached operations differently. And actually, I think we\u0026rsquo;ll circle back to sort of what that culture would look like, because I have a lot of questions there. But assuming that such a culture exists, you\u0026rsquo;re trying to shift the culture into that direction and the only option toward doing that is to influence other folks. Is this something that, like, is this like an explicit strategy that you\u0026rsquo;ve like outlined to management and they bought into it? Is it more sort of like, oh, Lauren\u0026rsquo;s off doing his thing and we sort of trust him, or like, how does that situation work?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eLorin: So on my current team, it\u0026rsquo;s more the latter. More like, okay, Lauren\u0026rsquo;s off like doing this thing. On my first team, it was like that too. Like my first team, it was like, okay, Lauren\u0026rsquo;s off doing these weird things, studying, you know, incidents, even though that\u0026rsquo;s not what he does. When I was on the second team, when I was on what\u0026rsquo;s called the core team, that was more explicit. That was more, okay, I\u0026rsquo;m going to be doing some resilience type stuff. This is sort of my scope. I had to go on call because all the engineers at the time on that team, when I was on there, the only way I could really get on that team was to do incident response as well as the analysis. I didn\u0026rsquo;t want to do the response, but I\u0026rsquo;m like, all right, I\u0026rsquo;ll do it. The other option was to become a tpm. I didn\u0026rsquo;t want to do that, but there it was quite explicit. And we ended up hiring a couple of new, like, resilience engineers onto that team. And I worked on creating job descriptions for that and I was involved in hiring those folks. So there, it was a little more deliberate on that. And then I honestly sort of kind of got burnt out on that and I said, so I did that. After a year, I\u0026rsquo;m like, wow, this is really hard. And it was too much, I think, to do both the on call kind of work to move back and forth. So one of the challenges I found at an organization where you have to work at different levels like we do, one day you\u0026rsquo;re coding and debugging and next day you\u0026rsquo;re doing sort of larger scope project stuff. I have a hard time moving up and down those levels. And on that team I had a hard time switching back and forth between doing incident response and then doing the sort of broader analysis. And then, okay, how do we look across a whole bunch of incidents and find themes and how do we, what do we do with this. And so I was like, okay. The problem was I got what I wanted and what I found. The second time in my career that I went after something that was hard and I got it. And I was like, wow. Actually, day to day, this is not really what I want to do. And so I went back to a more traditional role. But I still am very interested in that style. I sort of have to do it out of the corner of my eye, I think. I feel like I have to do the, like, higher impact stuff on the side rather than being the primary focus, because otherwise it\u0026rsquo;s just too much for me.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s a really interesting insight. When you felt like you recognized that the role that you had got wasn\u0026rsquo;t what you wanted, how did you go about having that conversation with your manager or your organization to transition to a different role?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah, so my manager at the time was really, really great. So he was the one, I would say was mostly responsible for me being able to move over to that team. At the time, when I moved over to that team, the core team, my manager was then an IC on that team, and he sort of sponsored me to come over. And then he became manager, and then he created space for these other roles and the more human factors stuff. But he was super easy to talk to, and he knew that I was getting stressed out. And I told him at one point that I couldn\u0026rsquo;t do both. I just told him one point, I just can\u0026rsquo;t do both. And he took me off call for a while and I just told him that I did not find myself being happy with that. But he was just like, he\u0026rsquo;s great. We still get along really, really well. And he was just a very, very approachable person to talk to. And he\u0026rsquo;s like, okay, you want to switch teams? We\u0026rsquo;ll make it happen. So I was very fortunate. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: I think there\u0026rsquo;s a lot of people who listen to this who are staff, and they may not be exactly where they want to be or senior. And having those kinds of conversations could probably be incredibly stressful because you have to sort of acknowledge, maybe I don\u0026rsquo;t want to do the thing that I\u0026rsquo;m doing. But in my experience, and I know it\u0026rsquo;s not universal, when you actually just bring these things up and talk to your managers, they\u0026rsquo;re usually very compassionate about these kinds of things. So it\u0026rsquo;s good to hear more examples of that. Yeah.\u003c/p\u003e\n\u003cp\u003eLorin: I mean, I would say that the hardest part of that is actually saying it out loud to someone when you are at the point where you\u0026rsquo;re like, actually, this isn\u0026rsquo;t really what I want to do. You might think that and feel that, but saying it out loud to someone is extremely cathartic. And especially, especially saying it out loud to your manager is a huge thing. Yeah. I would say. I see a lot of people at Netflix switch back and forth between IC to manager and then back because they think they want to do something, they think they want to try that path. And you go there and you\u0026rsquo;re like, well, actually, no, this isn\u0026rsquo;t a good fit for me. And many of them just oscillate back to IC again. Nice.\u003c/p\u003e\n\u003cp\u003eAlex: I wanted to talk a little bit about the work that you\u0026rsquo;re doing around resiliency. I thought it really interesting example that you brought up was the OOPS group or the OOPS talking. I\u0026rsquo;m curious about that because a lot of places I\u0026rsquo;ve worked at, if an incident didn\u0026rsquo;t happen, people would have been like, great, we did our job and we didn\u0026rsquo;t have an incident. And so do you think you could explain a little bit, like, why an OOPS or like a close call is almost as important as an incident to learn from as an incident might be?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah. So, I mean, it depends on what you\u0026rsquo;re trying to get out of it. Right. So to me, I think of incidents as a way of understanding how the system actually works. So one of the challenges is we all work in these sort of huge machines and we all only see these little tiny parts of it, like our own part, right? And when something unexpected happens, when an operational surprise happens, something happened in the system that somebody didn\u0026rsquo;t expect, there was something we didn\u0026rsquo;t know about the system, and that\u0026rsquo;s usually really interesting. And it\u0026rsquo;s very often an interaction between two parts. We all have our own parts, and these things sort of fit together and we don\u0026rsquo;t realize that something weird is going to happen. And even if there\u0026rsquo;s no customer impact, you can still learn just as much about this thing about your system you didn\u0026rsquo;t know from those sort of close calls. And the other thing is that I am interested in things like, okay, is there something confusing about a control interface, like an operator interface? And you can still learn from those about that, and you can still deal with problems like that or just watching. I mean, my favorite is watching experts in action and the close calls. Typically there\u0026rsquo;s an expert that caught something early. So I want to be able to learn from their experience. And so if I can get them to capture that experience and I can read over it Then I can learn from that. There was one guy on a team who. This always blows my mind. So there\u0026rsquo;s this service at Netflix and it\u0026rsquo;s Java based and you could actually run a repl on. And it basically runs a lot of jars that people want. And he connects to it and ran a repl and was querying the internal state of it to see that it had gotten into a bad state. And that just sort of blew my mind that you could do that. That\u0026rsquo;s usually thought a lot. You can\u0026rsquo;t do a repl in production. That\u0026rsquo;s nuts. But of course, the Rails people do that all the time, right? So, yeah. So if you\u0026rsquo;re interested in learning in particular about how experts do things, I think that close calls are great or maybe even better. The challenge, once again, is like making space for that. It takes time to do that. I mean, we get very few people doing it and even me, I try to do them when they happen. We have operational surprises on my team and sometimes I get halfway through and I\u0026rsquo;m like, oh, I\u0026rsquo;m too busy, I\u0026rsquo;m not going to finish this up. And I have several. I have many half finished oopses that I just never ended up publishing, which I feel bad about. And then the real irony, the scary thing, is that I\u0026rsquo;ll hear something and I\u0026rsquo;ll go talk to someone and say, hey, I saw this surprise happen. Can you write it up? And the person\u0026rsquo;s like, no, I\u0026rsquo;m totally underwater, I can\u0026rsquo;t. And I\u0026rsquo;m like, well, actually. Actually, that\u0026rsquo;s really dangerous. The oopses that don\u0026rsquo;t get written up are on the teams that are running too close to the margin. And so the places where we have the least signal are the ones where the most danger is. And that\u0026rsquo;s kind of scary. And so one thing that I\u0026rsquo;ve always been really, really interested in is how do we collect those kinds of signals that we don\u0026rsquo;t usually see about teams that are running into trouble so that we can act early on them? Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: The thing that I\u0026rsquo;m struck by is the. The value of a near miss is like, it\u0026rsquo;s easier to talk about because you didn\u0026rsquo;t cause an incident. Right. And so people are, I think, more open to the idea of talking about it, which is always nice. Do you feel like these things that you have done, are they influencing, you know, the organization you work in in a positive manner?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah. So I think it\u0026rsquo;s very small scale. So, like, I sort of am able to infect people in different parts of the organization, right. Like, I think if you like, you step back, you probably won\u0026rsquo;t see that much impact. It\u0026rsquo;s hard to see. And honestly, sometimes I don\u0026rsquo;t even really know, but I think you can find like little clusters, right? And sort of starts to spread around that way. Like putting like a drop of ink in the water. And that\u0026rsquo;s sort of like I have found, like that tends to be the most effective way to make these sort of changes. It\u0026rsquo;s like you need. Right. And this is like well known, right. You need a champion, right. So the only way to really get like a change to happen is to have a champion who\u0026rsquo;s pushing it. And so if you can build champions, then you can sort of orchestrate change that way. And I guess I\u0026rsquo;m trying to get people excited and interested in this sort of thing. Like the people who write up the oopsies are the people who start to get really into it, right. Like, that is their self motivator. They\u0026rsquo;re like, oh, this is really cool. I like reading about these. I want to write them up myself. And there\u0026rsquo;s like, I have an oopsies channel and I slack about like, hey, look at this cool thing that happened here. And so, I mean, I don\u0026rsquo;t know, maybe there\u0026rsquo;s very little impact. I mean, it\u0026rsquo;s very easy to say, look, I don\u0026rsquo;t really see anything. But I\u0026rsquo;m hoping that as I sort of infect people that it sort of spreads that way.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Do you feel like you could name sort of like the cultural value that you\u0026rsquo;re hoping to spread throughout the company?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah.\u003c/p\u003e\n\u003cp\u003eDavid: So.\u003c/p\u003e\n\u003cp\u003eLorin: I don\u0026rsquo;t know if I\u0026rsquo;d phrase it as a value. Like, I\u0026rsquo;m trying to think how to articulate it.\u003c/p\u003e\n\u003cp\u003eAlex: There\u0026rsquo;s definitely a notion of value. Whatever you. I\u0026rsquo;m not so worried about the specific verbiage.\u003c/p\u003e\n\u003cp\u003eLorin: Sure. So I\u0026rsquo;m very interested in distributing operational expertise. Right. So I mean operational in particular, that\u0026rsquo;s my personal interest. But expertise. So basically, at every organization there are people who are really, really good at stuff, right? And I\u0026rsquo;m sure you both can name people in your orgs you\u0026rsquo;ve worked with that are really good. And my question is always like, how do we leverage those people in a way to bring everyone else up? And so that is sort of the value that I sort of push the hardest on that I\u0026rsquo;m most interested in is how do you take people that are good and make them better? By leveraging the people in the org who are better and spreading their skill around. We\u0026rsquo;re Good as a society, I would say from training people up from novice to like intermediate, but going beyond that is a different way of. It\u0026rsquo;s not like training. Right. The learning is different and it\u0026rsquo;s more experiential. And so how do you sort of scale up people\u0026rsquo;s experience, scale up their expertise? That, to me, is the kind of grand challenge of improving engineering in an organization. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Do you feel like this sort of blocker to going from intermediate to expert is that, like, complexity is growing at such a rate and our ability to build capacity is probably what moves us into the expert level. But, like, building capacity into being an expert is such a mysterious thing at this point because the complexity is so high. Do you think that that\u0026rsquo;s like maybe one of the big blockers to sort of leveling up expertise in our modern. Especially when we work in tech and we work in distributed systems and that kind of stuff?\u003c/p\u003e\n\u003cp\u003eLorin: So, interestingly, I don\u0026rsquo;t think so. Complexity is definitely an issue, and we all face that all the time. We are overwhelmed with the amount of complexity, but that\u0026rsquo;s always a problem, and the systems are always too complex for us to really get a true handle on. I think the primary obstacle to upskilling is the carving out time for reflection. Right. The way you get better from your experiences, the way you leverage experiences, either your own or someone else\u0026rsquo;s, is by reflecting on them, by spending that time to look back. And when you\u0026rsquo;re stretched, when you don\u0026rsquo;t have time to think about it, then you don\u0026rsquo;t have an opportunity to actually make the most of those experiences and get better. And so that, to me is the hardest part. So there\u0026rsquo;s like, capacity in that sense is carving out the time to look back and understand what happened. So as an example, once an organization reaches a certain size, migrations are going to be happening all the time at some point. It\u0026rsquo;s not like, are you doing a migration? It\u0026rsquo;s like, how many migrations are happening and you have to get good at. Every organization has to have. Once it reaches a certain level, doing migrations well has to become a core competency. And I don\u0026rsquo;t know about you, but in my experience, many times the migrations are very painful. But I found it extremely rare for people to reflect and say, okay, those migrations, what happened? What did we think was going to happen? How did it actually go? What did we learn from them? Usually it\u0026rsquo;s like, okay, it\u0026rsquo;s done, let\u0026rsquo;s forget about it and move on. And I think this is my pet theory, is one of the reasons we don\u0026rsquo;t really get better over time, even though we think we will. Okay, last time that was more terrible, but this time it\u0026rsquo;ll be better, is that we don\u0026rsquo;t spend that effort to learn as much as we can from the previous migrations so that in the future we can design our systems to make the next one easier. And I just see this happening again and again. And I have on my list of things to do. I would love to go back at Netflix and treat as case studies the various migrations that we\u0026rsquo;ve done to understand what can we learn from them. But it hasn\u0026rsquo;t happened. I haven\u0026rsquo;t carved that time out, and that would be an interesting role. But, like, and I don\u0026rsquo;t know, I mean, I don\u0026rsquo;t know if you two have had experience with that, like, looking back at migrations, but, you know, I have to say, I haven\u0026rsquo;t really seen it happen very much.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that\u0026rsquo;s a good point. I think, broadly speaking, sort of retroactively analyzing anything is hard to do in our organizations, right? They\u0026rsquo;re trying to move forward so quickly. And I know that we. I kind of harped on this already a little bit earlier, but I\u0026rsquo;m tempted to go back to it because now that I sort of understand a bit more about the changes that you\u0026rsquo;re trying to drive. For myself, and I think probably for a lot of people listening, like, you\u0026rsquo;re kind of. You\u0026rsquo;re preaching to the converted, right? It\u0026rsquo;s like, yes, let\u0026rsquo;s make more time for this stuff. And I think the sort of refrain or the sort of, like, the hesitation that I certainly feel and that I think a lot of other people feel is like, sure, but, like, how do I justify that to management? Right? And so going back to that question of, like, what\u0026rsquo;s the story that you tell? Right. To a certain extent, you can just kind of do stuff, right? I\u0026rsquo;ve been there, done that. Don\u0026rsquo;t ask for. For permission, schedule the retro meeting, whatever it takes. Right? But, like, you know, it sounds like this is. This has become a pretty big part of your job, and after a point, someone\u0026rsquo;s going to ask, all right, Lauren, like, what was your, you know, write your performance evaluation for the half or whatever. Right? And it\u0026rsquo;s like, what goes in there?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah. So we don\u0026rsquo;t have performance evaluations.\u003c/p\u003e\n\u003cp\u003eDavid: Oh, awesome.\u003c/p\u003e\n\u003cp\u003eLorin: Right. Which is kind of wild. Which is actually one of the things I like about the Org. But of course, you get resources, right? Like, it\u0026rsquo;s one thing to, on my own, do things on the side. But it\u0026rsquo;s another thing to say, okay, now I want to spin up a team to do this and then it\u0026rsquo;s going to be like, well, are we going to get an ROI on this? Is it worth it? And honestly, I have not been super successful at that, to be honest with you. But here\u0026rsquo;s my sort of general thoughts on that. And it\u0026rsquo;s funny because Netflix is, at least in my org and platform has not been as, I don\u0026rsquo;t know, explicit about thinking in terms of, okay, how much progress have we made on certain things? And now we\u0026rsquo;re doing more OKR ish kind of stuff. So I would say in the future it\u0026rsquo;s going to be even harder to justify. You sort of have to. I was fortunate that I convinced my manager that this stuff was important. They bought into it and my manager\u0026rsquo;s skip level at the time was also into it. And so you had champions throughout the hierarchy. And this is one of the things with resilience is that you have to be able to justify doing things even if you can\u0026rsquo;t show a metric for it, that this is the right thing to do.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s one of the worst things, right, Is because the metric is basically bad things don\u0026rsquo;t happen and the action that you\u0026rsquo;re trying to take is cultural change. So it\u0026rsquo;s a very slow change where the feedback loop is going to be that nothing happened. It\u0026rsquo;s really difficult to measure.\u003c/p\u003e\n\u003cp\u003eLorin: Right? Yeah. I can\u0026rsquo;t give you a count of the number of incidents that didn\u0026rsquo;t happen. That\u0026rsquo;s the metric that I would like, but I can\u0026rsquo;t. And so you kind of have to infect management. And so the question is like, how do you do that? Right. And so one thing that I was doing right before I switched teams and unfortunately didn\u0026rsquo;t finish because of COVID and stuff was like, it\u0026rsquo;s one thing to look at individual incidents and go into a lot of detail, but we were looking. I was doing some work with some peers, putting Ryan Kitchens, who\u0026rsquo;s still on the team, looking at, okay, let\u0026rsquo;s look across the incidents that happened this year. And not like metrics wise and buckets, but like, what are themes that we can see because we did like more qualitative analysis on the instance. Can we look at patterns? Okay, here\u0026rsquo;s something that somebody didn\u0026rsquo;t know. One huge problem that you\u0026rsquo;re going to see again and again and again is that there is some missing bit of shared context. Like this person didn\u0026rsquo;t know X and this person didn\u0026rsquo;t know Y. And now in an organization, this is also the hardest problem to solve, is getting the information into the heads of the people who need it, the right information. And Netflix is the opposite of Apple. It\u0026rsquo;s like super open in terms of information. But that means that you could spend full time just reading docs and do nothing else and you still wouldn\u0026rsquo;t get all the information and you would get no work done. Right? And so it\u0026rsquo;s not just an access thing. It is like, how do you figure out what the important bits are? And that is really, really hard. But it\u0026rsquo;s a critical factor that comes up again and again and again. And here one of the other challenges is I can come up with problems, but not this sort of approach is good at finding problems, but not necessarily solutions. You\u0026rsquo;re going to sort of try different things, but if you can provide insights to management about stuff that they wouldn\u0026rsquo;t see otherwise, I think that is how you show that there\u0026rsquo;s value. Look at this thing, Look, I saw that this team is starting to go underwater and if we don\u0026rsquo;t do something, then three people are going to leave and they\u0026rsquo;re going to get burnt out. If you can provide those insights and you say, look, this is how I know this, and it\u0026rsquo;s qualitative analysis, then I think you can make an argument for more resources to do that. You\u0026rsquo;ve got to provide the insights. And there\u0026rsquo;s a famous quote by, I think, Danny Kahneman, the psychology researcher, he says that no one ever made a decision based on a number. They need a story. And what we do, the resilience stuff, it\u0026rsquo;s all stories. And so if you can tell a good story about why this stuff is valuable, then you can, I hope, then you can argue for it. But I mean, to be honest, very few orgs are able to justify this. And it\u0026rsquo;s hard. And I would not say I\u0026rsquo;ve cracked this nut yet. And management can change and that\u0026rsquo;s it. And the whole thing changes and you lose it. And so it\u0026rsquo;s very, I would say, fragile and precarious and very contingent on the particular details of your org. You can kind of do what you can to foster this sort of, I don\u0026rsquo;t know, qualitative analysis of what\u0026rsquo;s going on, but it\u0026rsquo;s easy to lose.\u003c/p\u003e\n\u003cp\u003eDavid: So maybe going back five years or so, every engineer that you asked would agree that developer productivity is important and your ability to deploy changes quickly to production is important, important and like your ability to have automated test coverage is important. All these things are like engineers, broadly Agreed. And managers who came up as engineers probably agreed as well, but, like, they didn\u0026rsquo;t have a way of quantifying it. And then, you know, the main change that I think happened in that arena is when Accelerate was published with Gene Kim and Jez Humble and Nicole Forsgren. And, you know, they sort of coalesced around like these four key metrics and they tried to support that, like delivery, lead time, deployment frequency, meantime, to restore and change, fail percentages, like that sort of the gold standard by which all developer productivity can be judged. And I don\u0026rsquo;t think it actually made a difference on the ground. Engineers always knew that stuff was important and they continued to know that stuff was important. But I think it made a difference to management because now people could point and say, hey, like, here\u0026rsquo;s the rationale, right? These are now our metrics for the. Org. And you know, you guys have to judge us based on that, basically. Do you think there\u0026rsquo;s sort of an analogous thing that\u0026rsquo;s possible for resilience engineering? And do you think that\u0026rsquo;s coming?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah. So I think the real challenge for resilience engineering is to tell management that you cannot get away with relying on a small number of metrics to do these sorts of things. That\u0026rsquo;s the key thing, and it\u0026rsquo;s really hard. So the appeal of metrics like the. And I totally think you\u0026rsquo;re absolutely right, the findings that Dr. Forkstrain published about and wrote up in Accelerate, any of those things, if you talk to engineers, they would say, yeah, these are important. We knew this. No one says, oh, no, I don\u0026rsquo;t care how fast it takes to deploy, I don\u0026rsquo;t mind waiting an extra two hours or a day. This was known. But it is very tempting for leadership, which is trying to oversee an organization that they can\u0026rsquo;t see much of. No one knows, I don\u0026rsquo;t know about you, but my manager doesn\u0026rsquo;t know what I do during the day. They have no visibility. It\u0026rsquo;s very, very hard to manage something where you just can\u0026rsquo;t see what\u0026rsquo;s going on. And so metrics give them visibility. You can say, okay, how are we doing? What\u0026rsquo;s our MTTR look like? How\u0026rsquo;s the trend? What\u0026rsquo;s the time between you commit and it actually goes out to production. But resilience is about the fact that the interesting stuff is. Well, I don\u0026rsquo;t know if it\u0026rsquo;s about the fact, but a big part of it I would say, at least from my perspective, is that it\u0026rsquo;s the stuff that you can\u0026rsquo;t see that way. It\u0026rsquo;s the stuff that is not visible through the metrics. It is like the workarounds that people are doing to get those metrics up, but they\u0026rsquo;re actually taking additional risks because of that. What are we sacrificing to improve those metrics? So there\u0026rsquo;s all these signals and no matter. So you could say, okay, do a huge number of metrics, but that\u0026rsquo;s not practical for leadership because if you give them 1000 metrics, what are they going to do with that? So the challenge is, how do leaders get signals about what\u0026rsquo;s important, what\u0026rsquo;s dangerous? So what I worry about is when the metrics are fine, but there\u0026rsquo;s a danger if the metrics are bad. So the thing with the metrics, if the metrics are bad, that usually means there\u0026rsquo;s a problem. If the metrics are fine, there can be a problem, but you don\u0026rsquo;t see it. And that\u0026rsquo;s what I worry about the most, is the metrics are fine, they\u0026rsquo;re stable, but there\u0026rsquo;s a problem and there\u0026rsquo;s a risk. And we don\u0026rsquo;t see it happening because people are putting off this tech debt or whatever or sacrificing some operational stuff. And so the challenge for leadership is, okay, how does leadership get better at collecting those kinds of signals from the organizations in ways that are not easily visible? And that is really, really hard. And that is a very tough sell because leaders are already completely squeezed the same way line managers are, the same way we are directors. Everyone up the chain is stretched to capacity. And to tell them, okay, I\u0026rsquo;m going to make your life harder. You\u0026rsquo;re going to have to work harder to figure out new ways to collect information that you didn\u0026rsquo;t see before. I\u0026rsquo;m going to write qualitative reports that are like 50 pages or something, or 30 pages, which I\u0026rsquo;ve done. Rather than give you a graph that shows you our products, it\u0026rsquo;s, wah, forget it. That is a really tough sell. And I\u0026rsquo;m not a manager. It\u0026rsquo;s a very difficult thing, I think very comfortable as an ic, But I think that is the pitch we have to make. And that is a very, very difficult pitch. And if you look historically at, I would say, trends around management, they are usually like, here is a process that will make this tractable. Where we are saying, look, you just have to become an expert and you have to build these muscles and figure out how to talk to people and listen and get information from different sources. And it\u0026rsquo;s a much tougher sell. And I don\u0026rsquo;t exactly know how to sell them. We sort of have to, I\u0026rsquo;m hoping, actually. So you mentioned stuff comes up from engineering management. I\u0026rsquo;m hoping in new generations of ICs that are the learn about resilience engineering kind of stuff, when they become managers, they will have these perspectives. But you\u0026rsquo;re talking about generational change. This is like progress, like one funeral at a time kind of thing. It\u0026rsquo;s like maybe multi generational.\u003c/p\u003e\n\u003cp\u003eAlex: One thing I\u0026rsquo;m struck by is I often have the experience I think that you\u0026rsquo;re talking about, which is like, I want to protect you from negative outcomes. People are like, great, do that. But at the end of the day, let\u0026rsquo;s say you do that. It\u0026rsquo;s hard to prove that you have protected people from X number of negative outcomes. But I think it seems like a lot of the folks who are focusing on resilience are starting to understand that the same things that contribute to your resilience contribute to your capacity to do more work. Right, because you talk a lot about Rasmussen and that sort of like the boundaries around work, there\u0026rsquo;s like a financial boundary, there\u0026rsquo;s sort of like other things, but work is constantly pushing us towards an error boundary. And so if you aren\u0026rsquo;t doing the work to increase your capacity, you\u0026rsquo;re going to hit the error boundary. And that\u0026rsquo;s where incidents happen. But the same thing that sort of pushes the error boundary away from us as we do more and more and bigger and bigger and more complex work is also increasing our capacity to do work. Do you feel like there\u0026rsquo;s a story that we could tell that\u0026rsquo;s more of the positive? Like we are increasing your team\u0026rsquo;s ability to do more things over time. And do you feel like that could be a more interesting or a more compelling story to tell management than like, we\u0026rsquo;ve protected you from X number of negative events?\u003c/p\u003e\n\u003cp\u003eLorin: Yeah, I totally think you can. And so to make a pitch about improving expertise on my team, improving operational expertise meant that we were more quickly able to diagnose problems. We spent a lot less time debugging certain issues because we had visibility, because of metrics. And so less time spent troubleshooting is more time spent developing and delivering value. And it also, the engineers just perform at a higher level. We do become more efficient in that sense. And so I think the learning aspects of the sort of upskilling is compelling because it\u0026rsquo;s saying, look, we\u0026rsquo;re going to sort of reduce the overhead of the firefighting kind of stuff, the kind of stuff that drags on us in a way that it\u0026rsquo;s not just, okay, we\u0026rsquo;re spending a whole bunch of time paying down tech debt. That\u0026rsquo;s one way to improve productivity, but that\u0026rsquo;s also a chunk of time. So I think you can definitely make the arguments around. Around improving expertise. That that\u0026rsquo;s just like, there\u0026rsquo;s clearly an ROI there. There\u0026rsquo;s clearly like, we are going to get better as an organization. Right? We know that experts, everyone knows experts are more valuable. That\u0026rsquo;s why we pay seniors higher salaries than juniors. Right? Everyone is aware of that. And so I think that\u0026rsquo;s an easier pitch to make about the learning and as a mechanism for improving the. Yeah, capacity is a good term. The challenge in increasing capacity is then you just ask to do more, right? So you improve capacity and then they throw more work, okay, you can move faster, then we\u0026rsquo;re going to thr more work at you. And so you just like you move the boundary out and you move closer to the boundary. The harder part is, I mean, it\u0026rsquo;s always an eternal struggle to carve out the additional. The thing about capacity is that you have to keep some of it, right. Like, capacity means you have some extra juice that you can use when you need it, right? And you\u0026rsquo;re not sort of. And you need some social organizational capital to justify not running at full capacity. I mean, this is a challenge with the centralized incident management team. Like, these folks just sit around waiting for incidents to happen. Like, you could have them be software engineers in building stuff, right? But there are extra capacity. That\u0026rsquo;s around.\u003c/p\u003e\n\u003cp\u003eAlex: One of the things that I think is interesting about this is it sounds like what we\u0026rsquo;re sort of saying is like the work that Dr. Forsgren has done in Accelerate, it\u0026rsquo;s valuable, but it doesn\u0026rsquo;t paint the whole picture.\u003c/p\u003e\n\u003cp\u003eLorin: Right.\u003c/p\u003e\n\u003cp\u003eAlex: There\u0026rsquo;s lots of things that we\u0026rsquo;re saying is like, there\u0026rsquo;s always going to be this squishy space. And the company or the culture that you work in has to value exploring the space constantly, because that\u0026rsquo;s where you\u0026rsquo;re going to find the things that you can\u0026rsquo;t measure is in that sort of squishy space. But maybe there could be. What about things like psychological safety and other things that if you know that a team has psychological safety, maybe they\u0026rsquo;re better at exploring the squishy space, right? So maybe there\u0026rsquo;s ways in which you can measure or evaluate a team where it\u0026rsquo;s not like, are you following these 10 metrics? But it\u0026rsquo;s like, do you have the right environment to create the ability to discover the unknowable at the moment.\u003c/p\u003e\n\u003cp\u003eLorin: Yeah, I feel like psychological safety is really sort of caught on. I think everyone, at least I don\u0026rsquo;t know, pays lip service to it. Netflix is pretty good. I would say people are pretty because once again they\u0026rsquo;re all seniors. Everyone sort of has strong opinions. They\u0026rsquo;re general. I mean a lot of people have imposter syndrome coming in. But then people are comfortable disagreeing with each other and are okay with that. I have tried, I would say for so one of the things and I blogged about this, I try to make it okay for when I have done rinse and it write ups that I name everyone\u0026rsquo;s names. I put there explicitly because that\u0026rsquo;s okay. It\u0026rsquo;s not the if you\u0026rsquo;re here then we trust that you are good. And so the assumption is that if we want to learn as much as possible, we should assume that everyone who was involved was doing things that made sense to them at the time. And by putting the names in, we\u0026rsquo;re signaling there\u0026rsquo;s nothing to be ashamed of here. And I do this myself. But of course when you push to production and something breaks, you feel terrible. We\u0026rsquo;re humans, we feel bad when we\u0026rsquo;re involved in breaking things. To me, the psychological safety thing, I\u0026rsquo;m very lucky to work in an organization where I feel it\u0026rsquo;s there. And so it\u0026rsquo;s hard for me to I can say these things. But I don\u0026rsquo;t work in places where I have read horror stories about government contractor stuff during the healthcare.gov where someone basically got fired, sort of got fired on the spot kind of thing or they accidentally dropped a database. There are environments that are like that. But I don\u0026rsquo;t know what to do about that. I\u0026rsquo;m fortunate I don\u0026rsquo;t work in one of those. I would just leave. I could choose my environment. I\u0026rsquo;m very, very privileged about that. I think if you don\u0026rsquo;t have psychological safety you have a huge problem. And it\u0026rsquo;s much harder to do these things unless you\u0026rsquo;re at a place where you feel where I can go and say half baked things to my team and here\u0026rsquo;s I\u0026rsquo;m sketching out a doc and it\u0026rsquo;s probably all wrong but we\u0026rsquo;re just going to talk about it. One of the things I\u0026rsquo;ve been recently reading a book about engineers. It\u0026rsquo;s called Designing Engineers and it\u0026rsquo;s about how engineers actually do design. And the guy who wrote it is a professor of engineering at MIT and he did some case studies. He went out to various companies and sort of observe what was going on and what he found was that a lot of the design work happens in the meetings, in the interactions between people, where different people have sort of incomplete views of what\u0026rsquo;s going on. And then they talk and they sort of negotiate what\u0026rsquo;s happening. And it\u0026rsquo;s in those interactions between people where the design actually happens. And I think one of the things that I would like to try to push is to think of the team or the org as the unit. It\u0026rsquo;s not like I\u0026rsquo;m designing it or I\u0026rsquo;m operating the system because I\u0026rsquo;m on call, but we are collectively doing this and each of us only has a partial view. And it\u0026rsquo;s the emerging result of what we do that is the thing. It\u0026rsquo;s not like I did this and you did this, but we are doing this together. And you should not expect to. You don\u0026rsquo;t have the whole picture. You only have one perspective. And it\u0026rsquo;s the interaction of us together that is the thing that is developing and operating these services. And it\u0026rsquo;s. We talk a little bit about that, but it\u0026rsquo;s a big perspective shift. And even I\u0026rsquo;m still wrapping my head around that. This is a joint cognitive system is what the resilience people would say. This is what we have. It\u0026rsquo;s not just us, it\u0026rsquo;s the system that we care about.\u003c/p\u003e\n\u003cp\u003eDavid: I think it\u0026rsquo;s interesting though, that they\u0026rsquo;re using psychological safety as a reference, because there too, I would argue that there\u0026rsquo;s an analog to the Accelerate book, which was Google\u0026rsquo;s project Aristotle, which was the. The seminal thing that translated psychological safety into like a concept that all managers could get behind, because now there\u0026rsquo;s like a research paper that validates it. And there again, they actually have metrics that you can use to measure psychological safety in a team. Whereas, like, to us as engineers, I don\u0026rsquo;t think we would have tried to go. Go about and do that. It\u0026rsquo;s just sort of a yes or no thing. And I\u0026rsquo;m still sort of left thinking that like, you know, either there used to be a sea change in management, which maybe, you know, goes back to what you were alluding to, to like one funeral at a time, but. But I feel like even then we might still be looking for something that can translate sort of the resilience culture that you\u0026rsquo;re describing into cliff notes for managers that they can measure. I don\u0026rsquo;t know if that\u0026rsquo;s ever going to happen or if it\u0026rsquo;s even sort of realistic to talk about it that way. I do want to hear your thoughts there.\u003c/p\u003e\n\u003cp\u003eLorin: So I think what we need to do is we need to figure out a way to provide management with a tool for aggregating the sort of massive information that they have access to that is not simply metrics. Right. We need to give them an alternative. And I think we don\u0026rsquo;t have a good story around that today. Right. Like you mentioned just now, metrics around psychological safety or whatever. And once again, that\u0026rsquo;s a way of aggregating data. Right. And they need that. They only have a certain amount of bandwidth, and we need to figure out a way to provide them or upskill them with a way for them to aggregate the signals without relying on metrics. And I think we just haven\u0026rsquo;t figured that out yet. No one\u0026rsquo;s written like, well, I guess there\u0026rsquo;s been Resilient Management book, but we need more in that direction.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting. So we have a few minutes left, and there\u0026rsquo;s two questions that we ask everybody. One of them is just sort of. And it sounds like you\u0026rsquo;ve got a lot, so I\u0026rsquo;m excited to hear your answer this question. The question is, what sort of resources have influenced the way that you work? And that can be books, of course, and research papers and conference talks, but it can also be just people that you follow, et cetera.\u003c/p\u003e\n\u003cp\u003eLorin: Sure, yeah. So, I mean, I got sucked into this two ways. One is reading a book by Sidney Decker called Drift Into Failure, which really was sort of like my entree into this resilience world. So I have an academic background, and that\u0026rsquo;s sort of one of his more academic books. And it just completely. I don\u0026rsquo;t know, I loved it, and I strongly recommend it. And the other one is John Alspaugh, who has been banging this drum for a very, very long time. And at one point I was like, okay, fine, let me start looking into this stuff. And John works with David woods, who was Sidney Decker\u0026rsquo;s PhD advisor. So the connection is there. And so after John constantly evangelizing about this material, I started to read about it, and then I just got completely sucked in and started reading tons and tons of papers. And if you go to resiliencepapers, Dot Club, you can see my list of papers that I\u0026rsquo;ve collected. I haven\u0026rsquo;t even read all of them, but I\u0026rsquo;ve read many of them, and there\u0026rsquo;s just a ton there.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Sidney Decker was my entryway as well. I love the in the tunnel, out of the tunnel perspective. That was the first thing that really resonated with me in terms of like, oh, we\u0026rsquo;re looking at this all wrong. So highly recommended. So our last question is how much of your time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eLorin: Quite a bit. I would say. Roughly half my time is spent coding. So I\u0026rsquo;m really like a traditional, you know, software engineer. It varies. You know, some days it\u0026rsquo;s more docs and meetings. But, you know, I do spend a good chunk of my time still coding.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Awesome.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. Well, Lauren, thanks so much for joining us on the show today. It was really lots of fun.\u003c/p\u003e\n\u003cp\u003eLorin: Yeah, I enjoyed it.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify or your podcaster of choice. It helps others find the show. It is a really useful signal to us that folks are finding value of this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at Our website podcast staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n\u003cp\u003eLorin: Sam.\u003c/p\u003e\n","date_published":"2021-07-27T09:00:00-05:00","date_modified":"2021-07-27T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/stacey-gammon-elastic/","url":"https://podcast.staffeng.com/season-1/stacey-gammon-elastic/","title":"Stacey Gammon (Elastic)","summary":"I am a doer and I like to do things and I have to get used to not doing things but asking other people to do things. And so delegating and then helping them through that because you don't just want to drop a bunch of stuff on their plate and it actually, you know, that helps you scale and then you can rely on that person to kind of pick that up the next time.","content_html":"\u003cp\u003eWhat works for a small company may not work for a large company, so what do you do when your organization experiences rapid growth, and the old way of doing things is no longer sustainable? In today’s episode, we speak with Stacey Gammon, a tech lead and Principal Software Engineer at Elastic. She has been with the company for almost five years and in that time has been able to observe firsthand the challenges that come with rapid growth in areas like scalability, communications, and project management. Tuning in you’ll hear Stacey break down the details of her role and how she manages teams and people. She elaborates on how Elastic is currently approaching the problem of scalability and how it is still a work in progress. We hear from Stacey about the many projects they have going on at one time and why the biggest challenge is often saying no to new projects. Later, we discuss retrospectives and why they can be a safe and effective way for teams to learn from past errors. Stacey shares the details of the formal mentorship program at Elastics and unpacks why the long-term benefits of delegating outweigh the extra time commitment it requires in the short term. Stacey shares her feelings on spending a large portion of her time in meetings and why she believes one-on-one meetings are valuable. We loved having Stacey on the show, and we’re sure you will find the conversation every bit as insightful and thought-provoking as we did! For all this and more, tune in today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/staceygammon/\"\u003eStacey Gammon on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.elastic.co/kibana\"\u003eKibana\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.elastic.co/elasticsearch/\"\u003eElastic\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/whereistanya\"\u003eTanya Riley\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8819863-stacey-gammon-elastic.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, thanks. Our guest today is Stacy Gammon, a tech lead and principal software engineer at Elastic where she works on the Cabana team. It was a pleasure to hear Stacy\u0026rsquo;s story, so let\u0026rsquo;s jump in.\u003c/p\u003e\n\u003cp\u003eDavid: Stacey, it is so nice to meet you. Thank you so much for taking the time today. Can we start by having you tell us who you are and what you are?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah. My name is Stacey Gammon and I\u0026rsquo;m a tech lead at Elastic.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. And what does a tech lead at Elastic do?\u003c/p\u003e\n\u003cp\u003eStacey: Depends which tech lead you ask. So my particular role, there\u0026rsquo;s about 80 engineers on the team that split up into five different areas and the tech lead is in charge of code quality. We do some project management, a lot of orchestration, just knowing who\u0026rsquo;s doing what and what\u0026rsquo;s going on, and guiding coming up with processes that will help our developers be more efficient. It\u0026rsquo;s a very free role as meaning, like, if I see something that I think needs to be done, I can do it. When I first got the role, it was told to me that it\u0026rsquo;s no longer my success is judged on the success of the team as a whole. So it was like, you see something that will help the team be do better, then that\u0026rsquo;s kind of what you have to do.\u003c/p\u003e\n\u003cp\u003eAlex: One thing that we\u0026rsquo;ve noticed is that everyone has their own unique spin on these sort of like archetypal roles. And I\u0026rsquo;m curious, what\u0026rsquo;s your special sauce or unique spin on being a tech lead?\u003c/p\u003e\n\u003cp\u003eStacey: I would say I get where your question is coming from. I think there\u0026rsquo;s people that are like depth, they\u0026rsquo;re domain experts and they can grow to be principal engineers in that way. And then there\u0026rsquo;s the other path, which is more breadth and it\u0026rsquo;s just more people oriented. And I think that\u0026rsquo;s kind of the path that I\u0026rsquo;ve taken. I\u0026rsquo;ve been with the company for a long time, five years, so I do have a very large understanding of the code base and how it\u0026rsquo;s grown Although now I\u0026rsquo;m pretty checked out of it by now, so. Yeah, it\u0026rsquo;s just trying to ensure code quality, setting architectural direction, technical vision, knowing the right people and getting the right people in the room. I don\u0026rsquo;t need to be the domain expert if I know who the domain experts are and I can just get them talking to each other, you know, just spying things that are going to cause problems down the road, shaping projects. It\u0026rsquo;s just a big can of various things.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, for sure. I know that. I\u0026rsquo;m sure lots of folks are familiar with Elastic and elasticsearch, but would you mind sort of like just explaining more generally what the project is and then sort of like how the organization that you work for, how it interacts with the elasticsearch code base.\u003c/p\u003e\n\u003cp\u003eStacey: Sure, yeah. So I work on Kibana and we\u0026rsquo;re a layer that sits above elasticsearch. We\u0026rsquo;re a platform team and other developers build their applications on top of Kibana. So we have a whole security organization that has their security product that has an application in Kibana and we have an observability product as well that writes code on top of Kibana. And then we leverage the data in elasticsearch to search and display and let users analyze that data. So I sit at the platform layer in Kibana.\u003c/p\u003e\n\u003cp\u003eAlex: Very cool. This is probably my ignorance, but do you feel like your platform in client facing, like client side code, or do you feel like your platform backend services? Or am I just completely missing the architecture?\u003c/p\u003e\n\u003cp\u003eStacey: Both. We have a lot of client side code. It\u0026rsquo;s very complicated, so it\u0026rsquo;s not like your average client side browser facing code. We also have a lot of server side code that\u0026rsquo;s in Kibana. So there\u0026rsquo;s. We\u0026rsquo;ve talked about having Kibana as middleware before. We\u0026rsquo;ve got Task Manager, we\u0026rsquo;ve got alerting capabilities, we need to be scalable and then we leverage elasticsearch as a service as well.\u003c/p\u003e\n\u003cp\u003eAlex: And so your role sort of like encompasses the whole scope of Kibana and you support teams through who do that work?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah, my role encompasses the platform side of Kibana. So the area teams are operations, security core, which is just like the core capabilities that like every developer building on top of Kibana needs to use. Like we have these things called savedoc objects and that\u0026rsquo;s like a core concept that\u0026rsquo;s owned by the core team. Migrations, backward compatibility. Then we have the application services team, which kind of is more UI facing. They will have like these reusable components. And then Kibana was like. So Kibana is split into two halves. We\u0026rsquo;ve got the platform half and then we have the analytics half. And the analytics half will have things like our Dashboard application and our visualization capabilities that can still be reused. They\u0026rsquo;re still, you can still consider them part of the platform because they expose code that other developers can then use in their own plugins. And then outside of that, we actually have the two organizations, the solution teams, which are completely separate organizations, but still commit code directly to our repository and they leverage utilities from our visualization plugin, from our dashboard plugin. They might embed a dashboard inside their page so they don\u0026rsquo;t have to build it themselves. They might use this search bar capability inside their page. We try and give them the building blocks to make it really easy for them to iterate quickly and also build solutions that are very connected. So we have like, for example, this system called UI Actions. And so like you, you want to register like an action on like a panel kind of like in Chrome, you know, and like you go in an application, you want to like share a photo. There\u0026rsquo;s a bunch of different things that come up. And other developers registered their, you know, special link inside that. So we have something similar to that. So you can kind of connect the solutions together. So you\u0026rsquo;re in Maps and you want to run a machine learning job on it, or you\u0026rsquo;re in Discover and there\u0026rsquo;s like an IP field and you want to say, view this. In the Maps application, they\u0026rsquo;re all owned by different teams and the platform just kind of helps them connect together, create.\u003c/p\u003e\n\u003cp\u003eDavid: More of a flow, kind of rewinding a little bit. You mentioned that when you sort of moved up to staff, you were told that like your performance would be kind of measured against the performance of your teams rather than you individually. And so I\u0026rsquo;m curious, like, did that transition happen while you were at Elastic or was that, was that earlier or like sort of. How did that come about?\u003c/p\u003e\n\u003cp\u003eStacey: That was at Elastic. Before Elastic, I was never in a leadership position. I joined Elastic as just an engineer. I actually had no leadership ambitions. I was quite scared of making any decisions and I coding, you know, role and I quite enjoyed it. And then at some point someone asked me to be an area lead of a team. And an area lead is like 20%. Back then it was 20%, 20%, like roadmapping, kind of mentoring responsibilities and 80% coding. So I was like, ah, you know, it\u0026rsquo;s a opportunity and it\u0026rsquo;s only 20%. So I\u0026rsquo;m gonna, you know, get my feet wet with this leadership thing. And I took it and I enjoyed it. And then I think maybe like a year or so later, I. My manager reached out and asked if I wanted to be the tech lead. And that was a huge jump because it was from, like, leading a team of like, three. Three people to. To leading a team of 20. I think at that point, it\u0026rsquo;s not, say, leading. It\u0026rsquo;s not. I\u0026rsquo;m not a manager, so I don\u0026rsquo;t have direct reports, but leading the architecture, so, you know, helping developers code and overseeing, you know, the architecture and everything. And it was pretty scary to get, but I was like, again, I was like, this is an opportunity. I can\u0026rsquo;t say no to it. So I. I took it. I\u0026rsquo;m really grateful for that manager because if he didn\u0026rsquo;t actually, like, reach out and ask me, I don\u0026rsquo;t think I would have actually reached for it. And then once I got my feet wet doing that, I was like, all right. I kind of like. And then I\u0026rsquo;ve been pushing up the career ladder, you know, ever since, and trying to, you know, see what I can do for the company.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome.\u003c/p\u003e\n\u003cp\u003eStacey: That\u0026rsquo;s.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s really cool. Do you think. You know, sometimes people talk about the idea of, like, a staff project or basically, like, completing some sort of project that\u0026rsquo;s of a big enough scope that the company\u0026rsquo;s like, oh, okay, yeah, like, maybe this person is ready for more responsibility, that kind of thing. Was that your experience? Was there anything like that around the time where your manager sort of prompted you toward tech lead or sort of. What do you think prompted that decision, if not like, a specific project?\u003c/p\u003e\n\u003cp\u003eStacey: So there were a lot of projects going on at that time, but I. I suspect that wasn\u0026rsquo;t the reason I was asked. I think I was asked because I was more outspoken about things that I wanted to push for change. Like when we moved away from Angular into React and JavaScript to TypeScript, I just had no fear of creating documents and sharing them with the team and being like, we should change this. This is a risk, et cetera, et cetera. And I think it pro helped that I did have big projects that were going well in addition. But there are plenty of developers that run big projects successfully that it\u0026rsquo;s not like a requirement to. To get to the next level. And even when I actually finally got to Principal Engineer 2 just last month, and that. That also. Thank you. That also didn\u0026rsquo;t come with the project. There were some things that I were running, but it was actually more of, I think, the communication and the outreach and just getting to know people in all parts of the. Being more involved and more heads up as opposed to just staying down in a project is actually one of my weak spots. I think that I had a tendency too much to do that and I needed to look up more, connect with other people.\u003c/p\u003e\n\u003cp\u003eAlex: So I\u0026rsquo;m curious, when you\u0026rsquo;re sort of like documenting issues or talking about the future of architecture, how do you connect these, like, sometimes it seems like very technical achievements or goals with like, sort of what the organization is trying to do it. Do you have a specific approach to aligning those two things?\u003c/p\u003e\n\u003cp\u003eStacey: Such a good question. And we are trying to figure that out right now. We are. You know, we\u0026rsquo;ve grown so quickly that we had like no process and all these teams would have their own roadmaps. And we\u0026rsquo;re really feeling the pain of that now of trying to figure out how do we prioritize, how do we get teams to prioritize technical debt and compare the priorities, and how do we also avoid micromanaging these teams and saying, you have to do this, you have to do that. So we\u0026rsquo;re actually just now trying to experiment with okrs, and if we can come up with like, measurable results that we can give the teams, then maybe that can give them more direction as opposed to this giant list. We have this list of like 80 projects to try and keep track of, but there\u0026rsquo;s just too many. There\u0026rsquo;s tons. And it really dilutes our focus and causes a lot of slow feature development. So we\u0026rsquo;re growing as a company.\u003c/p\u003e\n\u003cp\u003eAlex: Are there any projects that you\u0026rsquo;ve worked on in the last few years that you feel like really aligned well with the organization and created a lot of value?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah. So one of my first projects that I worked on was this thing called Embeddables. And it was sort of like our dashboard and capability has a pluggable infrastructure. So you can have these little, what we termed embeddables plopped in there, and then anyone could write their own, and then it will show up there too, and it will also, you can add them to your own application. So if you have a dashboard, but a solution wants a curated dashboard that\u0026rsquo;s specifically set up with their things, they can do that. The UI actions one I really liked as well. I actually didn\u0026rsquo;t even realize it kind of related to the Chrome or the, the Android way of doing things. They have like a very similar system. Until another developer was like, oh, it\u0026rsquo;s really like this. And I looked at it, I was like, oh, that\u0026rsquo;s very cool. And then most recently I\u0026rsquo;ve been documentation has been my pet project that I\u0026rsquo;ve been really excited about. I wrote TypeScript, like documenting JavaScript, especially in our very unique world where we have a single giant repository with a bunch of JavaScript plugins that are all in it. And like we have our own way of defining what those boundaries are. Like, what are the capabilities that each plugin says this is a service that you can use and which is like internal code. It\u0026rsquo;s just like something we define and I don\u0026rsquo;t know anybody else in the industry that does it. So we were looking at using API Extractor, but it just didn\u0026rsquo;t work for us. And so I wrote something using this library called ts morph on a light layer on top of the TypeScript compiler. And it\u0026rsquo;s just so much fun. It\u0026rsquo;s also because I can get my hands dirty coding again. So that\u0026rsquo;s my therapy, the project management stuff. I\u0026rsquo;ll go into my little code corner and build more API documentation stuff. But it\u0026rsquo;s actually, it\u0026rsquo;s supporting now the ability to track like, code metrics, code quality metrics, which I really want to. That\u0026rsquo;s a passion of mine because we have so many developers writing code to this repo and we\u0026rsquo;re in different orgs. If you go up the hierarchy, the first person in common is our cpo. So like, we\u0026rsquo;re not going to go talk to the CPO and try and come up with like a development best practice. So we really have to like work together to come up with these best practices and having insight into the plugins. And if we could give them a quality score, then we could say, hey, this is the bar we\u0026rsquo;d have to get agreement on. And we have this thing called the Contributor Council, which is something I came up with that getting representatives, technical representatives from all of those solution teams into a group to try and make it more of something that we did together rather than something that the Kibana platform team is dictating. Because we can\u0026rsquo;t really dictate it. We don\u0026rsquo;t want to dictate it. We want to do this together. We want to understand their needs. Yeah. So my API documentation system, I just have so much fun with.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Did the API documentation service arise out of the work that you were doing to create the code quality metric, or were you just sort of like scratching your own itch and then it happened to become useful?\u003c/p\u003e\n\u003cp\u003eStacey: It actually, no, I started using it, I think for the code quality metrics. Then it all kind of came together organic and I was like, I can use this to Create our documentation system as well. So it just came together and that\u0026rsquo;s kind of why I started using TS Morph as well. It\u0026rsquo;s just I had a lot more control. You\u0026rsquo;re not going to get a lot of control with API Extractor. It\u0026rsquo;s just for documentation. But with using the Typescript compiler, I can say how many times is this public API using the any type? How many public APIs are missing comments, that kind of stuff.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool. I think a lot of engineers, I think they sometimes like inherently understand the value of these kinds of tools, right? They\u0026rsquo;re like, oh man, that\u0026rsquo;s amazing. It\u0026rsquo;s going to make my day to day so much more better. But we often struggle to communicate like how valuable these tools are in a business context. Did you have to sell this idea to non technical users or someone? And how did you do that?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah, it\u0026rsquo;s tough. And selling the idea of projects is something that I\u0026rsquo;ve had to work towards for a while. I felt like, oh, I need a ton of metrics and stats and this giant presentation to convince product that this is really important. And that would be kind of a blocker because that would be very time consuming and I wouldn\u0026rsquo;t always get around to doing that. And then at some point I realized if I just say it, they actually trust me. So I\u0026rsquo;ve been leveraging that a little bit, just being like, oh wow. I actually have some, you know, people trust my opinion and I can say this is really important. And also getting the contributor council to, you know, the solution teams to be like, what is important to you? More communication going on. But it\u0026rsquo;s really, it didn\u0026rsquo;t actually take as much as I thought. It helped that I also kind of took on the work by myself. But I am delegating the actual writing of documentation at this point now and there are teams that are on board and fully behind it. So that\u0026rsquo;s really awesome.\u003c/p\u003e\n\u003cp\u003eDavid: I think it\u0026rsquo;s interesting you mentioned that, you know, it helped that you did the work yourself. Something that I\u0026rsquo;ve found is that oftentimes when trying to sort of sell, to basically sell the value of a technical change to the business, it helps a lot to have like de risked significant parts of it by having jumped into some of it yourself. Right? You might not have the finished solution, but you can prove that like the hard part is tractable or whatever. Is that kind of what you mean when you say that you jumped into it or like to what extent? Like what level of polish did you have before sort of presenting it to folks.\u003c/p\u003e\n\u003cp\u003eStacey: I had it practically done. Honestly, when I was doing, I had like a side project where I was tracking the, some of the metrics and I was like, oh, I can do this. And it actually did not take me that long to pull it together. And so it was like, hey, it\u0026rsquo;s done. And then we actually went through a review with some of the teams that we thought might end up owning this code in the long run. And they had some concerns about not using API Extractor and using this like custom implementation. And at the end of the day it\u0026rsquo;s like, well, listen, we\u0026rsquo;re in the prove value phase. We don\u0026rsquo;t have any documentation now. We haven\u0026rsquo;t for years and it\u0026rsquo;s been a huge gap and now we have something and I\u0026rsquo;ll maintain it for the time being. And once we can prove that this having documentation is really valuable, then we can have the conversation of who owns it. And you know what, if you want to go and like rip my whole implementation out and put in your own, feel free. I don\u0026rsquo;t care. You know, I just want documentation and how does it.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s a good segue to sort of the next thing that I wanted to ask you, which is like, once you\u0026rsquo;ve sort of got buy in from the. Org on any project, right, this, this API documentation is a good example, but just in general, like there\u0026rsquo;s also a step where you sort of need to get buy in from the, from the various teams involved, right? And sometimes the, sometimes the different teams are sort of like focused on different things and might not have exactly the same sort of incentives or exactly the same goals. What\u0026rsquo;s the approach that you take for sort of selling the project to teams and using, you know, influencing those folks to sort of buy it? Because you mentioned earlier, you\u0026rsquo;re not a manager, you\u0026rsquo;re not telling people what to do, right. And so there is a little bit of a, of a sales process happening there too, or something like that. What does that look like?\u003c/p\u003e\n\u003cp\u003eStacey: Great question. That\u0026rsquo;s actually something that\u0026rsquo;s been difficult for me with the role to figure out. You know, I\u0026rsquo;ve had to learn that it\u0026rsquo;s not like you have. There are subtle ways to get people on board with things. It\u0026rsquo;s an art, you know, like, how do you make someone think something\u0026rsquo;s their idea, you know, or like, or listening to them and framing it in a way that they can understand. And it\u0026rsquo;s, it\u0026rsquo;s a work in progress for sure. There are a lot of things and sometimes you just have to back off. And be like, all right, if this isn\u0026rsquo;t important for you, you know, like planting seeds like this is here for you, maybe, you know, I think this is important. But, you know, if you don\u0026rsquo;t, sometimes you have to just let people go ahead and fail or not fail. Like, maybe they were right and it wasn\u0026rsquo;t important and maybe you, you know, maybe you were right and they will fail. But that\u0026rsquo;s okay because it\u0026rsquo;s a learning experience and you all learn from it and there\u0026rsquo;s value in that.\u003c/p\u003e\n\u003cp\u003eDavid: It is a little bit tricky when you end up being right and they did fail and you still have to bite your tongue and not say, I told you so, but you\u0026rsquo;re right. I mean, I think, I think that makes sense. I think letting people fail is hard but important. And also, at least for me, I\u0026rsquo;m not right all the time. And so it\u0026rsquo;s interesting to sort of. To sort of see other ways that people solve problems. Do you find that there\u0026rsquo;s sort of like that you ever have to sort of mediate between different teams and sort of get them. Maybe someone has bought into your idea or they\u0026rsquo;ve sort of taken it on as their own idea, or they\u0026rsquo;re feeling ownership around it. But you\u0026rsquo;re now trying to get multiple different teams to collaborate on something. Or maybe you\u0026rsquo;re trying to convince the managers to allocate some resources. Maybe the. Org is bought in, but you still actually need to do a little bit of horse trading to get the right engineers working on the thing that you want instead of the other priorities. Is that something that you run into? How do you navigate that?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah, it\u0026rsquo;s really tough. And it\u0026rsquo;s more. Rather the most difficult part is saying no compared to getting other people to say yes. I think it\u0026rsquo;s new projects coming up and saying like, no, this is not more important than these other things. And we don\u0026rsquo;t have the best process right now. We\u0026rsquo;re working through it. We\u0026rsquo;re trying to come up with just now we\u0026rsquo;re trying to come up with our stack level priority. Stack, we call the Stack encompasses the elasticsearch team, the Kibana team, the machine Learning team, and I think Logstash team too. And we have to coordinate with the solution teams, the Observability team and the Security team. And we have these top five projects. We have one between Kibana and Observability, one between Kibana and Security, one between Kibana and elasticsearch, one between Stack and Cloud. And I\u0026rsquo;m like, okay, that\u0026rsquo;s like 25 projects. And most of those projects end up falling on just a few of the core teams. And so, you know, you\u0026rsquo;ve got 20 developers and 25 projects. It\u0026rsquo;s just not sustainable. And so we really need to consolidate those lists and figure out which are the highest priorities, what are the goals of the company, and where can we stick in some of the technical things, too. We actually, with the OKRs, one of them is being operationally stable because as we\u0026rsquo;re moving so fast, we\u0026rsquo;re hitting some issues where that\u0026rsquo;s some scalability issues, and even if it takes that whole fail thing. But now when you feel the pain, it\u0026rsquo;s like, all right, now we have to really focus on this and make sure that we can have insight into our operational stability and what\u0026rsquo;s going on with a lot of these new services that we\u0026rsquo;re building. That\u0026rsquo;s really cool. A perfect answer for that. I\u0026rsquo;m figuring out if you have the right answer. You can tell me. No.\u003c/p\u003e\n\u003cp\u003eAlex: We learn a lot by listening to folks like yourself and how you do it. We talked about sort of learning from failure a couple times, and I\u0026rsquo;m curious, is there any particular way that you think teams do that well, or how do you help teams learn from failure?\u003c/p\u003e\n\u003cp\u003eStacey: Retrospectives, I think, are the best way to do it, and you need to in a delicate manner so that you\u0026rsquo;re not blaming anybody. We had a project recently that went through a retrospective and we came out with a lot of good ideas, project management ideas, because it\u0026rsquo;s like, all right, this team didn\u0026rsquo;t know that this team was doing it. This team had expectations on this other team, but they had no idea. They didn\u0026rsquo;t realize they needed it by this date. And so it\u0026rsquo;s like, all right, well, where\u0026rsquo;s the information? We\u0026rsquo;re in. We\u0026rsquo;re a remote first company, and so we need more things written down, but not just more. More things written down could equal nothing written down. If you have too much, you have nothing because you can\u0026rsquo;t wade through all the information. And that\u0026rsquo;s actually something. We\u0026rsquo;ve been a very open communication company. And, you know, it\u0026rsquo;s like, don\u0026rsquo;t have so many email lists because just like, hey, email the whole team. But now it\u0026rsquo;s like, I don\u0026rsquo;t think that\u0026rsquo;s going to scale because not everyone can read every email. So, yeah, trying to scale and figure out how our communication is is really important.\u003c/p\u003e\n\u003cp\u003eAlex: Changing subjects real quick. I was curious, like, do you mentor or sponsor folks at all through your work or in your role?\u003c/p\u003e\n\u003cp\u003eStacey: We have a formal mentorship program which I Did a few times, which was really great. And informally there is mentorship where like delegating is one of the things that I\u0026rsquo;ve been focusing on because I am a doer and I like to do things and I have to get used to not doing things but asking other people to do things. And so delegating and then helping them through that because you don\u0026rsquo;t just want to drop a bunch of stuff on their plate and it actually, you know, that helps you scale and then you can rely on that person to kind of pick that up the next time. Do that kind of tip.\u003c/p\u003e\n\u003cp\u003eAlex: When you delegate like that, how do you make sure that you don\u0026rsquo;t increase your time commitment by having to answer all the questions necessarily and that kind of thing?\u003c/p\u003e\n\u003cp\u003eStacey: Well, I think you have to be prepared to increase your time commitment initially with your sight set on the long term goals of eventually decreasing because yeah, there is likely going to be an increase. And even if then like you, you know, you get pick up a new mentor and that\u0026rsquo;s more time, you pick up a new merchant. It\u0026rsquo;s just part of the job. I think it helps the company out in the long run because those people can then grow and then mentor people of their, their own.\u003c/p\u003e\n\u003cp\u003eAlex: Earlier you mentioned that you there was this sort of, I think you called it contributor council. Is that something that you, you participate in?\u003c/p\u003e\n\u003cp\u003eStacey: Yeah. So it\u0026rsquo;s just a group of people that tech leads that are from the different organizations so we can kind of learn from each other and some of the principles like I feel like myself, I have a co tech lead as well and we\u0026rsquo;re very passionate about a lot of these topics because we\u0026rsquo;re the platform team and we\u0026rsquo;re very quality conscious and some of the more the other teams are very more feature focused and so it\u0026rsquo;s just a way that we can share information with a smaller group of people too because we have an email list that the entire contributors of Kibana but we can no longer, you know, back when we were young when we wanted to make a decision we\u0026rsquo;d have like a GitHub issue and it would be like vote thumbs up or thumbs down to like figure out what you wanted to do. You can\u0026rsquo;t do that when you\u0026rsquo;re like at 100 people or especially contributors it\u0026rsquo;s like 300 people. So have a smaller group that you can kind of iterate more quickly on decisions, learn what\u0026rsquo;s important for them. And also what I the goal was to, was to also kind of give them more ownership in it. So we aren\u0026rsquo;t dictating the quality terms. However, as it\u0026rsquo;s turned out, they have a lot on their plate as well. This was like an optional thing. It wasn\u0026rsquo;t like they have all their usual priorities that they\u0026rsquo;re doing. So we found that they\u0026rsquo;re for the most part happy to sit back and just listen and talk about their problems. But there\u0026rsquo;s not a ton of volunteering to drive any of these like projects that we\u0026rsquo;ve suggested. But I get that that\u0026rsquo;s fine.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. I think a lot of folks are probably interested, I mean, are familiar with sort of like working with a manager and then I think as you sort of like go up in the career ladder, you become comfortable working with a team and sort of like aligning up and down. But things like the Contributor Council. Right. Those are sort of like a third kind of work, you know. And do you, do you have like a particular approach that you bring to these sort of like cross cutting groups to make sure that there\u0026rsquo;s the concerns that you have are sort of represented and dealt with?\u003c/p\u003e\n\u003cp\u003eStacey: We have a process for the Contributor Council. We\u0026rsquo;re trying to make it very async friendly. So like we started out with a meeting and then we\u0026rsquo;re like forget it. And honestly we haven\u0026rsquo;t been that good at sticking with it because that\u0026rsquo;s the thing with the meeting. It\u0026rsquo;s the forcing function. You have something on your calendar that you\u0026rsquo;re going to go to, you take that off. You have to rely on someone to remember to send out an email to say, hey, what are the topics? So we do have a process written up for it. It\u0026rsquo;s a work in progress and we have picked out a few projects. The Developer Documentation 1 is one of them and it was great to see like, hey, like other people on solution teams are very interested in that. So that can also help raise the, the visibility of certain projects.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s cool. And was that something that was important to you and your team as well? The projects, the developer documentation, I guess.\u003c/p\u003e\n\u003cp\u003eStacey: Oh yes. Yeah. Actually the team that was the least interested in it was like the core platform team because they don\u0026rsquo;t use a lot of platform services. And then we had this meeting where someone was like, I\u0026rsquo;d rather have no documentation than documentation written in this way that we might need to rewrite. And so then we had other people from the solution teams or from the analytics side that were like, whoa, whoa, whoa, you know, we really want this documentation. So nice.\u003c/p\u003e\n\u003cp\u003eAlex: So is it, do you feel like you, was that like a plant, the seed kind of opportunity or Is that sort of like a sweet, we all got lucky. We all want the same thing kind of a circumstance.\u003c/p\u003e\n\u003cp\u003eStacey: There was a lot of planting of seeds with the documentation stuff and. And we also got lucky. I mean, there\u0026rsquo;s always plant seeds.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. I\u0026rsquo;m curious, you know, your experience with it sounds like inside of Elastic you had a lot of opportunities where people sort of reached out and said, hey, we\u0026rsquo;d really like you to do this work. And that seems to have worked out really well for you. Do you find yourself doing that at all with other people in your organization?\u003c/p\u003e\n\u003cp\u003eStacey: You\u0026rsquo;re referring to how I like got the tech lead role. Yeah, we don\u0026rsquo;t do that anymore. Now that we\u0026rsquo;ve grown, it\u0026rsquo;s not really that fair. And I get that, you know, we now we\u0026rsquo;ll post like a job and we\u0026rsquo;ll have people interview for it and give opportunities to everybody. Otherwise you\u0026rsquo;re just relying on someone saying like, oh, that person, you know, might make a good fit for this role. And we want to give everyone the same opportunity. So. And I weigh in on like, oh, this person I think would. Is like doing very well, but I don\u0026rsquo;t make those decisions. That\u0026rsquo;s up to the team, the teammates.\u003c/p\u003e\n\u003cp\u003eDavid: So what does the process of that look like then? If you\u0026rsquo;re sort of. If there\u0026rsquo;s a new opportunity that comes up, like how is it sort of broadcast and how do you evaluate sort of the applicants, so to speak?\u003c/p\u003e\n\u003cp\u003eStacey: So we have these weekly emails that go out from each team and at the top of them are all of our career opportunities. And it says, interested in any of these yourself? You know, apply. And so that\u0026rsquo;s the visibility. And then they will just go through the normal review process and interview process.\u003c/p\u003e\n\u003cp\u003eDavid: And what about like opportunities that maybe like, we\u0026rsquo;re not talking about sort of a change in official role or a change in level, but like opportunity to, to drive a new project or something like that. Is there a process for sort of. For sort of distributing those opportunities?\u003c/p\u003e\n\u003cp\u003eStacey: Not an official process. There\u0026rsquo;s definitely like, there\u0026rsquo;s this one project runtime fields and there were a lot of like work streams that spun off of it. And I would suggest as like, this person would be great to run this. There\u0026rsquo;s also another person on a team that has been here for like a year maybe, and I think they\u0026rsquo;re doing excellent and I\u0026rsquo;ve noticed that they\u0026rsquo;re continually getting like the help this person out with this and help this person out with this. And it\u0026rsquo;s great for them because they have like such a broad knowledge of that area of code now. But I\u0026rsquo;m like, listen, I think this person\u0026rsquo;s ready to lead a project and I think they\u0026rsquo;d be great at it. And I don\u0026rsquo;t want them to get bored or feel like they\u0026rsquo;re constantly helping. So I talk to the team lead is what I do because. And the area lead, I don\u0026rsquo;t want to dictate anything. So give my suggestion.\u003c/p\u003e\n\u003cp\u003eDavid: This is shifting gears a little bit. We touched a couple times on sort of like the fact that you\u0026rsquo;re not a manager and that you obviously interact with management. But I guess I\u0026rsquo;m curious like how do you think of sort of your relationship with your peer managers? Like I think when we were talking before about sort of selling ideas to the org, my mental model for that is that there\u0026rsquo;s like a director or a VP somewhere that is like reviewing sort of the stuff that you\u0026rsquo;re proposing and deciding whether or not it makes business sense. That\u0026rsquo;s probably a little bit simplistic, but for the sake of argument. But then there\u0026rsquo;s also probably like a manager or a set of managers who are like basically sort of beside you in the organization. Right. Like you might be leading, you might be tech leading a team and there might be a manager that\u0026rsquo;s directly attached to that team. What does your relationship with them look like?\u003c/p\u003e\n\u003cp\u003eStacey: So we have this concept at Elastic that we call the three legged stool or the triumvirate. And it\u0026rsquo;s that at a certain level in the hierarchy you have your team, your tech and your PM and they work together and they theoretically have equal weight. And you, there\u0026rsquo;s a lot of overlap. Certain folks will end up having much more overlap and other folks will have less. But you just lean on your strengths. And so I, we have a like slack channel with. We\u0026rsquo;re actually a four legged stool. We\u0026rsquo;re very special channel cause we have two tech leads but we, we iterate a lot and so like the OKRs, we\u0026rsquo;re working, we\u0026rsquo;re all working together. We all like do the all hands together and it\u0026rsquo;s nice because you can lean on people\u0026rsquo;s expertises. It also on the downside, you have a potential for duplicate doing the same thing twice. Waste like we\u0026rsquo;re all in the same meeting or something that\u0026rsquo;s like, yeah, we don\u0026rsquo;t have to all be in the same meeting. Or it\u0026rsquo;s like should I be like am I stepping on my toes if I do this process thing? That might be more team leading. And it\u0026rsquo;s also I think at risk of the bystander effect being like, oh, this needs to get done. It\u0026rsquo;s like, well, there\u0026rsquo;s three people that could do it, but who\u0026rsquo;s going to do it? Who make final decision if we\u0026rsquo;re all equal, you know, so like in the perfect, ideal, happy world, we all agree and everything. But I think what can happen is that decisions can fall through the cracks because there\u0026rsquo;s just so much going on and there\u0026rsquo;s not one singular person that\u0026rsquo;s held accountable.\u003c/p\u003e\n\u003cp\u003eDavid: It\u0026rsquo;s really interesting. I think a lot of the teams that I\u0026rsquo;ve worked in certainly in the past several years have not been like external customer facing and there usually isn\u0026rsquo;t a product manager sort of part of the stool I\u0026rsquo;ve been working in, I guess in two legged stools for a while. How does the interaction specifically between sort of your role and the product manager look?\u003c/p\u003e\n\u003cp\u003eStacey: They help us shape the roadmap. They give us a lot of insight into how our customers use the product. They help create like the user stories and like they\u0026rsquo;ll work with the design team to create, create mocks. So we have like a planning feature development process where it\u0026rsquo;s like stage one is like, why, why do you want this? What are the goals? And that is heavy PM input. And then it\u0026rsquo;ll go to the next stage. I think it\u0026rsquo;s, it\u0026rsquo;s like research and vision. I can never remember which one\u0026rsquo;s which. But then the next stage, the tech gets more involved and help like the tech lead will get more involved and they\u0026rsquo;ll help shape the vision, like and phase it down. Like maybe they\u0026rsquo;ll say this is completely like architecturally this will be impossible. Or maybe they\u0026rsquo;ll say, hey, if just tweak this, we could like work a lot quicker and a lot more stable. And then, gosh, what\u0026rsquo;s next planning. Then you have to figure out like, when are you going to release it? Who\u0026rsquo;s doing what? We\u0026rsquo;ll do an RFC at that point. So start digging into the details. Because most of the before that it\u0026rsquo;s more hypothetical. You\u0026rsquo;re not into the details. Rfc. You get into the details, you have an architectural review, then you\u0026rsquo;re in the delivery phase where you\u0026rsquo;re actually like, this is like the project management phase where it\u0026rsquo;s like, did you do that yet? You know, and then you have like your check mark and you know, any at risk in real life, it\u0026rsquo;s not as simple as like I moved from stage one to two to three to four. There\u0026rsquo;s like a loop there. It\u0026rsquo;s like, oh, we hit four now. I gotta go back to two because we forgot about this thing. But having that defined really helps, right?\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned like sort of once you jump into execution. I actually have a lot of questions about that. I think the transition from planning to execution is sort of like one of the. Well, I mean there\u0026rsquo;s lots of interesting things in the processes that of our work but. But that\u0026rsquo;s one of them I guess. Two questions that I have. So first of all, like in my experience I found that it\u0026rsquo;s really easy to sort of like fall into a failure mode where like there\u0026rsquo;s a planning cycle and there\u0026rsquo;s like a bunch of people that are involved in the planning cycle and they put together some plans and like throw it over the fence to a bunch of other people to go and implement it. And I mean my experience has been that that doesn\u0026rsquo;t work super well. So when you think about sort of like designing projects from a high level, how do you think about the granularity of like the. To what extent is it, do you want to design to be fully spec before you sort of like engage some of the people that are actually going to be implementing it or like the engineers sort of like the more hands on programmers.\u003c/p\u003e\n\u003cp\u003eStacey: Great question. We often involve the people that are going to write the code in the plans. Like that\u0026rsquo;s actually. They\u0026rsquo;ll drive it, they\u0026rsquo;ll drive the rfc, the person who\u0026rsquo;s going to write the code. So prior to that it\u0026rsquo;s not fleshed out that much. It\u0026rsquo;s more like the vision, like what\u0026rsquo;s the end goal? And like paragraph summaries. But we\u0026rsquo;re not getting into the actual architectural details. And once you get into the plans, the engineer will create the rfc. And as far as details in the rfc, we try and focus on the public API, depending on how complex it is. If you\u0026rsquo;re changing a bunch of internals in a plugin and you want your team to review that, you could come up with the architectural diagram. If you\u0026rsquo;re changing public APIs that might affect downstream teams that are consuming those APIs, you\u0026rsquo;ll want to do this and get their input there. So we try and keep it high level. Like it\u0026rsquo;s not a PR review. That\u0026rsquo;s the last, that\u0026rsquo;s the delivery phase.\u003c/p\u003e\n\u003cp\u003eDavid: Makes sense. And then you also mentioned like, sort of like on the execution side there\u0026rsquo;s like this progress tracking that has to happen.\u003c/p\u003e\n\u003cp\u003eStacey: Who.\u003c/p\u003e\n\u003cp\u003eDavid: Presumably someone in the, in the three legged stool, who\u0026rsquo;s responsible for that, which leg is it? And also like tactically, how do you measure progress in A project.\u003c/p\u003e\n\u003cp\u003eStacey: Good question. The team lead is technically responsible for delivery, but really, you know, again, it\u0026rsquo;s kind of. We all help out as far as how we go about tracking progress. We\u0026rsquo;re again working on that. We\u0026rsquo;re recently someone kicked off a JIRA experiment to see if we could do jira. We all kind of have our own way of doing this, which is one of the difficult things. Like, I have a project meta issue where I\u0026rsquo;m like, I have a table and I have tagged everybody and I\u0026rsquo;m, I\u0026rsquo;ll like update the, the issue every week and be like, did you do this? Yeah, like when I had to run a project, that\u0026rsquo;s what I did. But everyone does it differently and things can fall through the cracks where you just relies on like, we do sync meetings a lot, which I\u0026rsquo;m not a huge fan of because I like leaning more on it. Like our calendars are getting full and full and full. And it\u0026rsquo;s like when you have a repeating weekly meeting where it\u0026rsquo;s just like status updates. It\u0026rsquo;s like, wow, this could have been Async. And that\u0026rsquo;s why I lean on the GitHub issue. But it really depends on the, the project owner and the team lead. And it varies wildly. But we are trying to create some consistency, maybe with jira.\u003c/p\u003e\n\u003cp\u003eDavid: Every company eventually ends up with jira. And it\u0026rsquo;s not because JIRA is great, it\u0026rsquo;s because JIRA is there. But I don\u0026rsquo;t want to get sued by Atlassian.\u003c/p\u003e\n\u003cp\u003eAlex: So you mentioned how sort of the planning and RFC phase is different than the sort of PR review. And I was curious what makes sort of like your work on an rfc? Maybe you\u0026rsquo;re commenting on rfc, what makes it different from the work that you do in sort of PR review?\u003c/p\u003e\n\u003cp\u003eStacey: So the goal is, if you\u0026rsquo;re heading in a terrible direction, to stop before you have written an entire pr. And we\u0026rsquo;ve had that happen, you know, where if you just took the time upfront to think through the problem, to design the goal, to get input from other people, you can spot a lot of problems ahead of time. And using a template also forces the developers to, if they\u0026rsquo;re reading it, they\u0026rsquo;ll see some like, the pitfalls we have. Like, oh, did you pay attention to this? You know, don\u0026rsquo;t, don\u0026rsquo;t do this, don\u0026rsquo;t do that. So that helps a lot. And a tech lead will review it versus PR reviews, tech leads. Actually, I rarely review PRs anymore. Like, we\u0026rsquo;ve got the area leads that will do that. So for me that\u0026rsquo;s A way to scale.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting. I remember a question I had. Now it\u0026rsquo;s similar but you mentioned sort of the, your preference for async work. And I\u0026rsquo;m curious, I\u0026rsquo;m actually specifically curious how much of your week is spent in meetings and out of those meetings how many of them are recurring meetings versus like sort of one offs for a specific topic.\u003c/p\u003e\n\u003cp\u003eStacey: I actually in my like I keep snippets of what I do every week and I started tracking like how many hours I was in meetings. So it varies. 10 to 20, sometimes more. Maybe I should say 10, 10 to 20 hours. Yeah. In meetings most are recurring. Do a lot of one on ones which I actually find pretty valuable. I\u0026rsquo;ve been trying to make them to spread them out a little bit more so that my calendar gets a little bit more free and I try and front load all my meetings to like Monday and Tuesday. And so Wednesday, Thursday, Friday will hopefully be like my focus days. My company does this amazing thing for Covid. We have shut it down days because we\u0026rsquo;re all in different countries. If like holidays and stuff and days off, some people are still working. So it\u0026rsquo;s very rare that like everyone in the company at the same time stops working. And so we have these shut it down days where it\u0026rsquo;s like just don\u0026rsquo;t do anything, shut it down. And it\u0026rsquo;s not taken out of our just it\u0026rsquo;s two Fridays every month and it\u0026rsquo;s incredible, which is awesome. But it\u0026rsquo;s also like gosh, that was my day to actually go.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that\u0026rsquo;s one of the challenges, challenging things about anytime you take time off. It\u0026rsquo;s like the number of things you need to get done doesn\u0026rsquo;t change. But it is nice at least if everyone else is taking the same time off, you\u0026rsquo;re not going to come back to like a full inbox. That\u0026rsquo;s pretty cool on that same. So kind of following up on that. Then you mentioned you do one on ones a lot. I also am a like I\u0026rsquo;m a big believer in having one on ones with having lots of one on ones. Is there any specific sort of like format or template you use to decide like what to talk about in your one on ones and also who are you meeting with in your one on ones, what\u0026rsquo;s the frequency, that kind of thing.\u003c/p\u003e\n\u003cp\u003eStacey: So I don\u0026rsquo;t have a specific format. I probably could do better by thinking ahead of time more of what I want to ask. Often I have nothing lined up but my main goal is just to get more comfortable with like knowing these people and creating that communication path. So when something does come up, it\u0026rsquo;s like, oh, I know that person. I totally like able to go chat with them. And as far as who, it\u0026rsquo;s mostly people on my level or above that are, that are also in other organizations like tech leads, on other teams, some team leads, some product leads. It\u0026rsquo;s actually I didn\u0026rsquo;t used to do as many one on ones and one of the feedback I got when I tried to go up to Principal 2 a few times and I didn\u0026rsquo;t get it and the feedback from one cycle from one person was like do more one on ones. Because I don\u0026rsquo;t think I was seen as much. And people are like, who\u0026rsquo;s. What is she doing? You know, just like. And I think maybe it was like, like a nervous thing. It\u0026rsquo;s like oh gosh. And time. It\u0026rsquo;s like, ah. But I actually, you know, he said that and I was like, all right, I\u0026rsquo;m gonna do it. I\u0026rsquo;m gonna have set up a one on one with every person in this company. And on my calendar was like very full but it was actually really useful. And now like I\u0026rsquo;m in that habit and like just the other day I was like looking at our org chart and seeing like there\u0026rsquo;s a tech lead on cloud and I don. Know this person. They\u0026rsquo;ve been here for six years, I\u0026rsquo;ve never seen them. So it\u0026rsquo;s like I\u0026rsquo;m setting up a one on one. Like hey. And it\u0026rsquo;s very, you know, it\u0026rsquo;s just to get to know people, create that connection.\u003c/p\u003e\n\u003cp\u003eDavid: And what\u0026rsquo;s the frequency of the one on ones?\u003c/p\u003e\n\u003cp\u003eStacey: It depends on the person and whether like we\u0026rsquo;re involved in the same project or not. Like I had a one on one with someone I was mentoring to lead a project and it was weekly. So if there\u0026rsquo;s an ongoing project, it\u0026rsquo;ll be weekly. If you. It goes as far as like I think I\u0026rsquo;ve set some up to be like every six months if they\u0026rsquo;re like really far out there. Just because I want to like have a reminder. But you don\u0026rsquo;t want to take up too much of your calendar.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I just. For what it\u0026rsquo;s worth, I feel like one on ones are like the secret power. It\u0026rsquo;s like when you run into a situation, you get it. You can get an honest gut check from folks and relying on that one on one and it\u0026rsquo;s just immensely valuable for sure.\u003c/p\u003e\n\u003cp\u003eStacey: I think it helps in like bigger groups too. Like once you have you feel comfortable with person with a person like on an individual level. Level because you chatted like in private, then you feel more comfortable speaking up in a bigger group because it\u0026rsquo;s like, oh, that person knows me. They have my back, they know who I am.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, totally curious. Are there any resources you recommend that you have read along your career journey? You know, blog posts, books, or people that you would follow? Just any resources that you might recommend to someone who\u0026rsquo;s either at your level or trying to get to your level.\u003c/p\u003e\n\u003cp\u003eStacey: I knew you were going to ask me this question and I don\u0026rsquo;t have that great an answer. I have some answers I\u0026rsquo;ll follow. Like Tanya Riley, I think she\u0026rsquo;s amazing and I\u0026rsquo;m in a bunch of slack groups which I don\u0026rsquo;t have. I don\u0026rsquo;t spend as much time on there as I would like and honestly I rely on my co workers a lot to share good information. I should read blogs more, but I just, just I have a lot of non work things like hobbies I like to do and so I\u0026rsquo;m just not the kind of person that\u0026rsquo;s like, oh, I\u0026rsquo;m done for the day, now I\u0026rsquo;m going to go read 20 like engineering.\u003c/p\u003e\n\u003cp\u003eAlex: For what? That\u0026rsquo;s totally. What I love about these interviews is that you learn that everyone has a different approach. And I think that it\u0026rsquo;s great to sort of share with folks who are looking in this, you know, just all the different ways that people approach this kind of stuff. So I think that\u0026rsquo;s great.\u003c/p\u003e\n\u003cp\u003eStacey: Great.\u003c/p\u003e\n\u003cp\u003eDavid: Except for this podcast. Beyond, like if you listen to this podcast, you should be doing that in your spare time for sure. Beyond that, none of the resources matter. Other hobbies are great, but listen to the podcast. Last question. We ask everybody this. So if you knew you were going to get the other question, then you know you\u0026rsquo;re going to get this one. How much time do you still spend coding these days?\u003c/p\u003e\n\u003cp\u003eStacey: So little. It\u0026rsquo;s so sad. The established code week, which I think we\u0026rsquo;re going to try and do once every quarter where like mine\u0026rsquo;s next week. I think I\u0026rsquo;d like to decline as many meetings as I possibly can and I\u0026rsquo;m just going to go like fix a bug or add like comments so my API documentation looks better. Or maybe try and write a plugin for some like total side project in Kibana. Plugin? Yeah. Tech leads just don\u0026rsquo;t really get their hands dirty writing code anymore. It\u0026rsquo;s sad.\u003c/p\u003e\n\u003cp\u003eDavid: Yep, yep, fair enough. I understand. I\u0026rsquo;m not surprised, but I agree that it is a bit sad. Thank you so much for taking the time today, Stacy. It was really really nice to meet you.\u003c/p\u003e\n\u003cp\u003eStacey: You too. Thanks so much.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to Staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding finding value of this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-07-13T09:00:00-05:00","date_modified":"2021-07-13T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/will-larson-calm/","url":"https://podcast.staffeng.com/season-1/will-larson-calm/","title":"Will Larson (Calm)","summary":"Fear can prevent good things from happening, but fear can't prevent bad things from happening.","content_html":"\u003cp\u003e\u003cem\u003ePlease note that this episode contains brief mention of suicide.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eToday\u0026rsquo;s guest needs no introduction! Of course, but they will get one anyway:\u003c/p\u003e\n\u003cp\u003eWill Larson is the CTO of Calm and has worked at Stripe, Uber, and Digg. He is also an author and has written two books, one of which is on Staff Engineering and serves as the inspiration for this podcast! In our conversation with Will, we discuss one of his earliest blog posts on a catastrophic launch at Digg and why he felt it was important to write about his experiences. We talk with Will about the expanding role of Staff Engineers and how that is affected by the rate of change in the field of startups and technology companies as a whole. Later, we explore the tracks of technical leadership and management within technology companies and the pros and cons of the pendulum model. Will shares what he’s learned about the skills needed for leadership positions and why working with a team of managers versus a team of engineers requires a completely different skillset. After that, we talk about Will’s career in writing and public speaking. We loved having Will on the show, so join us for engaging conversation spanning many topics from the potential for leadership in technology companies to the joy of writing!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/will-larson-a44b543/\"\u003eWill Larson on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/lethain\"\u003eWill Larson on Github\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Will-Larson/e/B07RCW6CWQ?ref=dbs_a_def_rwt_hsch_vu00_tkin_p1_i0\"\u003eWill Larson on Amazon\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://lethain.com/\"\u003eIrrational Exuberance\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.calm.com/\"\u003eCalm\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/gp/product/B08RMSHYGG/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i0\"\u003e\u003cem\u003eStaff Engineer: Leadership beyond the management track\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/gp/product/B07QYCHJ7V/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i1\"\u003e\u003cem\u003eAn Elegant Puzzle: Systems of Engineering Management\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://lethain.com/digg-v4/\"\u003eDigg\u0026rsquo;s v4 launch: an optimism born of necessity\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884\"\u003e\u003cem\u003eHigh Output Management\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/\"\u003eThe Engineer/Manager Pendulum\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8747460-will-larson-calm.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, today\u0026rsquo;s guest is Will Larson. Will is currently CTO at Calm and previously worked at Stripe, Uber and Digg. Most important for this podcast, he\u0026rsquo;s also an author. He\u0026rsquo;s written two books, including a book on staff engineering, which was the inspiration for this podcast. Our conversation takes us many places. I think it\u0026rsquo;s best to get into it and let you all hear it for yourselves. Before we get into the interview though, folks should know that our conversation briefly talks about suicide. Folks, please take care of yourselves. Okay, so I want to dive right into this. I want to take you back to a blog post that you wrote a while back. I think it might have actually been the first blog post that I read of yours. It\u0026rsquo;s the Dig V4, a launch born of optimism. In that post, you sort of. You talk frankly about a kind of bumpy launch in your role in it. I\u0026rsquo;m sort of curious what led you to write that blog post.\u003c/p\u003e\n\u003cp\u003eWill: So this is definitely a blog post I really enjoyed and I might have written this like three or four years ago at this point, I don\u0026rsquo;t quite recall, but there\u0026rsquo;s just like certain moments in your career that are really, like, pivotal for you personally, even though, like, you might not have done something very impressive. But at the top of that blog post, there\u0026rsquo;s a couple of pictures from that time. And so we launched a Digby 4 and it\u0026rsquo;s just like the most amazing day. We had caterers. Literally, they got caterers, and we\u0026rsquo;re just in this giant warehouse. So it\u0026rsquo;s not like a reasonable place to have caterers. It\u0026rsquo;s like a very unreasonable place to have caterers. And they\u0026rsquo;re carrying around sushi and they\u0026rsquo;re carrying around flutes of champagne and they\u0026rsquo;re making drinks for you. But our site was down the entire time. It was just catastrophically bad day. And so all the engineers and the folks on the operations or around this table, it\u0026rsquo;s kind of war room, as they call it, at that point in the center of the room just desperately, literally. This is before aws. So we were literally reimaging servers to spin up the new site and that meant getting rid of the old site because we couldn\u0026rsquo;t have both. We didn\u0026rsquo;t have the capacity. And then everyone\u0026rsquo;s around us just drinking champagne, eating sushi. And I just think it\u0026rsquo;s really special and important to memorialize days like this that are just so weird. And at the time people looked at us like we were complete clowns. Like who are these idiots who can\u0026rsquo;t even run a site that hosts funny cat pictures? Right. But the reasons we got there from a business perspective were really hard to avoid. And I think it\u0026rsquo;s interesting where you can both the Internet\u0026rsquo;s like, these people are fools. But also seeing exactly the business pressures each step of the way, I think really hard to avoid in that room, surrounded by champagne, looking like fools on the Internet due to those business pressures.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I think you sort of touched on. One of the reasons why I asked this question is that it sort of memorializes like a moment in a career. And I think one of the things that I saw in that article was like my own experiences of like sort of wanting something when it wasn\u0026rsquo;t ready. Like I feel like that\u0026rsquo;s actually a fairly common experience and something that propels people to learn more about their job. To say, like, I think sometimes it\u0026rsquo;s like, oof, how do I not do that again? And others. I actually think at the end of your post you sort of wrote, you said it made sense how we got here. And so I\u0026rsquo;m curious, do you feel like folks who eventually become staff or staff plus are almost required to have experiences like that in order to achieve staff or staff plus?\u003c/p\u003e\n\u003cp\u003eWill: I do think there\u0026rsquo;s this interesting kind of balance here. Or I think one of the special powers of the Staff plus folks is they\u0026rsquo;ve done it before and so they\u0026rsquo;ve made some of the mistakes along the way. Conversely, I think that one of the biggest ways I see folks at this level screw up is they start a new job and they pattern match on the old job and you\u0026rsquo;re doing it the wrong way. It has to be we can\u0026rsquo;t use Jenkins. Jenkins is trash. You can\u0026rsquo;t use GitHub. GitHub doesn\u0026rsquo;t scale or just this list of really over learning the lessons that happened before. And sometimes like things that I did a decade ago, like just don\u0026rsquo;t make sense anymore. And if you try to like convince people that, you know, for example, at Digg, we were really early users of Cassandra. Cassandra, at that time, like, the running joke was that it was like a Trojan horse released by Facebook to, like, ruin a generation of startups. It wasn\u0026rsquo;t good software at that point. Today, though, Cassandra is incredibly stable, used at an enormous scale. Really, really good piece of software. But there are still people I worked with a decade ago who use Cassandra and just won\u0026rsquo;t touch it ever.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eWill: And so it\u0026rsquo;s really easy to overlearn these lessons. So it\u0026rsquo;s this interesting balance of, like, how do you take your experience that you\u0026rsquo;ve won in a really visceral way, but also not, like, privilege your experience so much that you can\u0026rsquo;t learn anymore.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: I wonder if, like, maybe somehow, like, do you think that maybe, like, we\u0026rsquo;ve gone through this, like, generational change, right, where, like, we, a lot of us did screw up or made big, you know, and now that knowledge is starting to diffuse and. And, like, maybe that is also why staff has grown, because it\u0026rsquo;s like, there has to be keepers of the knowledge, maybe, or something like that.\u003c/p\u003e\n\u003cp\u003eWill: It\u0026rsquo;s an interesting question. When you say staff has grown, do you just mean that the number of people in the role, or do you mean, like, the scope and complexity of the role?\u003c/p\u003e\n\u003cp\u003eAlex: Well, I think both of them, like, sort of like the invention of staff, the sort of, like, diffusion of staff across the industry. And now even, like, I think, you know, we\u0026rsquo;re seeing people do staff engineering, you know, in lots of different domains. Right. So it\u0026rsquo;s like, it\u0026rsquo;s sort of growing in all sorts of dimensions.\u003c/p\u003e\n\u003cp\u003eWill: I think that\u0026rsquo;s a really good. That\u0026rsquo;s a really good observation. I think there\u0026rsquo;s a lot of forces that are driving the expansion of the role. And one of the pieces is that, you know, when I started working, there were very few systems out there that were more than, like, five years old that were in, like, the Internet space. Like, the Internet was just, like, pretty new. So even things like Yahoo search for it got to work. Like, it wasn\u0026rsquo;t really that old. Like, it just hadn\u0026rsquo;t been running for that long relative to, like, some of the systems on the Internet have been running for, like, a really long time now. And I just think the complexity of that is, like, we\u0026rsquo;re starting to find it a little bit in kind of the areas that we\u0026rsquo;re on. So one piece. I just think the industry is getting weird and complex. The rate of technical change is not slowing, though, and in a lot of ways it\u0026rsquo;s accelerating. And there\u0026rsquo;s a lot of, like, tribalism. Around technologies and that create a lot of technologies go obsolete sort of before their time because they become like uncool. And like PHP is a great example. Like when I started Yahoo, like I was doing PHP programming and like that\u0026rsquo;s just like what all the front end code was. It was like I remember like using APC to get like the Flash like file upload progress bar working. And this is the only like PHP like APC Flash widget. The only way you could do this like basically at the time and now like if you said you use like Flash and PHP like people like wouldn\u0026rsquo;t like use call you for an interview, right? And that\u0026rsquo;s an exaggeration. There\u0026rsquo;s a lot of great companies using PHP now, but there is like the tribalism that\u0026rsquo;s accelerated the rate of change. So I do think the rate of technical change kind of accelerating largely driven by like trend as opposed to like actual technical innovation. Like this is one thing that\u0026rsquo;s made it like increasingly important to have folks at the staff level who can kind of have context in a lot of cases like push back on trends. Two, like the software itself is getting older. Three, I do think the hyper scaling kind of era where we\u0026rsquo;ve had these organizations that pop up and kind of grow really, really quickly, like that business model has created more demand for staff because when a business grows at a sort of sustainable, coherent rate, the problems get fixed usually early on or they become like we will never fix the style problems where you just never try to fix it. And there\u0026rsquo;s like companies out there that have been using like MySQL or Oracle database or something for decades and they\u0026rsquo;re just, they\u0026rsquo;re never going to switch and like the data model is like really hard to work with and they just don\u0026rsquo;t change the data model anymore and they\u0026rsquo;re just kind of like never going to change it problem. And so I think with hypergrowth though, like the problems happen so fast and they\u0026rsquo;re like so extraordinarily painful. Like when I was at Uber and I pitched candidates like my actual pitch to candidates was like the great thing about hypergrowth is problems are so bad they get fixed. And I think that\u0026rsquo;s like a real up which some companies never fix problems, right? And at a hypergrowth company they always get fixed. The downside is that it\u0026rsquo;s like just really unpleasant working there a lot of the time while the problems are coming together. So I do think the business model has created a demand and sort of requirement for this level of like tenured senior, like Technical leader on the individual contributor side as well.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. I didn\u0026rsquo;t know that you\u0026rsquo;d worked at Yahoo. I also worked at Yahoo around 0506. One of the things I remembered about working there is that I did do a lot of php, but that one of the things that they would do is they would sort of like hook in like, C backends to sort of like accelerate php. And I think of that as an interesting sort of like, proto platform that, like, no one really talked about it in terms of platform. They were like backend engineers. But it was sort of like a way to cross the boundaries. Anyway, I didn\u0026rsquo;t really have a question there.\u003c/p\u003e\n\u003cp\u003eWill: I will just say, like, the thing about like, Yahoo or these older companies is like, they kind of invented like every version of the Internet first, right? Like, there\u0026rsquo;s like Yinst, which was like, basically like apps, but like Yahoo. And they had like six or probably maybe by now like 12 different versions of it where they rewrote it from scratch each time. They did like, really sophisticated stuff. It\u0026rsquo;s just it was like all like, local, so you never really saw it anywhere else.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, no, that\u0026rsquo;s funny. Why? It\u0026rsquo;s. Oh, man. I was brand new. Like, Yahoo was my first professional sort of like computer. And I was just ruminating about this the other day because, like, I remember spending weeks getting my development environment set up, right? And I was just thinking about, like, I can just hand people docker containers nowadays and like, here you go. Right? And it\u0026rsquo;s. I think, though that, like, containers are standing on the shoulders of that learned knowledge. Like, so many people understand the pain. So it\u0026rsquo;s. We\u0026rsquo;re sort of like pulling that knowledge forward through sort of like technology, technological diffusion somehow.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;m curious about. So, I mean, you\u0026rsquo;ve obviously sort of worn a lot of hats in your career and today you\u0026rsquo;re a CTO at Calm, and you\u0026rsquo;ve written a book about management and you\u0026rsquo;ve written a book about staff, obviously. So I\u0026rsquo;m interested in sort of how you think about the interplay between the management track and the technical leadership track.\u003c/p\u003e\n\u003cp\u003eWill: Yeah, I think that\u0026rsquo;s a really interesting question. And there\u0026rsquo;s. Man, there\u0026rsquo;s a lot of different perspectives in the industry, right? Like, I think one perspective that I heard a lot at Uber is like, you know, what a manager does and a senior engineer or what an early staff engineer does are very similar. But as you go further down the paths, they diverge more and more. Where, like, what a VP of engineering does versus what like a principal engineer does like totally different was like that perspective. And you also see places, I think like Google, where like being like a technologist remains like really central to in like the management track. And you have kind of Google VPs who move to other companies and are like trying to be staff engineers there in addition to being the VP of engineering and often really piss off everyone they work with. And so there\u0026rsquo;s lots of different kind of veins of evolution here. And it\u0026rsquo;s not that there\u0026rsquo;s one that\u0026rsquo;s right per se or one that\u0026rsquo;s wrong, it\u0026rsquo;s just recognizing there\u0026rsquo;s lots of veins of evolution I think is really important. The industry is still at a phase when people are trying lots of different things. And some of them are going well, some of them are going really badly, but most of them are working to some extent depending on the company. And so it\u0026rsquo;s hard to say which is right one or which is the wrong one. Similarly, there is an idea that managers, when they switch over, should stop programming immediately. Because if you try to be like a tech lead manager or split you like, it\u0026rsquo;s really hard to do both well. And some of the things when you try to be like a TLM make you a much worse manager because you trying to learn how to be a manager for the very first time is hard. And then if you\u0026rsquo;re also trying to be the tech lead, usually are really bad at one of those two roles. Either like you\u0026rsquo;re doing a terrible job as a tech lead and you\u0026rsquo;re kind of getting the way of someone else on your team, or the tech lead is so comfortable that you just kind of use all your time to do that and you hide from the management tasks, which are not what you want, but sort of the career path pushed you into it somehow.\u003c/p\u003e\n\u003cp\u003eDavid: Great.\u003c/p\u003e\n\u003cp\u003eWill: So I think every different company will find its own version of what it wants on this. And I think to me one of the most important things is just management\u0026rsquo;s a bit of a different career and the feedback cycle is slow. I think staff engineering, the feedback cycle is slow too, where you might have an idea for a big improvement. It takes two years to actually get it rolled all the way out, then another year before you know if it was actually a good idea or not. So it can take quite a long time, which I think people don\u0026rsquo;t always quite know going into it, how weird it is to get feedback at that reduced rate. But I think a lot of companies are still forcing people into management roles for career growth or compensation growth. And really stopping that, I think is My biggest hope in terms of what we can confirm or get more consistent on as an industry is just people go into management for purely compensation reasons. It\u0026rsquo;s bad for them, it\u0026rsquo;s bad for the folks they work with. How do we make sure that through staff roles and the kind of real empowerment of leadership for people in these roles, that people need to do that. If we just standardized on that, even though some of these other questions are still open, that would be amazing to me.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense and I agree with you. But I\u0026rsquo;m curious, maybe kind of going back to the context of the evolution of the staff role that you know, we\u0026rsquo;ve been observing. How do you think that like have there always been staff type folks in large companies to some extent, maybe even outside of tech? I guess like one of the things that I\u0026rsquo;ve observed or that I\u0026rsquo;ve thought about is like when we think about organizations in general, growing organizations, Andy Grove talks about know how managers, right, in high output management. And it\u0026rsquo;s this idea of someone who doesn\u0026rsquo;t have direct reports, but who still sort of functions like a manager in a lot of different ways. And that to me resonates a lot with sort of some of the staff archetypes. But if we go back further, you know, like another example that I think of a lot is that, you know, some folks have drawn the analogy between sort of the way corporations are structured and the way military organizations are structured. And in that analogy, I think of staff engineers as sort of like the non commissioned officers, right? The people who are sort of building a bridge between the boots on the ground, so to speak, and like the, the management core. I\u0026rsquo;m curious, that resonates with you and if there\u0026rsquo;s sort of other analogies that you think make sense or like sort of in the history of organizational evolution, like how the staff role sort of fits into it.\u003c/p\u003e\n\u003cp\u003eWill: I spent some time while I was writing the book trying to answer like, where did this title even come from? So like, why do we use this title? I did not get to the point where I think there\u0026rsquo;s a canonical answer. My sense though is that this largely came out of like research things like, you know, park, you know, like these different like labs like that had like a staff level kind of title, member of technical staff or something like that. And in most of those labs the kind of idea of leadership and technically like people and technical leadership was just like one track. And they really did not try to distinguish between these two. And if you go into academia, academia is also like largely the same where there\u0026rsquo;s no idea of like the professor manager or something who\u0026rsquo;s like managing all these professors and researchers. Like that person is the leader on the kind of the research side and oftentimes a terrible people manager, but a brilliant scientist or something. And there\u0026rsquo;s lots of stories to this effect of labs where people did great work but did not enjoy working with the principal involved. And if you look at the product side, the product side mostly doesn\u0026rsquo;t have this distinction for product managers. A few companies do have staff product manager roles or something now. But for the most part the people management and the proficiency are the one. If you look at like the legal like generally to be a leader on the legal side you must go into people management while also remaining like quite involved in like the legal kind of like technical work to be a cfo. Like you don\u0026rsquo;t get to be a CFO by being a great people manager. Like you have to do like all the professional finance y, like the accounting, the FP and A and like you have to build those skills to end like somehow be a people manager. And so I do think it\u0026rsquo;s kind of like a rare privilege for us in technology to actually like split these two apart. And the interesting question is like why, why have we gotten the privilege? But also the seemingly like need to do this? And I think it\u0026rsquo;s the rate of change is extremely high. These companies that are changing very very quickly and the industry is just like very, very, very new. And potentially you could argue that actually like most companies are becoming technology companies. Although like you really have to ask yourself what does that even mean? And I think there\u0026rsquo;s a lot of different ways to think about what it means to be a technology company or not. Like that\u0026rsquo;s like a whole different discussion. I think Andrew Chen has a really good blog post about kind of what is a technology company. But the key centers entirely on the business model, not on web software involvement. Whereas we talk to technical or software folks, they typically are going to say like oh, what makes technology company is being engineering led and not talk about the business model at all. So there\u0026rsquo;s lots of ways to think about it. But yeah, it is interesting to me and I do think it\u0026rsquo;s just the, it\u0026rsquo;s an early industry and we don\u0026rsquo;t really understand what we\u0026rsquo;re doing by and large. The interesting thing is going to be I think one of two things will happen. If you are a believer in like the economic efficiency, then you would believe that the size engineering organizations will shrink over time as like platforms and tooling will rise up to kind of like capture more and more of the repetitive work. That\u0026rsquo;s like one worldview. I think the other worldview is that like most companies become technology companies in terms of being like primarily enduring headcount. And these roles will remain largely differentiated simply because of the volume of work to be absorbed. Personally, I think the latter feels a little bit more authentic to me about what\u0026rsquo;s going to happen. But I think it\u0026rsquo;s important to have both possibilities in your mind as you think about 30 years out. A lot could happen in 30 years.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that\u0026rsquo;s interesting. The analogies to legal departments or finance departments is actually something I hadn\u0026rsquo;t considered and it\u0026rsquo;s fascinating. It kind of points to like staff plus roles in engineering being sort of like an anomaly and actually like it\u0026rsquo;s much more normal to have technical leadership and management living on the same track. Or maybe normal is the wrong word but more common. I\u0026rsquo;m curious then what you think about like Charity Majors has this awesome blog post about the pendulum between technical leadership and management. And I know that that\u0026rsquo;s something that you\u0026rsquo;ve explored yourself switching back and forth. I\u0026rsquo;m curious sort of how you think about that. One of the things that I\u0026rsquo;ve been curious about is like to what extent or at what point does it not work to switch? Like if you\u0026rsquo;re like if you\u0026rsquo;ve been on the technical leadership track the whole time, it seems unlikely to me that you magically become like a director or something. So I\u0026rsquo;m curious how you think about the interplay between the two paths.\u003c/p\u003e\n\u003cp\u003eWill: A lot of thoughts here. First, I think one of the realities is like getting a director title or director role. It\u0026rsquo;s like sort of like interviewing well and like someone wanting to give you the role in the title. So you know, it\u0026rsquo;s totally possible to get that role without ever having managed before, for example. And so I think people want to view interviewing and hiring as like this rational system of like kind of free like economic system where there\u0026rsquo;s like supply and demand and then like these curves that bend. But it\u0026rsquo;s like there\u0026rsquo;s a lot of people involved and there\u0026rsquo;s like a lot of just like weird stuff that happens and like you might have like a really special skill that is really highly valued and they will give you a title and a role that doesn\u0026rsquo;t quite make sense from like a purely economic perspective. Right. So these are not perfect optimized systems. These are lots of one off oxygens that weird things happen. Two, I do think the pendulum model is really interesting. I think it\u0026rsquo;s an amazing blog post and I think it\u0026rsquo;s right in a lot of ways. But I think it kind of depends what are you trying to do here. I do think from an economic perspective, switching a little bit early on is really powerful. Where I think a staff engineer who\u0026rsquo;s done some management just knows how to work a different way. It can also be really clarifying if you like, hate the job. Like, I know people who are like, I think I would like management more, but I haven\u0026rsquo;t tried it. I think if you try it, you will know probably in a couple of weeks if you like it or if you really hate it. And then just like being able to close off that avenue of exploration is really powerful. And it can go the other way where you like switch over and you love it and you\u0026rsquo;re like, I never want to kind of give the staff one and I\u0026rsquo;m going to close off that avenue of exploration. But focus is really powerful. I think economically though, it\u0026rsquo;s really hard if you go decently far on the management track to switch back without a really significant financial penalty to doing it. There are of course counterexamples to doing this always. You can always find counterexamples to anything. But particularly if you think about being a VP of engineering, if you\u0026rsquo;re a VP of engineering at a, a startup, like, you\u0026rsquo;re going to get offered like 1% equity, like approximately as a staff engineer, you might get a fourth of that, you might get a tenth of that. And it\u0026rsquo;s just, there\u0026rsquo;s really no way to overcome that. Like you will find as a staff engineer, there are startups that will give you 1%. But if you were the VP of engineering getting hired there, you would get like 4% then instead or something like that.\u003c/p\u003e\n\u003cp\u003eDavid: Right?\u003c/p\u003e\n\u003cp\u003eWill: So you can, you can kind of make the counter argument. But like, by and large, I think it\u0026rsquo;s actually really, really hard to make it effectively. There\u0026rsquo;s entire recruiting firms out there for hiring VPA roles. That industry doesn\u0026rsquo;t exist for staff plus roles. So I do think there\u0026rsquo;s a real economic penalty here. I think it\u0026rsquo;s interesting to ask why that is. Most VPs and CTOs aren\u0026rsquo;t that good. I think you work with them, you\u0026rsquo;re, yeah, this person\u0026rsquo;s not that good, but they\u0026rsquo;re getting paid more and they\u0026rsquo;re in a really esteemed position. And then some staff engineers are bad, but the ones that are bad are usually bad in terms of their behavioral purposes and generally from A technical perspective. The staff plus engineers I\u0026rsquo;ve worked with have been pretty solid. I think in both cases, man, if we just knew how to evaluate people, we would make much better decisions. But evaluating is just incredibly challenging.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that\u0026rsquo;s really interesting. I think it makes sense to me that the path back from management to staff plus would be difficult both from a compensation standpoint, as you outlined, and also I think my perspective, I\u0026rsquo;ve worked in people management a little bit, but it\u0026rsquo;s been a while. My perspective on people managers broadly is that the sort of technical proficiency tends to degrade after a while if there isn\u0026rsquo;t really intentional effort to keep it up. And so I think that\u0026rsquo;s a challenge as well for sort of the move from management toward technical leadership. But what about the other direction? Like you mentioned earlier, this idea of like, you know, a distinguished engineer from Google goes and is the CTO of a hundred person startup or something like that. I\u0026rsquo;m curious, like it seems to me that the people management skills aren\u0026rsquo;t something that you can just sort of similar to not being able to pick up the technical proficiency at the drop of a hat. The people management skills also can be picked up at the drop of a hat. And so I\u0026rsquo;m curious, sort of how you\u0026rsquo;ve observed that model working or like what sort of advice you would have for staff engineers who like are really interested in the technical track but are also interested in eventually sort of organizational leadership.\u003c/p\u003e\n\u003cp\u003eWill: I think it\u0026rsquo;s an interesting question. I think when you think about what like a people manager needs, there\u0026rsquo;s like three or four buckets, some of which you can do like really, really well among the staff plus kind of career. So problem solving without authority, like I think this is like really core to like kind of staff plus engineering, but also like as a VP or CTO or whatever. Like you do a lot of problem solving without authority as well. And I think the perception of like authority, like in both cases, like people will probably think you\u0026rsquo;re empowered in a way that you\u0026rsquo;re prob. Not, but people think you are. And a lot of that power is just like the fact that other people involved like trust you and are willing to kind of listen to you in like a serious way. So I think that\u0026rsquo;s something you can develop, can get really good at and caring about people is something you can like develop and get good at or. And you can argue a little bit about whether that\u0026rsquo;s innate. And I think there\u0026rsquo;s parts of that that are innate, but I think there\u0026rsquo;s caring about people from like a. Oh, here I really want to care about people like versus like the impact of actually doing things make people better or support people. And I think you can really get a lot better about the impact portion of caring for people. Where I think it\u0026rsquo;s easy, you kind of start where you are in terms of like how much you care. But a lot of people care about helping other people, but mostly get reframed as like non collaborative or not actually doing work to help and kind of increasingly get tuned out. And so there is like a skill set of like figuring out how do I channel my energy of caring for other people into like things that actually help them as opposed to channeling them into like getting fired, which took me a while to like understand how to like differentiate those two a little bit. There\u0026rsquo;s like a third bucket which is just like the process of like running an organization. And it\u0026rsquo;s really hard to pick up the experience of that because there\u0026rsquo;s I guess like two different big buckets there. There\u0026rsquo;s like the day to day and there\u0026rsquo;s like the really weird exceptions. And so the day to day there\u0026rsquo;s like running performance reviews, running calibrations, doing compensation, doing one on ones, doing career growth. Like and you can, you can you just get better as you do these up to a certain point, at which point you like often get worse because you stop paying attention to them. But you can, I think it\u0026rsquo;s hard to build like a lot of those without, without seeing them. And that\u0026rsquo;s where like switching from like managing a team to managing a team of managers is, is really hard. It\u0026rsquo;s just like a totally different set of skills and it\u0026rsquo;s a different career and no one really tells you that. And you just suck at it for a little while while you figure it out. And so this is where I think it\u0026rsquo;s hard to kind of cut over laterally because you just are missing a lot of those skills. The other piece though is the exceptions. And there\u0026rsquo;s just. As you\u0026rsquo;ve managed long enough, you just see some really weird stuff. And so yeah, I could kind of go on on this topic, but you know, like at Uber, like I had a friend come interview, we, we rejected him and he committed suicide that week. And that was incredibly difficult to experience. Right. And as you\u0026rsquo;ve managed long enough, you just see like a lot of really weird stuff that is difficult and you process it and try to learn from it or not decide not to learn from it, as is the case in a lot of these situations.\u003c/p\u003e\n\u003cp\u003eDavid: Right.\u003c/p\u003e\n\u003cp\u003eWill: And you come out having seen it before. But it\u0026rsquo;s just really hard to develop that without just having gone through all these incredibly odd exceptions that pop up that you just won\u0026rsquo;t see as a non managerial role.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m sorry to hear that. But I also appreciate you telling it because life is messy and I think that like you said, as we progress in our career, there\u0026rsquo;s just things that we\u0026rsquo;re going to see that are hard to think about but we still keep moving forward and hopefully we can learn if at all possible.\u003c/p\u003e\n\u003cp\u003eWill: Yeah, I think that\u0026rsquo;s really important and something that I believe and try to center on is that we can fear can prevent good things from happening, but fear can\u0026rsquo;t prevent bad things from happening. And so if we spend a lot of time anxious and worried about bad things happening, they\u0026rsquo;ll still just happen anyway when that happens. I could have never imagined something like that happening. It just would have never thought it was possible. It was just so out of the left field. But there\u0026rsquo;s lots of good thing is that like by worrying about things, bad things happening, I could like not, not have that happen. So I just try to remain centered on like not stopping the good things from happening in a way where I can\u0026rsquo;t stop the bad things from happening anyway. Because otherwise like, you know, it\u0026rsquo;s a real life like we\u0026rsquo;re living and like we have families, we have friends and they\u0026rsquo;re going through different things and you just can\u0026rsquo;t stop things from happening. I try to keep that front and center. It\u0026rsquo;s. There\u0026rsquo;s just a lot of chaos and work and even in really well managed organizations, the businesses change. You just can\u0026rsquo;t stop change. It\u0026rsquo;s really hard to be in a leadership role on management, staff plus engineering, anything if change makes you uncomfortable. Because change just never stops.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. On that notion. I know that you\u0026rsquo;ve written a lot about systems and even in this interview we\u0026rsquo;ve talked a lot about the rate of change in technology. And so I wonder, the level of complexity is just growing and complexity can be bewildering, but it\u0026rsquo;s also like how you actually overcome new challenges. Like you have to complexify in order to do new things. And I\u0026rsquo;m wondering like if you as a leader have to empower people to deal with complexity, would you rather have a person who can command or would you rather have a person who has to lead by influence? And so like you said, I think that staff engineers often have to lead by influence and managers can sometimes lead through sort of like command. Please do this you know, in the face of complexity, do you think that might explain the sort of like ascending role of these folks who really have to lead by influence?\u003c/p\u003e\n\u003cp\u003eWill: I think that\u0026rsquo;s a really good question. There\u0026rsquo;s so many different types of change and complexity. Right? I do agree with your point. I think complexity is. Every successful business has more complexity and if you don\u0026rsquo;t have more complexity, your business is probably not growing. And so I do think this is like a sort of the table stakes of success is like dealing with complexity. You know, accountability is I think ties into this a lot. So I think there\u0026rsquo;s companies where if everyone is like individually accountable for their work and are actually accountable and there\u0026rsquo;s like a huge delta between what companies say people are accountable for and what they\u0026rsquo;re held accountable for. Right. And there\u0026rsquo;s lots of companies like we hold everyone accountable, but then like the in practice like it\u0026rsquo;s do we like you or not? And then we hold you accountable if we don\u0026rsquo;t like you or something like that. That happens a lot. If you actually hold people accountable, typically through creating a culture where people hold themselves accountable, then I think you don\u0026rsquo;t need that much top down, mandate driven work until you hit some level of complexity where you just can\u0026rsquo;t coordinate all the pieces individually anymore. So I think there is like a point where just like the amount of change coming that you can\u0026rsquo;t control, it\u0026rsquo;s really hard to isolate at which point I think companies start reverting back to top down direction because it\u0026rsquo;s just too slow. And there\u0026rsquo;s a great article recently between Biden and Xi talking about autocracies versus democracy and the rate of response in these two different forms or styles of government and whether the 21st century is just such a fast moving century that democracy is too slow. And I think it kind of is a parallel to the question you\u0026rsquo;re asking where I do think in some cases any decision made quickly is going to outperform the right decision made slowly. And I think conversely there\u0026rsquo;s also a bit of expression of what we believe and what we value and how we want to solve problems where we might be willing to take some pain to get through more of a consensus style because we fundamentally believe and the people who will join us and work with us on that journey believe this is the right way to do it, even if it doesn\u0026rsquo;t work as well in some circumstances. So I do think that there\u0026rsquo;s a really important values and piece to center there where I do think if you focus only on the efficiency of solving certain problems, you end up in a really weird structure. But long term, the thing about change is change changes and we don\u0026rsquo;t keep having the same types of change. And so I think when we talk about a little bit more of like a collective, like group and less like top down authority, the thing this really helps us is like long term stability as change continues to vary and evolve over time. I don\u0026rsquo;t think it\u0026rsquo;s particularly effective or efficient in terms of like responding to the same types of changes happening a.\u003c/p\u003e\n\u003cp\u003eDavid: Lot in that context. I\u0026rsquo;m curious. So one of the things that I think is reasonably well defined, maybe there\u0026rsquo;s variations, but I think it\u0026rsquo;s reasonably well defined the delineation between sort of staff engineers and management when it comes to sort of how technical decisions should be made. I\u0026rsquo;m curious if or to what extent you think staff engineers should have influence in sort of team growth, team dynamics, team culture, things like that.\u003c/p\u003e\n\u003cp\u003eWill: Yeah, I think that\u0026rsquo;s a great question. I think there\u0026rsquo;s an interesting idea. So a lot of companies will have a product manager and eng manager kind of joined at the hip and kind of have joint accountability, but do different work. And I do think about the staff plus role and the engine manager role in a similar way where there\u0026rsquo;s just a lot of work to do. And I think some staff engineers are like, I should be in all the calibrations, I should be doing like the performance reviews. And the problem is there\u0026rsquo;s just like too much work where if you actually double up on everything, it just won\u0026rsquo;t get it done. And so I do think there\u0026rsquo;s a piece of relying less on everyone does everything and more on how do we make sure we\u0026rsquo;re aligned and believe the same things and do it that way. Because I think otherwise you just don\u0026rsquo;t get much value from having two people doing the work. It\u0026rsquo;s actually less efficient to have two people doing it because I can, you know, make decisions quickly if I have to coordinate with you on like each of the decisions. Like we\u0026rsquo;re pretty slow. So in general, like I think the effectiveness is what really matters and I think having two people overlapping a lot usually is not the right way. That being said, I do really believe in this idea of like each pairing and sometimes there\u0026rsquo;s like it\u0026rsquo;s a trio or it\u0026rsquo;s like a pm. There\u0026rsquo;s an engine manager, there\u0026rsquo;s a staff engineer kind of working closely together, maybe like a product designer or something as like a fourth piece, figuring out the balance for themselves. It doesn\u0026rsquo;t have to be this exact set of responsibilities. But in general, I think if people are really focused on why am I not allowed to do something? It\u0026rsquo;s actually a relationship and a trust issue as opposed to because I\u0026rsquo;ve never had a staff engineer I\u0026rsquo;ve worked with where if I\u0026rsquo;m like, oh, let\u0026rsquo;s just do all of this managerial stuff together, a week later they\u0026rsquo;re like, actually, I would love to not be doing this. And so usually by just like letting them do it, they will realize they don\u0026rsquo;t want to do it pretty quickly.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. So changing gears a little bit, I think a lot of people who might have like read your books or followed your blog might remark on just sort of like how much stuff it seems that you do from the outside looking in. And you know, I was curious, given that you write books and blog posts and you do community organizing, all sorts of stuff, you know, how do you decide how to spend your time? Like, how do you strike this balance between all the things that you want to do in your life?\u003c/p\u003e\n\u003cp\u003eWill: It\u0026rsquo;s a good question. And I\u0026rsquo;ve been thinking about this a lot. So I think first, I think if you look at my writing, if you like actually looked at like my writing over the years, like there\u0026rsquo;s a period From I think 2013 to like 2016 when I wrote like effectively nothing, maybe wrote like four pieces over that like three or four year period. I just like, the work situation was really, really challenging. Some other stuff was going on and I just like didn\u0026rsquo;t get anything done in terms of my personal hobbies on this side. Like, I didn\u0026rsquo;t speak, I didn\u0026rsquo;t write, I just ran out of energy and I just did nothing for three years. Conversely, like the last like four or five years have been like really prolific for me. There\u0026rsquo;s just been like a lot of stuff that has been possible that just wasn\u0026rsquo;t possible before. And I\u0026rsquo;ve been really excited about it. So I did a lot more speaking two years ago, ramped that down a little bit as I think. Public speaking on average, I think just isn\u0026rsquo;t like my personal medium that I want to spend a lot of time on. I really enjoy the privilege to get to do some of the speaking. But I look at my writing and I look at my speaking and I\u0026rsquo;m like, if my writing\u0026rsquo;s better, I can do it faster. I just think I should focus on it a little bit more. Some of the community building and I think the communities that I\u0026rsquo;ve built, kind of like two different ones that I\u0026rsquo;ve worked with. There\u0026rsquo;s this techwriters.dev, and I think that Community is like sort of trailing off a little bit. I think it suffered a bit for me finishing my book in the sense that the book was really centering for me in terms of that. And there were three or four other folks at the same time working on books. And I think the four of us kind of have all finished our book and it\u0026rsquo;s lost a little bit of the gravity kind of from that. But also I guess I think it\u0026rsquo;s interesting to share here, but actually five weeks ago I had a stroke because I was in the hospital for, you know, three days and you know, wasn\u0026rsquo;t able like lost the ability to speak for like six to seven hours.\u003c/p\u003e\n\u003cp\u003eAlex: Wow.\u003c/p\u003e\n\u003cp\u003eWill: And coming back from that, it was just like utterly mind blowing experience. First, don\u0026rsquo;t recommend it if you can avoid it. Second, like really humbling. Right. Like the first two weeks that I was back wasn\u0026rsquo;t working. My energy level was just incredibly low and I just like sat on. I couldn\u0026rsquo;t use a computer the first week because they were just like too many windows open. And I just like, it\u0026rsquo;s just like overloading. I could only use a phone because phones really zoom in to one thing at a time. Yeah. And it took me, it\u0026rsquo;s only a month later kind of that my energy level is really back to approximately where it was. But even now at the end of the day, I\u0026rsquo;m still just like, I just have no energy left to write. And so I think it\u0026rsquo;s been humbling in a lot of ways. Right. Where I think it helped me articulate, which is like, I like to be kind of right at the cusp of too busy. And then I think with that all of a sudden where that line was like completely shifted and it\u0026rsquo;s been like humbling where I just really haven\u0026rsquo;t written anything since that. And I think at some point I\u0026rsquo;ll go back into it, but with like a young kid, you know, working pandemic, you know, like trying to like be present in my relationship with my wife, I just like kind of like lost the energy to write. Right. So I think there\u0026rsquo;s like a bit of like a seasons of your life bit to it where you have to know like what you\u0026rsquo;re trying to do and like put the energy where you think you can. And I think sometimes you just can\u0026rsquo;t and you just like, I just don\u0026rsquo;t have it right now. And so I think, you know, I hope to get back into Writing a little bit more as the energy level returns. But just like, I think you also have to like, recognize your life as like, kind of a dynamic thing. And like, you\u0026rsquo;ll have like, periods when you\u0026rsquo;re just. You\u0026rsquo;re just not readying. And it\u0026rsquo;s not like, oh, I\u0026rsquo;m. I\u0026rsquo;m not writing because I\u0026rsquo;m like, public speaking. It\u0026rsquo;s like, I\u0026rsquo;m like, not doing anything in public. And like, that\u0026rsquo;s okay. And so I think just being, giving yourself some grace is important. And the last thing I\u0026rsquo;ll say is just that there are people who are trying to make their profession like their. Their career, like, their livelihoods through, like, writing, through speaking, et cetera. And like, for me, like, I\u0026rsquo;ve. I\u0026rsquo;ve always really focused on not doing that. You know, I. I want to, you know, make my living. Like, my profession is like, really like, like the work that I do professionally. You know, working at calm right now really, like, making sure I have the energy to do that. And then if I have more energy to like, you know, to write, to speak, et cetera, like, that\u0026rsquo;s. It\u0026rsquo;s always number two for me. And just like, really knowing where it is, I think has been helpful, I think. My sister is a graphic novelist, and so, like, the way she lives is she like, sells graphic novels and people buy them. And so, like, that to me would be incredibly stressful. And I think not having that stress has always been important. It keeps it fun for me. Whereas if I was actually living off this, I think it would be really, really challenging. Wow.\u003c/p\u003e\n\u003cp\u003eAlex: Well, I\u0026rsquo;m glad that you\u0026rsquo;re here to do this interview, and I\u0026rsquo;m honored that we get a bit of your time given all that\u0026rsquo;s happened recently. So thank you.\u003c/p\u003e\n\u003cp\u003eDavid: I mean, first of all, seconding what Alex said, it\u0026rsquo;s really fun to have you here. We have two questions to wrap up with that we tend to ask every guest. First of all, the question is, when you think about resources around sort of staff plus level engineering, books, blogs, etc. Sort of what has been the most influential to you? And I want to start by saying that the resources that have been most valuable to me have been largely your contributions. And so I\u0026rsquo;ll take this opportunity to say thank you for that. But I am curious to hear your answer as to sort of what has influenced you the most in that vein.\u003c/p\u003e\n\u003cp\u003eWill: Well, first, thank you. I appreciate that. And I think the thing about the resources I\u0026rsquo;ve put together is that a lot of what I\u0026rsquo;ve done is I\u0026rsquo;ve synthesized Like, the different things, the experiences of folks like Alex, the experiences of folks like Michelle. So it\u0026rsquo;s been more trying to synthesize, like, what\u0026rsquo;s real and pull it together. And similarly, there\u0026rsquo;s a ton of amazing resources in my. You know, the book, like, has, like, a bunch of links to the resources. Also, like, on staffenge.com, there\u0026rsquo;s like, a link to the bunch of the resources that I found really helpful. But there\u0026rsquo;s a tremendous number of people out there. I think Tanya Riley has done a great job of evangelizing what real Staff plus Engineering is, and I\u0026rsquo;ve loved a lot of the stuff that she\u0026rsquo;s written, particularly the glue work piece, I think was really phenomenal. But there\u0026rsquo;s just a tremendous number of pieces out there, so I won\u0026rsquo;t list them all. But I really think I believe in the value of talking to practitioners because they give you what we write and what we live. Like, when we write online, there\u0026rsquo;s, like, all these, like, caveats, like, how do we tell, like, the most optimistic version of this story? So it looks like I don\u0026rsquo;t have a bad attitude, like, how do I remove the villain from the story so it looks like I don\u0026rsquo;t just blame other people for everything? And there\u0026rsquo;s, like, all these pieces, and you get, like, a version of the story that\u0026rsquo;s, like, really different, where if you just talk in a group, like a learning circle or something, you get, like, a much realer, like, not filtered version that I find really powerful. So I just think talking to folks in the industry in these roles is really, really valuable in a way that, like, things written publicly, like, just can\u0026rsquo;t because of your obligations to reshape it into something that presents kind of the best version of yourself that you want to be interesting.\u003c/p\u003e\n\u003cp\u003eAlex: I actually, now that you put it in those words, I hadn\u0026rsquo;t thought about this before, but it\u0026rsquo;s almost like your book is an ethnography of staff engineering. You know, I don\u0026rsquo;t know if you have any training in that, but it definitely, now that I think about it that way, it reads like that you\u0026rsquo;re pulling the experiences of folks into sort of, like a cohesive narrative.\u003c/p\u003e\n\u003cp\u003eWill: One of the complaints about my first book, An Elegant Puzzle, was basically like, this is just some idiot who worked in Silicon Valley talking about their experiences, which I think is a totally valid criticism of the work. Right. And so I wanted to not step into that same kind of approach and kind of center it instead on what are real practitioners saying, as opposed to, like, projecting Too literally, like what I thought they should be saying. Conversely, like, there\u0026rsquo;s not like a ton of consistency. So there, there, there, there certainly is like a lot of my perspective, like, shoved in as well. But yeah, I, I did try to approach it a bit, as you\u0026rsquo;re saying, from that perspective, because I wanted to make sure it was something real and not just like my opinion, pretending to be real.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, to me it reads like that. So the last question that we ask, we\u0026rsquo;ve been asking everyone, you know, in a typical month, maybe, you know, like, how much coding do you do?\u003c/p\u003e\n\u003cp\u003eWill: Yeah, this is a funny question. So if I go back, even starting to answer this, you, like, will kind of get the sense that if I go back five years, I was doing probably like 30 to 40% of time programming at Uber. And there\u0026rsquo;s kind of like seasons to that as well. Like, when I first started Uber, like, I was working with a team of, you know, three or four people, and we were like, we were in trouble from like a workload perspective and I was working really hard. And so I was like, directly involved in like, migrating from peak hosting, which I have a lot of kind of feelings about, into like our own data center, and so super involved there. And then, you know, we, we just only hired, like, I spent like basically a year growing the team from 5 to 70 through external hiring. And like, all I did was interview. I just, just didn\u0026rsquo;t do anything else basically. And then things slowed and I was like, started writing some, some software again. Not, not good software, but software, I think at Calm. I, like, I, I\u0026rsquo;ve done work coding like the Eng.com.com website, but honestly, like, none of my code is really doing anything important. And I think if it was like that, that would be bad, but finding ways, like, the question I think is this interesting, is like, how do you, as like a senior manager, track leader, actually stay in touch with what people are doing? And so for me, the DevOps side of things has been really helpful in terms of really paying attention to the datadog when there\u0026rsquo;s incidents, working through the dashboards to understand and diagnose what\u0026rsquo;s happening there, understanding the events, the logs, et cetera. So that\u0026rsquo;s been a really useful way to find a narrow spike they can use to explore the entire system. Even though it would be, I think a really bad day for everyone if I was committing iOS code or something like that just wouldn\u0026rsquo;t work. Well, I do miss it though, of course. Right. And I do think, you know, there\u0026rsquo;s this. The dream is like, how do I find, like 10 to 20% of my time that I could be, like, doing, like, development work like, every single day or week? I, like, look at what I should be doing and I just. It\u0026rsquo;s just irrational to prioritize it in. And so, you know, I still have the dream of, like, going back to, like, the technical track at some point. So my biggest advice to people when they think about managing make sure you finished what you want to accomplish on the technical track. Because it\u0026rsquo;s really hard to go back without disrupting what you\u0026rsquo;re starting to build. And I sort of feel the same way on the management track. It\u0026rsquo;s like, I want to make sure that I finish what I want to accomplish on the management track before I go back. Because it will probably take me like two to three years to be technically competent senior software engineer, let alone a technically competent staff plus engineer. I think it would take me that long just to ramp back into it. And I can\u0026rsquo;t. You can\u0026rsquo;t pendulum when it takes you like three years, like, be a competent senior engineer again, Right? Like that. That\u0026rsquo;s a really expensive pendulum.\u003c/p\u003e\n\u003cp\u003eDavid: Yep, yep. Fair enough. Well, Will, thank you again so much for taking the time. It\u0026rsquo;s really been a pleasure chatting with you.\u003c/p\u003e\n\u003cp\u003eWill: Likewise. Thank you for having me.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-06-29T09:00:00-05:00","date_modified":"2021-06-29T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/mahdi-yusuf-1password/","url":"https://podcast.staffeng.com/season-1/mahdi-yusuf-1password/","title":"Mahdi Yusuf (1Password)","summary":"Engineering is a means to an end, not the end. So focus on what you're doing.","content_html":"\u003cp\u003eToday’s guest is Mahdi Yusuf, Tech Lead for the Server Architecture Team at 1Password. Our conversation is about what it means as well as what it takes to navigate the needs of the org, client, and staff in order to find the best path forward. We kick things off by hearing more about what Mahdi’s job at 1Password involves and he talks about the chief concerns and responsibilities of working on the platform code that the rest of the app is built on. Mahdi’s role specifically requires him to do a lot more than write code though, including designing projects, communicating between nodes in the org, and mentoring staff. This is a balancing act indeed and our conversation moves to focus on what it looks like to handle these tasks with equal measure. One of the biggest skills the position of Tech Lead requires for Mahdi is empathy, and he talks about how a big part of what he does involves listening to concerns and working out when it is best to make a pivot and focus on something different for the overall good. In an environment with so many different stakeholders, knowing what this is can be a huge challenge! We wrap up our conversation with Mahdi on the subject of excelling in your career, talking about what it takes to do truly good work, thinking bigger than the specific problem one is working on, and the necessity of having difficult conversations. So to hear Mahdi’s insights on creating rock-solid products while maintaining a healthy and effective team, tune in today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://blog.mahdiyusuf.com/\"\u003eMahdi Yusuf\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/myusuf3/?originalSubdomain=ca\"\u003eMahdi Yusuf on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/myusuf3\"\u003eMahdi Yusuf on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://1password.com/\"\u003e1Password\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://architecturenotes.co/\"\u003eArchitecture Notes\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8585293-mahdi-yusuf-1password.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Absolutely. Madi Yousef is a senior staff engineer at 1Password. He\u0026rsquo;s worked at a number of roles in tech, including cto. Our conversation covers a lot of ground, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: All right, Mahdi, it is a pleasure to meet you. Thank you so much for taking the time to do this with us today. Could we start by having you tell us who you are and what you do?\u003c/p\u003e\n\u003cp\u003eAlex: Sure.\u003c/p\u003e\n\u003cp\u003eMahdi: My name is Marty Yousef. I am the Tech lead at 1Password for the server architecture team. I think maybe what translates best to other teams is the platform team. So there\u0026rsquo;s the backend platform that powers One Password. You know, I\u0026rsquo;ve joined on and kind of managed API and the backend and the database and that\u0026rsquo;s what I do. For the most part, me and my team do that.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. @1 password. Are there tech leads and is there like a common set of expectations for tech leads or folks who are operating at level?\u003c/p\u003e\n\u003cp\u003eMahdi: The tech leads aren\u0026rsquo;t based on title. They kind of go all the way down to senior and all the way up. So it just depends on your domain experience and people who we think could do the job. So there isn\u0026rsquo;t any like title that associated with a tech lead role. More about the domain and area that you\u0026rsquo;re working on.\u003c/p\u003e\n\u003cp\u003eAlex: Oh, interesting. And so I want to dig into that a little bit. Like what\u0026rsquo;s the difference between being a tech lead and a role? Like even like, would you mind explaining some of the role titles?\u003c/p\u003e\n\u003cp\u003eMahdi: So there\u0026rsquo;s an engineering manager associated with each of these teams, 1Password. And then there\u0026rsquo;s a tech lead who\u0026rsquo;s responsible for the technical work day to day. And you know, that\u0026rsquo;s breaking up tickets, planning the sprints with the rest of the team and making sure things are on track. But there\u0026rsquo;s a lot of cross functional stuff. So if somebody on another team has a bit more experience about this particular thing, you can kind of work together to get the job done, which I like. I think it\u0026rsquo;s A good thing. It also enforces, you know, communication and helping each other along. I think sometimes people get siloed into places where they don\u0026rsquo;t want to actually be and they\u0026rsquo;d like to branch out a bit more, which that gives a bit more space for and allows the team to have a bit more flexibility in what they work on day to day.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Just to make sure that I\u0026rsquo;ve got this right, so there\u0026rsquo;s teams have an engineering manager and they have a tech lead and then you also work with a group of ICs to get the work done.\u003c/p\u003e\n\u003cp\u003eMahdi: Correct, so. Yes, exactly. So each team is a bunch of individual computers, so you\u0026rsquo;d have a team. So the software architecture team, it\u0026rsquo;s my team and a few others. I\u0026rsquo;m the tech lead on that team and we work together for our particular task, basically making sure the API is stable, making sure the site\u0026rsquo;s reliable and staying up and we work as a unit. And then if there\u0026rsquo;s other teams that would need us to kind of deal with stuff like the queue, for example, is one of the things recently we\u0026rsquo;re dealing with. That would be something that we would get pulled in on and work with the team that\u0026rsquo;s dealing with the issue to resolve it and get it all the way through.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Thank you for explaining that. That makes a lot of sense. 1Password is interesting, I think from the outside looking in is that it was a native first company that has now built services out behind it. I\u0026rsquo;m curious, do you find yourself approaching the tech lead role differently than your native folks? Are there things that you do the same? How has that cross pollination happened?\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah, so maybe a little bit of history about 1Password maybe makes more sense to explain how that kind of grew out of there. So they were a local Mac at first, so I imagine there was a lot of Mac developers. The founders were pretty into it and pretty passionate about that. And I think the company kind of organically grew out of that into what it is today. And so I think they grew into that necessity. And you know, a lot of companies struggle going from one to the other. So either really good at back end or really good at the Mac and design and stuff like that. So finding a company with both, it really speaks to the team that was there early on and what they got done and that really informs generally how they work. There\u0026rsquo;s a bit of a split, so we kind of have to integrate at a high level in terms of how the client apps work and the backend work. So we have a book that we share across and then we synchronize there, and then they build against APIs, we write for them, and that\u0026rsquo;s how generally the teams work. There\u0026rsquo;s a whole ladder of ICs on that side that work towards getting things done, and then we meet in the middle.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. How do you find yourself approaching your role from a strategy perspective? Like, how do you help the team sort of choose what to do next?\u003c/p\u003e\n\u003cp\u003eMahdi: You know, that involves a bunch of things, right? So my team specifically isn\u0026rsquo;t tied to any particular feature or product, so it\u0026rsquo;s basically mostly monitoring the system and how it\u0026rsquo;s doing and our general initiatives internally, which also help the other teams build quicker and faster as a whole. So a lot of the stuff that we\u0026rsquo;re working on is paying down tech debt, ensuring that we have headroom to scale, and getting the metrics out so we can work with the ops teams to make sure everything is going in the right direction. And then we also have our own initiatives about making things incrementally better for the system. And things that we see that we don\u0026rsquo;t like incrementally iterate on them and go about that way. A lot of our work is informed by what we see in our metrics and our logging and error rates that we do get. A lot of the work is going down to putting that down. And then obviously, you know, as any large system has a little bit of tech that they have to kind of work around, so we put some effort around that and make sure that we pay it down as quickly as possible. So it doesn\u0026rsquo;t. It isn\u0026rsquo;t a limiting factor going forward. I\u0026rsquo;m still, you know, formulating my thoughts on that at a high level, how that works, but generally that\u0026rsquo;s my, you know, my strategy at the moment. But we\u0026rsquo;ll see how that evolves as things grow and scale.\u003c/p\u003e\n\u003cp\u003eDavid: With one password, how does planning and prioritization work in that context? And especially, like, how do you sort of decide between paying down tech debt versus building out new features?\u003c/p\u003e\n\u003cp\u003eMahdi: It\u0026rsquo;s a really good question, right? Like, it\u0026rsquo;s a really, a balancing act. And you have to constantly, like, thinking through, like, okay, well, this thing, and you have to think ahead, like, three, four months, right? Going, okay, we have one thing here now, you know, what does that enable if I do do it or if I don\u0026rsquo;t do it, what happens?\u003c/p\u003e\n\u003cp\u003eAlex: Right?\u003c/p\u003e\n\u003cp\u003eMahdi: A lot of it\u0026rsquo;s mostly a balancing act. And, you know, things could come at you from the side that you weren\u0026rsquo;t aware of, right? Something could go down or something could break and you have to kind of reshift on the fly as you\u0026rsquo;re going. It\u0026rsquo;s definitely something that you kind of work towards. You want to be a position of power where you can make these decisions from a place where you\u0026rsquo;re like, okay, nothing\u0026rsquo;s really pressing me right now. What would I like to do? And that\u0026rsquo;s your plan A and that\u0026rsquo;s how you want to be operating. But you know how it is when there\u0026rsquo;s big systems and things go wrong. Then you have your plan B of like kind of focusing on what you need to get done and get that there. We haven\u0026rsquo;t had too many of that, but generally that\u0026rsquo;s how I go between like, you know, short term goals here. What can we get done and what does that enable? Does that enable another team to kind of get their job done and what does that look like? And if it\u0026rsquo;s something that\u0026rsquo;s in the near term, then it\u0026rsquo;s like, okay, well, let\u0026rsquo;s see what we can kind of get done in the next couple months so that we can do the work that\u0026rsquo;s going to require us to do the heavy lifting. So incrementally getting there, I think is really key. Breaking them up into smaller chunks is something I think really helps in that regard. Because if you try to take on a big task and try to block out six months, you\u0026rsquo;re never going to get it done. But if you incrementally move in the direction that you want to be, then that kind of, you know, regardless, you\u0026rsquo;re always going to be making progress towards your goal.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. You mentioned sort of if there\u0026rsquo;s things that you can do to basically unblock partner teams, how do you keep context on sort of what those teams are trying to accomplish so that you can identify like the stuff that you can do that would unblock them?\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah. So, you know, we have meetings with other tech leads just trying to get a sense of what\u0026rsquo;s going on. And you know, we\u0026rsquo;re all aware as an org, you know, what the high initiatives and goals are for the quarter or for the year. So we tend to keep an eye on what\u0026rsquo;s going on. And you know, we communicate and try to get to what the core problem is and what needs to get solved in order to enable all this stuff. But I think communication is a big one and I think, you know, a lot of the tech leads exhibit that one password where they communicate with their, with the other team members and try to get ahead of these things when they\u0026rsquo;re planning Their, their work and that, you know, brings up discussions and meetings and so on and so forth. So a lot of it happens at design time too, where you know, okay, this is something we\u0026rsquo;re going to need from X amount of team or ask for input early on in the design phase so we can, you know, smooth the path to getting to where we\u0026rsquo;re going to go. So it\u0026rsquo;s just mostly about figuring out the decisions and then just implementing and that as smooth as that path can.\u003c/p\u003e\n\u003cp\u003eDavid: Be, the better that makes sense. If you think about sort of how you spend your time, if you\u0026rsquo;re anything like me, it varies quite a bit day to day. So let\u0026rsquo;s maybe think like on a longer time horizon, maybe a month or a quarter. What percentage of time do you spend sort of working on individual projects? And that might not be coding, it might be designing or whatever, but like specifically working on a project versus like the sort of communication aspect that you just described, where you\u0026rsquo;re kind of keeping tabs on what other teams are doing, for lack of a better word. And then also I think like the third big bucket that I think of and please let me know if you think I\u0026rsquo;m missing anything is sort of like the team oriented work, like the training, recruiting, mentoring, stuff like that.\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah, so there\u0026rsquo;s a lot there. So I\u0026rsquo;ll go from the last one. So the, so mentoring people on my team, you know, they all have goals, they all have strengths and you kind of want to, you know, help them along and where they\u0026rsquo;re going. And a ton of people did that for me when I was coming up and I, you know, super appreciative of that and giving them opportunities to shine on areas they, you know, want to show that they have experience or learn more. I think is really important. I think that should be in the forefront of your mind at all times in terms of being a lead or a leader in any organization really, because, you know, you\u0026rsquo;re directing them. So if you, you have a lot of power there and that shouldn\u0026rsquo;t be taken on lightly and it should be something that you think through and give time for that. So I have, you know, weekly meetings outside of like what we\u0026rsquo;re doing to talk just about what\u0026rsquo;s going on. And that\u0026rsquo;s outside of the one on ones that the manager does all that. I\u0026rsquo;m just trying to get a feel for what they want as a leader technically, just so they can get opportunities to work on, they want to work on. The next thing you mentioned is design and that\u0026rsquo;s about phases, right there\u0026rsquo;s new projects, new initiatives that come up, problems that arise that require design. You know, a lot of it starts in discussions and then as it becomes more real, it becomes more formalized and you start writing things and analysis as to what\u0026rsquo;s going on. You know, depending on the time of year it is, it\u0026rsquo;s, you know, 20 to 30% of my time. And then, you know, a chunk of it\u0026rsquo;s kind of dealing with stuff that happens and fielding questions and like, how should we go about this? So at least there\u0026rsquo;s some direction that we\u0026rsquo;re all like cohesively understanding that we\u0026rsquo;re going towards. And, you know, I just joined and there\u0026rsquo;s a lot of that trying to feel it out. You know, I\u0026rsquo;ve been there for about 10 months now and just trying to feel out, you know, people\u0026rsquo;s personalities and trying to show that you\u0026rsquo;re part of the team and want to help is a big part of it. So I think, you know, showing that humility to kind of work with them and get the things done as a team I think is really important. Can\u0026rsquo;t remember the last one. My stacks probably got too deep. What was the last part that you asked about?\u003c/p\u003e\n\u003cp\u003eDavid: No problem. So we asked about sort of focus on individual projects, which was the design bit. We asked about mentorship, which you covered. And then lastly, sort of how much time is spent in that sort of communication zone that\u0026rsquo;s constant?\u003c/p\u003e\n\u003cp\u003eMahdi: Like, that\u0026rsquo;s all the time. I think that\u0026rsquo;s like, honestly a lot.\u003c/p\u003e\n\u003cp\u003eDavid: Of in between everything else.\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah, context switching for that sort of thing. I think it\u0026rsquo;s pretty common for the glue bits. You know, people are trying to synchronize people across other things. Or if you notice something, you\u0026rsquo;re pinging somebody saying, hey, what\u0026rsquo;s going on here? Can you explain? So it\u0026rsquo;s a lot of asking questions. Right. And I tend to do that a lot when I\u0026rsquo;m trying to figure out stuff because, you know, I\u0026rsquo;m not working in these areas that I poke in on all the time. And it\u0026rsquo;s important to kind of leave it to the team that\u0026rsquo;s doing it. Right. They have more context than you. But yeah, I\u0026rsquo;d say that\u0026rsquo;s a good chunk of my time being spent just kind of communicating. You know, obviously there\u0026rsquo;s my team focused, sprint planning and all that stuff, of course, but, you know, that\u0026rsquo;s a bit more tight knit because we know what we\u0026rsquo;re working on and my context there is quite high. But for things cross team, it\u0026rsquo;s a lot of communication and Talking about what we\u0026rsquo;re working on and, you know, asking for a design document when that one doesn\u0026rsquo;t exist and kind of go on, what\u0026rsquo;s the intention here behind this? So, yeah, it\u0026rsquo;s hard to say really. I haven\u0026rsquo;t actually thought about percentages, but I\u0026rsquo;d say, you know, that one\u0026rsquo;s a good one, a good sized one. And then I\u0026rsquo;d say 30, 30, 30. You know, if we\u0026rsquo;re going to go there, leave the last 10 to miscellaneous.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. So it sounds like you do a lot of different kinds of things and that\u0026rsquo;s like a common thing that we see from lots of folks. I\u0026rsquo;m curious, when you sort of zoom out and you try to understand you\u0026rsquo;re doing all these different things, how do you know that overall quarter in, quarter out, the work that you\u0026rsquo;re doing is aligned with what your organization wants to do?\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah. So it\u0026rsquo;s a question I ask myself every quarter as we plan things going forward. The company has OKRs that we have and we want to line in with them, but we also have our own initiatives that we direct and that line up with those OKRs and things that we think are important. So it\u0026rsquo;s something that managers and I work together to kind of figure out what that is. And it\u0026rsquo;s honestly comes down to a decision of what we need to get done. And what does it enable. It\u0026rsquo;s kind of the same framework just to kind of work through. Okay, we want to do this thing. Okay, well what does that help? Right. And then you have to really like break that down, justify the reasons why you want to do it. That requires some introspection. Right. You can kind of go, technically that\u0026rsquo;s not great. Right. Very easily. And you can make an argument for that coherently, but you have to take a step back. Okay, well what does that really enable? Like if we spend a bunch of time reshifting it and it does the same thing it was doing before, what did we really gain here? We spent a bunch of time. So that decision making process requires you to take a step back and kind of go, what\u0026rsquo;s the gain for that particular effort? And that\u0026rsquo;s something you have to take. You have to do it at certain times. You can\u0026rsquo;t be doing that every day, otherwise you\u0026rsquo;ll be too close to the problem and you won\u0026rsquo;t get context at a larger picture. So, yeah, you need to be thoughtful about it, but not too thoughtful. You don\u0026rsquo;t want to be thinking about it all the time and spinning your wheels in that regard.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I\u0026rsquo;m curious. I think you just described sort of like a problem that we all face at one time or another, which is when you work maybe on something that\u0026rsquo;s technical, that\u0026rsquo;s not immediately visible, it\u0026rsquo;s maybe like a layer or two deep. You mentioned that you\u0026rsquo;ve got to think about what it enables. So if you work on a for instance, if you work on a platform team, how do you think about the work that you do and how that it drives sort of your customers experience and how do you make that case to the organization?\u003c/p\u003e\n\u003cp\u003eMahdi: So it\u0026rsquo;s tough because the nature of my team is mostly how it\u0026rsquo;s getting done and not what\u0026rsquo;s getting done. Less features, more about how can we accomplish this feature needs, this technical thing accomplished. How do we go about doing that is the focus of my team. So it\u0026rsquo;s less tied to individual experience, but more about reliability and consistency. The fact that like one password, if it goes down, you won\u0026rsquo;t have access to your newly created passwords, the syncing will go down. So those things are the things that are top of mind for things that we\u0026rsquo;re doing and the changes that we make day to day. It\u0026rsquo;s something that we want to think about as we\u0026rsquo;re making any given change. Because it\u0026rsquo;s not just a web app that\u0026rsquo;s talking to it that we can deploy every day. There\u0026rsquo;s client apps that have certain versions that behave certain ways. So I have to think long term. They make a change based on a server thing that we have. Well, the client apps going to exist and the customer may not update to the newest one. So that means whatever we built on the service that has to stay there until that one becomes deprecated or out of support. So those are the kinds of things that I\u0026rsquo;m thinking about. Right. And it\u0026rsquo;s a, I don\u0026rsquo;t know, maybe it\u0026rsquo;s a level, maybe a level down from where features land because those things you can iterate on and change as you see fit. So yeah, I get the question. And it becomes a bit more specific when you\u0026rsquo;re on a platform team because it\u0026rsquo;s more about the health of everything else because there\u0026rsquo;s things that are built on top of the thing that I\u0026rsquo;m working on, which means that you need to be rock solid most of the time. There\u0026rsquo;s a ton of people put a ton of effort to get it there and you want to see it through.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. I\u0026rsquo;m curious as I was talking to you either at 1Password or somewhere else, you know, have you ever been in a situation where you see a technical investment that you\u0026rsquo;d like to make, you feel that it would benefit everyone, but like the client value or the customer value may not be immediately apparent, you know. And if you have been in that situation, like, you know, do you have any specific techniques you use to sort of communicate the value to the organization?\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah. So prior I was the CTO at Gyroscope and you know, we had problems like that where we had a mobile app and an Android app that we had to support. But similar problem people were on old versions, conversions, whatnot. And you know, you always schedule time for the things that your goals, right? Which are features, you know, acquire customers, you know, lower churn. So these things take up your development time. But then there\u0026rsquo;s other things that, like, you know, tech debt or upkeep. And the way I kind of worked at it when I was over there is if there\u0026rsquo;s something bothering you, I\u0026rsquo;ll give you the time and then you can fill in the gaps. Right. And if it isn\u0026rsquo;t bothering you enough, then let\u0026rsquo;s just keep going. Right. But that\u0026rsquo;s a balancing act, right? You really got to get a sense of what\u0026rsquo;s going on. Because if everyone\u0026rsquo;s unhappy about something, right. You have to also think about your team\u0026rsquo;s mental health. You want them to be happy when they\u0026rsquo;re working because if they\u0026rsquo;re happy and they feel productive, they\u0026rsquo;re not stressed out because of all the monotonous things they need to accomplish. I think that\u0026rsquo;s good team management stuff where you can find the balance between going full tilt features, product stuff all day versus, okay, well, this is really painful for our engineers to get something accomplished. What can we do here? Or they\u0026rsquo;re uncertain about something. If they make a change, where they\u0026rsquo;re going to cause a regression, right. That means you need to pull the handbrake a little bit and go, okay, let\u0026rsquo;s take a cycle or two, writing some tests or planning out what we want to do to fix this specific problem. Right. It really becomes a thing about, you know, how much empathy you have for your, the engineers that are actually in the code every day manipulating it. Right. You have to keep involved and listen when there are complaints because if you don\u0026rsquo;t, then you\u0026rsquo;re just going to burn out your team over nothing.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: Then there\u0026rsquo;s a balance. Right. You can\u0026rsquo;t. It\u0026rsquo;s never one way fully one way or the other. Right. But you can always kind of strike a balance that helps people get to a happy medium.\u003c/p\u003e\n\u003cp\u003eDavid: We\u0026rsquo;ve touched a couple Times on sort of like the balancing of different priorities. And I\u0026rsquo;m curious, from a tactical perspective, like, what do you actually use to keep track of sort of all the things that your team needs to get done and sort of how you\u0026rsquo;re progressing against it.\u003c/p\u003e\n\u003cp\u003eMahdi: So prior Gyroscope, I was doing a bunch of GitHub issues, and now we use GitLab and that\u0026rsquo;s how we keep track of stuff. We have sprints that we do. That was a bit of a learning experience for me because we\u0026rsquo;re a smaller startup prior, and I was used to kind of working it that way, where everyone has high context on everything and a lot goes on set, right? Everyone just kind of knows what they need to get done and there wasn\u0026rsquo;t much time spent communicating. Now when you multiply the team by a couple hundred, then it gets problem. More of it becomes communication than working, right? Well, not more, but like, the ratio is way different. So there\u0026rsquo;s a lot more time spent sprint planning and getting things in order, getting everyone on the same page, getting everyone to buy in, you know, and having input. And I learned quickly that you need, you know, tight cycles here, right? You want to keep them tight and you want to learn from those cycles as much as you can do the cycle, you know, use your judgment. What do we think is a good goal? Okay, let\u0026rsquo;s go do that. Then you come back afterwards, what did we do wrong? And then you iterate on that as best you can until you get to a place where you. Everyone\u0026rsquo;s happy and on the same page and they know what\u0026rsquo;s coming up. Hey, I noticed this in last sprint. Okay, we\u0026rsquo;ll put it in the log for the next one. We\u0026rsquo;ll discuss it in the sprint there. And that keeps everyone on the same page as to what\u0026rsquo;s coming in, and it keeps them focused on what they\u0026rsquo;re working on now. So, like, okay, you noticed something, file an issue. We\u0026rsquo;ll deal with the next sprint or the sprint after that, and then we come and hash it out during the sprint, what do we want to do? And then people will advocate for this particular thing. Oh, this is a huge one. We can\u0026rsquo;t. Can\u0026rsquo;t progress without it. Or another person be like, no, that\u0026rsquo;s not important. For these reasons, this thing is more important. Then you kind of have to make a judgment call. You know, it\u0026rsquo;s tough being in that spot because it\u0026rsquo;s honestly kind of assessing what\u0026rsquo;s going on. And sometimes you don\u0026rsquo;t have intimate knowledge. You have to sit there and listen to what everyone thinks and what their explanation for the reason are. And then. And then you take a step back and go, okay, well what does this enable? And then you go into that framework going, okay, cool, that\u0026rsquo;s what\u0026rsquo;s happening there. Great. And then you step back in. Okay, we\u0026rsquo;re going to go with this one, I think. What do you guys think? Does everyone feel happy about it? You know, sometimes not everyone\u0026rsquo;s happy, but, you know, you got to make a decision and move forward. But that\u0026rsquo;s generally how I kind of keep track of it. Then obviously I have a side to do list of things that I just get inundated with that\u0026rsquo;s on my plate that I just kind of keep track of slowly. And then they\u0026rsquo;ll rise and shift depending on what\u0026rsquo;s happening. I haven\u0026rsquo;t found a solution for that just yet. I don\u0026rsquo;t think there is one. I think it\u0026rsquo;s just kind of dealing with it as you go and filtering those in as they become priorities into your Sprints.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, if you\u0026rsquo;ve got one to do list, you\u0026rsquo;re doing great. I\u0026rsquo;ve got, I think a Google Doc somewhere and physical notepad somewhere and a sticky note on my desktop.\u003c/p\u003e\n\u003cp\u003eMahdi: I try to keep the places where I need to look to a minimum, but I\u0026rsquo;m always constantly changing what I do there. I\u0026rsquo;m not exactly sure if there\u0026rsquo;s any concrete way of going about it, but I think honestly it\u0026rsquo;s about assessing the priorities at any given moment and trying to make the best call possible.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, there were two things that you mentioned there that I kind of want to circle back to. One of them was the tasks that the group feels makes sense to take on could change like, you know, based on the information that you get. And I\u0026rsquo;m curious what four of those decisions are made in if it\u0026rsquo;s like something that just comes up at Sprint planning or if there\u0026rsquo;s another way that you can sort of that folks in the team can flag that sort of concern about a plan. And then the other thing that I wanted to circle back and so I\u0026rsquo;ll make these two points and then we can address them one at a time. And I can remind you if I get too far ahead of myself here, but the other thing you mentioned sort of the change in atmosphere where in a small startup everyone has high context and sort of you can run quickly, whereas in a bigger org there\u0026rsquo;s more need to sort of make sure that the context is explicitly shared with folks before they start working on a thing or while they\u0026rsquo;re working on A thing as sort of the situation changes and I\u0026rsquo;m curious what tactics you use for that.\u003c/p\u003e\n\u003cp\u003eMahdi: So I\u0026rsquo;ll address the latter one because that\u0026rsquo;s the one I remember. So at a startup, you know, when I was last at the code base was actually quite big, right. It wasn\u0026rsquo;t a small one, but you know, I was there from early on so my context is very high. You could probably talk about any given thing and I would know what was going on. Right. So, and there\u0026rsquo;s a couple people early on they were in the same position that would know what was going on. So you can make a high level decision fairly quickly, right. Assessing like the need and what\u0026rsquo;s going on without having to look at anything. Right now in a team that is built on a product that\u0026rsquo;s pre existing, they all join the team, they may not have that context. So it requires you to take a step. There\u0026rsquo;s a step now where there\u0026rsquo;s an investigation phase that was different from the other startup. Now that\u0026rsquo;s just my role in that particular startup and that may be coloring my whole view on this. But if you\u0026rsquo;re intimately aware of a particular area of the code, you can kind of reason about it pretty well, right? What downsides to a particular decision? There are, and there\u0026rsquo;s people that I Lean on 1Password all the time for this sort of thing because it\u0026rsquo;s specific to one password. Now those things you have to get a decision point done. So you\u0026rsquo;re not stepping on any toes or going in opposition to what the plan was or what the previous design was. Right. There\u0026rsquo;s a time period for that. At a startup there\u0026rsquo;s a couple of people that kind of know that and they, there\u0026rsquo;s not that many stakeholders which, which makes the thing a bit more involved in terms of a discussion. Right. So at a startup you just kind of bring it up during the planning and then you, you kind of figure out that solution there and then you kind of move forward. At a company like this, it\u0026rsquo;s a bit bigger and we\u0026rsquo;re growing, so it\u0026rsquo;s probably only going to get, you know, gradually more difficult is that you need to have a phase where you design a phase where you, you know, reach out to everyone going, hey, we\u0026rsquo;re planning on doing this. What do you think? You leave some time for feedback and that\u0026rsquo;s the biggest thing that\u0026rsquo;s, you know, been a change for me, the pace, right. Where all those things happen before anything actually gets done. Right. And accounting for that.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: In the process and stuff like that, which I think Are all great things when you have to kind of work at the scale and size that the company is. So that\u0026rsquo;s how I balance it. Can\u0026rsquo;t remember anything about your first question.\u003c/p\u003e\n\u003cp\u003eDavid: So the first one was you mentioned that there\u0026rsquo;s sort of like an iteration cycle or you know, a process where you\u0026rsquo;ll define a goal with the team and then you\u0026rsquo;ll work toward it and then you\u0026rsquo;ll sort of regroup and you may change the plan as you go along. And I\u0026rsquo;m curious if Sprint planning is like the forum in which those changes are decided upon or if there\u0026rsquo;s some other way that, you know, folks in the team sort of flag changes.\u003c/p\u003e\n\u003cp\u003eMahdi: So like at the beginning, I remember there\u0026rsquo;s this cross org nature of things, right? So some decisions happen there, right? Where other people are making inputs like, you know, I prefer to be this way or you know, someone who has a bit more context around what we\u0026rsquo;re going to be doing says maybe that\u0026rsquo;s not the best way because we\u0026rsquo;re planning on doing this, that there\u0026rsquo;s a forum for that and you kind of follow up with them later. Then there\u0026rsquo;s some decisions that happen at a lower level as to what we\u0026rsquo;re doing and those are a bit more, the scope of them is a bit smaller. So they sometimes overlap, sometimes they don\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: For a lot of these other decisions, the Sprint planning is the place for that where, you know, a lot of the decisions get made. We, you know, as we discover in that phase I described where you\u0026rsquo;re investigating, you may learn that it\u0026rsquo;s not possible or you may learn that it\u0026rsquo;s a lot more work. Then you have to take a step back and going, okay, cool, maybe we need to take a second here and chat with more people in order to understand what the real goal here is. Right. Or what, you know, do we want to take a step back and reassess how we want to do it. So there\u0026rsquo;s always, I try to always plan a little bit ahead of where this always doesn\u0026rsquo;t happen, right. This is the ideal. But the ideal is that you kind of want to look ahead going, okay, well these are the things we need to investigate. Let\u0026rsquo;s try to get them in now so we have some time to look into it and then readjust if the plan needs to change. Because if you go, hey, we\u0026rsquo;re going north, right? And then you see there\u0026rsquo;s a giant storm ahead north, they\u0026rsquo;re like, okay, let\u0026rsquo;s go south. Because you want to maintain like some momentum with your team. Right. So as long as you kind of stay a bit ahead in terms of like, okay, these decisions need to get locked away before we can move in this direction I think is important. And that\u0026rsquo;s kind of the balancing that I kind of do in that regard. But honestly a lot of it comes down to having some key discussions about what the plan is in the direction. Once that\u0026rsquo;s settled, then you go about how and that\u0026rsquo;s a little bit more lower scoped investigation. And then once the, you know, the point, research points come out of that, then you\u0026rsquo;re like, okay, cool, here\u0026rsquo;s the plan forward. And knowing X, Y and Z, here\u0026rsquo;s the plan forward. A lot of it\u0026rsquo;s ad hoc, you know, and as I\u0026rsquo;m talking through it with you guys, I\u0026rsquo;m thinking through like what does that actually, actually end up being? And I try to stay ahead because, you know, I don\u0026rsquo;t have all the context everywhere.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: And you know, as the company gets bigger and bigger, I\u0026rsquo;ll have less and less. But you\u0026rsquo;re relying on experience a lot more at that time, right, Going okay, well I imagine this is how this thing works and then you go from there.\u003c/p\u003e\n\u003cp\u003eAlex: Something that strikes me about a lot of the things that you said is that it, it focuses a lot on your relationship with the people that you work with. You\u0026rsquo;ve talked about how you listen and you change the plan. I think you\u0026rsquo;ve earlier on you even mentioned you have to have a lot of empathy for the folks doing the work. And I\u0026rsquo;m curious, you know, is there something that led you to that understanding of empathy as being a way to help people?\u003c/p\u003e\n\u003cp\u003eMahdi: Well, you know, that\u0026rsquo;s just a personal thing for me really to be honest. Like, you know, to be fair, I can also be hard headed and other things. So it\u0026rsquo;s not totally like there\u0026rsquo;s always a balance to these things. Right. But I think most of my career I was the one implementing things and kind of going through the slog of it, you know, rewriting your signup form for the 18th millionth time. Like there\u0026rsquo;s no glory in that, but it needs to get done and you know, you just plug away through it. But you don\u0026rsquo;t want to burn out your engineers because they also want to have challenging, interesting problems they want to work on. Right. So you don\u0026rsquo;t want to create atmosphere where you know, that isn\u0026rsquo;t thought about. Right. You need to be thinking about it always and trying to, you know, challenge them just a little bit outside of their scope or a little bit more interesting work. Right. Where it isn\u0026rsquo;t just like, do as I say, and that\u0026rsquo;s what we\u0026rsquo;re doing. You want to have a place where people can go, hey, I\u0026rsquo;m kind of bored with this. I kind of want to work on this sort of thing. Okay, cool. We\u0026rsquo;ll try to get you more of that type of work sent your way. And, you know, a lot of it\u0026rsquo;s also figuring out, you know, what they\u0026rsquo;re comfortable doing and where they want to go with their career. Because they\u0026rsquo;re individuals, they may not be in it for what I was in it for.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: And for me, it\u0026rsquo;s about, you know, this stuff needs to get done. Let\u0026rsquo;s knock it out. And I was that type of person where you kind of get handed a problem or an area that\u0026rsquo;s kind of like, you know, not being organized. You kind of take it and try to put some hard edges so you have some, you know, bounds, and then you kind of work and iterate within there. Try to work in a way that you can incorporate others. Document what you can so that it\u0026rsquo;s clear when somebody new comes in. So I think empathy goes a long way in those things, documentation, right? Because if I write something, I know how it works, no problem. But if you don\u0026rsquo;t think about the person coming in behind you or you tell them to go read the code or something, to me, it\u0026rsquo;s like your job isn\u0026rsquo;t only that. It\u0026rsquo;s only a small subset of it. You should be there and available to field questions, have somebody challenge your assumptions and explain why you went that route. And maybe that route, we decided is no longer valid and we can go a new way. So to me, it requires a lot of humility and empathy and, you know, diminished ego a little bit, right? Where it\u0026rsquo;s like, it isn\u0026rsquo;t about you, it\u0026rsquo;s about what we\u0026rsquo;re working on and how we\u0026rsquo;re gonna get there together. Right? And I think, you know, I think a lot of those things are lost on most people because, you know, everyone\u0026rsquo;s out to make their name and stuff like that. But I think the people that I\u0026rsquo;ve remembered, you know, throughout my career are the people that were helpful to me and, you know, were kind and had impact, you know, broader than just what code they wrote. Right. There\u0026rsquo;s a time and place for that. Predominantly, my career was in startups where a lot of it\u0026rsquo;s just like, okay, get to it work, right? And then, you know, through various sizes, right? And it changes, right? The skills that you needed to. That got you There may not be the ones that get to the next goalpost. So it\u0026rsquo;s truly humbling because you\u0026rsquo;ll go through phases of that in your life and it really takes a second to kind of recalibrate, going, okay, I need to be different in this context, and I need to be a bit more open to feedback. And I\u0026rsquo;m a very generally inquisitive person especially, and I take time to take time to think back on why I did things and how I went about it and go, what can I do better? And, you know, asking that of your team is important too. Is there anything that we could do better here or we feel like we could do better? And I think that creates a mechanism where there\u0026rsquo;s an openness to discuss things and, you know, make things better.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Do you ever think about the work that you do in terms of psychological safety?\u003c/p\u003e\n\u003cp\u003eMahdi: Not in those words. Right. But like, if I see, like, for example, let\u0026rsquo;s say, you know, we\u0026rsquo;re getting a lot of regressions, right. There\u0026rsquo;s a reason that\u0026rsquo;s happening. Right. You talk to people, they\u0026rsquo;re smart enough. Okay, so then what is it? What\u0026rsquo;s the problem here? Is it, you know, it\u0026rsquo;s something that\u0026rsquo;s. That\u0026rsquo;s happening around them? Right. If people don\u0026rsquo;t want to have regressions, they don\u0026rsquo;t. Like, that\u0026rsquo;s not a goal. They wake up in the morning, I\u0026rsquo;m going to go create regression. That\u0026rsquo;s not the goal here. So then what\u0026rsquo;s the bounding box that\u0026rsquo;s causing that environment to thrive?\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: Are we going too fast? Do we not have enough tests, whatever it may be? Right. And I\u0026rsquo;ve gone through that. All companies are the same. Once you see enough of them, same problems crop up, same kind of issues. Technical aspects may change depending on what space you\u0026rsquo;re in and whatnot. But it\u0026rsquo;s all people stuff. And the more you think in that way, the more you realize, okay, well, this is happening. It\u0026rsquo;s not the individual, it\u0026rsquo;s something that\u0026rsquo;s happening around them and the environment that they\u0026rsquo;re. And that\u0026rsquo;s causing it. Sometimes it\u0026rsquo;s individual, sometimes, but most of the time it\u0026rsquo;s environment. Right. In that regard, yes, but not so psychological. But like, what\u0026rsquo;s causing this to happen? Right. What lever is being pushed for this to be the result? And if you can figure out the levers that you control, then you have some options as to how to get a different outcome.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that\u0026rsquo;s a really interesting insight. I think it can be always hard for us to hold on to the core idea that, like, no one shows up to create a bug. Right. And to really do the hard work of looking at the environment around the individual and to be empathetic towards their experience. Right. Like, it\u0026rsquo;s a hard task to fill.\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah. And it\u0026rsquo;s not always quantifiable. Right. Honestly, like, most of the time it\u0026rsquo;s not quantifiable. So you can ask a question, what\u0026rsquo;s wrong? Well, it\u0026rsquo;s hard to kind of articulate. Right. So you have to be kind of inquisitive. Okay.\u003c/p\u003e\n\u003cp\u003eAlex: What.\u003c/p\u003e\n\u003cp\u003eMahdi: When I\u0026rsquo;ve done stuff like that, right. What environment was I in? Was I working late? Was I shipping stuff quickly? And there wasn\u0026rsquo;t a lot of tests. Is the design lacking? Like, there\u0026rsquo;s a bunch of things to go through to kind of get you there. And I think that checklist. I\u0026rsquo;ve never thought about it that way, but those are the questions I kind of ask in my head going, okay, last thing, I think it\u0026rsquo;s this individual person that\u0026rsquo;s the problem. I get. That should be the. The very, very last thing. Right. It should be a bunch of other questions you asked prior before you get to that conclusion.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Zooming out a little bit. Like, what\u0026rsquo;s interesting, you know, there\u0026rsquo;s always an environment sometimes where, like, a bug happens, but then at another level, we, as individuals, we want to grow, we want to progress in our career, and sometimes that\u0026rsquo;s difficult. You know, when you approach that with people that you work with, maybe, like, you know, you might call it sponsoring or mentoring, like, how do you approach helping someone grow through their, like, career track?\u003c/p\u003e\n\u003cp\u003eMahdi: Yeah. So maybe I\u0026rsquo;m a bit different when it comes to this stuff. I never put much stock into titles and whatnot. And, you know, I know we\u0026rsquo;re on the Staff Edge podcast and stuff, so it\u0026rsquo;s a bit on the nose here, but for me, just focus on doing good works. Right. And I think if you focus on that and make that your priority. Right. And then, you know, tell people that you. What you did and how you got through it, and, you know, say, hey, I\u0026rsquo;m going to kind of take over this problem here. I\u0026rsquo;m going to try to get it to a solution point. Right. If everything\u0026rsquo;s, you know, transactional, then nothing has actually any meaning. Right. And that\u0026rsquo;s not what you\u0026rsquo;re taking away from the scenario. Right. When I leave a company, do I leave with my title? No, my title stays there and it\u0026rsquo;s done. Right. I leave with what I did, how I did it, the people I Worked with, you know, what I accomplished, what I learned as I was working, the insights that I had, the fun that I had with the people that I was working with, those are the things I can take away with me. Right. So I think, and I see this a little bit with, you know, people that are coming up and they want, you know, the title, the opportunity, the. The scope to work at will, exhibit that. And a lot of times what happens in these bigger companies is that you\u0026rsquo;re not rewarded because there\u0026rsquo;s so many people in the company and there\u0026rsquo;s. Everyone is requiring that attention. And you end up most of the time working at the level of the title that you\u0026rsquo;re looking for before you get it for a while. Right. And knowing that should try to unclick you from that. Right? Now, obviously, you want to have some career progress and stuff like that. Look for opportunities to shine. Look for. And those are tough to come by. Right. Especially in large companies where there\u0026rsquo;s a lot of initiatives at any moment and have varying levels of impact on the organization. But if you\u0026rsquo;re consistent and reliable, I would bet on the side that you\u0026rsquo;ll get there. Right now, putting a stopwatch to it is, you know, something I probably wouldn\u0026rsquo;t do. Yes, like watching an egg boil. But to me, it\u0026rsquo;s like kind of work towards it. And if your goal is to just get a title, it\u0026rsquo;s about the work that you\u0026rsquo;re doing. Right. And if your goal is to just get a title, then, you know, look for positions where you think that would be a good fit, you know, not at your current company or, or. Or pitch to them. But I always try to say this, right, in terms of sponsorship and knowledge. Like, knowledge is an experience of the things that I try to optimize for. Right. Because those things help you kind of grow and open your mind to new things. And those are the things that I try to get out and, and share for. And communicate. Right.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eMahdi: And share those experiences, things that I\u0026rsquo;ve experienced, things that they. Or opportunities for them to experience it. I think those things are better to do as a way of sponsorship and leadership and mentorship in that regard. So that\u0026rsquo;s my little, little talk on that. But, like, honestly, I think a lot of it depends on the individual and what they\u0026rsquo;re looking to get out of it.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: They may not even be interested in, you know, deep IC role. They maybe want to become an engineering manager or a product manager. You know, your openings in that regard are limitless. If you\u0026rsquo;re starting from an engineering perspective. Right. They\u0026rsquo;re always an asset. If you go into all those other areas.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. I want to touch on something you said earlier, which is that when people come to you and talk to you about career progression, I think you hit the head on those. You\u0026rsquo;re like, do good work. I\u0026rsquo;m curious, though, like, what if a person feels like they\u0026rsquo;re doing good work, but you don\u0026rsquo;t think that it\u0026rsquo;s necessarily aligned with what the organization needs? How do you help a person work through understanding the difference between just doing work and doing quote, unquote, good work?\u003c/p\u003e\n\u003cp\u003eMahdi: That\u0026rsquo;s a tough one. And I honestly haven\u0026rsquo;t come across it yet in my mind. You know, if you\u0026rsquo;re operating in a. Like, I\u0026rsquo;m assuming, you know, the company you\u0026rsquo;re at is operating in a metrocracy, or, you know, good work is rewarded and there\u0026rsquo;s a path forward from there. That\u0026rsquo;s a tough one. And my thoughts on it aren\u0026rsquo;t. If you feel like you\u0026rsquo;re not being. You have to really, really be honest with yourself. Right? This is where reflection comes in really key here, Right. Because if you\u0026rsquo;re not honest with yourself, right, Then it becomes a bit of a hole you can go down. That doesn\u0026rsquo;t lead anywhere good. Right. But if you are honest with yourself and go, okay, well, where can I improve? Listen to the feedback, right? Now, sometimes that feedback may not be true, Right. And I\u0026rsquo;ve been through positions in my life where that\u0026rsquo;s been the case. But you just keep working and focus on, like, what are you taking away from this? It comes back to that point, right. For me, like, if you\u0026rsquo;re really after, like, progression and that\u0026rsquo;s what you\u0026rsquo;re really focused on and you think you\u0026rsquo;re there, then great advocate that. Let that be known. That\u0026rsquo;s what you want to do. And then follow up with work. Now, good work in the sense of, like, communicate. It\u0026rsquo;s not what you\u0026rsquo;re working on, it\u0026rsquo;s how you\u0026rsquo;re doing it. And then your overall area. There\u0026rsquo;s tons of things to work on. What if you take a small. Be helpful. Right. Ultimately, what it comes down to. But there\u0026rsquo;s. I\u0026rsquo;m sure there\u0026rsquo;s an area that\u0026rsquo;s being neglected. Go there and clean it up. Right? Talk to your thing. Say, hey, what\u0026rsquo;s a thorn in your side? Right. Tech lead. What\u0026rsquo;s the thorn in your side that you wish you had time for?\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: Like, I don\u0026rsquo;t. I never ever tell people to work late unless it\u0026rsquo;s like, absolutely necessary. But you want to grow Quickly, then you got to put in the time, right. If that requires you working later or working in your weekend, up to you. And obviously that if you pick things that are going to move the thing forward or things that are painful to people, then great. Right. But to me, it\u0026rsquo;s. It\u0026rsquo;s a very hard question that I don\u0026rsquo;t have any, like, you know, really thoughtful insights on. But to me, honestly, it ultimately comes down to do you feel like you\u0026rsquo;re being recognized for the work that you do do? And then look for if there\u0026rsquo;s a mismatch between what the company\u0026rsquo;s valuing and what you\u0026rsquo;re valuing, it\u0026rsquo;s good to check in, right? So there isn\u0026rsquo;t. Because these things are few and far between.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMahdi: You check in, you know, for promotions, like once or twice a year if you\u0026rsquo;re at a company that does that, and then you go from there. So check in, check in early so you\u0026rsquo;re not wasting three months, you know, toiling away at something that doesn\u0026rsquo;t matter. But ideally, everything that you\u0026rsquo;re working on should be something that should be factored in. So if that\u0026rsquo;s mismatched with what you want in your progression, then you have to check in, talk to your team, lead. So I think, you know, it all folds in together there. But for the most part, if you feel like genuinely, if it\u0026rsquo;s a thing, you have to be honest, really honest with yourself, right? And like, you know, talk to a colleague that. A trusted colleague or a mentor that you have and ask them for some concrete feedback. There\u0026rsquo;s. And then if it\u0026rsquo;s. If they\u0026rsquo;re all coming out of the conversation going like, this doesn\u0026rsquo;t seem to be right. And have a tough conversation. It\u0026rsquo;s always tough, but it\u0026rsquo;s just a conversation. Don\u0026rsquo;t shy away from these things, these things that you kind of like, shy away from. My life general mantra is lean into them. Lean into them. It\u0026rsquo;s not as bad as you think, Right. And if you do that, more often than not, I think people will understand where you\u0026rsquo;re coming from and get insight to what motivates you. And I think it\u0026rsquo;ll lead somewhere good. End of that, it\u0026rsquo;s still not working. And then it\u0026rsquo;s. Then it\u0026rsquo;s like, okay, maybe it\u0026rsquo;s time to look around and see, like, the world\u0026rsquo;s a big place.\u003c/p\u003e\n\u003cp\u003eDavid: I think you touched on two things that are some of my sort of favorite ideas for in general, how to be good at stuff. And one of them is self awareness. And that gets to being honest. With yourself. Right. But it kind of goes both ways. Some people are too hard on themselves and some people are too easy on themselves. Right. And so I think of self awareness as being sort of an important, important cheat code to everything. But also the idea of like embracing difficult conversations. Right. That is something that\u0026rsquo;s taken me a long time to learn. But if you\u0026rsquo;re self aware and if you\u0026rsquo;re willing to embrace difficult conversations, including, you know, checking in about how people think about what you\u0026rsquo;re doing. Right. That\u0026rsquo;s a pretty powerful path forward for anything. Not. Not just sort of, not just software engineering, obviously.\u003c/p\u003e\n\u003cp\u003eAlex: Exactly.\u003c/p\u003e\n\u003cp\u003eMahdi: Right. And communicate what you\u0026rsquo;re facing, feeling and how your goals and I think, you know, we do a pretty good job at 1Password in that regard. Right. People are able to communicate what their personal goals are and the goals for them on the team and how they line up with our.\u003c/p\u003e\n\u003cp\u003eDavid: You know, that\u0026rsquo;s really cool. Is there, is there a process for doing that? Like, do you have sort of some. A way of folks sharing personal goals formally or is it just sort of like in the culture?\u003c/p\u003e\n\u003cp\u003eMahdi: So the culture is still forming, right? We\u0026rsquo;re growing big now and you know, but it\u0026rsquo;s something that I think everyone values the company and you know, seeing those line up for each individual\u0026rsquo;s in a, you know, let\u0026rsquo;s say like it\u0026rsquo;s like a long path, right. And everyone\u0026rsquo;s got their, you know, where they\u0026rsquo;re at and where they want to be and you know, they kind of highlight those things. Hey, I would like more opportunity to design things. I\u0026rsquo;d like more opportunity to implement these things. You know, some people are in the spot in their career where they would like to, you know, how there\u0026rsquo;s T shaped people and there\u0026rsquo;s very general. They know a little bit about a lot of things. There\u0026rsquo;s people that have, you know, deep about a few things. So there\u0026rsquo;s people who are still widening their. The top of their tail, other people who are trying to link more depth on particular topics, so they highlight those things. So then as work comes in, you can kind of go, hey, there\u0026rsquo;s an. Here\u0026rsquo;s an opportunity to kind of do this. And I try to keep my eye open for these things right. As. As they come in the pipeline sometimes there\u0026rsquo;s not a lot of opportunity for that. Right. But you can make some find something that kind of sucks and go, hey, can we put some time towards this? You know, we\u0026rsquo;ll fit it in. It\u0026rsquo;s print after spin. We\u0026rsquo;ll put some time towards it. So at Least the person is getting some development and some experience. I think finding that balance and prioritizing it is really important. What we do is we set goals, personal ones for the year. Then we have team ones that we set quarter that are fall into yearly ones for the whole org. And they\u0026rsquo;re not specifically tied together. The personal ones are hopefully not in competition, but they\u0026rsquo;re side missions and you can do them as you work in. And it requires a little bit of, you know, thoughtfulness from your leaders to kind of get that accomplished.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that\u0026rsquo;s a really interesting model. I\u0026rsquo;m going to have to think about that a little bit more. Shifting gears entirely. We\u0026rsquo;re almost at time. There\u0026rsquo;s two questions that we, we tend to ask everyone who comes on. One of them is, are there any people or resources that you can point to as like places where you\u0026rsquo;ve learned a lot about this stuff, about sort of like maybe staff engineering specifically, but also just like leadership and mentorship and you know, etc, all the stuff we talked about today.\u003c/p\u003e\n\u003cp\u003eMahdi: You know what, I\u0026rsquo;m a person who likes to think about things, you know, just like, hey, there\u0026rsquo;s this thing that I\u0026rsquo;m like, I range from getting really angry about them and like, just going like, this is not cool and going like, why is it like this? Right? And then I go, because I, I really believe, like I. And I, I don\u0026rsquo;t buy into like institutions much, right? I\u0026rsquo;m like, it\u0026rsquo;s just somebody making some decision somewhere. It doesn\u0026rsquo;t really matter, right? And they\u0026rsquo;re optimizing for something they think is important. And I don\u0026rsquo;t think that. And I\u0026rsquo;m not actively combative. I get sometimes you just have to fall in line and work within the org, right? And not specifically to companies, but just, you know, ideologies about these things. So I go, what\u0026rsquo;s the real thing behind it? What\u0026rsquo;s really motivating and thinking that through? And there\u0026rsquo;s, you know, there\u0026rsquo;s books I can riddle off all the books everyone reads and you know, but those are things that just expand your mind, right? They give you a bit more context, get you out of your daily rut, right? You\u0026rsquo;re thinking about like databases every day. Okay, well let\u0026rsquo;s, let\u0026rsquo;s stand up a bit and take a look around and see what other people are thinking about. What are the things that people are experiencing? You know, people deal with the same type of problem every day, right? They\u0026rsquo;re not entirely unique, right? There are some problems that are unique, but most of them aren\u0026rsquo;t. So what are these strategies like at a higher level? What are the strategies that people employ to kind of solve these problems? What are the ways of thinking about them? Right. Frameworks, I think, are the things that you should kind of collect as you go forward, but go deep on them. Right? Go deep. Right. Have some, like, you know, gut instincts, and all these things push you in one way or the other. So I\u0026rsquo;d say read the books, but then challenge what they tell you. Right? And then find the nuggets of truth there. Just find a book. There\u0026rsquo;s tons of book people will tell you to go find. You know, but I tend to, you know, personally, I\u0026rsquo;m of two modes. You know, something for the heart, something for the mind. So, you know, if you\u0026rsquo;re interested in new technology, go read about the book. O\u0026rsquo;Reilly\u0026rsquo;s got a bunch of awesome books that they put out for these things. Read and consume everything you can about a topic. Right. When you\u0026rsquo;re learning, just read. There\u0026rsquo;s infinite amount of resources here. Right. But also, don\u0026rsquo;t forget what you\u0026rsquo;re doing. Right. Engineering is a means to an end, not the end. So focus on what you\u0026rsquo;re doing and what you\u0026rsquo;re working on. You could spend your whole day working on algorithms, but what did you just do? What did you do? Right. Did you optimize a shopping cart? Or did you actually protect people or help them with their lives or make things easier? I think a lot of that goes unsaid in engineering. And a lot of the problems we\u0026rsquo;re seeing with a lot of these companies, it\u0026rsquo;s nobody taking a step back to go, why am I doing this? Right. And the places I\u0026rsquo;ve worked are generally places where I think I can have impact on people\u0026rsquo;s lives in a positive manner and get paid commensurately for that offering. Right. I think there\u0026rsquo;s not a lot of, you know, think about what you\u0026rsquo;re doing and how you\u0026rsquo;re doing it and what you\u0026rsquo;re working on. And these books, you know, there\u0026rsquo;s a list of them. You can go find them, read them, you know, and those are books that help you technically and give you some context here. And those are good. But the books I tend to find are more about, you know, entrepreneurship struggle. Right. You\u0026rsquo;re not the only one who\u0026rsquo;s had adversity in life. So read about other people\u0026rsquo;s difficulties, and they may seem, you know, the individual. Individual may be easy for some things, other things may not. So don\u0026rsquo;t. Don\u0026rsquo;t ever compare. Everyone\u0026rsquo;s on their own. Little path and try to learn from other ones that you can. Right. So that\u0026rsquo;s my, you know, what I tend to read and look into and stuff, but I\u0026rsquo;m more about, you know, what motivates people and what do you think is, like, what do you, you know, what you admire in others, right. And really talk to those people and kind of go, hey, what are those things that you\u0026rsquo;re doing on? And I try to do that when people reach out to me. So I don\u0026rsquo;t know, I kind of rambled on a little bit at the end there. But I think that answers your question.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that\u0026rsquo;s a really interesting take, you know, finding your way through learning, I think. So the last question that we like to ask, hopefully it\u0026rsquo;s fun. How much time do you find yourself coding nowadays?\u003c/p\u003e\n\u003cp\u003eMahdi: So last role to this role, I went from like, you know, 70% of my time to now, like 30% of my time, 35% of my time. And it was a bit of a balancing act. Like, early on, I\u0026rsquo;d leave going, I didn\u0026rsquo;t get anything done, right. And I\u0026rsquo;m like, what is going on? And I\u0026rsquo;d feel like, terrible. My dinner going, like, what\u0026rsquo;s going on? Right. And it took me a while to reframe in terms of like, okay, well, you know, you helped a bunch of people along and you got some of your stuff done, you\u0026rsquo;ll come back to it. Like, I end up staying late because I was like, I was fielding like meetings and questions and what do you think about this? And kind of going here, great. And then all my time that end up doing that, or majority of my time, I end up doing that. But that\u0026rsquo;s kind of why I\u0026rsquo;m where I am, where I am. To help facilitate that kind of discussion and move these things forward and maybe be a bit more forward looking in that regard. So, you know, I\u0026rsquo;d like to be coding more. Right. The idea of staying in the IC route is doing that. Right. But not what it ends up being, unfortunately, sometimes, right, where you\u0026rsquo;re kind of focused on, you know, larger problems and a class of problem rather than the actual solution to a particular problem. So, yeah, less so. I\u0026rsquo;d say about 30 now. And I can imagine that\u0026rsquo;ll probably go down as things progress, but I think you kind of have to kind of let that go and reframe what you. What the role is for you right now at the staff level, right. You can. There\u0026rsquo;s a lot of people deeply technical and kind of do that. But the higher up you go, I think there\u0026rsquo;s a little bit less and less of the coding becomes more of like, you know, kind of discuss what the problem is and then implement. But yeah, less.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. Well, Marty, thanks so much for taking the time today. It was really, really, really fun chatting with you.\u003c/p\u003e\n\u003cp\u003eMahdi: Awesome. Thank you guys for having me. And it was really, really cool chatting about all this ideas and stuff about engineering. There\u0026rsquo;s not a lot of space online for a lot of this stuff, so it\u0026rsquo;s awesome that you guys are doing this.\u003c/p\u003e\n\u003cp\u003eDavid: Actually, on that note, before we break, where can folks find you online?\u003c/p\u003e\n\u003cp\u003eMahdi: On Twitter, yousef3 and my blog, mightyuser.com awesome. Thanks.\u003c/p\u003e\n\u003cp\u003eDavid: We\u0026rsquo;ll link those up in the show notes.\u003c/p\u003e\n\u003cp\u003eMahdi: Awesome.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show. It is a really useful signal to us that folks are finding value in this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-06-15T09:00:00-05:00","date_modified":"2021-06-15T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/amy-unger-github/","url":"https://podcast.staffeng.com/season-1/amy-unger-github/","title":"Amy Unger (GitHub)","summary":"If you ignore the product direction, if you ignore what's making money, if you can't find some way to align the work you're doing or help frame the work that other engineers are doing in the context of what is delivering value, I think you're going to be less effective.","content_html":"\u003cp\u003eAmy Unger, our guest on today’s show, is passionate about providing a high-quality service to the customers who use the products she is working on. Amy has a diverse skill set and an equally diverse set of tasks that she undertakes weekly for GitHub, and at the core of everything she does is her drive to provide value. Amy came into the for-profit space from the academic programming space, and she explains the different experiences she has had in these realms. We discuss what a tech lead role consists of, in comparison to the deep diver role that Amy currently holds, the responsibilities that come with it, and why she loves what she does.  Amy also shares her thoughts about trade-offs, and the considerations that all engineers should be making before they embark upon certain projects.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/cdwort\"\u003eAmy Unger on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/\"\u003eGitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.heroku.com/\"\u003eHeroku\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://code4lib.org/\"\u003eCode4Lib\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://bepress.com/products/digital-commons/\"\u003eDigital Commons - bepress\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8513783-amy-unger-github.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;re interested in the areas of work that sets 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 Romis and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Amy Unger is an engineer at GitHub, previously of Heroku as well. Amy works on a dizzying array of things in a given week. It was fun getting to hear her approach and I think you all enjoy it as well. Let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Amy, thank you so much for taking the time. It\u0026rsquo;s really great to have you here with us today. If we could start by having you just tell us who you are and what you do.\u003c/p\u003e\n\u003cp\u003eAmy: My name is Amy Unger. I\u0026rsquo;m a software engineer. I started out in libraries and archives with connection there because of my history background and slowly moved more and more into developer tools. So I spent six years at Heroku and now I\u0026rsquo;m at GitHub.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. I\u0026rsquo;m curious, is there a typical set of expectations for a staff engineer at GitHub?\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, fun, perennial question. No, there\u0026rsquo;s not a standard set. I think every org has a different approach to how staff engineers kind of come up into the role. And I think a very common pattern is to bring folks into the role as something similar to what Will talks about as the tech lead archetype at GitHub. That\u0026rsquo;s, that\u0026rsquo;s very common. We also have a bit of folks who are deep divers. GitHub is at this point a very large monolith. Well, the core of it is a very large monolith. We need deep expertise in git systems in other parts of our technology and that\u0026rsquo;s a really easy to justify kind of model for your time. You get wins. They might be a little bit shorter. Shorter is the wrong word. With a tech lead, you\u0026rsquo;re really very clearly of use to your manager, someone who\u0026rsquo;s deep diving and solving bigger problems. You\u0026rsquo;re not necessarily working on a three month timeline, you might be working on a 12 month timeline, but you are clearly able to bring wins to the table with, okay, I brought performance up by 15%. I solved this memory issue. So those two models are really common for us. The tech lead for bringing folks into the world. It\u0026rsquo;s kind of a natural extension of probably what you were doing at Senior and kind of just getting you a taste of what you could do. And then solver for solver, deep diver for a different variation of staff that\u0026rsquo;s pretty easy to justify to the business in terms of value.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Do you feel like either of those epitomizes your approach to staff or do you have your own unique twist on being a staff engineer?\u003c/p\u003e\n\u003cp\u003eAmy: I think everyone rotates through different roles. Maybe if you don\u0026rsquo;t want to. I think a lot of folks rotate through different roles. That\u0026rsquo;s not what I\u0026rsquo;m doing right now. I work for a department that has about 30 ICs. One way of looking at us is we are some of the oldest parts of GitHub married with some of the newest parts. We have repositories which is like that is the first feature of GitHub. We have pull requests issues came in between. But when you\u0026rsquo;re talking about code collaboration and building, software issues help you track it. But the actual code work repositories first, pull requests next. Then to add in a little bit of the new we have codespaces which is helping you write code. A complete development environment in the cloud so you can write code, pull, request it and get it merged in all from your. Your iPad if you wanted. So it\u0026rsquo;s a really cool set of features. It\u0026rsquo;s very broad. My work is kind of mostly focused across the department, making sure that we understand where our risks lie. We have a lot of legacy code that we are very happy with because it\u0026rsquo;s delivering great features but it needs some care intending and if there\u0026rsquo;s no one there to clearly articulate that we need to get it done. Which obviously we have lots of ICs who are and have been doing that work. I help kind of coalesce all that into common approach. I take on anything that\u0026rsquo;s not being addressed that we think really should be and then every once in a while help out with assorted fires. So you know, critical ga date about to be missed because surprise, your team didn\u0026rsquo;t deliver something we\u0026rsquo;re telling you about today. The deadline is March 31st. Go that sort of fun stuff.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. This is a little bit tangential. I was curious. You said you mentioned you came from libraries. Are you familiar at all with the code for Lib Group?\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, I can\u0026rsquo;t remember which one I attended, but I was one of their scholars or sponsored whatever when I was.\u003c/p\u003e\n\u003cp\u003eAlex: In library school before working at Stitch Fix, the last company I worked for was a library vendor. So we sold software to libraries. Oh, which BPress? Digital Commons.\u003c/p\u003e\n\u003cp\u003eAmy: Sorry, I haven\u0026rsquo;t heard that before.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s an institutional repository. It doesn\u0026rsquo;t matter. The reason why I brought it up is that that was sort of a detour for me in my software engineering career and I was in my experience going to code for Lib and doing other sort of library software engineering activities. There was a very different approach to the job than I found pretty much anywhere else. And I was curious if that was something that you saw and if you have brought that approach to GitHub.\u003c/p\u003e\n\u003cp\u003eAmy: I wouldn\u0026rsquo;t say that I have brought that approach, no. Well, there are three things I\u0026rsquo;m really grateful for for starting out there. Probably first and foremost is that academic libraries, academic programming in general didn\u0026rsquo;t have the same exodus or forcing out of women from the field. So I had a lot of men surrounding me, but there were still some really senior, really kick ass women. That was really great and empowering for me. I think the second thing that has really stuck with me is just a service ethic. It is really easy to come to consensus. Well, maybe not easy to come to consensus, but you can always start from a point of sharing a dedication to patrons to serving the needs of your community and building knowledge and resources to those people. Personally, I wish eventually to get back to that. I think there is a strong component of that in developer tooling that I probably do relate to, but they\u0026rsquo;re very for profit companies and so I wouldn\u0026rsquo;t say that that ethic really applies. And let\u0026rsquo;s see. Oh yeah, the third was kind of. I didn\u0026rsquo;t see a lot of spectacular thinking around programming coming out there. So I\u0026rsquo;m curious what approaches to programming that you found and enjoyed working at the press.\u003c/p\u003e\n\u003cp\u003eAlex: Totally. So one of the things I think, I guess was the approach of the community to their job more than the approach to programming. Like you said, libraries sort of take this oversized role in our society, both like your local public library and your university library. It\u0026rsquo;s almost like become like this social infrastructure that we don\u0026rsquo;t really talk about that much. And it\u0026rsquo;s interesting, GitHub is also sort of social infrastructure for code and open source. And I was wondering if you found a sort of, you know, a shared theme there and it sounds like you do.\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, I think for me personally, yes, I think that as a staff engineer, particularly in the roles beyond tech lead, I think a little bit of business knowledge, product knowledge is always going to be a positive. And so I would hesitate to say that I approach my job first and foremost from a service ethic, I do probably put my team in department first as much as well. Yeah, but being constantly aware that you are a for profit company as much as we are the backbone of a lot of open source development at Heroku, we were the backbone of a lot of programming, teaching. So the ability to spin up free dinos for students to see their work was really important. But I think if you ignore the product direction, if you ignore what\u0026rsquo;s making money, if you can\u0026rsquo;t find some way to align the work you\u0026rsquo;re doing or help frame the work that other engineers are doing in the context of what is delivering value, and for better or worse, at a for profit company, that value is going to be tied to money in some way, shape or form. I think you\u0026rsquo;re going to be less effective.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s actually a pretty good segue to the next thing I wanted to ask, which is how do you decide what to work on?\u003c/p\u003e\n\u003cp\u003eAmy: That\u0026rsquo;s a tough question because I don\u0026rsquo;t think I have any formulated thoughts on it. For me, I think what I strive for is when I\u0026rsquo;m working across teams, I\u0026rsquo;m striving for working on the things that everyone thinks, oh gosh, we should have someone thinking about that, we should have someone working on that. But no one can because their role is shaped towards a different type of delivery than mine is. So I definitely limit the list based off of things that my role can do better than the other than if I were in a different role. But then, yeah, what is a higher priority and what isn\u0026rsquo;t within that? Because there are so many things that we\u0026rsquo;re just not getting to. I think some of that is a little bit of gut instinct. I definitely prioritize in my role, which is a little bit more tied to my director than to a product line. I am probably skewing a little bit towards the organizational and management challenges. This kind of role that works across teams. I\u0026rsquo;ve seen kind of two framings of the responsibility are either tied to a manager, which is true in my case, or you\u0026rsquo;re responsible for a product line, the technical delivery of a product line. And so if you know there are reliability issues, if there are, you know, if we didn\u0026rsquo;t address that tech debt and now we can\u0026rsquo;t deliver a feature in the timeline you expect because the code is full of way too many edge cases to make sense of, that\u0026rsquo;s your responsibility. If you are tied to a product line, I think there it\u0026rsquo;s. If you\u0026rsquo;re tied to a product line prioritization is based off of delivery of a great technical product to your customer. With a role that\u0026rsquo;s tied more to a manager. I think it\u0026rsquo;s a little bit harder to say a particular thing that I am aiming for, and that may just be my inexperience in the role. I was doing something similar to this, but kind of tied to both a product line and a manager at Heroku in this role is very crosses a bunch of different product lines. So I\u0026rsquo;m not sure I can tell you a formula for what exactly I work on, other than things that will make sure that my department continues to operate smoothly and that my director never has any surprises.\u003c/p\u003e\n\u003cp\u003eDavid: Would you say that your work is more oriented toward planning, training, recruiting and mentoring, or more toward guiding groups through sort of specific projects?\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, you know, I think that\u0026rsquo;s an interesting framing that I\u0026rsquo;m not sure either really applies. I guess I\u0026rsquo;d be curious to hear more about the distinction you\u0026rsquo;re trying to make there between those two models.\u003c/p\u003e\n\u003cp\u003eDavid: Maybe another way of framing it is like concretely what do you do in a week?\u003c/p\u003e\n\u003cp\u003eAmy: Sure. So my week generally starts with probably about maximum of two priorities or two deliverables. A selection of those might be getting together. Our department\u0026rsquo;s report for a monthly meeting that at Microsoft and GitHub is called Fundamentals. So that is basically how our engineering fundamentals doing from pages to tech debt to web performance, API performance security issues. I might be taking a look. Our department of 30 plus ICs has a shared on call rotation which means that things slip through the cracks in terms of process and knowledge sharing. So I might be working on something like that. A deliverable of writing up something to coalesce to last month\u0026rsquo;s incidents. A write up on here\u0026rsquo;s how you can tell that something\u0026rsquo;s gone wrong with Kafka, that sort of thing. I might be working on random tooling for the team that just doesn\u0026rsquo;t no one else can get to where I might be thrown a random fire like the one I referenced of hey we need something yesterday. Why didn\u0026rsquo;t you know about this? Let\u0026rsquo;s find a solution to unblock this feature launch. So probably deliverable of one of those things maybe a second and then pretty much a full day of meetings that are oriented towards I would say guidance and framing for managers. So my manager, the manager, each of the managers within our department and then the senior ICs. So rotating meetings trying to hear what their problems are help them frame technical issues, problem solve with who might be best suited to what with our senior ICs. That\u0026rsquo;s some of like what challenges are you having if you\u0026rsquo;re new to staff? Like, how are you adjusting if you\u0026rsquo;re senior in staff? What the heck is this weird thing we\u0026rsquo;re doing together? I don\u0026rsquo;t know. But let\u0026rsquo;s problem solve and then maybe a sampling of talking with our product folks just to get a little bit of an update. Then a half day of within that week, a half day of one on ones. I rotate through all of our ICs on a quarterly basis just to hear what they are working on and provide any context I can. When I was in a tech lead role, one of my measures for my own success was whether each of our ICs felt like they could draw a connection between the code they were writing and the technical strategy of the company. With 30 plus ICs, it\u0026rsquo;s a little bit harder to deliver on that universally. So quarterly as I can kind of framing like. Okay, well one of the reasons we might be framing our performance issues in this particular way because there are infinite performance metrics that we could deliver towards is because of X quality of our market.\u003c/p\u003e\n\u003cp\u003eAlex: Wow, that\u0026rsquo;s like an amazingly diverse set of things that you could tackle in any given week. That\u0026rsquo;s awesome.\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, it\u0026rsquo;s a fun challenge. I definitely enjoy it and love it. And I also think it speaks to the vast diversity of staff engineering roles that you can have once you get beyond the tech lead kind of position. There is a lot of freedom to look at what your skills are and what you can offer the company. And you know, you\u0026rsquo;re, you\u0026rsquo;re bringing to the table just as much as your manager brings to their boss an action plan. And part of the job is figuring out how you can best use your own skills for the business. And that leads to over so many different, wonderfully different, fascinatingly different answers for each and every one of our senior staff folks.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. You mentioned for a prior role, a set of measures of success. I\u0026rsquo;m curious, do you know what your current set of measures of success are?\u003c/p\u003e\n\u003cp\u003eAmy: No, I don\u0026rsquo;t. I am confident I\u0026rsquo;m hitting what my boss needs me to hit. But I do think that once you are in a role beyond technilead, you know, you\u0026rsquo;re bringing something to your own role, you\u0026rsquo;re bringing your own goals, you\u0026rsquo;re bringing your own direction. So I do have, you know, I have a 12 month set of 12 month goals I want to deliver for my department and each of those have metrics of success, but I haven\u0026rsquo;t yet. I mean, I\u0026rsquo;m six months into this job, so maybe it\u0026rsquo;s that. I also think some of it is being tied to a director. So I can kind of independently frame what success looks like if my responsibility is to a product line. But if my responsibility is to a director in a department and kind of an org, then it\u0026rsquo;s a little bit less under my control. But no, I don\u0026rsquo;t think so. And I think that\u0026rsquo;s something that is something I need to grow into.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Earlier you mentioned that you leaned more towards the organizational management and away from sort of tech or feature lines. Did I have that framing correctly?\u003c/p\u003e\n\u003cp\u003eAmy: Yes. In terms of responsibilities, there\u0026rsquo;s a model of staff engineer where you are the person for, let\u0026rsquo;s say, GitHub Actions. And if that\u0026rsquo;s not having success in the market for any technical reason, that\u0026rsquo;s on you. Yeah, that\u0026rsquo;s not my role. Currently it is. If my director isn\u0026rsquo;t happy, if our department isn\u0026rsquo;t succeeding, technically, that is on me.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. I was curious, is that like a conversation you\u0026rsquo;ve had with your director specifically, or is that just something you\u0026rsquo;ve. How do you know that that\u0026rsquo;s what you do?\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, it\u0026rsquo;s a job interview. My director was looking for someone to fill a role like that. I was looking to continue doing a role like that. And yeah, we were lucky, I think, to be able to. It\u0026rsquo;s rare that you hire externally for that kind of a role. I think it\u0026rsquo;s also somewhat rare to be on the market explicitly looking for that kind of role. Probably less rare than it is to have an opening, but it\u0026rsquo;s absolutely. It should be explicit, especially if you\u0026rsquo;re hired into it. If you\u0026rsquo;re promoted up, then yeah, maybe it\u0026rsquo;s a little amorphous. Especially so in my last job, my manager was tied to a product line. So my job was kind of in between. Personally, I think in that position where it\u0026rsquo;s kind of both. I mean, you can navigate both. I\u0026rsquo;m personally not going to navigate both. I like clarity. So for me, the choice is and always will be the product line and serving customers. First priority being not being a shitty human to my coworkers and the people that I am responsible to as an employee, but secondarily then to delivering an amazing product. And you navigate that with your manager by keeping them up to date on where you stand and if there is a disagreement working through that.\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned a couple times this example of. Typically, this is an example. I have no idea if this happened this week or not. But the example of like going to a team and saying, hey, like you know, you, you\u0026rsquo;ve basically dropped this deadline and the rest of the org needs it. Let\u0026rsquo;s make it happen. How can we make it happen? That type of scenario is one where like you\u0026rsquo;re trying to, trying to bring people along and you, you\u0026rsquo;re maybe representing some positional authority but you\u0026rsquo;re largely using your influence, right, to sort of, at least that\u0026rsquo;s been my experience. Do you have any, any sort of tactics that you use in those scenarios both for sort of navigating the maybe tough conversation of like addressing the problem and also like working together toward a solution and potentially sort of bringing together multiple teams that maybe, you know, oftentimes in these scenarios the reason something got dropped is because there, there was sort of not the right line of communication between those teams to begin with. So sometimes there\u0026rsquo;s a little bit of like patching up that needs to be done as well.\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, for sure. I\u0026rsquo;ll give a privileged answer first because I think if you are in a position where you can do this, it\u0026rsquo;s incredibly important make sure that your trade offs are the same ones that in a broad sense your organization is making. So it becomes incredibly difficult to navigate those conversations if you as an engineer fundamentally disagree with the pace of business, with the pace of taking on tech debt, or with the quality for however you defined quality, the quality of engineering being done. Obviously switching jobs is hard and I have been so lucky to have front loaded those kinds of conversations in my past jobs and be able to join a place where I am confident that kind of my comfort zone is somewhat similar to the ICs and managers that I\u0026rsquo;ll be directly working with. So I think it\u0026rsquo;s just a lot easier when you\u0026rsquo;re willing to make the same trade offs that folks around you are willing to make. For that reason, I think there would be a few very special small startups that I would love to be a part of. It\u0026rsquo;s going to be few and far between. My comfort zone is large, larger companies and if you know that about yourself, you\u0026rsquo;re going to set yourself up well. So then how do you handle those conversations? The first thing I think is important is to trust the people that you work with. If you trust your teammates first and foremost. So if they\u0026rsquo;re giving an estimate that is longer, push enough to understand why, but like it\u0026rsquo;s your job to go defend that. The next thing is to think about the risk that the organization is taking on by rushing work. And that\u0026rsquo;s usually how I frame whether it\u0026rsquo;s explicit or not. That\u0026rsquo;s how I frame any proposal or estimate that comes out of those requests. We can rush something. You\u0026rsquo;re going to be paying for that in terms of presume like a guesstimate of 20 tickets a week of whole series of security bugs and a compliance feature and just trying to frame those risks in terms of impact to the market. Most of the time you\u0026rsquo;re getting a rushed feature request because there is a need to deliver something to a customer. If it\u0026rsquo;s a security issue, then this calculus is very different. But there\u0026rsquo;s not much value in delivering a truly, truly broken experience to the market unless you\u0026rsquo;re under incredible financial duress and framing the trade offs, framing the risk that your team is taking on in terms of product risk that the business is taking on in order to deliver something that looks like what they promised. That framing can help make better choices about whether there might be other options, whether we can instead frame let\u0026rsquo;s say things I\u0026rsquo;ve seen. These are not GitHub examples. To be clear, things I\u0026rsquo;ve seen include okay, we acknowledge that there will be an extra support burden. We\u0026rsquo;ll bring over someone from support to write the docs for you and they\u0026rsquo;ll be like very specific. That only works if you can be explicit about the product failings. If you can\u0026rsquo;t be explicit about the product failings, then maybe it\u0026rsquo;s okay, well, we promised a public beta, but let\u0026rsquo;s say it\u0026rsquo;s a public ish beta where your public onboarding is like handheld. You get assigned a product manager. There is no chance that that customer will ever actually even reach support because they\u0026rsquo;re going straight to the PM who\u0026rsquo;s going to jump on a call with them and walk them through whatever BS we ended up shipping. And then there\u0026rsquo;s always moving a deadline. Right, to actually have allow the business the time to deliver an experience that\u0026rsquo;s going to work in the market as opposed to one that works for face saving. Ultimately, customers are not dumb and if you\u0026rsquo;re treating them like they can\u0026rsquo;t detect a bad product, then you shouldn\u0026rsquo;t be in the market.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. That\u0026rsquo;s a really great breakdown of how to have those conversations changing topics a little bit. Do you see sponsoring and mentoring as a part of your role?\u003c/p\u003e\n\u003cp\u003eAmy: Absolutely. I think it\u0026rsquo;s an interesting thing. It\u0026rsquo;s gotten a little harder as my role has been less involved with the day to day of shipping individual product features, but absolutely, I definitely see mentoring as a strong component of my job. I have struggled with formal mentoring. Mentoring for me is kind of just a scattering of folks that I have started infrequent one on ones with and we found them useful and we have kind of sped up the pace without any potential, any formal mentoring. I think one of the fun things about leaving a job is you can have some honest conversations. And I had some really lovely conversations as I was leaving my last job where we were like, hey, me, like, you did a really good job with the mentoring side of this. I\u0026rsquo;m like, oh yeah, I\u0026rsquo;m glad. Like, I\u0026rsquo;m glad you saw that and I\u0026rsquo;m glad that you felt that this was a mentoring relationship and not just like, I don\u0026rsquo;t know, something that I thought it was, but. But you didn\u0026rsquo;t. I struggle with formal mentorship programs and I don\u0026rsquo;t know how to do them and that doesn\u0026rsquo;t play to my skill set. So I will leave that to other folks. Sponsorship, however, is something that I very passionately and formally do. I think a lot of staff engineers get overwhelmed with the amount of work that they have on their plate. They may be able to prioritize, but prioritization doesn\u0026rsquo;t matter. If you\u0026rsquo;re not willing to make hard cuts, actually make cuts that feel painful. And so a lot of staff engineers get into a problem where they\u0026rsquo;re not thinking ahead enough to what they\u0026rsquo;re going to have to cut. And so by the time they have to cut something, they\u0026rsquo;re like, okay, well this is a hard cut. This still needs to get done for the department. How are we going to get it done? Okay, well we\u0026rsquo;ll pull this like mid level engineer. It\u0026rsquo;s a good growth opportunity. Well, what have you done there? You\u0026rsquo;ve added maybe three hours to your week of a one hour onboarding meeting, dropping context, an hour of slack chat sprinkled throughout the week, and one hour of reviewing whatever proposal they\u0026rsquo;re working on. So you end, you can very quickly end up in a place where you are delegating, not sponsoring. And delegation takes extra effort when you\u0026rsquo;re already underwater. So for me, I think about sponsorship as really anything that I\u0026rsquo;m working on. There should be someone who has the ability to take it up. I would say that\u0026rsquo;s something I\u0026rsquo;m not doing super well in my current role in part because the incentives are very much to alleviate burdens from the department. And so pulling someone in, in my past roles where I was a tech lead and then working on a product line is very clear. Like, okay, I will Just always have someone shadowing me for any given thing and we\u0026rsquo;ll just throw a little bit more at them as they come up to speed with my current role. There\u0026rsquo;s a lot of stuff that just. It\u0026rsquo;d be a burden to have someone on it and I don\u0026rsquo;t like that thinking in myself. But I also can\u0026rsquo;t justify the extra time. I think if I somehow disappeared from the company, a lot of the stuff, well, we\u0026rsquo;d kind of. It\u0026rsquo;d be in a good enough spot that we\u0026rsquo;d just amble along and it wouldn\u0026rsquo;t make as much progress. So it is definitely part of the role. I think it\u0026rsquo;s something that folks struggle with and I think when you get into some of the weirder variations of staff engineer, it\u0026rsquo;s unclear how much of it you should be doing.\u003c/p\u003e\n\u003cp\u003eDavid: That all kind of resonates with me. I\u0026rsquo;ve also struggled with formal mentorship programs at various points. I find the distinction between sponsorship and delegation and sort of the areas in between pretty interesting. I don\u0026rsquo;t feel like I have a good handle on them. But we\u0026rsquo;re almost at time and I want to touch on a couple other things before we break. One of them is just are there any people or resources that have influenced the way that you think about software engineering and staff engineering and sort of like everything that we\u0026rsquo;ve talked about today?\u003c/p\u003e\n\u003cp\u003eAmy: Yeah. I am horrible about written resources. Instead, I will say I have learned the most from other staff engineers who work at my company. Wherever I\u0026rsquo;m at finding the people who really think deeply about their role and just asking them about how they\u0026rsquo;re approaching their role and kind of sharing how I\u0026rsquo;m approaching my role and seeing where those differences are. I think you learn a ton about your weaknesses and strengths from seeing people who are in somewhat similar situations as you and. But are performing very differently if. If just as well, but just performing differently.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. So our final question. We hope it\u0026rsquo;s fun.\u003c/p\u003e\n\u003cp\u003eAmy: Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: Is how much time do you find yourself coding nowadays?\u003c/p\u003e\n\u003cp\u003eAmy: None. Absolutely none. I deployed my only meaningful production deploy. I have had a few PRs to tooling here and there. My only meaningful PR to production in six months was one that removed a bunch of if else statements in our HTML code from a. I believe it was a big push to do mobile better and it just never, never gotten removed. It was actually a pretty risky deploy because we don\u0026rsquo;t. It\u0026rsquo;s all verified by smoke testing. There\u0026rsquo;s. It\u0026rsquo;s really hard to write tests that are worth running in CI for every single deploy for every variation of every. Every mobile device. But yeah, it was literally just staring at if else statements and removing the, you know, if deprecated mobile client from 30 different. Well no, it\u0026rsquo;d be three. Three files. Probably about 30 different call sites.\u003c/p\u003e\n\u003cp\u003eDavid: Nice. That sounds, that sounds like staff work to me.\u003c/p\u003e\n\u003cp\u003eAmy: Sure. But it\u0026rsquo;s one PR out of six months, so. Yeah, I definitely, I think that if you\u0026rsquo;re uncomfortable with the amount of code you feel like you\u0026rsquo;re not writing, that\u0026rsquo;s either a moment to reflect on what makes you happy or and that\u0026rsquo;s a great conversation to have with your manager, or it\u0026rsquo;s a moment to reflect with yourself about what is the most valuable work you\u0026rsquo;re doing. And oftentimes the trade offs you\u0026rsquo;re making are that there\u0026rsquo;s just more valuable non coding work to be done and so long as you\u0026rsquo;re on the same page with your manager and other important stakeholders, then you are making the right call.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Yeah, that makes sense.\u003c/p\u003e\n\u003cp\u003eDavid: Amy, thank you so much for taking the time. It was really nice chatting with you today.\u003c/p\u003e\n\u003cp\u003eAmy: Yeah, for sure. That\u0026rsquo;s it.\u003c/p\u003e\n\u003cp\u003eDavid: Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website Podcast staffenge. Com. The website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-06-01T09:00:00-05:00","date_modified":"2021-06-01T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/brian-lawler-iterable/","url":"https://podcast.staffeng.com/season-1/brian-lawler-iterable/","title":"Brian Lawler (Iterable)","summary":"30 years of experience tells you a lot about, like when you're not ready to code something, right? And a lot of folks, especially younger folks, are going to. You're going to get the requirements, doc, whatever the design thing looks like, and you're just going to plow right into it and start coding. And it's important to know when you're not ready, it's important to be able to step back and say, you know what, I'm not exactly sure how I'm going to do this.","content_html":"\u003cp\u003eToday we welcome Brian Lawler, who is a Principal Engineer at Iterable! Brian has a load of experience with software architecture, having worked in the space for over 25 years, at a number of different companies and amassing a large amount of wisdom and expertise in the process. The rise of Iterable stands as a testament to the great ethos and community at the company and Brian generously shares a lot of insider info on how the teams and processes work. We get to talk about his specific role as it stands, his first period of employment at Iterable, and his thoughts on leadership style and problem-solving. Brian underlines the way they approach meetings and the feedback that follows before we hear how he divides his time as Principal Engineer. The conversation also covers how to keep a multidisciplinary organization in alignment, processes for flagging bugs, and the inextricable importance of mentorship in a company such as this. So for all this great stuff and much more from a seasoned pro, be sure to join us!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/bplawler\"\u003eBrian Lawler on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://iterable.com/\"\u003eIterable\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.accenture.com\"\u003eAccenture\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8498647-brian-lawler-iterable.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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, program, providing engineering perspective to the org, et cetera. My name is David Noel Romos and I\u0026rsquo;m joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, Brian Lawler is a software architect at Iterable. He\u0026rsquo;s been making Software for over 25 years. I\u0026rsquo;m excited for you all to hear this conversation with Brian. It sounds like he set up a great community at Iterable to foster the future of architecture. Let\u0026rsquo;s jump right in.\u003c/p\u003e\n\u003cp\u003eDavid: All right, well, Brian, thank you so much for taking the time to join us today. I\u0026rsquo;m really looking forward to chatting with you.\u003c/p\u003e\n\u003cp\u003eBrian: It\u0026rsquo;s my pleasure.\u003c/p\u003e\n\u003cp\u003eDavid: If we could start by just having you tell us who you are, what your background is, where you work now.\u003c/p\u003e\n\u003cp\u003eBrian: Well, my name is Brian Lawler and I have been working in the industry now for almost 30 years. Actually. I started in 1993 back in Chicago and I wasn\u0026rsquo;t actually an engineer to start with. I was. I actually started with Anderson Consulting, which is now Accenture. And so I was kind of a member of the Accenture army for a few years. So I wasn\u0026rsquo;t really an engineer per se. I was a consultant. Right. So they dress you up and trot you out to clients and then you do all that. The career path there was basically after four years, they. They decided that everybody was supposed to sort of progress into management at that point. So you had two years to sort of code for a while. You had two years to manage people who were coding for a while, doing small teams and then you progressed in the manager role. I got to about four years in and I was like, well, I\u0026rsquo;m not. I\u0026rsquo;m not done coding yet. I thought I was just starting to get good at it, actually. So my background, actually my degree is in electrical engineering. So it was close to computer science, but it wasn\u0026rsquo;t actually computer science. So I was just getting good at it and I wanted to stick with it. So I left Anderson and joined BEA Systems, which again, as a consultant, though not as an engineer yet. And it was more consulting, but it was more. It was a software company. Right. It wasn\u0026rsquo;t a systems integration company. And then there\u0026rsquo;s a whole bunch of time in between there that I won\u0026rsquo;t bore you with. But Basically there was a dot com happened in 99 and I quit BEA and joined a startup with X BEA people and moved out to San Francisco and stayed there for 20 years and now I live in Colorado. So I\u0026rsquo;m working at a place called Interbowl right now. Interbool is a. It\u0026rsquo;s a cross channel marketing company. We sell our product to marketers. Marketers are able to run marketing campaigns that span all the different channels. So email, sms, push in, app push, web, everything. So that\u0026rsquo;s where I\u0026rsquo;m at right now.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. And how would you sort of describe your role at Iterable?\u003c/p\u003e\n\u003cp\u003eBrian: At the moment my title is principal engineer. The interable story is kind of funny because I actually joined iterable in 2016 and then I left in 2018 and then I came back last year. So I\u0026rsquo;ve been there a year again now. When I came back, I came back on as a principal engineer. I wanted that the architecture role first. When I came in, the company had 30 people and I had 35 people when I joined and it was just basically a bunch of engineers in a huddle just trying to get stuff done and that was fine. But there were just things that I wasn\u0026rsquo;t really able to do that I wanted to do career wise. Right. So I wanted to. I wanted to make sure that was doing architectural things which. And we can get into what that means to me. But my role at Interval now is that. Right. Basically when I came back the company had grown so much that they determined that they really needed to have people that were not necessarily hands on the keyboard as much as they were making sure that the right things were happening. Higher level. Right. So that\u0026rsquo;s the role that I have right now in really broad strokes. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: What do you think the main difference is between a person whose hands on keyboard and the role that you want to tackle?\u003c/p\u003e\n\u003cp\u003eBrian: The interesting thing about problems that come up in applications are oftentimes it\u0026rsquo;s a bug and you\u0026rsquo;re one pull request away from a solution. A lot of times though, it\u0026rsquo;s not just a pull request. There\u0026rsquo;s a lot more at play. There are larger issues at hand and you can\u0026rsquo;t just go in and change a few lines of code that are wrong and hope that everything works right. You have to be thinking larger about the implications of doing things and what your scaling strategy is and stuff like that. So the difference is. And it\u0026rsquo;s hard to be that same person and do both Right. It\u0026rsquo;s hard to be thinking about the big picture and actually slinging code at the same time. You can do it, and early in the startup, everybody has to do it. But Itable now is pushing 400 people and the engineering. Org is getting really big. We can\u0026rsquo;t all just sort of be hoping that the right things happen architecturally. Right. So you need to have somebody who\u0026rsquo;s really trying to work at a higher level and make sure that stuff that is being considered is taking other things into account. And, you know, I do occasionally do some code and almost invariably it ends up being more complicated than we wanted it to be and that takes longer and it\u0026rsquo;s time consuming as things get more complex. So you can\u0026rsquo;t basically get to a size where you can\u0026rsquo;t focus on both.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eBrian: There comes a time where you have to be like, well, the best things for me, the best projects for me as an architect or as a principle, is when I can go to somebody and say, well, here\u0026rsquo;s these requirements. I don\u0026rsquo;t really care how you do it, but I need you to do these three things. There\u0026rsquo;s a couple of interface points, whatever. Their clouds are sort of cooling and planets are cooling and things are forming out there in the ether. I need you to be aware that those things are going to happen and we need to hook into those. And that\u0026rsquo;s the kind of thing that you really. You need to have somebody worried about that. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: Are there other principal engineers at iterable besides 12?\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, there\u0026rsquo;s. There\u0026rsquo;s one.\u003c/p\u003e\n\u003cp\u003eAlex: Do you feel like you share a set of expectations for what your role is in the company?\u003c/p\u003e\n\u003cp\u003eBrian: It\u0026rsquo;s funny because we were kind of the first two that have had the title technically. I mean, it was funny when I left. It was all sort of happening by Platoon. Right. It was sort of architecture by. It was just everybody was sort of contributing and everybody was. It was small enough and everybody was smart enough that the right things were happening. Now that I\u0026rsquo;m. And then I left and they grew a ton and I came back. I would say that it turns out that the two of us are actually. I think we have pretty different approaches to how we look at problems. And that\u0026rsquo;s kind of the way we end up dividing the work too. Right. So. And the way I would sort of delineate the way I think, the way the other guy thinks is that I\u0026rsquo;m sort of more facing the application developers and trying to make. Make it easy for them to understand a mental model for how they\u0026rsquo;re supposed to build an application. And he\u0026rsquo;s definitely more kind of on the. On the system side of really trying to squeeze the most out of the components that we have that we\u0026rsquo;ve chosen to optimize those for throughput. So it\u0026rsquo;s a pretty complementary setup at the end of the day. And I\u0026rsquo;ve talked to engineers who kind of appreciate having us both in the room because they\u0026rsquo;re both. They\u0026rsquo;re getting these different perspectives on how to address the problems.\u003c/p\u003e\n\u003cp\u003eDavid: How does the process work? What does the feedback loop look like? How do architectural requirements get identified? And then it sounds like there\u0026rsquo;s a process where you sort of describe them to other engineers and then they get implemented, and then presumably there\u0026rsquo;s some sort of iteration that happens there. Can you explain how that process works?\u003c/p\u003e\n\u003cp\u003eBrian: That\u0026rsquo;s an interesting presumption. You\u0026rsquo;re right. We\u0026rsquo;ve still been kind of formalizing the whole thing, you know, since I got back. Right. So we had this thing called the asg, which is the architecture support group. And historically, it\u0026rsquo;s just been kind of a place to just sort of come and bring a problem and maybe we\u0026rsquo;ll talk about it and figure out an answer. And we\u0026rsquo;re really trying to formalize it a little bit more at this point to make it part of the. So basically, if you consider the whole process, starting from product, with customer and product requirements, and going all the way through development and testing and deployment, we\u0026rsquo;ve gotten to a more kind of formalized place where we say, well, you want to bring this to the asg, right? And it\u0026rsquo;s not me telling them what to do. It\u0026rsquo;s they sort of bring this thing to the asg. And it could be anybody, see, engineer, staff, engineer we\u0026rsquo;ve had from all different parts of the engineering org, right? And they come and we\u0026rsquo;ve kind of made it a big deal to say, well, you\u0026rsquo;re going to come and present. I\u0026rsquo;ve got the presentation template. So I try to work with them ahead of time and say, well, here\u0026rsquo;s how the meeting usually goes. And we have, you know, we have a few dozen people in the meeting, right? So not everybody\u0026rsquo;s going to participate. But now that, you know, in virtual zoom, like, the conference room is infinitely big and you can come and go as you please. So I want to have as many people sort of experiencing the conversation and seeing the problem as we can. And that\u0026rsquo;s, you know, that\u0026rsquo;s becoming a more formalized thing, you know, so we go through that, and then the feedback is. We have sort of immediate feedback which is within the next couple of days, I go, I circle back with the presenter and I say, well, you know, what are your key takeaways from the meeting? Right. Did you get anything out of that? I send out surveys to everybody who was there and say, okay, well, the meeting was supposed to go like this. We were supposed to start at a high level and drive down to a lower level and get into the technical details and have a conversation. And I, I make sure to send the survey out afterwards to get a feel for how everybody. Did everybody get something out of the meeting? Can we do better? And then longer term, there\u0026rsquo;s also now more formalized process for me to circle back with the presenter and say, okay, here were the things we talked about, here were the decisions we made. If there are any decisions made, and then implementation starts and hopefully they\u0026rsquo;re at a point where they\u0026rsquo;re comfortable implementing at that point. Then I circle back later and say, okay, well, how, how\u0026rsquo;s it going? I mean, is it still look the same as it did? Did stuff change? What changed? Because we really want to make it. I mean, it\u0026rsquo;s a great point you bring up because we, we didn\u0026rsquo;t do this as formally before and you start to get disheartened a bit because you hate to have these meetings and you hate to pull all these people together and have these big discussions and then not have anything really come of it. So you really want to make sure that you do circle back and that people are. No, they can come back. I mean, sometimes you bring a topic back to the ASG and say, well, whoops, that didn\u0026rsquo;t work. Here\u0026rsquo;s what happened. What do we do now? So that\u0026rsquo;s. Yeah, that\u0026rsquo;s an important part of it.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting. Yeah. I think the ASG format is something that we\u0026rsquo;re going to want to dig into again later. But I\u0026rsquo;m curious just to sort of have a good mental model of what\u0026rsquo;s happening in those meetings. Can you describe, I mean, obviously to whatever level of detail you\u0026rsquo;re comfortable with, but like the types of problems that get brought to an asg?\u003c/p\u003e\n\u003cp\u003eBrian: Oh, well, let\u0026rsquo;s see. We have a data pipeline, you know, architecture that somebody. We don\u0026rsquo;t. If we don\u0026rsquo;t have a data pipeline, we\u0026rsquo;re going to get one. We need to talk about that if we\u0026rsquo;re going to integrate with an external provider to do whatever it is, the nature of the problems, it does vary quite a bit actually, because sometimes we talk about, you know, sometimes we even talk about incidents. Right. If there was a bad incident in Production, it\u0026rsquo;s oftentimes useful to. In this particular instance, I\u0026rsquo;ll break the incident down and maybe try and draw it out a diagram or something and then bring the whole group together and say, well, here\u0026rsquo;s the thing that happened, here\u0026rsquo;s the timeline. Because we have all that, you know, we have the timeline of the whole incident and all the discussions that were happening. If it\u0026rsquo;s a severe enough incident, that isn\u0026rsquo;t something that you\u0026rsquo;re going to fix with one pr, it\u0026rsquo;s almost automatically and architecturally, you\u0026rsquo;re almost required to pull it back around to a broader audience and say, well, here\u0026rsquo;s what happened. And basically the room is full of people who are experts in different parts of the application. Right. So we\u0026rsquo;ve got, you know, we\u0026rsquo;ve got a system and we\u0026rsquo;ve got a elasticsearch system and we\u0026rsquo;ve got all these different components and we have experts in the room that can sort of speak to what each of these things was doing at the time. Those are interesting. I haven\u0026rsquo;t done a whole lot of those, but some of them, sometimes people bring. I\u0026rsquo;ve actually brought and presented my own massive PR that I was doing that was kind of just a refactoring of something and just to explain to people, well, here\u0026rsquo;s, here\u0026rsquo;s what I did and I think this is important and I think we should all be doing it. So sometimes it\u0026rsquo;s more kind of an educational thing. So it really is kind of a wide open thing. I think the topics are more focused. What makes them interesting is the audience that\u0026rsquo;s there. Right. So because I know I\u0026rsquo;m going to have this audience, we have a set time every week, every Thursday, one o\u0026rsquo; clock in the afternoon. And I know that I\u0026rsquo;m going to get this group of people every Thursday. And we\u0026rsquo;ve kind of gotten to the point where that that hour has become important. People know that, well, I have to go to ASG now and they prepare for it and we go through this process and it\u0026rsquo;s good.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting. Pivoting a little bit to sort of like how you choose what you work on. You know, one of the things we talked to about two other engineers and staff plus roles is that they have a broad purview, like there\u0026rsquo;s lots of things that they could work on and then there\u0026rsquo;s always more things that they could work on than they could ever get to do. You sort of have a process for understanding what it is that you\u0026rsquo;re going to work on.\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, this is the Thing about Iterable. That\u0026rsquo;s really nice. And this is a kind of a big point about the whole staff. Eng StaffEng beyond thing is that you have to have good management for it to work. Right. And what I mean by that is if you don\u0026rsquo;t have management that actually values the role and has expectations of the role, then you aren\u0026rsquo;t going to have a process for figuring out what you\u0026rsquo;re going to do and you\u0026rsquo;re going to pick your favorite thing and you might be, you know, lost in the corner for three months trying to get that thing to work right. Or whatever. You know, I\u0026rsquo;ve gotten great on the management side. Just people who are very, very dialed into the importance of this type of work. And as far as what I\u0026rsquo;d end up doing is we also have these, you know, we have a very kind of elaborate process for our quarterly okrs. Right. So, and we talk about ahead of time, like, well, what are the priorities for the quarter and how are you going to measure it? All the stuff you\u0026rsquo;re supposed to do with OKRs, but everybody has to do that. Right. So I end up having objectives for the quarter that might be dialed into a particular project or this quarter. I\u0026rsquo;ve actually sort of worked with my and with my Director on getting OKRs around the efficacy of the ASG. I wanted to actually be measuring how well we\u0026rsquo;re doing at ASG because it was one of those things that was taking enough time where I didn\u0026rsquo;t want to have it just sort of be a time sink and not have any okrs attached to it.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eBrian: But on the project side, I\u0026rsquo;ve got a project that\u0026rsquo;s also on my list and I\u0026rsquo;ve only got a handful of OKRs. I have like four and three of them are related to ESG and then this other one\u0026rsquo;s related to this other project. And that\u0026rsquo;s great because now I\u0026rsquo;m on the hook every week to come back to the engineering leadership and say, well, here\u0026rsquo;s, you know, here\u0026rsquo;s how that project is going. So I know if I, if I\u0026rsquo;m getting sucked into other things, I\u0026rsquo;ve got something that\u0026rsquo;s pulling me back to the thing I\u0026rsquo;m supposed to be working on. Right. Those okrs are established beginning the quarter. We\u0026rsquo;re going through the process, you know, in the next coming month to, for the next quarter\u0026rsquo;s okrs and everybody\u0026rsquo;s going to sign off. They\u0026rsquo;re going to say, yep, that\u0026rsquo;s an important thing to do. You should be doing that. That\u0026rsquo;s been Great. But I have to say that the big point there, though, it\u0026rsquo;s bigger than just how I choose work, is the fact that if the management side of the House isn\u0026rsquo;t on board with the role of your staff or your principal engineers or whatever, you\u0026rsquo;re going to run into trouble. Right. Because you\u0026rsquo;re absolutely right. I could easily get sucked into any number of things that are interesting, you know, because I still like writing code. I mean, I still love clean compiles.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eBrian: When I. When the compile comes back clean. Oh, my God. I\u0026rsquo;ve been doing that since I was, like, 11. Right. So I\u0026rsquo;m talking, you know, it\u0026rsquo;s a long time. It\u0026rsquo;s like almost. And start writing code and click. A bio is still a very cool thing, and I still get a razz out of it, and I still like to be able to do it from time to time. But there\u0026rsquo;s other things that are more important.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, I want to touch on organizational alignment in just a second, but I was very curious. Would you be willing to share sort of the ways that you\u0026rsquo;re measuring the efficacy of your asg? Because that\u0026rsquo;s always a very sticky kind of thing to measure.\u003c/p\u003e\n\u003cp\u003eBrian: Oh, yes. I mean, it\u0026rsquo;s a bear. I mean, for us, it\u0026rsquo;s a question of. Basically, when I came in, it was a lot less formalized and there was less structure to the meeting. Right. So what I wanted to do as far as measuring efficacy was to say there are three things. Basically, it was like, one was audience. It\u0026rsquo;s an optional meeting. Nobody has to come. Right. And the question is, how many people are coming? And again, with zoom, it\u0026rsquo;s really nice because you don\u0026rsquo;t have to get a big room or small room. You just say, here\u0026rsquo;s the link, and come if you want. And I encourage people, come stay for 10 minutes if it\u0026rsquo;s not interesting, if you\u0026rsquo;re lost, you can leave. It doesn\u0026rsquo;t matter. It\u0026rsquo;s all zoom. But what I do is I measure. I measure how many people come, and I\u0026rsquo;ve got a target. And that target for this quarter is actually, I hope that 30 people come and we\u0026rsquo;re hitting that without a problem. That\u0026rsquo;s the one thing. The second thing is the survey that I send out afterwards. And the survey is only really about the structure of the meeting and the question. And it\u0026rsquo;s rated strongly Disagree. Strongly agree. 1, 2, 3, 4, 5. Did the speaker provide adequate context? Did the speaker dig down into the details, which is basically like, okay, is he doing a good job? He or she? Is he or she doing a good job of establishing context. What we\u0026rsquo;re talking about and then drilling down is the agree or disagree. If, you know, we then got into a technical discussion about the details and the last one is always like, did you learn something you didn\u0026rsquo;t know before that you can take back to your job? And that\u0026rsquo;s. I don\u0026rsquo;t really hold myself on the hook for actually teaching everybody in the meeting something they didn\u0026rsquo;t know before. But ideally, if the structure is right and we\u0026rsquo;re starting in a broad context and we\u0026rsquo;re narrowing down and then we\u0026rsquo;re talking about details, anybody that\u0026rsquo;s interested in being that meeting, in that meeting is going to be learning something they didn\u0026rsquo;t know before. And that hopefully what I really want is to be reinforcing the right architectural ideas so that when they go back to their desk, even customer success people in there, not just engineers, right? We have other people, product people, customers. I want them to go back to their desk and just have in their head just a slightly more refined idea of what architecture is, how these things work and things you need to be considering when you\u0026rsquo;re talking about changes. So that\u0026rsquo;s the measure. So there\u0026rsquo;s basically the count of people, there\u0026rsquo;s the survey, and then the last thing is the follow up. I\u0026rsquo;ve got three follow ups that I want to do for each asg, but that takes time. But it\u0026rsquo;s the immediate follow up from the presenter. We also like to track in jira, you know, if it\u0026rsquo;s, if it\u0026rsquo;s an epic they\u0026rsquo;re working on and presenting on. I want to have a JIRA ticket that links back to the notes in the presentation from the asg that\u0026rsquo;s part of the historical record for the thing. And then the third thing is just. Okay, and this is a reminder to myself to go back later and make sure that we\u0026rsquo;re looking at the results of the thing and seeing if it still matches up with the thing that we talked about in the beginning. So that\u0026rsquo;s cool. Number of people, effectiveness of the meeting and follow up are the three things that we\u0026rsquo;re measuring.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s really interesting. So like, sort of my mental model here that I\u0026rsquo;m thinking through is like, if you bring people to this meeting, they\u0026rsquo;ll become more aware of architectural practice, making sure that the fit is right for your company and what you need to do and hopefully that would flow into more appropriate architecture. And I\u0026rsquo;m curious that last that outcome, is that something that you sort of feel? Is there an explicit thing that you\u0026rsquo;re looking for.\u003c/p\u003e\n\u003cp\u003eBrian: Well, you know, it\u0026rsquo;s one of those things where we have a particular project that is happening right now that\u0026rsquo;s, it\u0026rsquo;s really like a big refactor of something that was done really badly before. So in that case, it was great to see the engineer brought this design and it was just such, such a better design. First of all, it\u0026rsquo;s so great. I was like, okay, this is fantastic. And in the course of his presentation, he was sort of referring back to things that, that I\u0026rsquo;ve been talking about since I rejoined the company. So he was very clear about like, these are ideas that are, they make sense to me. They\u0026rsquo;re. They\u0026rsquo;re good common sense things to do. I went and I reread some more stuff about those things and just to make. I wasn\u0026rsquo;t making it up, right. These are good ideas, stuff about cohesion and things like that. So in that particular instance, it\u0026rsquo;s going to be very easy to circle back and say, okay. Because the great first thing that happened was he\u0026rsquo;s obviously taken to heart the things that I think are important in code. Right. And he thinks they\u0026rsquo;re important in code too. Anything. My job was just to make it to provide sort of a, some type of leadership in that area that says, if you\u0026rsquo;re thinking like this, it\u0026rsquo;s the right thing to do, please keep thinking that way. Right. Instead of worrying more about schedules, it\u0026rsquo;s just evident the way that was done before was a very schedule driven answer. So, yeah. So the follow up on that particular. In that case is going to be really easy to say, okay, this is fantastic. This is so much better than it used to be. And that\u0026rsquo;s an easy one. Some of these bigger things that run into scaling problems and stuff that gets a lot more tricky to diagnose on the whiteboard and those are more likely to actually kind of circle back through ASG again. If we kind of roll it out and see that it\u0026rsquo;s not working great, we may have to look at that again. But the great thing about asg, and this was one of the things that when I first was coming back, the CEO was talking with me about, is just my words, not his. I mean, basically these designs should pass the whiteboard test. I mean, if you can draw it up on the whiteboard and it doesn\u0026rsquo;t pass the whiteboard test, right? If you can look at that and say, nope, that\u0026rsquo;s not a good idea. Because a lot of times the design looks fine and then when it hits production, something goes crazy. But sometimes it doesn\u0026rsquo;t even look good on the whiteboard, you know, so that\u0026rsquo;s another thing that we just want to. We want to be able to stop that right at the beginning and say, okay, we\u0026rsquo;re not ready. And that\u0026rsquo;s a big thing too. I mean, about this, about the experience. I could go on for days about this stuff, but 30 years of experience tells you a lot about, like when you\u0026rsquo;re not ready to code something, right? And a lot of folks, especially younger folks, are going to. You\u0026rsquo;re going to get the requirements, doc, whatever the design thing looks like, and you\u0026rsquo;re just going to plow right into it and start coding. And it\u0026rsquo;s important to know when you\u0026rsquo;re not ready, it\u0026rsquo;s important to be able to step back and say, you know what, I\u0026rsquo;m not exactly sure how I\u0026rsquo;m going to do this. I better get out pencil and paper maybe, or the whiteboard and just think about it some more before I get into it.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, it\u0026rsquo;s really interesting to hear about the ASG and how it impacts the culture. Going back to organizational alignment, it was really interesting to hear that you talked about how the managers had a really good understanding of what they wanted to communicate and what they wanted from you. I\u0026rsquo;m curious, have you ever been in a situation where the visions don\u0026rsquo;t necessarily line up and in that situation, what do you do to impact sort of like the okrs or the outcomes of those sorts of decisions?\u003c/p\u003e\n\u003cp\u003eBrian: You\u0026rsquo;re saying that is there a time when the management alignment wasn\u0026rsquo;t the case?\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Well, you know, I think one of the things we see with staff plus engineers is that they\u0026rsquo;re free to see things in a different way for managers. And that\u0026rsquo;s really powerful in an organization to allow two different groups of people to have different perspectives. And it\u0026rsquo;s in that sort of creative collision that like the best. And so I\u0026rsquo;m curious, you know, when you have a different sort of perspective on things, how do you make sure that it meshes with management?\u003c/p\u003e\n\u003cp\u003eBrian: It\u0026rsquo;s certainly on me to convince people because more often than not, it\u0026rsquo;s not that management has an idea and I have a competing idea. It\u0026rsquo;s just that I have a very refined idea and they have a set of requirements they\u0026rsquo;re trying to meet. Right? So if management\u0026rsquo;s saying, I don\u0026rsquo;t care how it works, but I know I need to support 100 million users and I need it, it needs to work this fast and I need it by, maybe that\u0026rsquo;s a set of requirements that are not the currency that I deal in. Right. So I\u0026rsquo;m more trying to think longer game about how this stuff\u0026rsquo;s going to work. Really. The question is then to what extent does the organization adopt these? Whatever my truth and beauty is over here versus the reality of how things actually need to work for the business to succeed. And ideally what\u0026rsquo;s going to happen is that if that aligns early, early on in the company, then that\u0026rsquo;s great and that\u0026rsquo;s your culture to start with. I would say that Interval is a company that\u0026rsquo;s been wildly successful at moving very, very quickly and growing very, very quickly. And things occasionally they\u0026rsquo;ll burst at the seams because of it. Right. So now we\u0026rsquo;ve gotten to a point where we do need to sort of step back a little bit and kind of agree on what the right path forward is. And my job is to, you know, to educate to an extent and to convince people that here\u0026rsquo;s a vision, here\u0026rsquo;s a way to go, here\u0026rsquo;s how we should do it. It\u0026rsquo;s going to take a long time, it\u0026rsquo;s going to be a lot of work, we have a lot of code that we need to go back and revisit. But it\u0026rsquo;s my job to convince the management that that\u0026rsquo;s the right way to do it. And I have to keep in my mind too some of their stuff. Right. So I can\u0026rsquo;t go dark for two years and recode the thing. Right. That\u0026rsquo;s just not an option. Right. So you got to be realistic about that. So it\u0026rsquo;s really on me kind of to come up with the staff engineers too, to come up with a longer term vision that says, well, here\u0026rsquo;s where we want to get to and you know, let\u0026rsquo;s not really talk about how long it\u0026rsquo;s going to take yet, but where are we today? How far are we away from that today? So we\u0026rsquo;re a very long way away from that today. How do we get there incrementally? It\u0026rsquo;s almost like more of a sales thing for me, having to sell an idea to the management about it and they might buy it and they might not buy it. That\u0026rsquo;s kind of par for the course. But if I think it\u0026rsquo;s drop dead important to do a certain thing, it\u0026rsquo;s great to have management that will, if these managers and directors and the vp, they\u0026rsquo;ll set up a process for going through that and saying, well, we need to talk about this. We\u0026rsquo;re going to have a few meetings, we\u0026rsquo;re going to hash this out and we\u0026rsquo;re going to come up with a decision that we\u0026rsquo;re all behind. So I\u0026rsquo;ll come at them with my whatever egg heading technical stuff I want to bring to it. I just need to bring to it enough to say, well, this is important, here\u0026rsquo;s why it\u0026rsquo;s important, here\u0026rsquo;s what this change or this different approach is going to enable and here\u0026rsquo;s how we can do it. It\u0026rsquo;s either an easy sell if they buy into that because most of these guys used to be engineers too, so they sort of know what I\u0026rsquo;m talking about, or it\u0026rsquo;s not an easy sell and then we have to compromise, right? We say, well, we can do part of that, but we just don\u0026rsquo;t have the time or the money or the whatever to do that whole. To do that whole thing. So. So it\u0026rsquo;s not really a conflict. I wouldn\u0026rsquo;t say as much as it is a sale, education process and sales process.\u003c/p\u003e\n\u003cp\u003eDavid: I think framing it as a sales process is kind of interesting. Alex and I have observed often that staff folks sort of have experience outside of just being a senior engineer in a big organization. And that can often involve working in startups or driving open source projects or in your case, I\u0026rsquo;m sure your experience as a consultant has kind of framed some of the ways that you propose changes to management and probably to peers or to the teams that you work with. I\u0026rsquo;m curious at a tactical level, what does it look like when you sort of, let\u0026rsquo;s say you need to flag a problem that you see and you want to make sure management is aware of it. What\u0026rsquo;s sort of the first thing you do? Is it Slack message? Is it a phone call? Is it a Google document? Like, how does it work?\u003c/p\u003e\n\u003cp\u003eBrian: I would imagine at this point in time that Slack would be the number one way to do it, but chances are that the things that I would flag of that sort that you\u0026rsquo;re talking about are probably more things that are not a surprise to anybody. I mean, this is like, if anything, the things that come up for me the most often are. Here was an incident that we had and here is my take on what\u0026rsquo;s going on there, right? So it\u0026rsquo;s not like I\u0026rsquo;m surprising anybody with, oh, by the way, you know, this crazy thing happened. It\u0026rsquo;s something we all know happened, right? So even without Covid, I\u0026rsquo;m remote anyway. So I\u0026rsquo;m pretty much like, I\u0026rsquo;m on Slack. I like it there because I do like that style of communication because it is kind of immediate, but it\u0026rsquo;s also kind of asynchronous. And it\u0026rsquo;s also, you have the history of it. Right. So that\u0026rsquo;s how we generally do it. And if it\u0026rsquo;s, you know, if it\u0026rsquo;s a big deal, it might immediately turn into a meeting. If it\u0026rsquo;s not as big a deal, it might turn into an ASG or less. Right. Just kind of depends. But yeah, that\u0026rsquo;s certainly the. It\u0026rsquo;s funny, I never call anybody. I don\u0026rsquo;t talk on the phone anymore. That\u0026rsquo;s. I\u0026rsquo;m done. I\u0026rsquo;m done with the phone.\u003c/p\u003e\n\u003cp\u003eDavid: It\u0026rsquo;s funny, I didn\u0026rsquo;t include as an option walking up to people\u0026rsquo;s desks because Alex and I are also remote, I think. I mean, everybody\u0026rsquo;s remote nowadays, but I\u0026rsquo;ve always been remote.\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, I think it\u0026rsquo;s, you know, it\u0026rsquo;s great. I mean, it\u0026rsquo;s just from being able to focus and things. I also find that like. And this is kind of a bummer about. This might be just particular to me, but when I\u0026rsquo;m bringing these ideas, it doesn\u0026rsquo;t always lend itself well to a conversational format because the ideas are bigger. Just like sometimes problems are bigger than a pull request. Sometimes ideas are bigger than a back and forth conversation. Right. I gotta. I mean, I\u0026rsquo;ll go and. I\u0026rsquo;ll go and make a deck. I\u0026rsquo;m very visual. I like to draw diagrams. I like the feeling that people can look at the diagram and come away with something in their head that actually like. So they can start drawing conclusions on their own about the way something works. Right. So, yeah, I\u0026rsquo;m really into the educational aspect of the whole thing. Right. And that\u0026rsquo;s. That\u0026rsquo;s kind of a big deal. Another thing, this isn\u0026rsquo;t really what you asked, but that I think is interesting is that earlier in my career I kind of assumed everybody wanted to aspire to be an architect. I always assumed that everybody, everybody wanted to draw pictures and everybody wanted to be thinking about itself. It\u0026rsquo;s kind of important to realize that that\u0026rsquo;s not necessarily true. I mean, there\u0026rsquo;s plenty of people out there who really just like solving problems, detailed problems in code. And those are important people to have. And especially if they really like doing it, they really like doing it at a high level for many years. That\u0026rsquo;s a great person to have around. Not everybody wants to do this and not everybody would be really good at it. Right. Not everybody\u0026rsquo;s necessarily good at putting it up on the whiteboard or explaining it in terms of dumbing it down, but you almost want to sometimes just draw things back to a more kind of visual representation of what the solution looks like so that people understand. Oh, ok, okay. That\u0026rsquo;s why that happened. Maybe next time I talk to the customer we can I have this better understanding of what\u0026rsquo;s going on. So that to me is kind of one of the most fun parts of the job.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that\u0026rsquo;s really interesting. Actually. The insight that you just described about realizing that sort of not all folks have the same aspirations that you do was a pivotal realization in my career as well. In hindsight it maybe seems kind of obvious, but I think we often sort of think about groups and make the assumption that everyone wants the same thing and actually usually that\u0026rsquo;s not the case.\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, I\u0026rsquo;m not the best developer at Iterable. I mean, that\u0026rsquo;s for sure.\u003c/p\u003e\n\u003cp\u003eDavid: Oh yeah, no, I\u0026rsquo;m definitely not the best engineer among my peers either. I think that\u0026rsquo;s actually pretty common with a lot of the staff plus folks we talk to. People say I am not the most technically proficient person in the room, nor am I sort of supposed to be. One of the things that\u0026rsquo;s interesting about staff plus roles is that, and you mentioned it earlier, sort of there\u0026rsquo;s this requirement to lead, but there\u0026rsquo;s not, there\u0026rsquo;s not the role based authority that comes with it. You lead by influence. And I imagine in the, I know that the, in the case where you\u0026rsquo;re trying to drive an architectural refactor or you\u0026rsquo;re trying to help someone else drive an architectural refactor, you\u0026rsquo;re often going to be dealing with multiple stakeholders, probably multiple different engineering teams that have different. Their compass is bent in different directions, they have different priorities. Right. And so how do you approach that? How do you sort of get people aligned on the architectural change that you think needs to happen, even if it doesn\u0026rsquo;t directly match up with everybody\u0026rsquo;s short term goals?\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, I mean I think the first thing that\u0026rsquo;s really, can be really hard to do is to just kind of read the room, right. And figure out, well, how far off am I from what other people actually think needs to be done? Right. So you know, if I\u0026rsquo;ve got an idea about something and the other thing that usually happens with my ideas, I mean it\u0026rsquo;s taken me, like I said, it\u0026rsquo;s taken me a long time to get to this point. Right. So I\u0026rsquo;ve got a lot of experience for better or worse and most of my ideas that I struggle, that I hold most strongly are things that I\u0026rsquo;ve actually done. And most of the things I\u0026rsquo;ve actually done, I\u0026rsquo;ve messed it up at least once and then I got it right. I feel like I can come at these conversations with a very empathetic view of both sides of the table. Right. I said, I know what you\u0026rsquo;re saying, you want to do it that way. I know why you want to make a new ORM system. I\u0026rsquo;m going to tell you why that\u0026rsquo;s not going to work. Whatever it is, all kinds of stuff like that. So, so really it\u0026rsquo;s the first thing you do is you come to people and. Because maybe they haven\u0026rsquo;t even. This is kind of the same thing as the management question. They might not even have a very solidified idea about what they want to do and I might just have a more solidified idea. And then when I tell them, they\u0026rsquo;d be like, well, wait a minute, does that mean I have to do this, that the other thing differently than I used to? And then again it\u0026rsquo;s back to me to say, well, yeah, but here\u0026rsquo;s what you\u0026rsquo;re going to get if you do that. It\u0026rsquo;s very helpful to be able to kind of just read the room and understand how far off we are from being, because we might not even be that far off at all. It\u0026rsquo;s just that I\u0026rsquo;ve got a more refined idea about what we need to do than you do. Or we might be way off, in which case there are certain arguments that I don\u0026rsquo;t really want to have that much anymore. I mean, back end code I think should be compiled, it shouldn\u0026rsquo;t be interpreted. And that\u0026rsquo;s just kind of my own thing. That\u0026rsquo;s one of the things that I kind of am adamant about. That\u0026rsquo;s not really a conversation we have to have that often in interval or a scholarship that\u0026rsquo;s kind of, that\u0026rsquo;s done.\u003c/p\u003e\n\u003cp\u003eDavid: If you can\u0026rsquo;t compile it, how are you going to get a clean compile?\u003c/p\u003e\n\u003cp\u003eBrian: Right. But you know, generally speaking what you find is that especially with refactors, people have probably roughly the same idea and it\u0026rsquo;s, and it\u0026rsquo;s amazing how often that you really do end up having very similar ideas as people. It\u0026rsquo;s just that you haven\u0026rsquo;t really sat down and talked at, through to the level of detail, to the same level of detail to the point where it actually happens. So that\u0026rsquo;s, Yeah, I mean, it\u0026rsquo;s, it\u0026rsquo;s kind of an empathy thing. It\u0026rsquo;s kind of a, you know, I, I, you know, I definitely want to, I want to listen first and then try and say, well, to figure out where we are and how different we are from where we need to be and take it that direction. Interesting.\u003c/p\u003e\n\u003cp\u003eAlex: Outside of things like the asg, outside of sort of like your role as, like, architect, do you see things like sponsoring mentoring as a part of your role?\u003c/p\u003e\n\u003cp\u003eBrian: Well, I mean, it\u0026rsquo;s hard not to. We don\u0026rsquo;t really have a formalized program for that right now. If you\u0026rsquo;re going to be around as many engineers as we have, you know, we\u0026rsquo;re up to several dozen engineers, and they\u0026rsquo;re of varying skill levels and varying experience levels. You really have to take seriously your role as a mentor in this situation. When you see people doing things that you know are just not good ideas, you have to pick that out and say, well, I see what you\u0026rsquo;re doing. Here\u0026rsquo;s probably a better way you could go about doing that. Or if it\u0026rsquo;s really bad, you say, absolutely, do not do that. Do it this other way, or whatever the situation is. Mentoring is kind of. It is a big part of it. And if anything, I keep coming back to this. But after doing this for so long, right, after 30 years of doing this, you see the same patterns over and over again, and you see the same archetypes, right? You see the same types of people coming through, and you can kind of pick them out pretty quick. And some people, you know, some people you can see. Well, they probably, I think they do want to be an architect and they do want to aspire to that next thing. And. And they do have the communication skills and things to do that. And some people, you have to know. No, they don\u0026rsquo;t. But let\u0026rsquo;s just try and mentor them and get them further on their path that they\u0026rsquo;re going. But again, there\u0026rsquo;s nothing really formal about it. I\u0026rsquo;m not a people manager, obviously. I\u0026rsquo;m still an IC technically, but I do have conversations with folks about, like, career wise, like, you know, what\u0026rsquo;s the next step and how would I go about doing this? And ASG is great for that, actually. It\u0026rsquo;s a great venue for people who obviously are wanting to level up, even, you know, from junior engineer, senior engineer to staff engineer. And that\u0026rsquo;s a great venue for it. Right. Because it really is a opportunity to present about your problem and to learn about presenting and to learn about communicating with issues you\u0026rsquo;re running into and where you want to go. So if there\u0026rsquo;s anything formal about our mentoring program, it\u0026rsquo;s that I\u0026rsquo;m very ready and willing to help anybody with their ASG presentations beforehand and. And to give them some feedback afterwards. That\u0026rsquo;s cool.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Outside of, like, direct Intervention or, you know, one off. Do you like have any sort of like process for helping someone level up or sort of like help them gain a new perspective or anything?\u003c/p\u003e\n\u003cp\u003eBrian: Again, I\u0026rsquo;ll go back to the management side of this. One thing that we\u0026rsquo;ve been working on at Iterable is just really being crystal clear about the expectations for each role. And crystal clear that just because you\u0026rsquo;ve been here for four years doesn\u0026rsquo;t mean you\u0026rsquo;re automatically going to the next role. Right? I mean, basically I have another roll up, right? I could become a. Whatever it is, a distinguished. We don\u0026rsquo;t have principles as high as we have right now. There\u0026rsquo;s two more roles up. But I look at those personally look at those requirements and say, well, do I really want to do that? Right? I mean, if it\u0026rsquo;s getting away from the office and doing more conferences and thought leadership outside the company, is that something I really want to do? So it\u0026rsquo;s the same thing for Levels coming in junior all the way up to principal and this is a recent thing, we just sort of got those kind of published last quarter. So that will be my process for saying, okay, well, even for assessing, you know, we do this 360 reviews, whatever, six months it is, or where you say it\u0026rsquo;s great to have those expectations in your hand so you know that this person actually meet these expectations. It\u0026rsquo;s very helpful to be able to refer to a document like that. So my process will be like, well, if this person is performing at the level that you know that they\u0026rsquo;re at. First of all, because the job requirements came after most people got their roles, right? So we were sort of superimposing them on top. But you really want to make sure that now that we all have our positions and we all have our expectations that people are kind of meeting those things. And my opportunity to do that is pretty much, you know, and part of the expectations actually involve asg. Are you an active participant in asg? Do you bring your expertise and spread it around to people who are coming and presenting on areas that they\u0026rsquo;re maybe new to? So yeah, so that\u0026rsquo;d be my role. A process such as it is, it\u0026rsquo;s not a very formalized process, but we all have very clear expectations about what we\u0026rsquo;re supposed to be capable of doing. That\u0026rsquo;ll be a critical part of it.\u003c/p\u003e\n\u003cp\u003eDavid: It sounds like Iterable is sort of in the phase where, I mean, you\u0026rsquo;ve recently sort of refreshed your career ladder, as you mentioned, and there\u0026rsquo;s sort of maybe not roles that are in the process of being defined, but roles that have been freshly defined. And you also mentioned that you, you were at iterable and then you left and you came back. Is it safe to assume that you were a staff engineer at arable before you were a principal?\u003c/p\u003e\n\u003cp\u003eBrian: Was I a staff engineer? It\u0026rsquo;s funny, it kind of depends on how you, on who you ask. I didn\u0026rsquo;t feel like it. I didn\u0026rsquo;t feel like it because again, when I left, I felt ineffective when I left. And my ineffectiveness was that I wasn\u0026rsquo;t as good at the, at understanding the code that was there. I mean, I was coding, right? So I was, I was trying to solve incidents. I was trying to make things better, but I wasn\u0026rsquo;t the best at it. That was like the value chain at that point was like, you know, the people that the heroes were the ones that were good at fixing the problems right now. And I didn\u0026rsquo;t feel like that person. So if there was a career ladder at interval at that point in time, then the staff level person was the one who was going to be able to fix things and when they broke, got it. And I was aspiring to that, but I wasn\u0026rsquo;t getting there. And, you know, part of the frustration that led me to leave in the first place was that I didn\u0026rsquo;t feel like I was being very effective at affecting changes that I knew needed to happen, but I was unable to do it because I wasn\u0026rsquo;t quite the level of these other folks that were fixing problems as they happened and making things work. I didn\u0026rsquo;t mean to have a complicated answer to that question. I mean, I, you know, if you looked at my resume when they hired me, I would probably say I would expect that they would have hired me and its staff.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah.\u003c/p\u003e\n\u003cp\u003eBrian: But they didn\u0026rsquo;t really have it, so.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. I guess another way of framing my question maybe is like, how do you think of the difference between the staff level and the principal level? I\u0026rsquo;m curious how iterable frames it in general, but I\u0026rsquo;m also curious sort of how you think about it and how you would describe your progression from sort of from senior engineer through to where you are now.\u003c/p\u003e\n\u003cp\u003eBrian: Well, I mean, you know, it\u0026rsquo;s. It\u0026rsquo;s part of coming to the realization that you might not code and that you might actually have and that there is a need for that. Right. And that you\u0026rsquo;re able to then kind of go up and fill that need. Right. Of identifying maybe sequencing projects. Right. Doing one thing before another thing is a broad enough, you know, high level enough decision that has to be made that you become better at making. Right. So you become sort of, you know, the big challenge with any startup and any significant software project is I think most people understand how to come up with like where you want to be in five years or what their goal is for the thing. But man, that bridge from here to there is really, really hard to come up with. Right. Especially if you\u0026rsquo;re looking at a five year plan and you\u0026rsquo;re saying, what am I supposed to do next week? And the task that you\u0026rsquo;re doing next week seems so insignificant as far as like where you want to get to. Coming up with that vision is a different skill set than writing the code. So, you know, for me, that became pretty clear that I enjoy doing that. Again, I still enjoy coding, but I also enjoy doing that and then just sort of finding yourself in a situation where you\u0026rsquo;re in a company that needs it, which Iterable kind of restructured themselves into that after I left. So that\u0026rsquo;s what they want from me and that\u0026rsquo;s, that\u0026rsquo;s what I want to provide. So.\u003c/p\u003e\n\u003cp\u003eDavid: No, I think actually I really like that answer because the one insight that I pulled away from that was this idea of like that defining the path ends up being sort of more valuable than defining the vision a lot of the time. I think that\u0026rsquo;s something that I\u0026rsquo;ve observed as well, is that there\u0026rsquo;s a lot of smart people in our industry and most of them are capable of drawing a picture of where we want to end up. Right. But the challenge is always sort of mapping that to where we are now and how do we gradually move the pieces around? You know, the analogy that I always like to use is turn the car into an airplane while it\u0026rsquo;s running.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eBrian: Right.\u003c/p\u003e\n\u003cp\u003eDavid: And so, yeah, I think that resonates really strongly with me. We\u0026rsquo;re almost at time. There\u0026rsquo;s a couple of things that we always want to cover with folks before we, before we stop. First of all, are there any resources that you found valuable or that you would refer other folks toward who are sort of interested in understanding more about what it means to be a staff engineer or a principal engineer?\u003c/p\u003e\n\u003cp\u003eBrian: Wow. I can\u0026rsquo;t tell you that I read a book and that it made everything clear. Unfortunately, my path has been long to get here, so experience to me is kind of more the thing really. Just what\u0026rsquo;s a goofy thing to say? It\u0026rsquo;s kind of goofy to think that you\u0026rsquo;re. You have to listen to yourself. But like, if you find yourself doing these things where you\u0026rsquo;re Sort of where you are drawing the pictures and you are interested in. I mean, basically the reason, the only reason I ever even considered the other path into management. Well, first of all, that\u0026rsquo;s very well documented path, right everybody. There\u0026rsquo;s a million books about that. And what happens after 10 years or 15 years if you get a manager where you\u0026rsquo;re like, you know what? I think I can do a better job at that. And then maybe you try it and maybe you like it and you stay there and maybe you don\u0026rsquo;t like it so much and you go back to the other thing. I would put myself in the latter camp and that was just. Yeah, it was really just a matter of like deciding that it wasn\u0026rsquo;t something I like to do the other thing and that this thing was going to be the thing that I wanted to do. But I. Yeah, I hate to say it, but there aren\u0026rsquo;t really any, any books I would suggest for that. The big thing though is you really just have to be. You have to keep learning, right? You have to just keep on learning stuff. If you really like to code and you want to keep learning code, you know, I keep. I mean, Scala is funny to me because I\u0026rsquo;m still learning Scholar. I\u0026rsquo;ve been trying to learn Scala for 10 years now. There\u0026rsquo;s always something more to it that I learn later. Oh my gosh, this is amazing. Again, that\u0026rsquo;s what I enjoy. So I mean, just learning in that direction and. But there\u0026rsquo;s nothing specific about being staff plus that I would say, sorry.\u003c/p\u003e\n\u003cp\u003eAlex: No, that\u0026rsquo;s fine. What we\u0026rsquo;re finding is that it\u0026rsquo;s not well defined. Right. Even though the book that Will Larson put out Staff in just feels very novel still.\u003c/p\u003e\n\u003cp\u003eBrian: Yeah, yeah.\u003c/p\u003e\n\u003cp\u003eAlex: So the last question we like to ask folks is hopefully a fun question. How much time do you find yourself writing code nowadays?\u003c/p\u003e\n\u003cp\u003eBrian: Actually it comes in bursts, it turns out, so I couldn\u0026rsquo;t give you a percentage per month or week or whatever. Last week we had a hack week, so I spent more than eight hours a day coding last week, which was wonderful. And it was an idea that I\u0026rsquo;ve had for years so that it was a great together group of people around it. We delivered a hack and hack week over the summer. There was a couple of projects that really required like full time attention. But I would say probably in the normal steady state of things, I probably don\u0026rsquo;t code at all. I mean, I review code, but when it comes to just keeping things straight as far as the ESG goes and everything else, there\u0026rsquo;s no code involved with that I\u0026rsquo;m trying to not get into it, because, like I said, once you get into it, you\u0026rsquo;re. You\u0026rsquo;re sucked in and then you\u0026rsquo;re putting more time into it than you really intended to. So I try not to spend a lot of time coding at all. You know, honestly, too, is the other thing is that sometimes there\u0026rsquo;s something that kind of needs to be done. It would be good to have it done, but nobody, everybody else is doing, like, priorities that have already been identified. You kind of swoop in and maybe do that. Those are nice. So, you know, that might account for 10, 15% of the time, but, yeah, that doesn\u0026rsquo;t happen a whole lot. So not a whole lot of time coding. But I do like to keep involved with it. And during hack week, you know, you bet I\u0026rsquo;m going to be all in. So whatever the stuff like that, it\u0026rsquo;s funny because, like, it kind of depends on what we can talk to me because some weeks I\u0026rsquo;m much more into it because we have some things that. The other thing that I\u0026rsquo;m trying to do, I find myself doing the big thing, just to make the answer longer than you probably ever thought it would be, is trying to make sure that I\u0026rsquo;m proposing something that makes sense and that people can do and make sure I can do it myself. That\u0026rsquo;ll sometimes take a little time. So whether it\u0026rsquo;s this kind of refactoring, I\u0026rsquo;ve got this thing called untangling that I\u0026rsquo;m trying to do where it\u0026rsquo;s untangling the source code base. That process has been interesting because I wrote a big paper about it when I first got back, and here\u0026rsquo;s the things I see and here\u0026rsquo;s some measures that we can look at to say, yep, it\u0026rsquo;s tangled up. Here\u0026rsquo;s some approaches to untangling. I wrote about that, but then I started actually digging in and doing it just to make sure that I wasn\u0026rsquo;t asking people to do something that was totally ridiculous. And it\u0026rsquo;s not. So I\u0026rsquo;m happy to say. So that ends up taking some coding time as well. Nice.\u003c/p\u003e\n\u003cp\u003eAlex: Well, Brian, thank you for speaking with us. I learned a lot.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, this is great. Thanks so much, Brian. It was really, really nice chatting with you.\u003c/p\u003e\n\u003cp\u003eBrian: It was my pleasure, guys. I\u0026rsquo;m happy to do it. That\u0026rsquo;s it.\u003c/p\u003e\n\u003cp\u003eDavid: Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show. It is a really useful signal to us that folks are finding value in this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at Our website podcast staffevenge.com the website also has our contact info. Please don\u0026rsquo;t be shy. Sa.\u003c/p\u003e\n","date_published":"2021-05-18T09:00:00-05:00","date_modified":"2021-05-18T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/matthew-bilotti-twitter/","url":"https://podcast.staffeng.com/season-1/matthew-bilotti-twitter/","title":"Matthew Bilotti (Twitter)","summary":"Mentoring people is probably the best thing you can do. If you want to have great senior staff and staff engineers in your org, protect your time to mentor.","content_html":"\u003cp\u003eOn today’s episode of StaffEng, we speak with the formidable Matthew Bilotti who works as a Senior Staff Software Engineer at Twitter and has been at the company for 11 years. Matthew currently leads a team that plays a critical role in user safety. Matthew has also taken on a key role when it comes to mentoring junior members at Twitter. In our conversation, Matthew talks about why he’s spent so many years at Twitter, his deep passion for teaching, and why the work his team does is invisible until something goes wrong. Matthew also elaborates on what goes into hiring a new senior staff member and why, at Twitter, they make it possible to easily switch teams to help retain the employees after the company has spent so much time investing in them. For all this and much more, join us for a riveting discussion on leadership, mentorship, and how to balance idealism with realism in a mission-based company!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/mbilotti\"\u003eMatthew Bilotti on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8430322-matthew-bilotti-twitter.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Aromas and I\u0026rsquo;m joined by my co host Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, this was an awesome interview with Matthew Bellotti who is a senior staff software engineer at Twitter where he has worked for over 10 years. One thing that came across in this interview was how much Matt cares about mentoring, which for me is always a challenge. It\u0026rsquo;s great to hear how others approach it. So let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Okay. Well Matthew, thank you so much for taking. It\u0026rsquo;s really nice to meet you. If we could start by having you tell us just kind of a bit about yourself in your own words, who you are and what you do.\u003c/p\u003e\n\u003cp\u003eMatthew: Sure. Thanks Dave and Alex, it\u0026rsquo;s really nice to meet you both too. And thanks for the invitation to be here and to talk about this kind of stuff in public. I think it gets a lot of play in my one on ones, but it should be talked about more. And so who am I? What do I do? I\u0026rsquo;m a senior staff engineer at Twitter. I\u0026rsquo;ve been there for a very long time. I recently celebrated 11 years. So I know this is very uncommon industry wide to have tenure of that length. But one of the reasons I stayed there that long and still stay there is because of the opportunity to grow my career. First to staff, then to senior staff, maybe contemplating principles at some point in the future and the opportunity to learn the skills and work with the folks to make that a reality. Those opportunities presented themselves at Twitter. And I mean I like Twitter, right? Twitter is full of really wonderful people and I think we are an important service for the world to have and it is kind of fun solving the problems. We\u0026rsquo;re not so big that you still don\u0026rsquo;t have a large impact on the user\u0026rsquo;s day to day experience. We might be one of the smallest of the quote big unquote companies. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: One of our questions that we like to ask everyone is like what does a typical staff plus engineer do at your organization?\u003c/p\u003e\n\u003cp\u003eMatthew: I feel like the role is so highly nuanced that it might not be atypical. I can give you some generalities. Certainly this is the kind of stuff I tell my mentees. So I think, you know, a staff engineer, staff plus engineer is a leader and an influencer, not a people manager. And the influence and guide that our staff plus engineers, you know, give us are because they are. They\u0026rsquo;re highly knowledgeable technical experts and their advice is highly grounded in the needs of the business. Not just now, but many quarters, perhaps years sort of into the future. And I also think a key element of the role is being an excellent communicator. Right. So I\u0026rsquo;m not your manager. I can\u0026rsquo;t tell you what to do, but I can appeal to our shared goals, business goals, stuff we need to get done. I could say the work leads us in this direction. There\u0026rsquo;s risks over here. Let\u0026rsquo;s try to avoid that. There\u0026rsquo;s probably a sweet spot of investment for, you know, to return if we go in this direction. But I try not to say no. I try to say yes. And right here are some things you should be aware of. But, you know, at a certain point, you\u0026rsquo;re leading the project and I\u0026rsquo;m a resource, sort of for you.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. It\u0026rsquo;s impressive to hear that you\u0026rsquo;ve worked there for 11 years.\u003c/p\u003e\n\u003cp\u003eMatthew: I know. I can\u0026rsquo;t believe it myself.\u003c/p\u003e\n\u003cp\u003eAlex: Do you feel like there was any particular projects or anything that sort of allowed you to grow as a senior? I see, you know, especially going from whatever was before staff plus to staff plus.\u003c/p\u003e\n\u003cp\u003eMatthew: Right. Well, I just want to say that the projects that I did that got me promoted or at least proximate to my promotion, they weren\u0026rsquo;t always my best work and they weren\u0026rsquo;t always, you know, a complete example of operating at that next level. Right. I think I got promoted for showing sort of directionality. I got promoted for being a multiplier and an enabler. I think that was my senior staff promotion, guided an arc of work that took 12 months with several teammates in the SUI2 and senior SUI ranks. And also an intern who is great and still works at Twitter as a full timer and is wonderful that year. We came in January with a complete roadmap. We had thought of the year before and an excellent product manager explained to us that there was a massive broken window that was leaving many monthly active users locked out. And she is also wonderful and is back at Twitter now. We scuttled the whole roadmap and we pulled a few folks together and we delivered it. It took till December, like right about holiday party time. We landed it and we didn\u0026rsquo;t even expect a couple 100k users to be released. From. I don\u0026rsquo;t want to be so specific about what we worked on, but it. It did enfranchise a bunch of people that we didn\u0026rsquo;t realize were being locked out of the platform due to some of our sort of challenges and security measures that just weren\u0026rsquo;t sensitive to the fact that folks, you know, recycle phone numbers, you know, move to a new city, go to the AT\u0026amp;T shop, get a new phone number. Who knows who had that before? That person could have been locked out of Twitter.\u003c/p\u003e\n\u003cp\u003eAlex: Sure.\u003c/p\u003e\n\u003cp\u003eMatthew: And now we fix that. So you\u0026rsquo;re not.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool. For what it\u0026rsquo;s worth, I think a big theme that we hear about a lot is learning. And so taking the time to acknowledge when things didn\u0026rsquo;t necessarily work out as well as they could have is probably a very big part of growth. I think, just in general, you mentioned the word directionality, and I was just curious, is that something that means something inside of Twitter or is that something that you have developed? What does that mean to you?\u003c/p\u003e\n\u003cp\u003eMatthew: Oh, no, I brought up that word because I feel like it used to be industry sort of practice back in the day to say, well, if you want a promotion to staff, just operate as staff for six to 12 months and then we\u0026rsquo;ll see about the promotion. And I don\u0026rsquo;t think that\u0026rsquo;s the case any longer in at least larger shops or maybe at least Twitter. I think we try to recognize people\u0026rsquo;s velocity towards growth or the derivative or whatever it is they\u0026rsquo;re going to get there. And we don\u0026rsquo;t really gatekeep the upper ranks of the IC ladder as maybe strictly as one would have, if you\u0026rsquo;re a small company and a promotion is a very risky thing. Right. If you promote the wrong person, does that person have undue shape on the direction of where you go? You probably want to select conservatively at a smaller place, but you have advantages because if you\u0026rsquo;re a smaller shop, you can make a claim to that level of growth as a company. For example, if you\u0026rsquo;re pre ipo, that a company like Twitter couldn\u0026rsquo;t make that claim now. So when we go out into the open market and we try to hire senior staff plus engineers, which we do, I wouldn\u0026rsquo;t say we have any more, any less success than. Than other companies, because these folks are often fairly happy where they are because they have a lot of control over how things go and they often feel like their work is not done right and they\u0026rsquo;re a necessary mainstay of the engineering org\u0026rsquo;s direction and success. I Think that\u0026rsquo;s reasonable. But, you know, you need to be able to say, hey, I can hire you at senior staff. You don\u0026rsquo;t have to come in at staff with 12 years experience, but then work your way up over the next five years to senior staff. We have that role open now. Right. So if both of you are looking for roles, we\u0026rsquo;re hiring, had to do it.\u003c/p\u003e\n\u003cp\u003eDavid: On that note, sort of the idea of like, because you\u0026rsquo;re right, that is a common idea that I\u0026rsquo;ve certainly heard before, is like, if you want the promotion, you sort of need to demonstrate yourself operating at that level. I guess I have two questions about an approach which differed from that. One of them is like, how do you identify if the person isn\u0026rsquo;t actually already operating at that level? And then the other one is like, you mentioned sort of the idea of the riskiness of promoting the wrong person. What would happen to Twitter if you promoted the wrong person?\u003c/p\u003e\n\u003cp\u003eMatthew: Well, we don\u0026rsquo;t have a mechanism for releveling anybody other than pip. I\u0026rsquo;m not aware that that\u0026rsquo;s common in the industry. I think that\u0026rsquo;s why folks were conservative early. You know, I mean, if you really, if they came to me and said, oh, Matt, you had a bunch of kids, I work a bunch of flex time now. We\u0026rsquo;re just not seeing that senior staff level contribution any longer. If my manager were to say that to me, which they would not, hopefully that would be a signal that I\u0026rsquo;m being shown the door. Right. So it\u0026rsquo;s almost useless as a tool to shape your engineering org. I think that\u0026rsquo;s a completely off the cuff opinion. But the worst thing that could happen is you\u0026rsquo;ve got someone who shapes things in the wrong direction. So someone who greenlights random things that will be, short term, shiny in the short term, that will pose massive amounts of technical debt in the future. I feel like where I sit at Twitter is I\u0026rsquo;m sort of the old guy lashed to the mast saying, no, I\u0026rsquo;m old technical. Because I feel like it falls on our team to sort of clean up and close the loops around a lot of the things when terms like velocity are thrown around.\u003c/p\u003e\n\u003cp\u003eDavid: What is your team, by the way? We didn\u0026rsquo;t cover that.\u003c/p\u003e\n\u003cp\u003eMatthew: Oh, yeah. Well, my team is called health. A lot of places call it safety or product safety. I think we\u0026rsquo;re responsible for a lot of the treatments that you see. When something is, for example, nsfw, there\u0026rsquo;ll be interstitial warnings and things around there, and those things are there for the safety of the general user of Twitter. There is a lot to it. There are misinformation warnings, there are warnings against attempts at disrupting integrity of elections. And these things are all playing a very important role in the business. I do think they\u0026rsquo;re critical. I also think they are tied into everything. It is the spider team with tendrils that touch every single portion of the product serving stack. It\u0026rsquo;s kind of amazing and kind of bewildering to be at the locus of all those things. So that is my team. And what would happen if we hired the wrong person at senior staff? Well, we usually don\u0026rsquo;t hire the wrong person. I think we once had somebody who was extremely senior and very, very bright who joined our team and they didn\u0026rsquo;t sort of like it. So whenever I\u0026rsquo;m involved in any kind of hiring panels, I like to give the disclosures and assess mission fit up front. I mean, honestly, it\u0026rsquo;s the kind of team where Jack Dorsey won\u0026rsquo;t take any notice of you if you\u0026rsquo;re doing your job well. But if you\u0026rsquo;re doing your job not so well, there\u0026rsquo;ll be input, let\u0026rsquo;s say. So it\u0026rsquo;s nice to be there. But in those cases, when the folks are not a good fit for us, they either leave the team or they leave Twitter, you know, so we make it relatively low friction to change teams.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMatthew: You don\u0026rsquo;t want to spend all this time hiring someone at any level, right? You\u0026rsquo;ve sold them, you\u0026rsquo;ve invested in them, you\u0026rsquo;ve trained them. I don\u0026rsquo;t know about you, but our documentation is very sparse. So the training is a very much a one on one or many on one. Let me show you what I do. And it takes a long time. It\u0026rsquo;s an investment, actually. It builds great relationships. So anyway, you\u0026rsquo;ve done all that and the last thing you want is someone to say twitter. Not for me, I\u0026rsquo;m leaving.\u003c/p\u003e\n\u003cp\u003eDavid: Right.\u003c/p\u003e\n\u003cp\u003eMatthew: So we have this process we call branch out. As many things are our bird metaphors at Twitter, as you can imagine. And birds like branches, we think. And that means you can, in a relatively low friction way, move to another team. And some folks have done that without any kind of hard feelings. I don\u0026rsquo;t think we\u0026rsquo;ve had anyone really at a high level in the engineering ranks that has done something really close to malfeasance are damaging the business. And if we did, I wouldn\u0026rsquo;t be able to tell you that in a public forum. There would have to be a private forum and probably some beer and there could be some stories about what didn\u0026rsquo;t go well. That one or two times, but they\u0026rsquo;re, they\u0026rsquo;re relatively few.\u003c/p\u003e\n\u003cp\u003eDavid: But of course that, yeah, that\u0026rsquo;s never happened. So there\u0026rsquo;s not even a story to be told.\u003c/p\u003e\n\u003cp\u003eMatthew: I\u0026rsquo;m sure it\u0026rsquo;s never happened in your guys stories either. So.\u003c/p\u003e\n\u003cp\u003eDavid: When you think about sort of like your day to day work, to what extent are you sort of helping teams drive specific projects versus sort of team oriented or organizational oriented work like planning, training, recruiting, mentoring, etc.\u003c/p\u003e\n\u003cp\u003eMatthew: Yeah, it\u0026rsquo;s all of the above. I think the do you directly manage a project like I was telling you about, that 12 month arc of work? That is the mode where you keep the big picture. You\u0026rsquo;ve broken the task down into small portions, you\u0026rsquo;ve distributed them across the team. You write maybe 25% to a third of the code, but review all of it as folks come in. You explain how their things fit in, you help them understand the choices that they\u0026rsquo;re making, you help them figure out what the next task is and then you do the communicating about it and you let leadership know and all that stuff and you eventually get to the lay on the plane successfully. I don\u0026rsquo;t do that every day and it might not be the highest leverage thing for me actually to be doing right. So that and how much time do I get to individually write code, which is a very small slice of, you know, my time, though enjoyable as an avocation, that is also not the highest leverage thing that I\u0026rsquo;m really supposed to be doing. So I\u0026rsquo;m really supposed to enable other people to do those things and more. And you mentioned a bunch of the tools in the tool chest to do that. Mentoring is a big one. Planning, writing and evangelizing a vision. So you can evangelize in a document form or in a public speaking form. I also we have a Twitter university inside where we teach ourselves things and I\u0026rsquo;ve been running a class for a while about health engineering. What it does, what it doesn\u0026rsquo;t do, where the intersections are that tends to be frequented mostly by new hires, you know, but it\u0026rsquo;s still, there\u0026rsquo;s still value there sort of in leveling up the team, sort of in a broad sense. There\u0026rsquo;s also a thing, I don\u0026rsquo;t know if you mentioned this or not, but a thing that occurred to me that you find at the high levels of IC roles is like organizational service. So there\u0026rsquo;ll be promotion committees, there\u0026rsquo;ll be technical committees, folks figuring out anything from what technologies we should adopt or not adopt to what should the hiring strategy be for senior staff plus candidates. The questions would be Different. What skills would you try to assess? I actually worked on that one a little bit. A new thing that\u0026rsquo;s come onto my play recently. I recently realized that our engineering mentorship program had flagged because a key person who was driving it left. And I learned this by advising people to seek out the program. Right. You know, folks will say, well, how do I get mentorship? It\u0026rsquo;s like, well, that\u0026rsquo;s actually the thing we have a program for because it is hard to find. Right. They will match you and make sure folks had a productive match and do sort of follow up assessments to make sure it\u0026rsquo;s going well. All that good stuff you\u0026rsquo;d expect from a top shelf mentoring program. And it hadn\u0026rsquo;t been running because of someone who had left the org. So I said, what right I have to get involved? And so I just started emailing people that I know had worked on it in the past who that who might leadership and development side folks who might provide an umbrella where we could restart this program was like, yeah, I want to restart that. Mentoring people is probably the best thing you can do. Well, it\u0026rsquo;s one of my favorite things to do if you want to have great senior staff and staff engineers in your org is protect your time to mentor. So because I don\u0026rsquo;t scale right, I can\u0026rsquo;t mentor high tens of people. We should have a mentorship program where everybody who is staff plus has one mentee and we keep it in rotation so people get different perspectives. So we\u0026rsquo;re going to start that.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool. And it sounds like there\u0026rsquo;s like a wide variety of things you could work on. And I want to touch back on that in just a moment. But one of the things we like to talk about are sponsoring mentoring and leadership. And so. And you mentioned that that\u0026rsquo;s something that you, you like to do and that you think is important. You know. Do you think you could talk a little bit more about like your approach to mentoring?\u003c/p\u003e\n\u003cp\u003eMatthew: Oh, my personal approach is other than prioritize it, which I seem to have the earned a little bit of autonomy to do that. I don\u0026rsquo;t know if it is or isn\u0026rsquo;t on the career ladder, but I think it should be. I think it\u0026rsquo;s a really important part of how we level up our own community. And you want that, right? The person working next to you, you want them to be as excellent and as best prepared as they possibly can be because that\u0026rsquo;s the kind of person you want to work with. So want to help them with whatever they need. So my personal strategy for mentoring is kind of reactive. I feel like I have a lot of set pieces about things I\u0026rsquo;ve seen in the past and that when I identify someone as sort of slotting into one of those tracks, I bring out a couple of set pieces of advice, things that I\u0026rsquo;ve observed or learned from other people or things that have happened to me. So I tell those stories pretty freely. Can\u0026rsquo;t tell all of them here, but sort of like in our one on ones I tell the truth, right? And sometimes the truth is not awesome. Sometimes things didn\u0026rsquo;t go well. Sometimes things are not equitable, Sometimes there\u0026rsquo;s conflict with leadership, sometimes mistakes are made. So I try to kind of lay it out there and see if folks can key on any of those things. Ask me questions and kind of like I asked you before we started recording, which is please elicit the knowledge from me because I don\u0026rsquo;t know what I know and I need to wait for someone to ask the question and then I go, oh yeah, let me tell you about that time.\u003c/p\u003e\n\u003cp\u003eAlex: Cool, Miyam. It makes me want to be mentored by you.\u003c/p\u003e\n\u003cp\u003eMatthew: Oh, that is a very kind thing to say. No promises about whether I\u0026rsquo;m any good, but what I at least make up in the lack of quality is in the quantity. I never say no to someone who wants to chat at any level. Really.\u003c/p\u003e\n\u003cp\u003eAlex: Going back to sort of the organizational stuff that you were talking about, a common theme that we hear is there\u0026rsquo;s always more things you could work on than you have time for. And that as you go up the track, organizational impact and sort of like really looking forward into the future becomes more and more important. Do you have a particular approach to understanding how to pick the right projects that have the most organizational impact and that make you aligned with what the organization wants to do?\u003c/p\u003e\n\u003cp\u003eMatthew: I would say that I don\u0026rsquo;t really have the intuition that would allow me to choose the project that makes the biggest splash where, you know, folks start ladling out titles like Principal. Right. I don\u0026rsquo;t have it. What I do have is a sense of my immediate area, which is, I think, fairly deep. And because it\u0026rsquo;s super highly intersectional with not just what we do on the product side, but even fundamentals of the business, it\u0026rsquo;s essentially an advertising business, as you probably were. I know what to do in those spaces that I think are the right things. And I do know, I think I have a sense of what not to do that would be either a very risky thing to do or something that would have such high confidence bands in the return on investment that it\u0026rsquo;s not smart to go from there to hair hair to there right away, but to take maybe baby steps in between. I don\u0026rsquo;t always get my way about that. I feel like I\u0026rsquo;m not here to say no and slash people\u0026rsquo;s roadmaps, but I do try to get people on an incremental track of stuff that it\u0026rsquo;ll eventually be good for our users and that means it\u0026rsquo;ll be good for our business if we do it right. Again, the specific stuff we work on is highly wrapped up in user trust. And even if it\u0026rsquo;s not wrapped up in user trust, it might be wrapped up in do governments think we\u0026rsquo;re treating our users properly? And those governments are all around the world with all different kinds of privacy and data protection regulations that affect us, kinds of regulations on what is or isn\u0026rsquo;t lawful speech in those jurisdictions. And we have built out all sorts of stuff to be really responsive to that. At the end of the day, if we\u0026rsquo;re sued out of existence or blocked from operating in certain countries, we\u0026rsquo;re not serving that person who needs to document injustice going on in their communities or whatever it happens to be. Twitter is a vehicle for citizen journalism. So if we keep it safe and we keep it up and running and healthy and happy, then we\u0026rsquo;re doing. That\u0026rsquo;s the story. There has to be one. It\u0026rsquo;s part of the sustainability, three legged stool. You want to work at a place where the company is neutral to positive in the world. And so there\u0026rsquo;s a story to that. The degree to which you buy it is up to you. But if Twitter gives voice to the voiceless, then it\u0026rsquo;s a zone for free speech. To the degree that\u0026rsquo;s possible, then it\u0026rsquo;s doing something that\u0026rsquo;s positive.\u003c/p\u003e\n\u003cp\u003eDavid: I want to dig into that a little bit actually. The idea of narrative guiding mission and the impact that can have on organizations. Because while you mentioned it earlier, staff engineering is all about influence. And one of the things that affects your ability to influence is sort of like the extent to which people around you, people that you work with, are aligned on the mission. So I have found it interesting working in a mission driven organization, sort of the balance that maybe needs to happen as a leader between really being truly bought into the mission. And it sounds like you are, while also being a realist, which it sounds like you are. Right. At the end of the day, these businesses exist, certainly they have a mission, but they also want to make money. And there\u0026rsquo;s, you know, there\u0026rsquo;s lots of factors at play and I find it important when I\u0026rsquo;m dealing with folks to try to present that authentically, right? Yes, I believe in the mission, but also like I\u0026rsquo;m not necessarily drinking the Kool Aid. Right. And maybe that\u0026rsquo;s sort of a cynical way of expressing it, but does that resonate with you and do you sort of have those, do you sort of sometimes think about the right balance of how to present yourself as a leader when you\u0026rsquo;re sort of presenting that mission?\u003c/p\u003e\n\u003cp\u003eMatthew: Yeah, I mean, I try to keep it pragmatic. So as I mentioned earlier, we\u0026rsquo;re not the kind of team that gets a lot of visibility. So specifically on our team, if you\u0026rsquo;re going to be happy here, you got to be a little bit self motivated. So when I was trying to hire some folks into our team, I would be screening up front to try to understand do they want to combat, you know, racism on the Internet, sexism on the Internet. Right. Hate speech and other bad things. If you do and you can be self motivated by that mission, you will be a good fit here. And the pragmatism comes in. And so far as you\u0026rsquo;re not going to get a pat on the head for doing this, right, you can\u0026rsquo;t prove a negative to the board or to Jack Dorsey, right. I mean, I know he understands sort of academically that we exist and certain members of the staff of Twitter definitely understand quite viscerally that we exist and aren\u0026rsquo;t doing important things to keep us where we\u0026rsquo;re at. But yeah, you\u0026rsquo;re not going to get recognition for this. And it might be, that might be a thread to pull on later because recognition often translates to career growth. But if you\u0026rsquo;re in our team, right, and you can be self motivated and you understand that you need it, because there isn\u0026rsquo;t going to be a lot of kudos all the time, then that\u0026rsquo;s fair. And I like to disclose that up front because I really don\u0026rsquo;t want someone to come in three months later and be like, well, no one\u0026rsquo;s giving us a cookie, right? Or worse, you know, hey, why are we making decisions about content amplification and what isn\u0026rsquo;t amplified? And that goes against some notion I have of, of the freedom of expression. Right? And that. And it has to be acknowledged that some of the decisions that we make are business decisions, right? Twitter is a business and it exists not necessarily to make huge amounts of money, because otherwise we would have done that by now.\u003c/p\u003e\n\u003cp\u003eAlex: Right.\u003c/p\u003e\n\u003cp\u003eMatthew: But it does exist to fund this engineering organization and I\u0026rsquo;m telling my peers, like, if you like to work here with engineers of this caliber solve meaningful problems that definitely have user and financial business related impact, then you want to make these decisions in this way to make sure we fund ourselves and keep the product available again for the citizen journalism.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. You mentioned too that the health team is kind of like a spider team and that you sort of have interdependencies with a lot of other teams at Twitter. I\u0026rsquo;ve worked in teams like that too, and my experience in those teams that oftentimes you end up sort of. Occasionally you\u0026rsquo;re tasked with influencing a lot of different teams in the org to make it. You mentioned something like cleaning up tech debt. Right. And so occasionally you\u0026rsquo;re tasked with sort of this need to influence a lot of different teams in the org to make some sort of change that they\u0026rsquo;re not maybe necessarily excited about, that it doesn\u0026rsquo;t necessarily directly drive their goals forward. And one of the challenges that, you know, broadly, I think staff engineers face is sort of like, how do you align groups of people towards something like that? Especially sort of the not sexy problems. Right. Is that something you\u0026rsquo;ve encountered and how do you deal with sort of the conversations with outside teams or even within your own team of sort of like, look, this is the thing that we have to do, you know, and let\u0026rsquo;s figure out how we can make it happen and how we can all work together toward this sort of bigger, nebulous, messy thing.\u003c/p\u003e\n\u003cp\u003eMatthew: Yeah, that\u0026rsquo;s a really good call out. So if I can step back maybe to 2019, the team that I work on today is a component of House. It\u0026rsquo;s about, if you count myself, seven ish ICs. And we didn\u0026rsquo;t exist until December of 2019. And so what happened was folks were building product, they were duct taping things together. I don\u0026rsquo;t mean to be pejorative about the quality of the engineering. Right.\u003c/p\u003e\n\u003cp\u003eDavid: Sometimes I think every engineer listening to this does not take duct taping things together as a pejorative. It just is something that happens at various stages of growth.\u003c/p\u003e\n\u003cp\u003eMatthew: Okay. So we acknowledge that there\u0026rsquo;s sometimes business bets and stuff that make us optimize for velocity. And that\u0026rsquo;s part of the thing that one of the skills that we have, I mean, if they left me alone, I would make the most beautiful infrastructure ever. Just put a page up that says Twitter is down for maintenance for like a year.\u003c/p\u003e\n\u003cp\u003eDavid: Do you implement edits?\u003c/p\u003e\n\u003cp\u003eMatthew: Let\u0026rsquo;s talk about that later. Constant joke right around the office.\u003c/p\u003e\n\u003cp\u003eDavid: Evergreen. It\u0026rsquo;s perfect.\u003c/p\u003e\n\u003cp\u003eMatthew: The edits. There might be a couple of secrets around that or whether that\u0026rsquo;s actually hard these days. Or not. It was definitely hard early. It was definitely hard early because of database replication and indexing of tables made it super, super hard to go in and do random seeks and writes to the corpus of tweets. Of course, things aren\u0026rsquo;t stored that way anymore, so maybe an edit button is in your future.\u003c/p\u003e\n\u003cp\u003eDavid: Just keep asking directly.\u003c/p\u003e\n\u003cp\u003eMatthew: I\u0026rsquo;m sure he\u0026rsquo;d be so happy to hear that.\u003c/p\u003e\n\u003cp\u003eDavid: Perfect. Yeah, I\u0026rsquo;ll put that in the show notes. Ping jack directly. Done.\u003c/p\u003e\n\u003cp\u003eMatthew: Oh boy. If he finds out that for sure, then I would be shown the door. Yikes. Let\u0026rsquo;s not do that. We were talking about spider teams.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. And the challenge of getting different groups of people to collaborate on things that maybe don\u0026rsquo;t even further their roadmaps that much. And it\u0026rsquo;s largely about sort of getting people to do you a favor and clean up their code.\u003c/p\u003e\n\u003cp\u003eMatthew: Right. Well, I did something different. So I started to tell you a long story about growing a team where none had existed to own this sort of cross product nexus of health related treatments, warnings, interstitials, flags and sort of things. Just general purpose safety features. Well, it didn\u0026rsquo;t exist. So I wrote a vision document and sent it around and it said basically the fact that this is completely unowned or is in, it\u0026rsquo;s in that space, the cracks between team ownerships and it always falls through. It\u0026rsquo;s like owned by everybody, but owned by nobody. I said this is a massive business risk. We need to create a team to do this. And lo, the leadership gave us some headcount. So what we did with that headcount is we started to go into other people\u0026rsquo;s services and swashbuckle a little. We took some of the logic that really should be ours per charter out of their services, put it in libraries with some, I don\u0026rsquo;t know, then maybe not the best interfaces that exist. But there are interfaces where formerly there had just been intertwined growth of stuff which no engineer likes. Right. We factored stuff into our own code base, we\u0026rsquo;ve established interfaces, as I mentioned, we\u0026rsquo;ve cleaned up other people\u0026rsquo;s services at all layers. Right. Core services layer, composition layer, API layer. We now have touched maybe 15 services that we don\u0026rsquo;t own, responsible for serving nearly everything in the primary product serving stack of Twitter. Right. So that\u0026rsquo;s a kind of a. Not an answer to your influence question, but it might be. So I didn\u0026rsquo;t influence teams to clean up their own tech debt. I said the fact that this debt is unowned and doesn\u0026rsquo;t Track with Health\u0026rsquo;s product sort of vision and timeline means we need to own it for you and you will be our customer. And of course that goes back in the hiring for those particular ICs where you want to say not only is the mission fit essential and the fact that you won\u0026rsquo;t get pat on the head, we\u0026rsquo;re also going to clean up a bunch of folks legacy stuff. So I managed to find a few very, very excellent like minded folks who once they came in they said I\u0026rsquo;m ready for this challenge. They looked at this stuff and said that is really disgusting. We can go make it beautiful or at least less disgusting. We went and did it and it\u0026rsquo;s still an ongoing process. But the end vision is you\u0026rsquo;re going to make a change, make it in one place or a small number of places. Right. Not 15 services that all have randomly different deploy schedules and with mismatched versions of libraries running in production and. And of course they\u0026rsquo;re not independent. Right. So treatments adjusted at the core services layer will be munged again at the composition layer and will the APIs render them or not? And then what do the clients do? If I\u0026rsquo;ve got the same sort of business logic encoded in multiple different fields on the API struct, they\u0026rsquo;re going to shout because that\u0026rsquo;s not great. So my work will never be done.\u003c/p\u003e\n\u003cp\u003eAlex: I mean that\u0026rsquo;s a really interesting approach. Was that you said that you wrote a vision document. Was that sort of the. The start, you know and it was that something that you identified and were sort of self motivated to create and distribute.\u003c/p\u003e\n\u003cp\u003eMatthew: Yep, that was one of my greatest hits. Still gets hits mostly me showing it to new hires. Read this. There\u0026rsquo;s a lot of it is still true because it would be would be multiple years to really make. Well no one\u0026rsquo;s going to fund us to make the gleaming thing so we have to. For example forcing functions like the COVID crisis and the elections of 2020 in US were functions that caused us to make changes to some of those treatments that how they\u0026rsquo;re represented on the product. So what we would do is we would slide in under that work sort of a little bit of tech deck cleanup, a little bit of consolidation, a little bit of nicety, fewer places to touch. Put ourselves out of the business of making changes in 15 services and getting 15 different code reviews and waiting for 15 different deploys.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. That\u0026rsquo;s awesome.\u003c/p\u003e\n\u003cp\u003eMatthew: Thanks.\u003c/p\u003e\n\u003cp\u003eAlex: So you mentioned that you\u0026rsquo;ve been at Twitter for 11 years now and you also mentioned that that might be a little bit different than Others. And I\u0026rsquo;m curious, to what degree do you, do you think about that and do you reflect on the road not taken and what sort of keeps you where you\u0026rsquo;re at?\u003c/p\u003e\n\u003cp\u003eMatthew: Yeah, I get this question a lot. It\u0026rsquo;s a good question. Certainly. When I was at Twitter originally it was a startup and some of those folks, we were about 120 total heads. When I joined, I remember because we had a party for the 140th joiner and if you get the joke, used to be the case that we limited the tweet length to 140. Now it\u0026rsquo;s a circle.\u003c/p\u003e\n\u003cp\u003eAlex: I remember, I remember. 140.\u003c/p\u003e\n\u003cp\u003eMatthew: All right.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eMatthew: Well, the SMSing of tweets is not something we do as often as we used to. These days at any rate, I definitely encountered folks in a trajectory of putting chips down on the felt and moving every two, three or four years. Four would be sort of long in the tooth for someone who was sort of going breath first. Cover a bunch of industry bets. Now a lot of my peers early in that first batch at Twitter are telling me, hey, you\u0026rsquo;re leaving money on the table. And you know, that might be true. So. But about the end of my first sort of four years, I get the chance to sort of apply for staff. I told my manager that I would like to go for it and definitely rejected. So I think that might be true of folks that are listening, may resonate with that because I do think staff is a high bar. And I still tell folks I mentor inside Twitter that staff is actually kind of a high bar. So we have to make sure we craft the stuff that you\u0026rsquo;re going to show that\u0026rsquo;ll eventually make it into that packet. You know, pretty carefully. We\u0026rsquo;ve got to choose the. Be a little bit tactical about how we choose what we do to, you know, show that sort of 12 month track record that\u0026rsquo;s going to get you the win. And once you get that level, then you can sort of relax back into the autonomy that it affords and go attack the problems that are the right ones. You know, there\u0026rsquo;s sometimes a little bit of a divergence there. I\u0026rsquo;m not telling any secrets, right?\u003c/p\u003e\n\u003cp\u003eDavid: No, definitely not.\u003c/p\u003e\n\u003cp\u003eMatthew: But you asked me why I stay. Oh, definitely not. Do you want me to continue the story about why I stay at Twitter?\u003c/p\u003e\n\u003cp\u003eDavid: Yes, I do want to hear that. I think actually I want to introduce briefly. Yeah, I do want to hear it, but I want to bookmark because I think the idea of like preparing a promo packet and, and sort of the idea of like the difference between what it takes to get to staff and then what you can do once you\u0026rsquo;re there. You mentioned like the autonomy that it affords. I do want to revisit that. I think all of that is really, really sort of relevant to our conversation broadly. But I\u0026rsquo;m sorry to interrupt. Please continue with telling us sort of.\u003c/p\u003e\n\u003cp\u003eMatthew: Let\u0026rsquo;S go where I think the, you know the most me is right. You know, the story ends up with me getting old and having a bunch of kids. So if you.\u003c/p\u003e\n\u003cp\u003eDavid: And then your manager told you that you weren\u0026rsquo;t hitting senior staff. Right. That was the you told us earlier.\u003c/p\u003e\n\u003cp\u003eMatthew: Well, I\u0026rsquo;ll get back to that story. So you asked a little bit about what you do in a run up to a promotion case versus what you sort of do when you\u0026rsquo;ve checked that box and you can be autonomous as really what the latter asks you tell us what we should be doing. Right. Where we can improve. Well, anyway, so I recently had an experience where I mentored and I see that. I really, really appreciate up to staff. And we started talking about this in over a year ago. Right. I think it took about a year for that case to be heard, maybe a little under a year. But we gave it a long track record. And so we kept a doc, which we both worked on and we kept adding stuff to it and we chose to IC\u0026rsquo;s work diet. Not to the degree that I choose things right, but I encourage them to prioritize specific things not because they had the most business impact, but they had a property common to them. So one property was you would be working with someone on another team. A little bit of cross team exposure does, I think tend to help. Again, not a secret. Also, I chose them. I helped them choose their work, you know, nuggets because they were small enough that they could be sort of delivered in a certain time frame. A series could be shown like a little bit of a track record. And they would have, if you imagine overlapping dependencies with people on other teams. So you would really get around, you know, a cross section. Someone from revenue, someone from Enterprise, someone from, you know, core product serving.\u003c/p\u003e\n\u003cp\u003eDavid: What you\u0026rsquo;re describing sounds like a pattern that I\u0026rsquo;ve seen, but I think it\u0026rsquo;s interesting that it\u0026rsquo;s sort of different than the conventional idea, which is like a staff engineer leads one big project and then they\u0026rsquo;re ready for their promotion.\u003c/p\u003e\n\u003cp\u003eMatthew: Well, that is a way I think I would think that. Well, I thought about this ahead of time because I anticipated you might ask this. So we often think about, you know, Paradigms of staffness which sometimes try to classify, which I think is reasonable. From my observation, I see there are sort of two broad categories, depth first and breadth first. So my depth first staff sort of exemplar. I\u0026rsquo;ve seen a few of them who were very, very deep technical experts on a specific thing. Sometimes that thing is mission critical and sometimes that thing is one of those sort of overlooked, it should just work kinds of things. And that can be unfortunate. I remember a specific person who was thinking about advancing the senior staff and I was telling them we need to take this technology on a roadshow through the org. We need to meet people, potential customers on other teams, ask them what they need, build the things that they need, right? At least build a relationship with those people. Because if we\u0026rsquo;re, you know, separated by many layers of abstraction, you\u0026rsquo;re like, they\u0026rsquo;re not going to know you, right? And I\u0026rsquo;m not saying those people are specifically on the committee or not or those people are specifically going to give feedbacks that go into the packet or, you know, not. But the general I influenced by communication, I set vision, try to build consensus around it. Some folks subscribe to it. If they can get something out of it, great. That sort of paradigm, I think at the senior staff level that is pretty much all I see. I don\u0026rsquo;t see the depth first delivered like one huge project folks. I can see them get to staff. And I don\u0026rsquo;t want to say that Twitter\u0026rsquo;s promotion practices are not up to par. I just think there are headwinds to the depth first model. That\u0026rsquo;s an opinion. It\u0026rsquo;s probably based on the folks that I know, probably based on where I sit in the technical and org structure of, you know, places multifaceted as Twitter. So on the other hand, so I coach people like the Mapiloti school of, you know, staff plus engineering, which I do individual sessions of that at work all day. It\u0026rsquo;s the breadth first one, you know, each of these pieces of work under a common theme, each has a different dependency. Each had a specific measurable business impact. There\u0026rsquo;s a story to each one. A lot of times for us in health, the stories is easy because of the. I don\u0026rsquo;t know if you know this, but it\u0026rsquo;s an axiom on our end like more unhealthy behavior equals less user engagement, retention, growth. So it\u0026rsquo;s just drive down the bad stuff and it removes a depressor of growth that\u0026rsquo;s been around a long time and we don\u0026rsquo;t bother to measure it anymore. We just measure Bad stuff and say it\u0026rsquo;s on this face a good thing to drive it down.\u003c/p\u003e\n\u003cp\u003eDavid: Right? Interesting. The Matt Bellotti School of Staff Engineering. I really like that. I think that\u0026rsquo;s going to be the title of this episode. The question that I have next is going to be hard to answer succinctly because I think it\u0026rsquo;s not super realistic, but it\u0026rsquo;s maybe a useful starting point for people is like kind did you learn all of this? And especially are there any resources that you would point folks toward if they came to you and they\u0026rsquo;re like, hey, I want to learn what it means to be a staff engineer, you know, or to just be a high impact software engineer in my organization? Right. Are there books? Are there blogs? Are there like other people? Do you want a bunch of people pinging you directly? Like, where would you point people?\u003c/p\u003e\n\u003cp\u003eMatthew: Well, there are certainly a lot of books, blogs and other really useful stuff. I think probably our session here and the broader project that you guys are driving would be a useful resource for folks. And so thank you for doing it. But no, I\u0026rsquo;m sort of of the school really where if that\u0026rsquo;s what you want to learn from me, I\u0026rsquo;ll sit with you for as long as it takes to try to talk about it with you. You know, over time I never turn anybody away. Which is why I mentioned that it would be nice if our sort of centrally executed mentorship program would still be in operation. And I\u0026rsquo;m going to go make sure that it gets back up and running to the degree that I can. But it\u0026rsquo;s super valuable. I think people should have mentors and I think mentors should not, you know, prioritize anything else because there is a limited supply of them. You know, it wouldn\u0026rsquo;t be fair for me to say, oh, too busy, you\u0026rsquo;re stuck at senior forever. Right? Terrible. What if I lost a five year senior engineer because I was too busy to talk to them? And when I say talk, I really mean help you plan what goes in to that case for the next couple years. Think about tactically when you want to launch the case, right? Who do you want to talk to? Who do you want to ask for feedback from? How do you make the ask? Right? Make sure you provide an escape hatch for folks who feel like they don\u0026rsquo;t have bandwidth or signal to write for you. If you don\u0026rsquo;t provide that escape hatch, you\u0026rsquo;re going to get slapdash or maybe even bad feedback at best, unuseful. So there\u0026rsquo;s a few tactical things to it. And then I just, my Other problem is I didn\u0026rsquo;t write it down. So you ask if there\u0026rsquo;s books or blogs. Right. I feel like there should be. There are a lot I know. I feel like I should write one if it isn\u0026rsquo;t already a very well subscribed space. But nothing is better than you bring me your situation and I try to help with your specific situation. That is a personal opinion that might lead to a lot of time spent for possibly low benefit. I acknowledge that. Right. But it is fulfilling to me because I come from an environment where one on one advising was a very, very integral, sort of normal part of the experience. And I carry that with me. I liked doing that. I thought I was going to be a university professor because I like doing that so much, but I\u0026rsquo;m not. So I get to scratch the itch by helping people grow and it actually builds that relationship. So now they\u0026rsquo;re off in other corners of the org and I can make a suggestion to them and it\u0026rsquo;ll be considered seriously. And I like that. I appreciate that. And also they stick around. Right. So if I can stretch someone\u0026rsquo;s career at Twitter from five years to eight years because they made staff and they\u0026rsquo;re still learning, challenged, growing, just doing whatever the right thing is and hopping from project to project whenever that\u0026rsquo;s necessary, that makes me feel good. Anyway, I want the Twitter where I want to work to have those people doing those things there. So it\u0026rsquo;s entirely self serving. Yeah.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s an incredibly thoughtful approach. And if you\u0026rsquo;ve got a book to write, I\u0026rsquo;d read it so well, you.\u003c/p\u003e\n\u003cp\u003eMatthew: Complimented me already twice today, Alex, and that\u0026rsquo;s really generous. I appreciate that. You know, we\u0026rsquo;re going to have to.\u003c/p\u003e\n\u003cp\u003eAlex: Bring you back on to tell us the story of your time at Twitter, but I don\u0026rsquo;t think we have enough time today. And the last question we like to ask people, and you already touched on this, is, you know, how much time do you spend coding nowadays?\u003c/p\u003e\n\u003cp\u003eMatthew: Waxes and wanes. But guess what? I\u0026rsquo;m not that good at it anymore. Right. You know, I\u0026rsquo;m actually writing some code on a tiger team right now because there was a need and a tiger team was organized of all staff plus. So I\u0026rsquo;m all in there writing code. Not like I\u0026rsquo;m, you know, yelling at my intellij why the unit test will, you know, break. So I don\u0026rsquo;t have the, you know, at senior where your peak of codop or you\u0026rsquo;d be turning around several diffs in a day. And you\u0026rsquo;ll see, you\u0026rsquo;ll see a null Pointer, exception of some kind. And you say, oh, I know there\u0026rsquo;s a gap in this mocking here. I\u0026rsquo;ll know where it is. Plug those gaps, you\u0026rsquo;ll be able to execute very quickly. But me, no. Right. No manager or high level leader should say, put Matt on some code. Right. Because it\u0026rsquo;s going to take three months, you know, because I have a lot of things to do. And so when I do code, it is usually stuff that\u0026rsquo;s not on the critical path. It\u0026rsquo;s usually something that makes things better behind the scenes. Efficiency, cleaning up stuff, that kind of thing. And it\u0026rsquo;s purely as an avocation. This is really not what I should be spending my day to day on. I know that. But I still can\u0026rsquo;t get the bug out. I mean we essentially, this is why we joined this. We like to fix broken stuff. I have to be at peace. And I still struggle with this. I\u0026rsquo;ve been at senior staff for five years now and I still struggle with, hey, the way that I make stuff better and solve problems is by teaching someone else how to do it so they can just go off to the races. I teach everybody that I work with, everything that I learned along the way. Then it\u0026rsquo;ll be the best engineering org ever and I can relax.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Well, thank you so much for coming on the podcast.\u003c/p\u003e\n\u003cp\u003eMatthew: Well, thanks a lot. It was a real pleasure to meet both of you, Alex and Dave. And I really appreciate you driving this project. I think it\u0026rsquo;s going to be fun. I will be a subscriber. I\u0026rsquo;m a noted consumer of podcasts and this will be in rotation, so let me know.\u003c/p\u003e\n\u003cp\u003eDavid: Matthew, it was great to have you on and Alex is right. I\u0026rsquo;m sorry for cutting off your story about your time at Twitter. We\u0026rsquo;re going to circle back to that one day. I can\u0026rsquo;t wait.\u003c/p\u003e\n\u003cp\u003eMatthew: That sounds fun. I think. So I planted the seed to earn myself a return visit. That\u0026rsquo;s great. So I\u0026rsquo;m looking forward to it. Thank you guys. Be well.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staffinch. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-05-04T09:00:00-05:00","date_modified":"2021-05-04T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/natalia-tepluhina-gitlab/","url":"https://podcast.staffeng.com/season-1/natalia-tepluhina-gitlab/","title":"Natalia Tepluhina (GitLab)","summary":"The main idea about being staff engineer is scale yourself. It's not something that there is you, you cannot be replaced. You just some unique diamond in the team. If you are scale yourself, make other people diamonds as well.","content_html":"\u003cp\u003eAs today’s guest, Natalia Tepluhina walks us through her professional history and describes her experiences at GitLab. After getting to know Natalia a little better, we talk about the challenges she has faced as a staff engineer. We then get into what makes GitLab a documentation-first company. Natalia goes on to explain the inherent traits of being a documentation-first company, like practicing open-sourced work and documenting every step of your knowledge journey. As our conversation with Natalia evolves, she describes her day-to-day responsibilities as a staff engineer and touches on the processes she implemented for her team to achieve success. From here, we take a deep dive into GitLab’s organizational structure and discover the differences between managers and technical leaders, finding out why Natalia prefers the former. Later in the show, we talk to Natalia about what goes into being a technical leader and hear more about her experiences collaborating with other divisions internally and as a GitLab consultant. To draw the episode to a close, we ask Natalia what it takes to surpass the staff level and for her to share her most influential resources. Find out what these are and much, much more by joining us today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.nataliatepluhina.com/\"\u003eNatalia Tepluhina\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/n_tepluhina?lang=en\"\u003eNatalia Tepluhina on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://about.gitlab.com/\"\u003eGitLab\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8347617-natalia-tepluhina-gitlab.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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\u0026rsquo;m joined by my co host, Alex Kessinger. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, this is a great interview with Natalia Teplohina. She works at GitLab as a staff engineer on the front end. Fun fact. She was also the first front end staff engineer at GitLab. In addition to her work at GitLab, she\u0026rsquo;s also a core committer on the Vue JS project. This interview is a lot of fun to do and I think you all enjoy listening to it, so let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Well, Natalia, thank you again so much for taking the time. Maybe we could start by having you introduce yourself. If you could tell us where you work and sort of what your role is and what has led you to that point.\u003c/p\u003e\n\u003cp\u003eNatalia: I work currently as a staff frontend engineer at GitLab and as a side activity I\u0026rsquo;m also a core member of UGS Framework.\u003c/p\u003e\n\u003cp\u003eDavid: How did you get to staff? Were you leveled into the role at GitLab or did you start that way?\u003c/p\u003e\n\u003cp\u003eNatalia: I was hired as a senior and after a year and a few months in being a Senior Engineer at GitLab, I was promoted to the staff and for GitLab it was first staff engineer in front end because previously we had a very nicely developed career stages for backend engineers through senior staff, distinguished and fellow. But our front end engineers were stopped at the senior and there was no possibility to be promoted to staff. I was kind of paving the way for front end engineers.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting. Was there a specific project or something that you felt was like your staff level project?\u003c/p\u003e\n\u003cp\u003eNatalia: I think so, because why didn\u0026rsquo;t we have staff engineers before? Because there was a strong belief that front end side is not complicated enough to have staff engineers. Why would you promote someone to staff if it\u0026rsquo;s something simple, if it\u0026rsquo;s something basic to work on? And my main work after I joined was about introducing GraphQL and Apollo to our front end site. I was actually building the first front end application fully relying on GraphQL API and Apollo client on the front end and we discovered it to be complicated enough. So I was responsible also to share this knowledge, write the documentation and level the whole front end team to be knowledgeable about Apollo client and state management with it. So I think it was evaluated as a staff level effort.\u003c/p\u003e\n\u003cp\u003eDavid: What were some of the challenges around you mentioned like leveling the team up around sort of the Apollo stuff and GraphQL in general. What\u0026rsquo;s the process around that for you?\u003c/p\u003e\n\u003cp\u003eNatalia: Why it\u0026rsquo;s challenging? First of all, because Apollo client itself is not only a GraphQL client, it\u0026rsquo;s not something that we can say is Axios for the rest API. Apollo also offers you caching and caching the data on the front end side can replace any state manager you\u0026rsquo;re using on your front end, be it Redux for React or Vuex because we\u0026rsquo;re using Vue js. And aside of this, when you use Apollo client you kind of change the architecture of your components as well because you are querying data in components and this is very complicated for people who got used to I just dispatch an action and state manager is doing this for myself. It\u0026rsquo;s denied to have a query in the component and teaching them to this paradigm of Apollo cache in general. Also it was complicated because it relies on observables and people who never worked with observables previously were kind of surprised of how it works. How much magic is baked inside this? And GitLab is documentation first company. What do we mean by this? If you own a piece of knowledge, you are responsible for documenting it and making it available for the whole team. We have front end development guidelines, backend development guidelines, they are open source so anyone can check them and see what we\u0026rsquo;re doing and how. And part of being a senior or staff engineer is is also documenting everything you\u0026rsquo;re doing. So you discovered how to test Apollo on the front end with Vue js Because this is non trivial task as well, you need to write the whole documentation detailed and explain things to your team as well.\u003c/p\u003e\n\u003cp\u003eDavid: Was there a process for advocating for the use of Apollo client or any other sort of technologies that you primarily sort of, that you introduced to GitLab?\u003c/p\u003e\n\u003cp\u003eNatalia: This is a great question by the way, because when I just joined we started with GraphQL on the backend so there was an API but front end part was almost non touched in this case I think there was one query done somewhere deep in the component and that was it. And when I joined I created an issue because I wanted to know what path are we selecting going forward? Will we use some client just as a client? So just making queries and mutations with GraphQL or do we want also to leverage State management, because these are two completely different strategies. And I built a proof of concept like a small project. I explained possible options there and it was a great achievement because since this moment we decided to have front end RFCs, which is request for commands. Before it was just like create an issue and discuss. But after this we created a separate repository for RFCs. So any new thing you want to bring is discussed within the RFC. I kind of paved the way for RFCs as well for GitLab. And yes, there was a huge discussion about this. How should we go? What should we use? We analyzed our own state managers and how much we are relying on the API responses in them because of course there is some local state and there is a state that we are storing locally on the front end, but which in fact is just caching data we are fetching from the backend. So kind of a mirror on the front end. And we found out that we have like around 90% of our data just mirroring backend. They\u0026rsquo;re actually not even local. This is just mirror. And in this case using Apollo was good idea because this work with the cache is done almost automatically for you without the boilerplate. So this was a process of discussion.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting. Did you work with a team in order to discover sort of how this was working? And like, was there a process that you followed to sort of like organize your team in order to sort of achieve even just like the description or the documentation first and then the project?\u003c/p\u003e\n\u003cp\u003eNatalia: Yes, definitely. Because I didn\u0026rsquo;t want this to be just brought by one person and okay, I decided on the architecture. You should be all happy about Apollo client. And I was asking other people who were working with GraphQL and Apollo previously, before GitLab to make sure that we are going the right direction. And after this it was an iterative process. So we implement one feature, we document it. I bring this to the front end call because we also have front end calls like hey everyone, please look here. If you have any questions, let me know. If you have any concerns about what we\u0026rsquo;re doing here, maybe this is not the best architecture for us, please let me know again. And after this, when other teams started implementing the same strategy, they were first of all copy pasting the code we had. I think this is a normal process for every single company and this is how bad practices are spreading. The most people just copy paste them from your code and reading the documentation. And this is the moment when documentation starts to improve because I\u0026rsquo;m writing it down how I understand it, but there are People that read documentation say, hey, it\u0026rsquo;s not really clear from the documentation how I do this thing. Can you please explain me? And this is the moment when you start feeling a bottleneck because you are one person and if it\u0026rsquo;s like one developer calling you and asking questions, second, third, it\u0026rsquo;s still just asynchronous calls. And this is the moment when you start improving documentation. Okay, if it\u0026rsquo;s not clear, we should just make it more clear in our documentation. We should just maybe give better explanation there. And this is the moment when team starts to contribute as well. Because the main idea about being staff engineer is scale yourself at GitLab. It\u0026rsquo;s not something that there is you, you cannot be replaced. You just some unique diamond in the team. If you are scale yourself, make other people diamonds as well.\u003c/p\u003e\n\u003cp\u003eDavid: So first of all, you mentioned that when you started you were the first front end staff engineer at GitLab. Has that changed?\u003c/p\u003e\n\u003cp\u003eNatalia: Yes, this changed. There was a second staff engineer because there was a person who was on track in parallel with me, arrived here a bit later. He was working with GitLab definitely longer than myself. I\u0026rsquo;ve been senior for a year and something. He had been working with GitLab I think for five years at this moment and also discovered lots of things on our front end. He was building our front end in these like five people that were starting on the frontend side at GitLab and he\u0026rsquo;s also working with Apollo. As myself, you mentioned a little bit.\u003c/p\u003e\n\u003cp\u003eDavid: About sort of the expectations for the staff level at GitLab. How would you describe sort of the day to day role of both sort of your responsibilities and also if you think it\u0026rsquo;s different, sort of the general responsibilities of a staff engineer at GitLab.\u003c/p\u003e\n\u003cp\u003eNatalia: So first of all you kind of inherit all the responsibilities from senior. So this is building a code with little guidance, building complicated features, collaborating with all the different areas like pm, ux, backend. Definitely. But stuff also has a bigger perspective in general. So you\u0026rsquo;re not building a feature like a small feature that PM just brought and created a task for this. When you\u0026rsquo;re building such features, you are also looking for the architecture and staffs at GitLab are responsible for the front end architecture. This is a big pain for our company. Unfortunately as I mentioned, we didn\u0026rsquo;t have staffs and frontend was considered being simple. This eventually led to the things when we were building features on top of features on top of features without real planning behind them. So we have lots of legacy code right now and staff engineers are responsible for cleaning this up and planning this cleanup for the team. It\u0026rsquo;s not that much on engineering managers and I will mention this bit later, it\u0026rsquo;s more on tech leadership, which are staffs. So you should identify the places that are bad. And by bad I mean when you develop a feature and 90% of your time is not developing is not just trying to fit this feature into existing code. And when you discover such area, it\u0026rsquo;s your responsibility to plan how we should make it better and what is the workload and how this workload is to be planned for the team. You cannot assign tasks. Again, this is for engineering manager, but you should describe this area and bring it up to the manager that okay, we have this kind of tech debt and this should be fixed, of course with product as a priority, but still. And speaking about engineering managers, I better describe a bit our organizational structure because right now we are speaking about staff and this is something like undefined. Okay, we have staff engineers and something else. So at GitLab, when you an engineer, be it back end or front end, the track is single until you\u0026rsquo;re a senior. So we go middle engineers and senior engineers. There are no Juniors at GitLab. There are sometimes interns, but we start usually with middle engineers. And after senior this track splits on two. If you have an interest of being a manager, you go through engineering manager, senior engineering manager, director, and so on. Some people do not have any interest in managing other people, which is completely fine, it\u0026rsquo;s just how it\u0026rsquo;s designed to be. But they have interest in tech leadership. So in this case we go through staff engineers. Right now we have a small reorganization, so there should be principal engineers after staff. Currently there is no such stage, but it\u0026rsquo;s in review, I think. So it will be announced maybe next week and then after this we have distinguished and fellow. If you are a staff engineer, this still means that you have to communicate with people as well as engineering managers do and have some kind of leadership as well as engineering manager does as well.\u003c/p\u003e\n\u003cp\u003eAlex: Would you describe the way that you operate as a staff engineer as similar to the other staff engineers that you have or is there like a common expectation for staff engineers at GitLab?\u003c/p\u003e\n\u003cp\u003eNatalia: There is a common expectation, definitely. But I would say that it\u0026rsquo;s very different for front end and back end staff engineers. Even though written responsibilities are the same, like advocating for innovations, trying new architectures, improving the code, learning something new and teaching other people to this knowledge, and so on. I would say that our backend engineers are mostly focused on their team work or stage. So they have an area of responsibility and they are digging into this one. And for front end you are more widespread. So for example, if we speak about GraphQL and Apollo, this wasn\u0026rsquo;t for my stage or my team, this was for the whole front end. This was a thing that everyone needs to adopt essentially as we adopt GraphQL on the backend and front end. So I would say that me and other frontend engineer, staff, front end, engineer are working rather on the level of front end than on the level of our stages when backend is more focused.\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned sort of the split that happens when you move past the senior engineer role. You either go into technical leadership or you go into management. Did you ever consider going into management?\u003c/p\u003e\n\u003cp\u003eNatalia: Not really. I just don\u0026rsquo;t like the management position and I think I\u0026rsquo;m just not ready sacrificing the pleasure of writing the code. Because at GitLab, when you are a manager you are to communicate with people and this is another kind of pleasure. I can\u0026rsquo;t say that something is better or something is worse for everyone. But for myself, I really enjoy writing the code. I really enjoy discovering new things and refactoring and bringing this knowledge to my team to just explain things. Being a manager, I know that they sacrifice writing the code and I don\u0026rsquo;t want to.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, I think that makes sense. What advice would you have for someone who is making the transition from senior engineer to staff level, especially someone at GitLab?\u003c/p\u003e\n\u003cp\u003eNatalia: It\u0026rsquo;s really nice question. First of all, I would say that be ready for definitely way more communication that you had on the senior level. And be ready to answer questions, be ready to explain things. Be ready to explain things multiple times, even to the same person, just one by one. And don\u0026rsquo;t be irritated over this because this is the thing. And also there is something I recently complained about and it was really funny because there are people that come to you for guidance or for validating a solution of sanity checks. But there will be really hard for you because you don\u0026rsquo;t have anyone to make this sanity check. Sometimes you can do this with your colleague, which is a single staff engineer. And you\u0026rsquo;re like, you too are like, okay, I think this is fine. I hope we are not breaking something essential here. So this is like walking on a swamp. You are not sure that your next step is not a fail. And failing is inevitable because you are discovering new things for your team as well. You have this knowledge after this to bring to them so they are safer and they can ask you. But be ready for this for like to experience something that there is no advice on. Sometimes it\u0026rsquo;s things that you cannot ask anyone in the Internet. So a quick example, we have a Vue JS as our main front end framework and we have Apollo client as our GraphQL client. Unfortunately for us, this is not a mainstream stack. If you work with Apollo mainstream stack as React, Apollo and Typescript for this stack, you can find anything in the intranet. You can find courses, articles, guidelines, stack overflow answers. If you\u0026rsquo;re not sure about something, you can ask Apollo team and they will answer because they work with React and they develop something with React as well. But if you work with Vue, you\u0026rsquo;re about to write things yourself. So we needed to test our components for example, and our components didn\u0026rsquo;t have any kind of way to mock a client, which is a library for React. But for Vue it\u0026rsquo;s non existent. And still to this day if you Google for test view components with a poll. I\u0026rsquo;m just finding my own articles on dev too. This is a bit frustrating when you\u0026rsquo;re an engineer because you really want to feel safer. So yeah, if you\u0026rsquo;re going for this one, you should be prepared.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really interesting. I just wanted to clarify something I think I might have missed. When you\u0026rsquo;re talking about sort of like being in a swamp, you were saying that like, because you\u0026rsquo;re a staff engineer, you might be encountering something for the first time. And so if you become a staff engineer, you should be ready to sort of misstep and that will just be inevitable. And so I\u0026rsquo;m curious, you know, when you\u0026rsquo;re doing this work with less of a safety net, how do you have that sort of like self compassion that you\u0026rsquo;re going to make mistakes or how do you bring psychological safety to those kind of situations?\u003c/p\u003e\n\u003cp\u003eNatalia: So first of all, here will be a praise to my employer, which is non intentional, but this is the context because a few years ago probably people that work in the industry remember that GitLab had a massive, let\u0026rsquo;s say fail. It was a database drop, it was a database that was deleted and unfortunately there was no backup for I think five hours of data. I wasn\u0026rsquo;t working at a company at this moment, but I was reading about this and watching this stream and it was really nice to see that there was no blame from the company to the person who actually did this mistake. And when I joined the company, when you joined the GitLab, first of all, you have to have five coffee calls with random people across GitLab you just select them and call. I called the person who actually dropped the database. I really wanted to hear, like, how it was. He said that there was no pressure from the company. No pressure at all. Because we don\u0026rsquo;t punish people for their mistakes. Wow. Because every single mistake is a thing to learn something. And we learned a lot. And this guy, he became a security specialist after this because he made this mistake. So there was a lot to learn. How to not repeat this mistake and how to be more cautious about this and what comes company should do. So this brings a lot of safety to staff engineers as well, because when you\u0026rsquo;re building a proof of concept, you already that this might not work. There is always a possibility that this is the wrong way and management is ready for this as well, which is really nice. So it\u0026rsquo;s like, usually it\u0026rsquo;s said with a manager, okay, we just give it a try for a week. If it works, it works. If it doesn\u0026rsquo;t, well, okay, we learned something. We just throw it away and we try some other things. So this really helps in psychological sense.\u003c/p\u003e\n\u003cp\u003eDavid: I think it touches on such an interesting aspect of what staff engineers do. Because when I first got to staff, one of the things that I kind of that scared me about it relative to my role before was that, you know, I was really sort of expected to find my own things to work on. And there wasn\u0026rsquo;t really the same sort of roadmap carved in front of me for me to follow. That\u0026rsquo;s really intimidating. It kind of lines up with the loneliness that you described, where there\u0026rsquo;s less sort of sounding boards available around you. Even in an organization with lots of staff engineers, there\u0026rsquo;s still, you know, other people are focused on other things and you\u0026rsquo;re expected to carve out your own area, and it\u0026rsquo;s hard. Do you find yourself doing anything to sort of help other people along that journey? Maybe people that are. Maybe people that are still at the senior level, but that are moving up another way of asking the question, maybe reframing it away from sort of the loneliness. Although I think that\u0026rsquo;s. That\u0026rsquo;s still a factor. But sponsorship and mentorship in general, to what extent is that? Is that something that is relevant to your work?\u003c/p\u003e\n\u003cp\u003eNatalia: So first of all, do I help other seniors? Definitely, yes. Because there are always people who aim to go to staff position and they will ask you questions about what do I lack, what do I need to focus on to be there. Usually it\u0026rsquo;s really nice to help them to find their spark, let\u0026rsquo;s say spark, because I was recently Watching the soul and I really like the term. So to find the spark to work on and to bring to the team where they shine. This is also helping with some communication strategies because at GitLab, if you can have any major blocker on your way to stuff, this will be communication. There should be no conflicts. Or I mean by conflicts I mean something really hard. You shouldn\u0026rsquo;t be conflicting, you shouldn\u0026rsquo;t be pulling ranks, you should discuss with people really nicely being on their level. Because the main fear for myself for example, was and still is like when you get starstruck, when you feel, okay, I\u0026rsquo;m a staff engineer, so I\u0026rsquo;m kind of a queen here and I will just be above you all. This is non acceptable at all. And this brings us to the mentorship because and sponsorship in general. So for me it was something that I really enjoyed being staff because you are required to mentor people, you are required to bring them to your level, to a level of knowledge in particular. And I join it because in my work on Vue js, I\u0026rsquo;m writing documentation. So I\u0026rsquo;m kind of mentoring people on VUE in my open source contributions. So the same happens with GitLab. And while we are speaking about Spark, why I\u0026rsquo;m trying to help people find this because I see that people that enjoy some area, let\u0026rsquo;s say of the code, are great with mentoring and advocating for it. Sometimes of course we are probably too much into it. So when I was building like very first things with Apollo client, there were people that were trying it, using it in a wrong way, which happens. But blaming the technology which is like, oh, this thing is just not working. This library is so bad. No, it\u0026rsquo;s not bad. You\u0026rsquo;re using it wrong. But this is something that makes you want to teach people like, okay, let me explain how to use it in the right way. And when you\u0026rsquo;re mentoring other seniors to go to the staff level, it\u0026rsquo;s communication strategies and mostly finding the area they really like.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really great to hear. Sort of helping people level up through working with them. Earlier you alluded to the fact that you work a lot with sort of other business partners. Well, I guess in GitLab it is a business, but I know it\u0026rsquo;s also an open source project. So I don\u0026rsquo;t know how you refer to your sort of cross functional partnerships. What role do you feel like you have as a staff engineer when you collaborate with another area of the organization with product? I think you mentioned, what do you see your role as a staff engineer is in working with product or other cross functional partners.\u003c/p\u003e\n\u003cp\u003eNatalia: It\u0026rsquo;s a great question because we are required to be cross functional in general. And with product engineer sometimes you can see that you need to squeeze some refactoring or re engineering or maybe even changing the whole structure of the feature PM already planned. This is really hard because you need to explain what technical difficulties you have here and what do you need to change and how it could or should be implemented. And also when you\u0026rsquo;re working with pm, sometimes it\u0026rsquo;s given flesh and bones to the ideas product venture. Have an example to this very abstract description is my product manager was about okay, let\u0026rsquo;s make a page widget. So let\u0026rsquo;s abstract separate features to widgets that can be added to the page, removed to the page, like very basic thing. But with our architecture it\u0026rsquo;s not basic, it\u0026rsquo;s very complicated because we have let\u0026rsquo;s say far from perfect front end structure and building widget in terms of this was really complicated because you don\u0026rsquo;t even know what widget is like. Okay, I want to add widgets. What is widget, is it application, is it component, how it should communicate, what contracts should it have, how it should collaborate with the backend. And here we\u0026rsquo;re bringing backend to the party. It\u0026rsquo;s like okay, how do you want to play? And shaping the API because again GraphQL is shaped mostly by our frontend. This is backend is giving you data you want to see in the schema. And this is also working with the UX because we have our own design system. We have great UX designers and explaining to them what attack difficulties and what can we see here? How widgets should be changed and so on and so on is also part of the game. But also in terms of cross functional, GitLab is not that monolithic. We have three main sections which are DevSeco and Ops. And these teams rarely collaborate so they work on their own areas. But this is not for staffs. So staffs are also included as let\u0026rsquo;s say internal consultants. So you need to build something complicated. You don\u0026rsquo;t have a staff engineer in your team. There are only two front end staffs for the whole company, not even one for the section. And we\u0026rsquo;re both actually in the same section. Other teams kind of go to your manager and say hey, we need the help from your staff engineer. And this is help that needs like lots of working hours. Because if it\u0026rsquo;s like small mentoring, if it\u0026rsquo;s just asking a few questions, this doesn\u0026rsquo;t need to be scheduled, right? But if they need you as a consultant, sometimes you join their team and help them build architecture, help them involve the practices you already learned and consult them on what is better for them currently. And we had a kind of opposite process as well. When there is someone joining your team as an intern to learn something from you as staff engineer, like building architecture, for example.\u003c/p\u003e\n\u003cp\u003eDavid: That consulting model sounds really interesting. Can you say a bit more about the process around that? So you mentioned that a manager will come to your manager and and ask to sort of borrow you. At what stage in the project does that happen and sort of how do you influence the design and to what extent? Like basically what\u0026rsquo;s your time commitment look like to that project while you\u0026rsquo;re, while you\u0026rsquo;re sort of loaned out to it, et cetera.\u003c/p\u003e\n\u003cp\u003eNatalia: It\u0026rsquo;s different, it happened on different stages already. Sometimes it\u0026rsquo;s something that they were already building, but they are stuck currently because there is problems with scaling the project. There are problems with like adding new feature. So this is kind of like a legacy thing and you are asked to go there to make it better, kind of clean up the whole dirt. I know the term is not really nice, but that\u0026rsquo;s what you do. And sometimes you are involved really early when there is an idea to build new complicated feature and people do not know how to make it better. With some new technologies like Polo, like we want to have really extensive local state, can we use this or that? Sometimes it\u0026rsquo;s somewhere in the middle. So a quick example was an application that already had a VUEX state management. So it\u0026rsquo;s like flux, like state management for Vue js and they also had a part with Apollo and there was a problem just to synchronize two states properly because two single sources, not even single two sources of truth already. So how to make it happen? And this is why I mentioned observable, because people had no idea they can subscribe to the Apollo cache and this was very new to them in general. And building a proper one way connection was a problem. So I was asked to be there around and to help them. As for time commitment, it really depends because when I was promoted to staff there was an agreement with my manager that there is like 70% of my time working on our deliverables on our own product and like 30% of time for, let\u0026rsquo;s say staff responsibilities in general. Even if you\u0026rsquo;re not involved into other team, it\u0026rsquo;s like again building documentation, improving it, thinking about migration strategies. Because libraries always update and there is a major update of two main libraries. We Use Apollo and view Both the version 3 kind of version of Doom. It will be really hard to migrate and this is part of responsibilities as well. But when sometimes there is a high priority for other team to build something new and they really, really need stuff. So if it\u0026rsquo;s within 30%, the process is not even formal, they just let you know and let know your manager, okay, she\u0026rsquo;s working with us, is it fine? Okay. Okay. But if it\u0026rsquo;s like some really big time commitment, they should be agreed with the whole team, like with a manager with pm, sometimes director level as well. And in this case it might be like even 100% of time of the staff engineer dedicated to this team.\u003c/p\u003e\n\u003cp\u003eDavid: Something that I was curious to circle back to as well. With that consulting model, you said that sometimes there\u0026rsquo;s like 100% sort of commitment to the new role. In that case, would you be participating in the design aspect of the project as well?\u003c/p\u003e\n\u003cp\u003eNatalia: In technical design, definitely yes. In this case, you would be starting with a very basic architecture and mostly based on our GraphQL API. So what we can do, because it\u0026rsquo;s still limited. So you\u0026rsquo;re bringing the consultant on this stage and you\u0026rsquo;re also explaining really high level architecture to the team.\u003c/p\u003e\n\u003cp\u003eDavid: Right. Going back to another thing you mentioned as well, you\u0026rsquo;ve talked a lot about sort of the introduction of the Apollo client and you\u0026rsquo;ve also talked about sort of some migrations from different state management systems. In general, what kind of strategies do you use for driving a big migration across sort of potentially multiple systems and multiple teams?\u003c/p\u003e\n\u003cp\u003eNatalia: First of all, what we do is we start with removing the parts that are deprecated in a new version and adjusting them to be working for both versions. So this already happened for Vue 3, so we are preparing our code base, at least removing the things that are deprecated in a new version and same for Apollo. So before we even start the migration, we are identifying the parts that we should fix and we can fix in the scope of the current version. So I can say for Apollo client, for example, there are cache updates and they need to be immutable and it\u0026rsquo;s not a requirement for version 2. It\u0026rsquo;s recommended to have them immutable in version 2.6, which is the latest of 2, but you can still go with mutable. So what we did, we haven\u0026rsquo;t migrated to version three right now, but we already made all the cache updates immutable. And how this happens. First of all, again, you create an rfc. Everything starts with an rfc. You explain why this should be Done. And how to do this? You build a prototype, you show this to the team, you build a documentation about this and after this you add a linter. Because any single explanation cannot beat a linter in terms of being effective. Don\u0026rsquo;t mutate the state, we\u0026rsquo;ll int against this. This is the first part of the migration. Next steps are usually you plan what should be done first. So in terms of our Vue 3 migration, for example, we have a component library, GitLab UI, which is unfortunately a wrapper around Bootstrap View. And unfortunately, because Bootstrap view is not migrated to version three, so this is a major blocker, you cannot start a migration. You can only clean up your database and prepare everything to be working as much as possible on both versions. So you need to change as less code as possible. So this is first thing and bringing the migration. It\u0026rsquo;s actually good that GitLab is not monolithic, that we have some standalone app like customers portal, because this is a playground, because you can start migration on these smaller applications to see what else we discovered during the migration and what should be brought to the main code base without breaking it. Also, for such things as like major migration change, we introduce feature flags usually. So if something goes really, really wrong, we just like scroll down. Okay. Feature flag off. Sorry, this wasn\u0026rsquo;t dropped. It works so something like this.\u003c/p\u003e\n\u003cp\u003eAlex: So it sounds like RFC is like the main tool of technical alignment. Does that extend to team level alignment too? Like, do you use RFCs on a team to sort of align on what you\u0026rsquo;re going to do?\u003c/p\u003e\n\u003cp\u003eNatalia: Technically, not really. This never happened on a team, from my memory. It actually only happens for the front end. I recommend the backend team to adopt this strategy as well. So this is not a company initiative. It was initiative of the team to make us aligned and to agree on things. Maybe for the backend it\u0026rsquo;s less effective or maybe even less necessary due to the nature of the front end. Because basically on the backend we have Ruby and Ruby on Rails, so they have more or less monolithic again stack, let\u0026rsquo;s say. So there is no that huge JavaScript platform that includes billions of tools and even for us and also architectures. Again, Ruby has lots of magic baked in, but if we compare with, let\u0026rsquo;s say Vue js, Vue JS is way more flexible. This is good and bad. It\u0026rsquo;s good because it allows you to build whatever you want. It\u0026rsquo;s bad because it allows you to build whatever you want. So you can build anything and you can shoot yourself on the leg without knowing it. So maybe due to this flexibility, we really needed to agree on some things that might sound basic for backend engineers or even for other JavaScript engineers. For example, things like do not use JavaScript classes on view data because for us it doesn\u0026rsquo;t work and there were so many things about it. But there are also major discussions that do not have a correct answer. For example TypeScript, there was a long discussion about should we use types on our frontend or not. While for TypeScript fans it might sound like very obvious, like why not use types? It\u0026rsquo;s type safety. In fact, when we analyze the effort we need to put into it and the profit we would have from it with our test coverage, which is pretty impressive, around 70% for the front end side. For the backend, I think it\u0026rsquo;s like closer to 100. There is not that much benefit from TypeScript for us, but without the discussion in the RFC it wouldn\u0026rsquo;t be that visible.\u003c/p\u003e\n\u003cp\u003eDavid: How do RFCs work tactically? Is it a Google Doc? What platform do you write them in?\u003c/p\u003e\n\u003cp\u003eNatalia: It\u0026rsquo;s a great question because GitLab is all about dog fooding. Eat your own dog\u0026rsquo;s food. So all the discussion happens in issues, but it\u0026rsquo;s not something specific to development. At GitLab, everything happens on issues. If you are human resource specialist, we call them people ops, not human resource. If you\u0026rsquo;re sales special, it doesn\u0026rsquo;t matter. You work with issues and merge requests always. That helps. Testing our own product. So yeah, RFC has issues.\u003c/p\u003e\n\u003cp\u003eDavid: So then is the RFC like a markdown document that you submit as a merge request or is it actually like an issue where you write up sort of the thing and then people comment in a thread underneath it?\u003c/p\u003e\n\u003cp\u003eNatalia: It\u0026rsquo;s an issue. First of all, it\u0026rsquo;s always an issue. And there are two major things you need to do for the rfc. First of all you need to prove that this is two way door decision because if it\u0026rsquo;s not, it\u0026rsquo;s way much harder to convince people to move to it. You should be able to go back, you should be able to roll this down. And second one that we required after like first few months of doing RFCs is implementation. You want to bring something, build a proof of concept, build a small project because not everyone is grasping concepts just from the text. Build me a project so I could run it, play around it and see what is good and what is bad about it. So these are two hard requirements. And after this there is just discussion in the issue. And when everyone is like stopped commenting, we have two weeks and if there are no hard objections from everyone. So if there is kind of consensus on the issue, it\u0026rsquo;s closed and we assign the DRI direct to the responsible individual. Usually this is an author, so if you have any kind of initiative, be ready to implement it because it\u0026rsquo;s yours. Otherwise it just doesn\u0026rsquo;t make sense. Just bring an idea like, I want a typescript now. My dear team, enjoy implementing it yourself. No, it doesn\u0026rsquo;t work this way.\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned something really interesting about two way doors. That resonates with me. I think obviously trapdoor decisions are worthy of a whole lot more scrutiny. However, it\u0026rsquo;s really hard to avoid trapdoor decisions sometimes. I\u0026rsquo;m curious how you think about that. Like from my perspective, adopting TypeScript, once you get to full adoption, that\u0026rsquo;s pretty close to a trapdoor decision. I mean, obviously you can undo it, but the work to undo it is significant. So how would you go about composing an ARC RFC that describes it as a as a two way door rather than a trapdoor?\u003c/p\u003e\n\u003cp\u003eNatalia: When you have a no 2 way door. Okay. When you have a trapper one, you should have really good arguments that are measurable. Don\u0026rsquo;t say, okay, TypeScript is cool, we will have type safety. No, type safety doesn\u0026rsquo;t work. What it will give us in terms of like less unit tests. How much unit tests is it definitely like this, even in just in code streams. How much more code will we need to write in terms of our framework? Evaluate our framework. Because one thing, if it\u0026rsquo;s angular with built in TypeScript support and actually written in TypeScript with Vue JS, it\u0026rsquo;s more complicated. Then you need to obviously describe any kind of caveats. Because if you propose a decision that is not two way door, analyze caveats and describe them as detailed as possible so we will be able to evaluate. Okay, we are going this way. This is dangerous one. We want to know dangers before we start. If you don\u0026rsquo;t do this, usually this is a team doing this and this is usually against the tower decision. This was basically one of the things why TypeScript was not adopted because yeah, too much work, not that much added value, measurable added value for the team. And the fact that going back would be really hard and would block us for using libraries that do not have typings because this still happens for Vue js, not every single library has typings. And yeah, this is really complicated because sometimes we have these decisions and we have them adopted. For example, Apollo client as a state manager is also not the way door because going back to Vuex would require as much work as writing it from scratch. But it was a discussion about benefits and the benefits were actually measured in terms of even the right written boilerplate. And this is measurable because you can compare the boilerplate for two examples and see, okay, this is more preferable for us.\u003c/p\u003e\n\u003cp\u003eAlex: When you\u0026rsquo;re making the argument for a specific RFC, or if you\u0026rsquo;re trying to ask an organization, especially with something like Apollo or GraphQL, which feels like it has a very big impact, do you try and align with some sort of larger organizational goal or are you making almost like a purely technical argument?\u003c/p\u003e\n\u003cp\u003eNatalia: No, no, of course this always goes with organizational goal. Maybe Apollo itself on the front end is smaller side, so it can be decided technically. In our case it wasn\u0026rsquo;t. It was also discussed with lots of PMs and I can even tell you why, because we were going for real time updates as well and this was a major product goal. Definitely not tech team goal. Our product were about, okay, we want issues in merger quest to be updated in real time, which sounds fine in 2020 I guess. And when we were working together with backend team, we discovered that using GraphQL subscriptions in this particular case with our API would be way more performant than just hitting websockets and then just sometimes because our websockets were without payload. So WebSocket has a signal you are refreshing the query. And our REST API queries if you check like GitLab jsons that are returned from REST API, it\u0026rsquo;s huge. It\u0026rsquo;s just a super huge JSON object. So when discussed this all so product goal, real time updates, technical implementation. The best one is GraphQL subscriptions. GraphQL subscriptions better handled with Apollo client. So this leads to like, okay, this is one more point to this one. As for GraphQL API itself, it was discussed I think on a much higher level and way before I joined the company. And it was an interesting moment when we already had an API, but we were not using it on our own front end for a year and a half, I think I have no idea why that happened, so don\u0026rsquo;t ask me.\u003c/p\u003e\n\u003cp\u003eDavid: Switching gears a little bit. One of the things that you mentioned earlier was that GitLab is introducing the principle as rung on the career ladder. I\u0026rsquo;m curious how you think about sort of progressing past the staff level and what you think is required to get there.\u003c/p\u003e\n\u003cp\u003eNatalia: Great question, because I was in the working group for defining an individual contributor path and this is still a tough question for me because we decided to have principal level to be merged between backend and front end, which is complex because you are going deeply into one area of course doing some work that relies on backend. So I\u0026rsquo;m writing Ruby code obviously and our backend engineers sometimes write JavaScript code as well. But this is not on the level of senior engineer by no way. A full stack introducing principal role is still challenging for us because this will be even higher level than staff engineer and you would need to understand not only front end challenges, but also the challenges of the code base in general to making decisions there. I have to say that at this moment the responsibilities of principals look rather badly defined to me. That\u0026rsquo;s why we\u0026rsquo;re not merging this merge request and we are still trying to find out how it should be and how we should work with management. But this is different management level as well. Currently staff engineers report to managers and principal will be reporting to pan level hire, which is senior manager and working with them. And there is also a decision to limit principal engineers to one per team for both backend and front end, which is again very questionable for me because there are some teams like security teams that are working on cutting edge of the technology and maybe there was more sense to have more steps and more principles there. And there are teams that do not require principle at all, which is completely fine. Again. So yeah, it\u0026rsquo;s a good question, but I don\u0026rsquo;t have a good answer for this.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting. One of the things you mentioned there that piqued my interest. You mentioned that we\u0026rsquo;re not going to merge the merge request quite yet. Obviously you\u0026rsquo;re again dogfooding GitLab. Can you say more about how organizational changes fit into a git repository?\u003c/p\u003e\n\u003cp\u003eNatalia: Basically, when you started the company, one of the first requirements for yourself is merge something to the handbook. Because we have a handbook which is an impressive document of thousands and thousands. No, hundreds. Hundreds of thousand.\u003c/p\u003e\n\u003cp\u003eDavid: I\u0026rsquo;ve seen it. It is pretty crazy.\u003c/p\u003e\n\u003cp\u003eNatalia: Yes, it is. So you\u0026rsquo;re requested to make a change there because handbook is continuously evolving and as I said, everything is a merge request. Our guidelines, actually documentation and you met merge requests too. Our organizational structure is again placed on GitLab pages and you just make a change there with a merge request. Our team is changing with a merge request. If you check GitLab team, it\u0026rsquo;s like you might merge request. So yeah, even the word merge request. It\u0026rsquo;s so funny because when you join GitLab, most of people use GitHub for their open source activities or their own repositories and you\u0026rsquo;re constantly fixed. You\u0026rsquo;re like, I made a pull request. We call it merge request here. It\u0026rsquo;s definitely funny. And you get used to this, like, do not merge a merge request.\u003c/p\u003e\n\u003cp\u003eDavid: I confess that I\u0026rsquo;ve bitten my tongue a couple of times over the course of this interview between the difference on those two.\u003c/p\u003e\n\u003cp\u003eNatalia: I know, right? But for me, and this is not because I\u0026rsquo;m working for GitLab, that are merge request is kind of more intuitive than pull requests. Okay, I have changes. I request to merge them to this repository. While pull request is like pull them. What do you mean?\u003c/p\u003e\n\u003cp\u003eDavid: What are some resources that you\u0026rsquo;ve learned from in your sort of journey as a staff engineer and getting there? Books, blogs, people, et cetera.\u003c/p\u003e\n\u003cp\u003eNatalia: Oh, this is really complicated because I think my main resource, and it is funny, was my engineering manager at the moment and the whole promotion was because it was his initiative to promote me and to start working on the promotion document. And my main resource was actually the promotion document because it outlines the areas you need to have and what you\u0026rsquo;re lacking in this case. So for me, for example, I needed to prove that I am able to work with performance and to improve performance, which is non trivial if you think about front end, because what you can improve in terms of front end performance, rendering times. This is bound to Framework lcp. Okay, you have largest contentful pain. This is something you can work with, but again, limited. So it was rather like finding out what I still need to learn and learning with specific resources. So for performance it was just basically JavaScript performance and GS performance articles mostly. Yeah, not really helpful, but that totally.\u003c/p\u003e\n\u003cp\u003eAlex: Makes sense, you know, in general, are there any other blogs or books or people that you see as role models or just like sort of interesting thinkers?\u003c/p\u003e\n\u003cp\u003eNatalia: Yeah, I definitely have a role model. And this is Sarah Dresner, who is vice president of. I might be wrong with her position, honestly. So she\u0026rsquo;s Vice President of Developer Relations, I think, at netlify and we are friends because we are both working for Vue JS Framework as well. Not working, we\u0026rsquo;re just contributing to Vue JS Framework. But it\u0026rsquo;s like another work and I definitely learned a lot in terms of communication and resolving conflicts and being understandable. How to communicate with management, for example, or how to communicate with your teammates, how to resolve conflicts in the team. That all I learned from her.\u003c/p\u003e\n\u003cp\u003eDavid: On that note, I\u0026rsquo;ve been meaning to ask you a little bit about your contributions to Vue JS as well. How long have you been doing that and how do you see that work sort of influencing your work at GitLab or sort of your outlook on software engineering in general.\u003c/p\u003e\n\u003cp\u003eNatalia: So I\u0026rsquo;ve been contributing for more than two, almost three years. Of course, not in the core team for all this time, but I started with working with Vue JS and noticed a few things that I didn\u0026rsquo;t understand from the documentation or they were wrong in the code, in my opinion, and started like small contributions around to the framework, to the documentation. And also at this moment, I started communicating with the team because when you do some subsequent contributions, they reach out and ask you and you\u0026rsquo;re just, okay, let\u0026rsquo;s fix this, let\u0026rsquo;s fix that. And then eventually you gain a core team title because you\u0026rsquo;re already doing lots of workaround and everyone\u0026rsquo;s like, oh yeah, she\u0026rsquo;s core team. No, I\u0026rsquo;m not. I just lack a formal title. Okay, you have it. This is very informal at vgs. If you do something for the framework, you will be in the core team. And how this influence actually a lot because this is beneficial for both areas. In terms of GitLab, I can bring the good practices from the documentation and from the framework and also the latest news as well. So it\u0026rsquo;s like, okay, in version three, we are deprecating this even before the documentation is published. Because I\u0026rsquo;m not even an insider. I write the documentation so I can share this with my team. This is not a secret, it will be published. But also GitLab is a huge code base in Vue and I believe at the moment it\u0026rsquo;s the biggest open source project written with Vue js. And this helps us discover bugs and bring them to the team. That helps us develop good practices and bring them to the world. I know that people are copy pasting our unit tests with Vue a lot and also this helps to shape the product. So, for example, testing library Vue test utils that we have, they were planning a few breaking changes, but when I said, okay, could you please look at our code base in terms of tests? And you are going to break more than 5,000 tests with this change for the company. And this kind of gives library authors the idea of how their product is used in practice. Because when you\u0026rsquo;re writing a framework, sometimes you have no idea how people can use it and they can use it in all the different ways. So this gives an idea to Vue JS and Vue JS ecosystem authors how the product is used and what to do and what not.\u003c/p\u003e\n\u003cp\u003eDavid: That makes a lot of sense. One last question. We\u0026rsquo;re almost out of time, but sort of the perennial question for staff engineers. How much time do you still spend coding?\u003c/p\u003e\n\u003cp\u003eNatalia: A lot, actually. Last week I think all my working time was coding because I\u0026rsquo;m in the middle of future factoring, currently unifying the same stack, and it was a full week of coding. I\u0026rsquo;m really happy about this because previous months were mostly mentoring, which is nice as well, but less coding, less fun.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome. Well, Natalia, thank you so much for your time. It was really, really a pleasure.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, thank you. It was nice to meet you.\u003c/p\u003e\n\u003cp\u003eNatalia: Thank you. It was nice to meet you as well.\u003c/p\u003e\n\u003cp\u003eDavid: Take care. That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show. It is a really useful signal to us that folks are finding value of this so that we keep doing it.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-04-20T09:00:00-05:00","date_modified":"2021-04-20T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/jam-leomi-honeycomb/","url":"https://podcast.staffeng.com/season-1/jam-leomi-honeycomb/","title":"Jam Leomi (Honeycomb)","summary":"One of the things I'm having to get used to now, especially growing into my role, is that some of the stuff I just have to delegate and not everything is up to me to take on to fix.","content_html":"\u003cp\u003eToday we are joined by the inspiring Jam Leomi, who is currently the Lead Security Engineer at Honeycomb. Jam has worked in tech for over ten years, holding positions in both operations and security, and we get to hear about some important milestones in their journey thus far. Jam gives us some great insight into how things work for engineers at Honeycomb, talking about expectations and priorities, and the way they currently split their time between different parts of the job. We also discuss OKRs, communication practices, and how Jam aligns personal goals and values with those of an organization. Listeners get to hear about measuring the success of security practices, strategies for effective rollout, and the task of navigating organizational politics. To finish off this great episode, Jam shares some of the things that have influenced them along the way, from books and blog posts to colleagues and mentors. Make sure to listen in with us on the StaffEng podcast today!\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/jamfish728\"\u003eJam Leomi on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.honeycomb.io/\"\u003eHoneycomb\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/EricaJoy\"\u003eErica Joy on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339\"\u003e\u003cem\u003eAccelerate\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897\"\u003e\u003cem\u003eThe Manager\u0026rsquo;s Path\u003c/em\u003e\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.lastweekinaws.com/\"\u003eLast Week in AWS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://charity.wtf/\"\u003eCharity.WTF\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8303908-jam-leomi-honeycomb.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined joined by my co host, Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;d be delighted to. Jam Leomi is a lead security Engineer@Honeycomb IO. Before that, they worked in tech for more than 10 years in both ops and security roles. I always relish the opportunity to talk to security folks. So let\u0026rsquo;s get right into the interview.\u003c/p\u003e\n\u003cp\u003eDavid: Jam, thanks so much for taking the time to do this with us today. And a good place to start would be for you to just introduce yourself, tell us a little bit about your current role and what led you to that point in your career.\u003c/p\u003e\n\u003cp\u003eJam: Hi, my name is Jam Leomi. I am the lead security Engineer@Honeycomb IO. And what led me to this gig is really that I was searching to do more leadership y stuff and Honeycomb came at me and it was one of those companies where I was waiting for them to actually have an opening and they had all the qualities that I was looking for in a company. Like, as you get further along in your career and you get more senior, you start to have certain things that you want more than just the work. And the work\u0026rsquo;s important, but it\u0026rsquo;s not the, like the overarching factor. So for me it was like good people and what the role would offer me, but like the people and what the product did and how impactful it was was super important to me. So that\u0026rsquo;s the reason I kind of ended up where I was at in the short part of it, the long one. Well, you can keep asking me questions for that.\u003c/p\u003e\n\u003cp\u003eAlex: Awesome. That\u0026rsquo;s really good to hear. So at Honeycomb, are there like engineering levels? At Honeycomb?\u003c/p\u003e\n\u003cp\u003eJam: Yes, there are.\u003c/p\u003e\n\u003cp\u003eAlex: For your role and your level, is there like a typical approach, typical expectation of an engineer?\u003c/p\u003e\n\u003cp\u003eJam: I think the typical expectation is that you\u0026rsquo;re kind of the authority on things. Like for principal engineers at Honeycomb, you kind of are the head of your domain in a sense, and also a lead in kind of your own right. So you do have that autonomy, but you\u0026rsquo;re also required to collaborate and work with other people and kind of be that person. To answer some questions. So, like, for me it\u0026rsquo;s very, very unique because there\u0026rsquo;s not a whole lot of people, at least that I can see in my position. And it\u0026rsquo;s also unique because unlike, you know, many of the other principal engineers, my impact is company wide. So a lot of questions I get are not just from engineering or not just from sales. Like, it\u0026rsquo;s from sales, it\u0026rsquo;s from customer success, it\u0026rsquo;s from hr, it\u0026rsquo;s from finance, it\u0026rsquo;s from engineering as well. Because pretty much security touches so many things.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, that\u0026rsquo;s cool. It sounds like you have a wide impact. Is there something that you feel like you can do in your role as principal that you wouldn\u0026rsquo;t have been able to do, you know, as a less experienced engineer?\u003c/p\u003e\n\u003cp\u003eJam: I think the thing as a less experienced engineer is kind of seeing how you need to shift with the growth of a company. I think that\u0026rsquo;s something that just takes time and experience to learn, like knowing, okay, when the company is growing to this level, here\u0026rsquo;s how you need to shift or here\u0026rsquo;s how you need to balance it. I think early on there was more trial and error, and there still is trial and error, but there was much more. And then probably the second thing is just knowing how to influence people and have those hard conversations, but also like learning the balancing act of compromising and not compromising.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. I want to get back to the idea of sort of influencing folks around you in a bit, but before we get to that, I\u0026rsquo;m curious about sort of like the day to day of your role. And specifically what portion of your time do you spend working on sort of executing specific projects versus team oriented or organizational oriented work like planning, training, recruiting, mentoring, etc.\u003c/p\u003e\n\u003cp\u003eJam: Right now it\u0026rsquo;s kind of a balance between the two and it changes every day. Right now because I\u0026rsquo;m a team of one. There isn\u0026rsquo;t a ton of like day to day mentoring, but instead that mentoring comes in the form of people asking me a lot of questions. Like one of the things I\u0026rsquo;m having to get used to now, especially growing into my role, is that some of the stuff I just have to delegate and not everything is up to me to take on to fix, especially in security. Like some people just need that gut check that everything is okay like to do. And luckily the current company I work at, we have a lot of smart people, they know the basics of security and the things not to do and know to ask first at least to do a gut check.\u003c/p\u003e\n\u003cp\u003eDavid: How do you decide what to work on? Is it largely sort of things coming to you, or is there sort of an element of exploring and finding things that you think are important to work on?\u003c/p\u003e\n\u003cp\u003eJam: Half of it is things coming to me, and the other half is things I kind of want to work on.\u003c/p\u003e\n\u003cp\u003eDavid: Right.\u003c/p\u003e\n\u003cp\u003eJam: More often than not, the people coming to me is more often than the things I want to work on.\u003c/p\u003e\n\u003cp\u003eDavid: Got it. Got it. Is there a process within the organization? So you mentioned, for instance, that you act as a sounding board for a lot of security questions. My guess is that Honeycomb is still at the size where a lot of that is pretty informal. Like someone pings you and says, hey, I want to ask you about this thing, or is there like a more sort of formal process set up for sort of getting. Getting your review on something?\u003c/p\u003e\n\u003cp\u003eJam: You have to keep in mind that I\u0026rsquo;ve only been at Honeycomb for six months. At other places, I have had more formal ways of people asking me, but sometimes the informal just checks out with more people and it\u0026rsquo;s more personable. So I tend to take either.\u003c/p\u003e\n\u003cp\u003eDavid: In the portion of your work where you\u0026rsquo;re driving projects that you sort of identified as being important, do you have any processes around sort of communicating out, like the progress on your work? You mentioned that you\u0026rsquo;re sort of a team of one right now, so I imagine that\u0026rsquo;s even in some ways more interesting. Like, you probably want to still make sure that you\u0026rsquo;re maintaining visibility throughout the company.\u003c/p\u003e\n\u003cp\u003eJam: Usually at companies I\u0026rsquo;ve tried to do good about giving email updates or usually orgs that I\u0026rsquo;m a part of will have, like, team updates that they\u0026rsquo;ll do and I\u0026rsquo;ll add to that.\u003c/p\u003e\n\u003cp\u003eAlex: One of the things that I feel like staff plus engineers do a lot of is sort of finding how to align with the organizational goals. And I was curious, like, how do you approach that with your organization, making sure that the work that you do is in alignment with your organization?\u003c/p\u003e\n\u003cp\u003eJam: Well, for me, I really just always try to keep abreast or aware of what\u0026rsquo;s going on in my organization as well as the business objectives and basically seeing how I can fit in, especially for security, like, what oftentimes you run into is that security isn\u0026rsquo;t the top priority. And so in some situations, like, you kind of have to make do with that security, especially has to keep aware of business objectives so that they can align and that they can make those opportunities happen about getting that growth in for the org.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Do you do any sort of formal measurement or OKRs or anything like that with the organization to make sure that you\u0026rsquo;re in alignment.\u003c/p\u003e\n\u003cp\u003eJam: Yeah, we just started doing those for security. I haven\u0026rsquo;t built them out yet simply because, again, only been at Honeycomb for six months. But at previous companies I have, like, built out full roadmaps. Previously when I was at Splice, I pretty much did that of being like, okay, here\u0026rsquo;s the roadmap and also here\u0026rsquo;s the okrs for each quarter, like, planned down to the week. Yes, I have done that and usually try to align it with the business goals on what was needed. So, like, one of the things is, okay, we haven\u0026rsquo;t gotten a pen test in a while. How about we do that?\u003c/p\u003e\n\u003cp\u003eAlex: When you approach sort of like measured goals, is there any sort of friction that you\u0026rsquo;ve experienced there as an engineer, like, finding a way to, like, measure your alignment?\u003c/p\u003e\n\u003cp\u003eJam: Yes and no. I think what I\u0026rsquo;ve tried to explain, because with security, it\u0026rsquo;s hard because you can\u0026rsquo;t exactly say a metric with security because it\u0026rsquo;s like, oh, no news is good news. I guess that\u0026rsquo;s great. So usually you have to claim it either by impact or like a project completion. So, like, at my last company, it was, hey, did we get this benchmark and stuff cleaned up to match up with this benchmark completed? Cool. That was one way. And it\u0026rsquo;s like, here\u0026rsquo;s how much more secure we are and here\u0026rsquo;s how much we\u0026rsquo;re fixing or did we get this rollout accomplished? So it\u0026rsquo;s more project heavy than metric heavy.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. It\u0026rsquo;s hard to measure the negative. Right. We stopped 10 attacks this last quarter. So if you find maybe tech investment or parts of your process that you want to improve, how do you work with Cross Functional Partners to get that on their roadmap?\u003c/p\u003e\n\u003cp\u003eJam: Well, usually the first thing is try to appeal across the board. At one of the companies I was a part of, one of the things we were dealing with was a password management system. We all knew it was a problem. We all knew it needed to get fixed. Doing the research and being like, here\u0026rsquo;s our possible options. What do you think? So that\u0026rsquo;s one example. Another example is I worked at another company where we had, I think within the first month of me joining, they wanted a new alternative to vpn. And again, that was across the board. The VPN solution they were using was terrible to the point where, you know, some engineers couldn\u0026rsquo;t do their jobs. So, like, finding the common thing of, oh, this needs to get fixed, and using that as an opportunity to find improvements and being like, what new tooling can we introduce and put in and also like keep in mind, like maybe the company may not have enough money for that or maybe they want to test this out to see if it works and see the most optimal solution. So I feel like the best way to start with it is being like, what is a major problem that everyone has and that is visible.\u003c/p\u003e\n\u003cp\u003eDavid: Right. With projects like that, like a password manager or a vpn, what strategies have you seen work well for sort of driving the rollout? Right. Like I think oftentimes if an organization is of sufficient size, it\u0026rsquo;s sort of like you can\u0026rsquo;t just flip it on one day. Like there\u0026rsquo;s sort of a little bit of strategy that needs to go into it to make sure that you\u0026rsquo;re sort of like communicating about it properly and you know, maybe doing a gradual rollout or whatever the case may be. What strategies have you seen work there?\u003c/p\u003e\n\u003cp\u003eJam: Searching for opportune testing grounds I think is a huge thing to do. For the VPN option, they were using VPN for this new ui, but they needed to share with external parties and with the VPN system that wasn\u0026rsquo;t possible for that project specifically, it was a good testing ground to figure out, okay, how can we make this visible to external parties, parties outside of engineering. For me, I took the first two weeks of my job to just of that job to just figure out how to roll out a kind of duo like system using saml. Auth and I tried several different SAML solutions before laying on one and then rolling it out to that new ui.\u003c/p\u003e\n\u003cp\u003eDavid: Right, right. So you had sort of a new use case that you could try with the new system kind of entirely and then once you sort of proved it there, then you could rol to other places.\u003c/p\u003e\n\u003cp\u003eJam: Yeah, so that\u0026rsquo;s one of the ways of doing it for other things that are vendor heavy, that are like more encompassing. Usually having training beforehand before the change happens and letting people know what to expect. Like I\u0026rsquo;ve rolled out new IT solutions which can always be a bear to roll out to people because they\u0026rsquo;re like, what are you doing to my machine? If you are transparent about it, like here\u0026rsquo;s what\u0026rsquo;s going to happen with your machine, here\u0026rsquo;s what to expect. Yes, this is normal. Even afterwards when you repeat yourself it\u0026rsquo;s like, yes, this is normal. And like setting the tone of like this is going to happen, letting people know ahead of time again like emailing people, slacking people, letting them know of timelines of here\u0026rsquo;s how this is going to happen, here\u0026rsquo;s what time it\u0026rsquo;s going to happen. And then afterwards, especially, like with security IT Solutions, ensuring that people know the progress that\u0026rsquo;s being made. Like, okay, we have 25% of the company, like 40%, 50% and so on. So, yeah, it\u0026rsquo;s either finding opportunities to have a testing ground and then communicating to people that the change is happening and what to expect.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. I\u0026rsquo;m curious to what extent you feel that navigating organizational politics is a part of your job, and if so, how do you navigate it?\u003c/p\u003e\n\u003cp\u003eJam: Navigating politics is a huge chunk of my job. I feel like as you get higher up in engineering, in your career, that it just becomes more of a cognizant thing. I feel like sometimes it\u0026rsquo;s just inescapable. So I\u0026rsquo;ve tried my best to just roll with it. And also, knowing office politics and the power dynamics also lets you know, hey, it\u0026rsquo;s time to tap out of this job or not.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, fair enough. What are some of the factors there? Like, which situations do you think are sort of like, hey, this is just like, sort of the normal type of politics that I got a roll with and, like, maybe try to influence. And then what are some of the things where it\u0026rsquo;s like, nope, nope, nope, I\u0026rsquo;m out.\u003c/p\u003e\n\u003cp\u003eJam: I actually posted this on Twitter. Like, I think either this week or last week, about one of my red flags is when they bring in a new C level and the C level brings in his. His buddies, right? Quote, unquote. And it doesn\u0026rsquo;t happen in all the cases, but usually in most of the cases, when a C level order exec brings their buddies in, it creates this power vacuum where it either pushes out or burns out the people that are making the company run. Like, the engineers that are making the company run. Like, that\u0026rsquo;s something that I usually keep in mind. Now, like, in terms of politics, where it\u0026rsquo;s like, we\u0026rsquo;re gonna do this because, like, especially at sea levels, when there\u0026rsquo;s a shift at the top like that, it can change the power dynamics, it can change what\u0026rsquo;s being done, it can change your work being done. That is one thing I do keep an eye on, especially.\u003c/p\u003e\n\u003cp\u003eDavid: Yep, that makes sense. Are there other situations where it\u0026rsquo;s like, no, this is kind of like to be expected, you know, this is like, this is how organizations make decision decisions. Sometimes there\u0026rsquo;s politics and like, in those situations, sort of, how do you try to fit yourself into it and how do you try to influence the conversation?\u003c/p\u003e\n\u003cp\u003eJam: I think when reorgs happen or when people are let go, right? And those are huge changes and they can also be emotionally devastating. But it is also something that happens at companies. Sometimes companies lose money and they can\u0026rsquo;t keep the people that they need to. Or sometimes they have to reorg because they need to move people around. I\u0026rsquo;ve kind of learned to roll with because that\u0026rsquo;s just part of how businesses run, especially in the startup land.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah. Do you have any sort of tools for navigating that? Especially maybe like when it comes to sort of if there\u0026rsquo;s a team that you\u0026rsquo;re working with or folks that are sort of looking up to you?\u003c/p\u003e\n\u003cp\u003eJam: That is a really good question. One of the things that I\u0026rsquo;ve learned from past experiences for this is just being able to hold space for people when it happens, because some people are not going to be able to deal. And by being able to kind of hold space for venting or whatever needs to happen, like for the people who are still there, is beneficial. I appreciated that when it happened at a previous company one time, leadership was very, very keen on being like, okay, what\u0026rsquo;s being engaged on the people still here? Are they feeling okay? Like, you know, are they feeling heard? Like, what\u0026rsquo;s going on? And I appreciate that, that space being held.\u003c/p\u003e\n\u003cp\u003eDavid: One of the challenges that I\u0026rsquo;ve had is when there\u0026rsquo;s a sort of an organizational transition coming. Oftentimes we\u0026rsquo;re in positions where we sort of know that it\u0026rsquo;s coming ahead of time before it\u0026rsquo;s folks. And then I find there\u0026rsquo;s sort of this. It doesn\u0026rsquo;t feel super authentic. Well, I don\u0026rsquo;t always know how to. How to behave in those situations. Like, you know, other people are absorbing news that I\u0026rsquo;ve already known for a little while and it\u0026rsquo;s hard for them. And so when you think about making space, like, do you have any thoughts on sort of the right way to engage with folks that are sort of absorbing the news often, or at least in some cases, sort of news that you\u0026rsquo;ve already known was coming.\u003c/p\u003e\n\u003cp\u003eJam: Really just reminding yourself that you\u0026rsquo;ve already had the news for a bit and that you may have already processed some of the feels that you may have. For me, it\u0026rsquo;s kind of different because I have my own kind of internal processing and I usually try to not let work things hit me as hard. But I know for some others they have their own process of things. And so I think it\u0026rsquo;s kind of having empathy of what the other person may be feeling at the time. And keeping that in mind, this isn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eDavid: Just specific to the context of navigating an organizational change, but in General, how do you think about the difference between our role as technical leaders and management?\u003c/p\u003e\n\u003cp\u003eJam: I feel like management is a whole different ball game simply because we\u0026rsquo;ve been talking a lot about holding space. You\u0026rsquo;re holding a lot more space for people engaging how they\u0026rsquo;re doing, how they\u0026rsquo;re feeling. Like you have to gauge how they\u0026rsquo;re doing their projects. Like how they\u0026rsquo;re doing in general, holding their career growth. Not entirely, but there\u0026rsquo;s bits and pieces that you hold, and this is on top of managing projects that may be happening. The politics of stuff, it\u0026rsquo;s very, very different than being an. I see. Even if it\u0026rsquo;s principal or staff level.\u003c/p\u003e\n\u003cp\u003eAlex: Interesting. Have you ever considered going the management track? You know, going to the other side?\u003c/p\u003e\n\u003cp\u003eJam: Oh, yeah, I totally have. Like, that is because for me, that is one of the stepping stones to get to executive leadership, which is one of my goals. And I still realize that it takes a lot of work and a whole lot more than what I\u0026rsquo;m currently doing in my role.\u003c/p\u003e\n\u003cp\u003eAlex: I was reflecting on the idea that we were talking about how these are different jobs, they take different expertise, but would imagine that we recognize that they both are valuable for different reasons. I\u0026rsquo;m curious, having considered going the engineering manager track, what kind of work do you feel like you can achieve as a senior IC that maybe you wouldn\u0026rsquo;t be able to achieve as a senior engineering manager?\u003c/p\u003e\n\u003cp\u003eJam: Pretty much right now I\u0026rsquo;m able to get some projects done. I don\u0026rsquo;t think as a manager, you\u0026rsquo;re. You\u0026rsquo;re able to get any done within a workday. I\u0026rsquo;ve seen my manager\u0026rsquo;s calendar.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s a lot given that, like, senior ICs maybe have a little bit more time than engineering managers. Is sponsoring other engineers like, an important aspect of your role?\u003c/p\u003e\n\u003cp\u003eJam: Oh, yeah, definitely. And that\u0026rsquo;s something that I hope to do, especially as this role grows and as security parts of engineering grow.\u003c/p\u003e\n\u003cp\u003eAlex: Do you have a particular approach that you\u0026rsquo;ve used or that you\u0026rsquo;re looking forward to using?\u003c/p\u003e\n\u003cp\u003eJam: One thing I love is having kind of game days to kind of teach people security skills. Like, at my last job, one of the things I did to kind of. I used it twofold. One to teach people a skill, which was threat modeling, and the other to glean, okay, what are problems that the engineers are seeing that I\u0026rsquo;m not? And so we played a game called Escalation of Privilege, which is basically setting out, what does our infrastructure and app look like now? Tell me the problems with it using these cards. Yeah, no, it was super cool. And it allowed Me to glean a lot. Like, I ended up playing with two separate groups of engineers, and not only did they know how to think of what are the problems that you may not even think about, but also just again, it helped me learn too, from the context of other engineers.\u003c/p\u003e\n\u003cp\u003eAlex: So, like, outside of the maybe like, leveling people up in their. In their skill set, do you engage in any sort of, like, mentoring in your role at all?\u003c/p\u003e\n\u003cp\u003eJam: I used to at my previous jobs. Not yet for this one, though. I\u0026rsquo;m hoping that to be more so in the coming months. Cool.\u003c/p\u003e\n\u003cp\u003eAlex: In your previous roles, how do you seek to help?\u003c/p\u003e\n\u003cp\u003eJam: Through mentorship, basically, Again, going back to that holding space for mentors to ask questions of being like, how do I do this? How do I do that? I feel like a lot of times, especially with me coming up, there wasn\u0026rsquo;t that space to ask questions or be like, why isn\u0026rsquo;t this working? It was usually just read the manual, and sometimes you don\u0026rsquo;t need the manual, the manual to be read. Sometimes they just need a hand, or as somebody put it, for lack of a better word, sometimes you need just somebody to help you kind of pull the trigger. You know, sometimes you need that help to, like, actually do the thing and have confidence that doing the thing will go right. So, like, holding space for somebody to have success is super important. And, like, a lot of things, you know, that includes like, pairing with a person and being like, let\u0026rsquo;s go through terraform code together and figure out how this work is working and what, you know, what troubleshooting steps that you need to do and also helping, you know, people with their careers and stuff. So, like, some mentorship I\u0026rsquo;ve done, it\u0026rsquo;s more than just questions. It\u0026rsquo;s sometimes on career direction on where should I go, what should I be learning, or can you look at my resume and clean it up a bit? It\u0026rsquo;s kind of been all over the place in terms of mentorship. But I think the big thing again is holding space and helping your mentor succeed.\u003c/p\u003e\n\u003cp\u003eAlex: That sounds like a very great way to be impactful and helpful. One of the things I was thinking about as you\u0026rsquo;ve talked a lot about holding space, and I feel like you\u0026rsquo;re sort of talking about leaving rooms for the sort of emotional side of our job. And one of the things that I think when I think about security is oftentimes it\u0026rsquo;s like maybe my least skilled area, and it might be for a lot of engineers, because it\u0026rsquo;s so technical, there\u0026rsquo;s just so much stuff to learn that I might even feel sheepish or I might feel it might be hard for me to talk about security. Is there anything that you do as a security leader in your company or companies to like, give people the space to come and talk to you about security?\u003c/p\u003e\n\u003cp\u003eJam: I always just leave an open door. This is one of the reasons why if people come at me with questions, I don\u0026rsquo;t have them go through a formal process simply because I want them to be able to ask me questions and give me the proper context of the question. But I try to always leave the door open. I try to always. When I\u0026rsquo;m sending out communications, if people have questions, I\u0026rsquo;m like, if you have any questions, please feel free to reach out to me. I also try to make myself approachable. I\u0026rsquo;m not just a security engineer, I am a person. I try to talk with my coworkers about other things outside of security, things that I enjoy, things that I like. One of the big things about me is building those relationships and building those connections. That way people don\u0026rsquo;t feel sheepish because they know me.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Do you feel like exercises like you talked about previously, where you\u0026rsquo;re like playing a game with someone, do you feel like that makes it easier for someone to come to you in the future and talk to you about security?\u003c/p\u003e\n\u003cp\u003eJam: Oh, yeah, totally. That definitely helped more people come to me with security questions and also helped kind of establish me as the authority at that company too.\u003c/p\u003e\n\u003cp\u003eAlex: Do you have a systemic approach at all to one on ones or anything like that?\u003c/p\u003e\n\u003cp\u003eJam: No, I actually don\u0026rsquo;t. That\u0026rsquo;s like one of the one things that I\u0026rsquo;m kind of building for that one. I try to let it flow organically unless there\u0026rsquo;s something specific that needs to be talked about.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. It sounds like one on ones, though, are something that you do. It just happens organically.\u003c/p\u003e\n\u003cp\u003eJam: Organically or. I know with leadership, I try to have one on ones consistently. I know with our team growing and also some recent stuff internally, it\u0026rsquo;s kind of fallen to the wayside this month. But I hope to pick it back up next month because it\u0026rsquo;s something that really keeps me in tune and in touch with the rest of the company.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. What kind of cadence do you use for your one on ones? And like you mentioned, sort of with leadership, how do you decide who to have your one on ones with throughout the org?\u003c/p\u003e\n\u003cp\u003eJam: Well, the first one is my manager, simply because I always want to stay in sync with them, especially because they are the VP of engineering. But for other people, it depends on whether I\u0026rsquo;m working with them on A project or whether I want to stay and seek with them on stuff. Back when I was first starting, I had like weekly check ins with managers simply because I wanted to get up to speed. And one of these managers had been at Honeycomb for a while, like since the founding. So it was just like, okay. And the other one was with an onboarding buddy, which was also weekly for me. Now, like what I hope to pick back up because our team has grown so much and we have more managers and I only have so much time, it might be more widened out to like maybe every other week with each manager or once a month.\u003c/p\u003e\n\u003cp\u003eDavid: Yep.\u003c/p\u003e\n\u003cp\u003eJam: Cool.\u003c/p\u003e\n\u003cp\u003eDavid: Who are some people that have influenced your approach to work or that you\u0026rsquo;ve learned from throughout your career?\u003c/p\u003e\n\u003cp\u003eJam: I think one of the first examples I had of somebody who looks like me in the industry that I could look up to was Erica Baker, who\u0026rsquo;s Erika Joy on Twitter. She was actually one of the first black engineers that I like, saw when I was interning at Google. Which was funny because the reason why I noticed her is because we got confused with each other while I was interning.\u003c/p\u003e\n\u003cp\u003eDavid: So sure, that\u0026rsquo;s cool. I\u0026rsquo;m aware of Erica\u0026rsquo;s work. That\u0026rsquo;s. That\u0026rsquo;s pretty neat. Are there any blogs or books that have influenced your approach to work?\u003c/p\u003e\n\u003cp\u003eJam: Accelerate. I love that.\u003c/p\u003e\n\u003cp\u003eDavid: Oh yeah, that\u0026rsquo;s an awesome book. Accelerate by Jez. Humble, right?\u003c/p\u003e\n\u003cp\u003eJam: Not just Jez, but also Nicole.\u003c/p\u003e\n\u003cp\u003eAlex: Nicole Forsgren, PhD.\u003c/p\u003e\n\u003cp\u003eJam: Mm. Thank you. But absolutely love that book and the practices that it puts out. Other book for me that\u0026rsquo;s been kind of helpful on my path is the manager\u0026rsquo;s path. I actually really enjoyed that book in terms of reading and kind of giving me an idea of, okay, what does leaders at various roles look like?\u003c/p\u003e\n\u003cp\u003eDavid: Camille Fournier, right?\u003c/p\u003e\n\u003cp\u003eJam: Yep. I love the last week in AWS blog post that gives me all the News. Also our CTO\u0026rsquo;s blog, charity. WTF.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah.\u003c/p\u003e\n\u003cp\u003eJam: Because I feel like she gives some really good insights, especially making it okay for people. Like, I love the manager to IC cycle and how she talks about that. Because I feel like before she posted that I think it wasn\u0026rsquo;t okay to consider, hey, maybe I just want to go back from being a manager.\u003c/p\u003e\n\u003cp\u003eDavid: Awesome article. It\u0026rsquo;s influenced the way I think about it, for sure.\u003c/p\u003e\n\u003cp\u003eJam: Yeah. And I think it\u0026rsquo;s made it more comfortable for people to make that transition without feeling shame about it or like, you failed.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. Did you follow Charity Majors before you joined Honeycomb?\u003c/p\u003e\n\u003cp\u003eJam: Oh yeah. Like I\u0026rsquo;ve been following her since there was an sre con. A few years ago that I went to in Dublin. Dublin, Ireland. I\u0026rsquo;ve been following her since then.\u003c/p\u003e\n\u003cp\u003eAlex: I\u0026rsquo;m curious, you know, Senior, I see lots of influence, lots of meetings. You\u0026rsquo;ve got a lot to do, you know. How much time do you still spend coding?\u003c/p\u003e\n\u003cp\u003eJam: I\u0026rsquo;d rather not say.\u003c/p\u003e\n\u003cp\u003eAlex: Sounds good.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s our final question for everybody. We always got to get that in there. Well, Jen, thank you so much for taking the time again. It was really, really a pleasure to chat with you today.\u003c/p\u003e\n\u003cp\u003eJam: Absolutely a pleasure to chat with y\u0026rsquo; all as well.\u003c/p\u003e\n\u003cp\u003eAlex: It\u0026rsquo;s nice to meet you.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-04-13T09:00:00-05:00","date_modified":"2021-04-13T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/mike-mcquaid-github/","url":"https://podcast.staffeng.com/season-1/mike-mcquaid-github/","title":"Mike McQuaid (GitHub)","summary":"What I try to do is solve problems that have maximal impact, that can only be done by me. Every pull request, commit whatever I make, if I was to create an issue for this instead, would this get done in a reasonable time frame by someone else?","content_html":"\u003cp\u003eToday we have a great guest to talk about his transition to, and current role as, a staff engineer: Mike McQuaid from GitHub! Mike is also a project leader at Homebrew, and brings a wealth of expertise and experience to the table, as well as the obvious added perspective that any engineer from the GitHub team would have. In our conversation, we get into a bit of Mike\u0026rsquo;s journey up until now, the period of stepping up into the position of staff engineer, and how his time spent with open-source projects has influenced his other work. Mike gives us a good rundown of the different levels of leadership that exist at GitHub as well as painting a picture of the way he prefers to oversee engineers and projects. We talk about the healthiest ways to prioritize and tackle work and get into the sometimes murky waters of impact and value measurement. We ask Mike about what it is like working at GitHub where the people building things are also the ones using them, before discussing some thoughts on mentoring and sponsoring, OKRs, and the resources that have been most useful to Mike along the way. Tune in with us today to hear it all! \u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://mikemcquaid.com/\"\u003eMike McQuaid\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/\"\u003eGitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://brew.sh/\"\u003eHomebrew\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8247672-mike-mcquaid-github.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romos and I\u0026rsquo;m joined joined by my co host Alex Kessinger. We\u0026rsquo;re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Our guest today is Mike McQuaid. He is a staff engineer at GitHub. Additionally, he\u0026rsquo;s a project leader for the Homebrew project which is a package manager for Max. This interview is a lot of fun.\u003c/p\u003e\n\u003cp\u003eMike: I got a kick out of what.\u003c/p\u003e\n\u003cp\u003eAlex: The GitHub monolith is called. And on top of that, I enjoyed hearing about Mike\u0026rsquo;s work. I think others will enjoy it as well. Let\u0026rsquo;s get into it.\u003c/p\u003e\n\u003cp\u003eDavid: Mike, it is a pleasure to meet you. Thank you so much for taking the time today. If we could start by having you tell us in your own words who you are and what you do.\u003c/p\u003e\n\u003cp\u003eMike: Sure thing. So I work as my day job as a staff engineer in the communities team in GitHub and yeah, I\u0026rsquo;ve been at GitHub for about seven years and I\u0026rsquo;ve been a staff engineer I guess about six months now and then my related hat outside of work is I\u0026rsquo;m the project leader for Homebrew, a Mac package manager as well.\u003c/p\u003e\n\u003cp\u003eAlex: Awesomeithub Is there a typical set of expectations for a staff engineer or does everyone sort of do it a little bit differently?\u003c/p\u003e\n\u003cp\u003eMike: I think probably a bit of both. There\u0026rsquo;s a set of expectations in terms of what is required for you to hit a benchmark to hit that promotion. So like I guess a base level of expectation across various different kind of metrics. So in my case it was something that we\u0026rsquo;ve been sort of talking about these metrics for a few years and stuff like that. And there were some that I\u0026rsquo;ve probably been meeting for five years and then there\u0026rsquo;s some that were the ones that I was struggling with, which I kind of had to get up to par in order to get promoted. So I think for me it\u0026rsquo;s a combination as well of whether you have those attributes and whether your manager feels that you have those attributes and actually being able to demonstrate them and say in the last whatever, 612 months. Here\u0026rsquo;s a demonstration of say something like mentoring or project management type work or whatever. Being able to actually point to work and say, okay, I did this. And it demonstrated that I was effective and other people respected my work on that, rather than just three years ago I did this, therefore I can do it. So that\u0026rsquo;s fine.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Do you feel like there\u0026rsquo;s a good definition of the difference between someone who\u0026rsquo;s just about to be staff plus and someone who is staff plus or the typical deltas between whatever is less experienced than a staff and a staff at GitHub?\u003c/p\u003e\n\u003cp\u003eMike: Yeah. So for us the leveling goes senior, staff, principal, distinguished, and I guess I\u0026rsquo;ll focus on senior to staff because that\u0026rsquo;s what I know I can talk a little bit about senior to principal. But then our distinguished engineers have been, I imagine like a lot of places, sort of unicorns in some respect. Where I think our internal benchmarks talk about you need to make industry wide impact. So as much of a flowchart you can follow to get that. But I think for us the jump from a senior to a staff looks I guess a fair amount like Will has talked about in the book, where you\u0026rsquo;re taking a step out from beyond what you might already be doing as a senior. You know, we would expect a senior to be doing a certain amount of work like mentorship review, splitting up projects, being able to lead projects, stuff like that. Whereas for a staff we really want to feel that like you not only do all those things and can do those things, but you are pretty excellent at the majority, if not all of them. And also I guess when your work starts to step outside primarily contributing through code. So we have a bunch of senior engineers who spend a lot of time doing things like glue work. I imagine a fair number of the people listening to this will have either read that blog post or heard that talk. So I won\u0026rsquo;t redefine that. But. So we see a lot of people doing that type of work. But it\u0026rsquo;s pretty rare that we have senior engineers where that\u0026rsquo;s the majority of their role is doing stuff like that. Most of them particularly, I guess in the part of the company where I\u0026rsquo;m at, where we\u0026rsquo;re primarily doing user centric feature development, those user centric features that you build are probably going to be the majority of your output, even if they\u0026rsquo;re not necessarily always the majority of your time, that\u0026rsquo;s what you\u0026rsquo;re going to be judged upon. And we see the people who move into staff is when you are going a bit above and beyond on that stuff. So you\u0026rsquo;re not just. There\u0026rsquo;s perfectly great seniors that I work with that will work with a PM or a designer or, sorry, pm, being product manager, designer on the team, their engineering manager, whatever, they\u0026rsquo;ll take work, they\u0026rsquo;ll deliver it on time to a high quality and that\u0026rsquo;s that. Whereas the staff folks, it always tends to be the people who are going a little bit above and beyond. So I guess to think of someone else on my team who just got promoted literally in the last week, so they\u0026rsquo;re someone who, for example, they were tasked with doing a migration for. This is GitHub sponsors was the stuff that we worked on together. So GitHub sponsors used to share a lot of the backend with GitHub Marketplace, which enabled us to get something out the door pretty quickly, but we wanted to sort of split them out. So she was sort of assigned with doing that and instead of just doing the work, cranking out some code, whatever, basically went and split out the work, made a plan for the next six to 12 months of this process, was going to work, and then went off on maternity leave for some of that time and came back and effectively her plan had been executed more or less to the letter while she was away, and everything was just smoothly running while she was out. And to me, that\u0026rsquo;s the type of thing that\u0026rsquo;s not an example that everyone does, but those are the types of things that I look around the company, I see people who are crossing that threshold starting to do when they\u0026rsquo;re doing those type of tasks that are really impactful on a bunch of other engineers. Work beyond just writing code.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. And when you were promoted, was there a particular initiative or a project that you worked on that sort of took you past the finish line?\u003c/p\u003e\n\u003cp\u003eMike: Yeah, I think so. So for me, it was probably two projects that sort of were pretty closely linked. So we have in GitHub, the main application we refer to as kind of GitHub, GitHub, which is a big rails monolith. So GitHub, GitHub, because it\u0026rsquo;s under the GitHub organization on GitHub and it\u0026rsquo;s the repository called GitHub, it\u0026rsquo;s, I think, the oldest repository there. And it\u0026rsquo;s, you know, what the. You can. It\u0026rsquo;s cool going back through the. The full history and seeing the founders kind of when they originally started the company and the project and stuff like that. Yeah, but obviously over however many years it\u0026rsquo;s been Now, I guess 11 or 12 or whatever years that GitHub\u0026rsquo;s been around, that\u0026rsquo;s kind of grown and are certainly one of the highest traffic Sort of Rails monoliths there are, if not maybe the highest traffic, I don\u0026rsquo;t know. But yeah. And when you\u0026rsquo;re clicking around the site, if we release a new feature, if it\u0026rsquo;s something like GitHub Actions, say there\u0026rsquo;s going to be a lot of that stuff that is outside the monolith and you can spin up new microservices pretty easily. But say you want something like on a pull request, you want to have your reviews handled differently, or whatever it may be, that feature is probably 99, 100% of that code is going to be written inside the monolith. So we have hundreds of engineers who are making changes and doing their work probably primarily in that monolith. So two problems that have been building up over time that are sort of related. One was we had an on call rotation for the monolith, you know, started with a probably reasonable number of people when I think I was initially on the infrastructure team when they started that. And it was just the idea of getting more application engineers to sort of take responsibility for the application code side of things, rather than ops people being woken up when it\u0026rsquo;s clearly an application problem. It started off with maybe 20, 30 people, and that rotation had grown to the point where it was probably more like 150 people by the end. So you have people who are on call effectively twice a year for the entire site, and everything that\u0026rsquo;s not a microservice that can go wrong is essentially for them to monitor and watch. I think that obviously anyone who\u0026rsquo;s been on call or dealt with that situation could probably start to immediately cycle through the many things that can and will go wrong in that situation. And I would actually say it held up pretty well for a pretty decent amount of time. But I think the work that was going into it was quite unevenly distributed because you would have some people who really knew what they were doing, who would help out all the time even when they\u0026rsquo;re not on call, and then some people who would be on call and just, you know, spent the shift hoping that they weren\u0026rsquo;t going to get paged. And if they did, you know, they knew how to handle things reasonably well. But there certainly wasn\u0026rsquo;t that level of, in my opinion, the ideal, which is that when I get unpaged, it\u0026rsquo;s for something that I\u0026rsquo;m closely related to, perhaps even ideally something that I\u0026rsquo;m actually working on. So that presented us with a problem that, okay, well, what we want to do is effectively split this up so that every team that\u0026rsquo;s Working on the monolith has their own on call rotation. But then that presented a comparable side by side problem, which was, okay, who owns what code in the monolith? So we have, I\u0026rsquo;m sure a lot of folks have used kind of the code owners feature on GitHub where you can make certain files or whatever owned by certain teams. And then we had our own thing which sort of predated that, called areas of Responsibility, which was sort of a more declarative thing that you could annotate your Rails models and things like that, sorry, Rails controllers. And the problem was is that these had both been around for a while. They disagreed with each other in certain ways. They weren\u0026rsquo;t very heavily linted. And whenever you had a company reorg and a team used to own this and now owns this, those cases weren\u0026rsquo;t always updated. So we ended up with a problem there of how to assign that ownership and get that information correct and stop a certain degree of backsliding. So we introduced a thing which is unlikely to be publicly shipped because it\u0026rsquo;s pretty special snowflake territory for how vast our monolith is and stuff like that, a thing called Service Owners, which is effectively a bit like code owners, but splits the code base along the lines of services rather than things being owned by teams. So effectively it moves what was a one to one mapping to a one to one to one mapping. So you have, instead of a file being owned by a team, a file is now owned by a service and a service is maintained by a team. And that has allowed us to kind of sort out the ownership and make the linting a lot stricter. So you can\u0026rsquo;t have teams that accidentally own, Sorry, multiple teams that accidentally own the same file, whatever. But then that also allowed us to comment out all our on call stuff as well. So things like exceptions, background jobs, failing, a lot of our logging, all this stuff\u0026rsquo;s now annotated with the service and then the service from that you can look up the relative team and then effectively page the right people. So I sort of was involved with the initial conception of that and then I probably did a lot of maybe the majority of the implementation side and ship that to completion at the same time as splitting out the encore rotations and developing a bunch of training and stuff like that alongside that to kind of try and ease people into the new process and good ways of doing Encore and things. So yeah, for me, I think that was the sort of project that very much felt like a sort of staff project that I think got me the promotion.\u003c/p\u003e\n\u003cp\u003eDavid: Interesting. I want to circle back to sort of the service owners thing and to sort of project execution in general. But something that you mentioned earlier, you mentioned that, you know, you oversee the Homebrew project. We\u0026rsquo;ve noticed a pattern where a lot of staff engineers we talk to are also pretty heavily involved with Open source or have previous experience as a, as a founder or as an early employee at a startup or. Anyway, I\u0026rsquo;m curious to what extent you think your experience in Open source has influenced your sort of day to day work. And especially if you think there are aspects of the staff engineer role that sort of stem from your experience in Open source.\u003c/p\u003e\n\u003cp\u003eMike: Yeah, no, I think so. And I mean the early stage startup stuff as well. I wouldn\u0026rsquo;t have thought about that necessarily, but that feels related too. So I think the thing that I see on both of them, I guess the biggest thing from Open source is, at least in GitHub, staff engineers and principal engineers do not have direct reports. We live in the org chart. And some staff engineers report to directors instead of engineering managers and principal engineers report to VPs instead of directors. But because you don\u0026rsquo;t have that reporting relationship, you don\u0026rsquo;t so much have the ability to order people around. Essentially. Probably the most formal power you have is the ability to say no to things and sort of shoot down proposals or require changes to be met. But if I want someone to do something for me, I can\u0026rsquo;t go and tell them in terms of how the organization is technically run. That\u0026rsquo;s down to their manager or product manager or whatever to decide. And in a lot of ways that\u0026rsquo;s very similar to Open source, where on Homebrew I can\u0026rsquo;t ever tell anyone what to do, or I can try, but they won\u0026rsquo;t necessarily do it. So I feel in both cases you can have someone who has effectively no hard power, but quite a lot of soft power. So with Homebrew, I\u0026rsquo;ve been working on the project for I think 11 years now. I\u0026rsquo;m almost losing count at this point. And most of the maintainers who are around today, I\u0026rsquo;ve been involved with kind of proposing that they join the project and helping them on board and stuff like that. So I think there\u0026rsquo;s a certain amount of kind of trust there that they know that I\u0026rsquo;m not going to just bark orders at them. But at the same time, if I do sort of say, hey, please can we do this? Or I really strongly object to this a lot of the time that\u0026rsquo;s enough for people. It\u0026rsquo;s not always. And there\u0026rsquo;s definitely times even in the last year where I\u0026rsquo;ve been quite frustrated that I don\u0026rsquo;t have more hard power and I can\u0026rsquo;t just say no to things and I lose arguments. But I mean that\u0026rsquo;s probably a sign that it\u0026rsquo;s healthy and that the process is working well, that I\u0026rsquo;m not just getting to getting to boss people around. And I guess similarly the early stage startup, I think the other thing that comes from both open source and that angle. I was the first employee at a company called Mendeley a few years ago and I feel like there\u0026rsquo;s a to talk about, I guess Will\u0026rsquo;s archetypes. I kind of see myself along the lines of a solver with the work that I do in GitHub. And I think there\u0026rsquo;s definitely an open source and early stage startup approach of being like, if you have a problem and it technically belongs to another team, do you just say to that team, hey, I want need you to do this? Or do you go and basically see the problem through to completion yourself? Which may or may not involve the other team doing it or not. But it\u0026rsquo;s kind of taking ownership of some of these problems. And it\u0026rsquo;s definitely something you see, the more junior an engineer is, the more they may feel slightly, I don\u0026rsquo;t know, helpless or frozen or whatever if something is very much outside of the responsibility of them or their team.\u003c/p\u003e\n\u003cp\u003eDavid: Especially in a bigger org, right? It\u0026rsquo;s really tempting to look at a problem as a junior engineer in a bigger org and say, oh yeah, that\u0026rsquo;s a problem, but it\u0026rsquo;s not my problem.\u003c/p\u003e\n\u003cp\u003eMike: It reminds me in many ways that it\u0026rsquo;s very similar with open source. And I guess, Obviously, unsurprisingly in GitHub almost all of the stuff we do, including a lot of even configuration if I want to be added or removed credentials for a service that\u0026rsquo;s a pull request on a repository that gets a review in a merge and stuff like that. It\u0026rsquo;s quite easy for me to look at that and see the part of my brain goes oh, this is open source, I know this and say okay, well if I\u0026rsquo;m making a deploy and there\u0026rsquo;s a message in there that\u0026rsquo;s output that I\u0026rsquo;m like that\u0026rsquo;s wrong or that\u0026rsquo;s really confusing or why doesn\u0026rsquo;t that link to the document that someone asked me about, I can just go and create a pull request and try and make it better. And it may be that that\u0026rsquo;s not always the best thing to do, or it may be that that will Tread on toes or that the other team will kind of have a different direction they want to go from my pull request. But again, that\u0026rsquo;s similar with open source. Not every PR I submit is one that I would expect necessarily to be merged. But the idea of doing that rather than, I guess, the open source consumer, or maybe as you say, big corporation approach of well, I\u0026rsquo;ll just go and ask the other team to do, doesn\u0026rsquo;t always pay off how it should because it may well be important to you, but it\u0026rsquo;s quite possibly not important to them. And if you\u0026rsquo;re willing to do the groundwork or the coding work or the testing work, or any part of the work really to facilitate that, then you may well find that that team, that maintainer, that project, that company, is dramatically more receptive to doing what you would like them to do. It\u0026rsquo;s making it easy for them to do the right thing.\u003c/p\u003e\n\u003cp\u003eDavid: That makes sense. And it\u0026rsquo;s actually a good segue to the next thing I wanted to ask you, which is basically, how do you decide what to work on?\u003c/p\u003e\n\u003cp\u003eMike: Yeah, so this is something that gets kind of a lot of conversation and thought and I\u0026rsquo;m still figuring this out. So thankfully I\u0026rsquo;m lucky enough to have kind of some good mentors at the company who\u0026rsquo;ve been doing this stuff better and longer than I have. But what I try to do, in my case, it maybe sounds a little bit, I don\u0026rsquo;t know, hubristic, but I think because I\u0026rsquo;ve been around the GitHub for a while and again because I worked on stuff like Homebrew for a while, I have sometimes more historical context, more relationships, and more, I guess, awareness of how other things are done. So what I\u0026rsquo;m trying to do is solve problems that have maximal impact, that can only be done by me. And that sometimes means writing the code, sometimes it means writing up a proposal or an issue or mentoring people or whatever it may be. But certainly, I guess a guidance for the code that I do write I try to have because I guess there\u0026rsquo;s that classic staff engineer thing of are you writing code anymore? Are you writing as much as you used to? And in my case, yeah, I\u0026rsquo;m definitely writing less than I used to, but I\u0026rsquo;m still writing probably a non trivial amount, but I\u0026rsquo;m trying to keep it focused on every pull, request, commit whatever I make. If I was to create an issue for this instead and completely wrote up what needed to be done here, would this get done in a sort of reasonable time frame by someone else? And if the answer is yes, then I shouldn\u0026rsquo;t be writing that code. And if the answer is no, then I guess the next question is, is this actually important and worth doing? Or is it me fiddling around with something that I find indulgent and fun rather than is really impactful? But you know, I\u0026rsquo;m human. I\u0026rsquo;ll allow myself to do that every so often. But that\u0026rsquo;s the stuff I\u0026rsquo;m trying to do at least, is trying to focus on things where I feel like the way the organization is set up right now, it\u0026rsquo;s not going to get done otherwise. And then I guess the remaining parts of my work, I try and have a. I\u0026rsquo;ve tried to sort of set. I was, when I initially was staff, kind of was on a feature team and was doing sort of some of this type of work, like on top of that work. But I found that didn\u0026rsquo;t really scale terribly well. And I think I just felt like I was a blocker on that team because I would get assigned work to do and then other stuff would keep pulling me away from that. And I just felt like I was very unproductive in holding other people up. So instead we\u0026rsquo;ve sort of moved more to a model where I\u0026rsquo;m encouraging. Basically any engineer on the team can come to me at any point and say, hey, Mike, I want you to review this. I want you to help me with this, whatever. And that\u0026rsquo;s, I guess, the sort of push. And then the pull side is I have weekly meetings with my director, at least one other ic, with my manager, people like that. And from them I\u0026rsquo;m trying to almost like extract from them anything useful I can do to help. So I\u0026rsquo;m looking for things where they have a gripe or whatever or think or say, hey, what would you think about this idea? And trying when it\u0026rsquo;s something I know that they care about, trying to almost go and often jump in, solve the problem before they\u0026rsquo;ve even had a chance to think about it idea I liked that a previous manager, before I was staff, actually, when he was talking about what he wanted me to grow into is he was talking about giving me a box of files rather than a file, just almost like, right, here\u0026rsquo;s all the stuff I need to deal with right now. You figure out what\u0026rsquo;s important, go off and do it and come back to me when it\u0026rsquo;s done. And I will hopefully not have to give you dramatically as much guidance as I would have to give to a senior or lower engineer. And I find that\u0026rsquo;s the type of work I find that\u0026rsquo;s really rewarding is when my director has something which has been bugging her or whatever and I can just go and say, right, I\u0026rsquo;ve done it without there needing to be a conversational back and forth or okay, I\u0026rsquo;ll add this to my roadmap and get to it in a month or whatever it may be.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting. So I think I hear what you\u0026rsquo;re saying is sort of like the work that you choose to do is something that you\u0026rsquo;re uniquely situated to do, but also highly impactful. And it does sound like you\u0026rsquo;re getting sort of like organizational signals sometimes that like this work is highly impactful. Are there any other tools that you use to make sure that the work that you\u0026rsquo;re doing is impactful to the organization as a whole?\u003c/p\u003e\n\u003cp\u003eMike: Yeah, no, that\u0026rsquo;s a good question. I mean, for me. So the stuff I\u0026rsquo;ve been doing most recently is kind of. It\u0026rsquo;s somewhat obviously impactful in that it\u0026rsquo;s very measurable work. So I\u0026rsquo;m improving some parts of our, I guess, local developer experience that like all of the people working on the monolith have to run some of this stuff ten times a day and I\u0026rsquo;m shaving like minutes off the time. And that\u0026rsquo;s the stuff where impactfulness, you can pretty much do back of the napkin calculations of how much time and probably even how much money you\u0026rsquo;re saving the company. When do you improve stuff like that? Beyond that? I find it slightly harder. Certainly the stuff I was mentioning with almost helping my director and stuff like that, I find those are the things that I struggle with a little bit more to articulate the value directly beyond just this person is my boss, they want this done. So I\u0026rsquo;m going to do this to help them. But I guess even the performance work, I guess the way I came about discovering that work is looking at a few years ago, I would have maybe been a bit more cynical about stuff like our OKRs, whereas I looked at our CEOs OKRs, our department\u0026rsquo;s OKRs, and got thinking maybe a little bit more abstractly, like, what does it mean to do this? So one of ours was talking about we\u0026rsquo;re doing a lot of performance work on GitHub at the moment to try and make the site as a whole a lot faster basically and cut some of those edges. And that kind of got me thinking about, well, we\u0026rsquo;re doing this effort on the site. But if you read the OKR describing this, it\u0026rsquo;s not just external facing stuff. We\u0026rsquo;re trying to be high performance in general. So what does that look like when you look through the lens of empowering engineers on our team to have higher performance tooling and things like that? So I can\u0026rsquo;t necessarily speak to what that\u0026rsquo;s going to turn into in the future because I\u0026rsquo;m not really sure. And this has been the first probably big thing I\u0026rsquo;ve picked up since my kind of role has changed and I\u0026rsquo;ve left a feature team. But yeah, I guess I would like to have something which is I can demonstrate a measurable impact effectively.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s really cool. You mentioned that you\u0026rsquo;ve done sort of infrastructure work and then earlier you were talking about how you improve the on call experience for the monolith. And I feel like you\u0026rsquo;ve talked about like performance and sometimes those things because I think many engineers see the innate value in that kind of work, but it\u0026rsquo;s not always necessarily explicitly visible to the whole product experience. You know, do you or does GitHub have like a framework for understanding the impact of that sort of work that\u0026rsquo;s less than visible in maybe the product experience?\u003c/p\u003e\n\u003cp\u003eMike: So for us, the performance work right now is being like that has actually been signaled pretty much from the top, that this is really important and this is a high priority for us as a kind of engineering Org and even as a company right now. So I think that\u0026rsquo;s helped. And I think from that perspective, I\u0026rsquo;ve never had direct reports, let alone kind of been vp, C suite, whatever. But I think having in this case a CEO and a VP of engineering who are both still fairly deeply technical and have a deeply technical background, I think that has helped with this type of work in that they\u0026rsquo;re not just expecting features to get cranked out the door and not really consider things like on call tech debt, performance, stuff like that. I think their leadership has kind of helped from that perspective. But I think as a company, I think it\u0026rsquo;s something where again hopefully it\u0026rsquo;s something that staff engineers and principals and above are sort of contributing to that conversation as well. Because you can see sometimes flows where a product manager has spoken to users and this is what users want and they work with kind of a designer to sort of spec up what\u0026rsquo;s going to get built and then the engineer kind of works with the implementation and builds it. And that\u0026rsquo;s a flow that works really well when you have a really good insight of what you\u0026rsquo;re building and what\u0026rsquo;s important. And as you say, when you have those organizational priorities. Right. And I think the tricky thing sometimes is if you have an engineer who assumes that the product manager is aware of technical debt and that they need to pay it down and that the fact that they\u0026rsquo;re not talking about it means that they just must think it\u0026rsquo;s not a priority right now. I think that\u0026rsquo;s something that is a sort of interesting diversion from that which I see, I guess some engineering managers, but certainly in GitHub, I think that\u0026rsquo;s a big part for the staff engineers to play, where they\u0026rsquo;re kind of coming in and saying sometimes, okay, this might look like a simple problem, but we really have to pay down some tech debt while we go along. And they are the ones who are sort of speaking to the product managers, speaking to engineering managers or whatever, and sort of articulating those concerns from more junior engineers who may sometimes know that there\u0026rsquo;s tech debt and it\u0026rsquo;s a problem that needs to be solved, but they may sometimes struggle to explain that in a sort of business centric framing rather than just this code is crappy, it needs to be improved. The staff engineers can actually articulate like, well, you know that feature that we just built that took longer than you thought it should have taken for us to do that? Yeah, we think it\u0026rsquo;s taken longer than it should have done too. And the reason why is because of X and we need to fix X before we pick up something else like this. And when you see people, senior engineers, staff engineers, whoever really speaking to product managers or whoever on those terms, then obviously it\u0026rsquo;s a smooth process. The product managers want this stuff and they care about this stuff being prioritized and dealt with too. It\u0026rsquo;s just sometimes there\u0026rsquo;s sometimes assumptions made that it\u0026rsquo;s that one person\u0026rsquo;s focus is the same as another person\u0026rsquo;s focus. And that\u0026rsquo;s, I think the staff folks I know in the company at least are the ones who are much better at sort of cross pollinating those ideas and making sure everyone\u0026rsquo;s on the same page.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. And I think it addresses a lot of sort of like how staff engineers can interface sort of upward in their org. One of the things that I\u0026rsquo;ve seen staff engineers do as well is act as sort of the mediator sometimes between teams that sit, you know, quote unquote below them in the org. So sometimes there\u0026rsquo;s like different teams that are, you know, maybe they\u0026rsquo;re planning projects that overlap and the staff engineer is helping them sort of find alignment in those projects, or maybe they have a difference on how something should be implemented and the staff engineer sort of helps Them find common ground. Have you seen that pattern as well? And if so, do you have any thoughts on sort of the, you know, how staffingers can be effective in that role?\u003c/p\u003e\n\u003cp\u003eMike: This is the first one I have to be completely honest and say I haven\u0026rsquo;t seen that pattern at all actually, because we have. So the, the part of the org I\u0026rsquo;m in, we have I guess three teams technically that are sort of underneath us, but they have been. I mean, a lot of this is down to our director. Our director has done such a good job of building those teams to feel like they\u0026rsquo;re one big team and that they\u0026rsquo;re one. You know, it\u0026rsquo;s called the Communities organization. So there\u0026rsquo;s an obvious pun about them being a community of teams there. But yeah, I think they\u0026rsquo;ve done that in such a way that I don\u0026rsquo;t think I\u0026rsquo;ve ever seen those teams be kind of oppositional to each other at all. I feel like I would be the first one to jump in and try and smooth things over and have people get on okay if that wasn\u0026rsquo;t the case. But it\u0026rsquo;s not something I\u0026rsquo;ve actually seen myself.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s fantastic. In that case you mentioned a minute ago, okrs. So it sounds like that\u0026rsquo;s a process that GitHub uses to sort of set objectives throughout the org. How do you work with your team to set objectives for sort of your group?\u003c/p\u003e\n\u003cp\u003eMike: Yeah, so from us there\u0026rsquo;s, I guess different okrs come from slightly different directions. So we have, you know, the company wide ones and team wide ones and even kind of in some cases ones that tie directly to kind of products that were, I guess, products within GitHub itself. Obviously GitHub itself is one product, but say something like GitHub sponsors, which has been something I\u0026rsquo;ve spent a lot of my time working on. So there may well be okrs that specifically relate to that. So generally those are kind of someone is the directly responsible individual who is kind of going to come up with the drafts for them and kind of push the process through to the conclusion. And generally someone\u0026rsquo;s kind of drafting these up and then we tend to have a fairly open discussion, sometimes in meetings, sometimes in Google Docs, sometimes on pull requests, on markdown files on what people think about those. What people think about both the OKRs themselves and how they map to. I imagine like most orgs, we tend to have ones where the CEO has their OKRs and then as you go down the hierarchy, effectively they look like more granular versions of what the company wide or CEO wide okrs are. So we\u0026rsquo;ll have discussion about how much we think they fit and how much these things are the things that we think are best able to impact those goals. And then obviously there\u0026rsquo;s the debate about numbers as well. I forget what our internal definition is, but it\u0026rsquo;s along the lines of you shouldn\u0026rsquo;t be unambiguously smashing all the numbers in all your KRs. If that\u0026rsquo;s the case, then it\u0026rsquo;s a sign that maybe they\u0026rsquo;re not quite as ambitious as they could be or should be. But yeah, it\u0026rsquo;s a fairly, I would say a pretty collaborative process sort of all around. And we try and have it be in such a way that the most junior engineers in the team are able to have just as much voice and input on those as folks who have been around for a long time and maybe a bit more senior.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s interesting to hear something that occurred to me as we were talking about sort of like cross functional partnerships. You were, you\u0026rsquo;re mentioning like a product manager. I wonder if you could speak to this if like, is it a unique experience working at GitHub also being an open source project maintainer? So you\u0026rsquo;re literally using the product that you\u0026rsquo;re building. And I\u0026rsquo;m curious, does that impact the sort of conversations that you have with your product team?\u003c/p\u003e\n\u003cp\u003eMike: Yeah, in fact this was something that came up. We\u0026rsquo;ve got a book club for the staff eng book happening at the moment. And this is something that came up yesterday actually is that pretty much every engineer at GitHub is able to provide some sort of pretty well informed input into the product because I guess from outside the company you would look at open source as well as being obviously, I guess in my case I was probably using GitHub on a daily basis for three years or so before I ever kind of applied to join the company, which took me three times instantly. And at the company your average engineer is doing the same thing. Everything on GitHub is on GitHub. Probably in the last couple of years we\u0026rsquo;ve started using some tools like Google Docs a little bit more. But certainly when I started everything was an issue was a PR. The main default place for information to live on GitHub is on GitHub, certainly for engineers and people inside the engineering. Org. And again similarly the default way of doing things on basically every repo is making a pull request and reviewing it that way, even if I\u0026rsquo;m updating documentation and it\u0026rsquo;s an actual typo, it would be very rare for me to just Push a commit because then you don\u0026rsquo;t have that almost notification and conversation and stuff like that. So I think, yeah, as a result, obviously we have a lot of people in the company who are very, very opinionated, justifiably so, on how the product should work and what things it does that we like and what things it does that we don\u0026rsquo;t like. And when it\u0026rsquo;s kind of interesting because there\u0026rsquo;s some features, I won\u0026rsquo;t point out the specific ones, but there\u0026rsquo;s some features that we\u0026rsquo;ve had to build a few years ago or whatever for various kind of contractual compliance reasons. And then we have to eventually comply with some of these same standards, particularly post acquisition by Microsoft. And people find some of them really annoying. Some of the kind of behaviors which were previously enabled or maybe more socially enforced and are now technically enforced, and people find it quite annoying. And that\u0026rsquo;s both a pro and a con. Because I guess our management team, their attitude is. Which I actually thoroughly agree with in that like, well, that\u0026rsquo;s good because probably everyone who has to deal with these compliance requirements on GitHub finds it annoying. So let\u0026rsquo;s find a way of making the entire product better for people in these cases. Rather than saying, okay, well, we\u0026rsquo;ll just turn this off for us or we\u0026rsquo;ll hack around it or whatever, because we don\u0026rsquo;t like this feature, let\u0026rsquo;s say, okay, let\u0026rsquo;s make this feature kind of better. How can we avoid this pain for other people? And yeah, I do think that that. To go back to your original question, Alex, I do think that that informs the conversation with product a lot because when you\u0026rsquo;re talking about particularly stuff around pull requests, GitHub actions, GitHub sponsors, whatever, then we have people who have a lot of experience and a lot of opinions and it\u0026rsquo;s nice to see the vast majority of engineers at the company, I would say, would be pretty comfortable expressing those opinions on how they think the parts of the product that they\u0026rsquo;re using should be working. But then on the flip side, there\u0026rsquo;s the slight. It\u0026rsquo;s not unrelated to kind of the open source analogy we were saying before, where if you\u0026rsquo;re on the pull request team at GitHub or we don\u0026rsquo;t have a dedicated pull request team, but the team that maintains pull requests at GitHub, then it\u0026rsquo;s a little bit more painful for you working on something which people use every day and people are making probably thousands of pull requests inside the company, maybe even tens of thousands on a daily basis. And if you slightly move their cheese, then you hear about it a lot quicker than someone who\u0026rsquo;s, you know, working on some enterprise SAML feature or whatever that you may well end up touching eventually, but it\u0026rsquo;s not so integral to their workflow. But then again, the flip side of that is I think that does make us conservative on the things that are used very, very heavily, which is probably a good thing because as much as it\u0026rsquo;s important for us, we have millions of users who are using GitHub every day who don\u0026rsquo;t want their cheese moved either. So if we\u0026rsquo;re going to do that, then we have to do it in a good way and for a very good reason that they\u0026rsquo;re going to be eventually happy for.\u003c/p\u003e\n\u003cp\u003eAlex: Earlier you were talking about how sponsorship and mentoring, it sounded like it was a part of your role and I was curious what your approach to sponsoring and mentoring was.\u003c/p\u003e\n\u003cp\u003eMike: Yeah, great question. So I think my approach is mainly around, I guess, two ways I look at it. So I try and have, if there\u0026rsquo;s someone I\u0026rsquo;m kind of working with at the moment, kind of relatively focused weekly meeting where it\u0026rsquo;s just one on one with just me and them to try and I guess almost work with them in a sort of manager like relationship to talk about whatever their goals are and see what we can do to work towards that on a given week. I don\u0026rsquo;t actually end up doing a lot of pairing just because time zones mainly because my team is mainly in mid and west coast of the US and I\u0026rsquo;m in the uk, so I don\u0026rsquo;t have a ton of time zone overlap with people. But what I try and do is I try and have that chat for sort of focus time and then encourage them to sort of think about what they\u0026rsquo;re going to bring to me and bring things to me throughout the week, but then also try and stalk them a little bit as well. So I try and keep an eye on what they\u0026rsquo;re up to, try and jump in and help them out if I can, try and just generally support them wherever I can. And then the big part of the role, I think as well, has been getting people towards promotion. So most of the people I\u0026rsquo;ve been mentoring have been people who are on the cusp of moving from one level to another, maybe becoming a senior engineer or becoming a staff engineer, for example. And I\u0026rsquo;m kind of, either they\u0026rsquo;ve been pointed to me or I\u0026rsquo;ve been pointed to them so that we can kind of work together on that kind of process. So hopefully they can get promoted. And yeah, I\u0026rsquo;m sure as those of you who worked for big companies will know, a certain amount of that is here\u0026rsquo;s how to become a better engineer. And a certain amount of that is like, okay, here\u0026rsquo;s how you need to play the game in some ways if you want to kind of get through that promotion process and get promoted. The other side of the mentorship equation for me as well is when those people are hopefully going up for promotion, then we have obviously a relatively big company formal process for making that happen and hopefully at that stage as well. I\u0026rsquo;ve worked with them enough and I\u0026rsquo;ve given them enough feedback and suggested what they have to do that they\u0026rsquo;ve actually done that and I\u0026rsquo;ve seen them do that. And then I can go and actively advocate for them as part of the promotion process as well. And I think particularly the higher level people are coming. Then we value obviously staff engineers feedback on someone who\u0026rsquo;s going to get promoted to a staff engineer more than we might value a junior engineer\u0026rsquo;s feedback or sorry, a more junior engineer. We don\u0026rsquo;t technically have junior engineers. So I think that\u0026rsquo;s the way I\u0026rsquo;ve gone about mentorship myself. But it\u0026rsquo;s something that I\u0026rsquo;m relatively new to, I guess the formal process of doing it. I\u0026rsquo;ve informally done outside of work mentorship for a long time through Google Summer of Code and Homebrew Maintainers and all these types of folks. But yeah, the more formal process is slightly newer to me, so I\u0026rsquo;m sure I still have a lot to learn there as well.\u003c/p\u003e\n\u003cp\u003eDavid: You mentioned sort of like the folks that you mentioned. It sounds like they\u0026rsquo;re not necessarily folks that are on your team. So I\u0026rsquo;m curious if there\u0026rsquo;s a process that you use for sort of choosing the folks that you work with.\u003c/p\u003e\n\u003cp\u003eMike: Yeah, so right now there\u0026rsquo;s like everyone, until very recently has been people within my org. So I\u0026rsquo;m generally happy to sort of do like one offs with anyone else. But I generally try and restrict my recurring meetings with people outside my org just because it\u0026rsquo;s folks that come to.\u003c/p\u003e\n\u003cp\u003eDavid: You or their managers come to you or you reach out to them or sort of.\u003c/p\u003e\n\u003cp\u003eMike: How does that work? Yeah, so the mentors within my team, team, it\u0026rsquo;s been a sort of discussion, sort of mutual between their managers and me and then I go and offer them. No one\u0026rsquo;s ever forced to kind of take mentorship, but I can offer them and say, hey, I can help you out in this way. And something I found helpful in that way as well. Because sometimes people can be A little bit not resistant but not from because they don\u0026rsquo;t want to be helped. They\u0026rsquo;re resistant because they\u0026rsquo;re like oh but you\u0026rsquo;re important and your time is so valuable. I don\u0026rsquo;t want to waste your time helping me. And then what I found this helpful to point out is say like well I guess particularly when I was going for the staff promotion I was like well I need to demonstrate my ability to successfully mentor people to become senior engineers. So you\u0026rsquo;re actually doing me a favor if you let me do this and if you let me work with you and if you get promoted that going to reflect well on me and help me get promoted as well. So it\u0026rsquo;s a win win here. And I find whenever I\u0026rsquo;ve sold it like that people are dramatically more willing to sort of engage with the process once they see that it\u0026rsquo;s benefiting me as well.\u003c/p\u003e\n\u003cp\u003eDavid: Right, right, that makes sense.\u003c/p\u003e\n\u003cp\u003eMike: But yeah, but I have kind of taken on people outside of my org as well and I guess in those cases I\u0026rsquo;m sort of looking for, I guess almost like what I was saying with the code stuff before of like why me? What is it specific about me that seems to provide value to that person? And in the one person who I\u0026rsquo;m mentoring in that way right now, I guess the answer is I have a pre existing relationship with them. I referred them to join GitHub and they will probably speak a bit more candidly to me and also perhaps accept more candor in return than someone who, because they\u0026rsquo;ve not been at the company a super long time and they maybe haven\u0026rsquo;t quite built up that trust and relationship with, with other people. But I guess for me all mentoring is or has been at least a relatively short term thing. Everyone I\u0026rsquo;m sort of mentoring, I\u0026rsquo;m sort of trying to reevaluate every six months. Are they still getting a lot of value out of this? And if they\u0026rsquo;re not, then can sort of offer them either to just do it less regularly, maybe go from weekly to fortnightly or monthly or whatever or you can say okay well let\u0026rsquo;s do this one offs when you need it or if they feel like they really still need it, then we can kind of continue to do that. But I\u0026rsquo;m trying to make sure get that balance of providing the most value to whoever I can provide it to.\u003c/p\u003e\n\u003cp\u003eDavid: Of course. So we\u0026rsquo;re almost at time. I have two more questions I want to cover. So maybe lightning round, what are some resources, books, blogs, people, et cetera that you\u0026rsquo;ve learned from and that have sort of helped you in your. In your journey as a staff engineer.\u003c/p\u003e\n\u003cp\u003eMike: Yeah. So I guess the main one would be relatively obvious, like the staff engineer, like staffengine.com site. I would say for me, that\u0026rsquo;s been 90% of my thinking around this stuff has been that. And then beyond that, it\u0026rsquo;s been just probably individual conversations with people in and outside the company about how they do things and how they work and stuff like that. But I guess as we touched on before as well, for me, another big part of it has been the open source experience and also perhaps the sort of the mentorship side of open source as well. Stuff like programs like Major Leave Hacking and Google Summer of Code and outreaching and things like that, where you can sort of have a more certainly on the mentorship side, a more formal sort of mentorship relationship with someone for a short time period. I think that\u0026rsquo;s been really useful in sort of teaching me some of these skills too.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. So our last question. Hopefully this is a fun question and we\u0026rsquo;ve asked everyone, how much time do you spend coding still?\u003c/p\u003e\n\u003cp\u003eMike: I don\u0026rsquo;t know. I would say maybe up to, on a good week, probably up to about 50, 60% of my time, and on a bad week, maybe like 20% of my time. I think for me, the nice fallback is that I can always find code to justify writing on Homebrew. So even if I know I can\u0026rsquo;t justify any GitHub code right now, I know that Homebrew\u0026rsquo;s got a backlog that\u0026rsquo;s longer than anything I\u0026rsquo;ve ever seen in my life. So I can always pick something up, work on something, and ship that in quite a satisfying way, even if I can\u0026rsquo;t necessarily do that with my work stuff.\u003c/p\u003e\n\u003cp\u003eAlex: Cool.\u003c/p\u003e\n\u003cp\u003eDavid: Well, that\u0026rsquo;s a pretty good outlet to have.\u003c/p\u003e\n\u003cp\u003eMike: Yep, it\u0026rsquo;s good. I like it. Cool.\u003c/p\u003e\n\u003cp\u003eDavid: Mike, thanks so much for taking the time. It\u0026rsquo;s really been a pleasure.\u003c/p\u003e\n\u003cp\u003eMike: Yeah, pleasure, guys. This was really fun to talk.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to Staff Eng. If you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website podcast. The website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-04-06T09:00:00-05:00","date_modified":"2021-04-06T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]},{"id":"https://podcast.staffeng.com/season-1/sarah-dayan-algolia/","url":"https://podcast.staffeng.com/season-1/sarah-dayan-algolia/","title":"Sarah Dayan (Algolia)","summary":"The higher impact you have at the company... the higher you will usually go. It's not about necessarily how technically awesome you are... It's more what you are enabling, how you're enabling others, what kind of multiplicator effect you're having in the company.","content_html":"\u003cp\u003eA promotion might be a climb up the ladder but, in actual fact, it’s a step in many directions. Today, we speak with staff plus engineer Sarah Dayan, about the many nuances of her current role at Algolia, both subtle and overt. In this episode, we find out what it takes to lead teams, advocate up and down within your organization, and why relationships are of utmost importance. Getting into the swing of things, we ask Sarah to tell us more about her background before she elaborates on the role of a staff engineer. She informs listeners that her role isn’t necessarily dependent on technical whizz and skill, but rather how she creates impact and implements beneficial change. Digging deeper, Sarah shares how she honed her skills as a staff-plus engineer and the need to add value in several ways; not just coding. For context, Sarah describes her role at Algolia, and you’ll find out how she tackles project direction and alignment, her approach to difficult conversations, and techniques for advocating up and down the company.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLinks\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://sarahdayan.dev/\"\u003eSarah Dayan\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/frontstuff_io\"\u003eSarah Dayan on Twitter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.algolia.com/\"\u003eAlgolia\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://seanwes.com/podcast/\"\u003eSeanwes Podcast\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"listen\"\u003eListen\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.buzzsprout.com/1687069/episodes/8172674-sarah-dayan-algolia.mp3\"\u003eDownload Episode\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"transcript\"\u003eTranscript\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eNote: This transcript was generated using automated transcription and may contain errors.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eDavid: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We\u0026rsquo;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 Romis and I\u0026rsquo;m joined by my co host Alex Kessinger. We\u0026rsquo;re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today\u0026rsquo;s guest.\u003c/p\u003e\n\u003cp\u003eAlex: Absolutely. I\u0026rsquo;m stoked about this interview. Sarah Dion 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 + engineering and how that works in a Developer Experience team. I learned a lot from this conversation and I hope you do too. Let\u0026rsquo;s take a listen.\u003c/p\u003e\n\u003cp\u003eDavid: Well Sarah, thank you so much for taking the time. It\u0026rsquo;s really great to have you.\u003c/p\u003e\n\u003cp\u003eSarah: Thank you. Thank you so much for having me.\u003c/p\u003e\n\u003cp\u003eDavid: Can we start by having you tell us, I guess introduce yourself who you are and what you do.\u003c/p\u003e\n\u003cp\u003eSarah: I\u0026rsquo;m Sarah, I\u0026rsquo;ve been working for at Algolia so we are a search and discovery company. I\u0026rsquo;ve been working there for about three years now, but I\u0026rsquo;ve been in the tech industry and working as a developer since 2010. So it\u0026rsquo;s been over over 10 years now. I started as a self taught engineer way before that, but yes, this is where I\u0026rsquo;m at right now. And so 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 or working better with the product. This is what we do. So you can count many things including API clients or SDKs, UI libraries, but also documentation which is the team that I\u0026rsquo;m leading right now. Anything that open source or not, helps you as a developer use the product better is what we focus on.\u003c/p\u003e\n\u003cp\u003eAlex: That\u0026rsquo;s cool. One of the things that we\u0026rsquo;ve been trying to talk to people about is sort of like what a staff engineer does in a particular organization. And I don\u0026rsquo;t think we\u0026rsquo;ve talked to anyone who works on the sort of like developer experience side of things. And I\u0026rsquo;m curious, what do you see the role of a like a staff engineer is when it comes to developer experience.\u003c/p\u003e\n\u003cp\u003eSarah: So 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\u0026rsquo;re working on and impact is the key part to define here, the higher you will usually go. It\u0026rsquo;s not about necessarily how technically awesome you are or being just a beast technically, as one could imagine. It\u0026rsquo;s more what you are enabling, how you\u0026rsquo;re enabling others, what kind of multiplicator effect you\u0026rsquo;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\u0026rsquo;re not mentoring other people, which to me is one of the most important parts. It\u0026rsquo;s not the only one, but it\u0026rsquo;s one of the most important because if you\u0026rsquo;re only working on code, there\u0026rsquo;s only so much that you can do with your two hands and your brains. But if you\u0026rsquo;re actually mentoring other people and enabling them to go higher in the career track, you\u0026rsquo;re actually enabling a lot more than what you would do only on your own. So that plays a huge role, at least in the company where I\u0026rsquo;m working. But it\u0026rsquo;s not only that. There is also a lot of advocacy. And that\u0026rsquo;s also something that you get with the more experience you have, is that the more you work on challenging projects, the more you\u0026rsquo;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\u0026rsquo;re able to have this kind of influence and the higher up, the more you can grow to such levels.\u003c/p\u003e\n\u003cp\u003eAlex: 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\u0026rsquo;m curious, is that something that\u0026rsquo;s defined, you feel like by the company that you work for, or is that something that you learned outside of Algolia?\u003c/p\u003e\n\u003cp\u003eSarah: So the company has a career track, which is, I believe the good thing about it is that it\u0026rsquo;s not just a list of checkboxes that\u0026rsquo;s like you check everything and it\u0026rsquo;s good, but it\u0026rsquo;s more of an overall feeling of whether you fit to a profile that they are 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, 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 the less of them and it will probably also be tied to very specifics of the company. So I think it\u0026rsquo;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\u0026rsquo;s also about embodying the values, I would say, of your company. We, at least at Algoya, we operate on values. It\u0026rsquo;s a huge part of the culture. It\u0026rsquo;s actually something that we are assessed on quarterly. And so this is also about that. It\u0026rsquo;s about how you\u0026rsquo;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 are. They know the language that the biggest part of the product is built on and some other like for. To give you an example, the engine of Algolia is built in C. I don\u0026rsquo;t write C, so I will not, I will never, unless I learned language. But even then I will virtually never be able to contribute on this. So there\u0026rsquo;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\u0026rsquo;s about going beyond only what you can do technically and be able to have conversations that are more high level. Something that I\u0026rsquo;ve seen becoming really important, especially for the last years, and it\u0026rsquo;s 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\u0026rsquo;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 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\u0026rsquo;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\u0026rsquo;t I get promoted Because I am so good at X or at this language or I can solve huge problems, technical knots. Sometimes it will make a lot of sense to promote someone who\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eAlex: 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?\u003c/p\u003e\n\u003cp\u003eSarah: No, I joined as. So staff level at Algolia is 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, and then passing.\u003c/p\u003e\n\u003cp\u003eAlex: Cool. Did you do any like, projects that contributed to your promotion process or was like there a specific project that enabled you to level up?\u003c/p\u003e\n\u003cp\u003eSarah: 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 try to, 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 rewrite of the JavaScript, like the entire JavaScript of one of our projects. But then it, it\u0026rsquo;s not so much one project, but more of a collection of different projects, like projects that made a difference. Yeah, I can give you the example of an onboarding tutorial that we made, but it\u0026rsquo;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 other people to make good code reviews. When I say code reviews, it\u0026rsquo;s not just about being extremely precise or being super uplifting, but it\u0026rsquo;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\u0026rsquo;s not going to be about arguing on things that don\u0026rsquo;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 yet 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\u0026rsquo;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\u0026rsquo;s something that I like networking, I like using my network on social media and 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.\u003c/p\u003e\n\u003cp\u003eDavid: How do you decide what to work on?\u003c/p\u003e\n\u003cp\u003eSarah: How do I decide what to work on? It can be hard and there\u0026rsquo;s definitely no clear path the higher I go. And especially lately with COVID and stuff, when you\u0026rsquo;re. I would say you have maybe more time to think because you\u0026rsquo;re less in the buzz environment of an open space. What I\u0026rsquo;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. That\u0026rsquo;s 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. That\u0026rsquo;s a pattern that I\u0026rsquo;ve seen for many folks who grow in carrier ladders. 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. I have, 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. Like if that person works on that topic, then they will be able to grow while me doing that task is not going to. It\u0026rsquo;s gonna. It\u0026rsquo;s gonna be done, but I\u0026rsquo;m not going to grow in higher levels by doing that task. It\u0026rsquo;s not where I can have the most impact.\u003c/p\u003e\n\u003cp\u003eDavid: Do you still find yourself contributing to projects directly, even if it\u0026rsquo;s not in code but in design and things like that? Or are you really trying to work through people more than sort of contributing directly?\u003c/p\u003e\n\u003cp\u003eSarah: So I don\u0026rsquo;t really have a choice because our chapter DX is quite small. Usually you don\u0026rsquo;t invest as much on something like developer experience when it\u0026rsquo;s not directly tied to revenue as some kind of other product team. So I don\u0026rsquo;t have a choice. I could never not be working on code at least. But I think that\u0026rsquo;s fine. I feel that it\u0026rsquo;s first. I like it. It also grounds me into the reality of the day to day that we\u0026rsquo;re working on. I don\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eDavid: Sure makes sense. You mentioned like you wouldn\u0026rsquo;t want to spend all your time on architecture or you wouldn\u0026rsquo;t want to spend all your time on looking ahead to sort of 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 sort of some of the things that you think about when sort of identifying the next high impact opportunities and how do you think about aligning the organization around you to do that?\u003c/p\u003e\n\u003cp\u003eSarah: That\u0026rsquo;s. That\u0026rsquo;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 debt. 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\u0026rsquo;s worth rewriting not because it\u0026rsquo;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\u0026rsquo;re going to be in a bad situation. But then it\u0026rsquo;s more about, I would say product and it\u0026rsquo;s more about connecting with other parts of the company that are not necessarily engineering. Usually 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\u0026rsquo;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\u0026rsquo;s also something that 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\u0026rsquo;s, I would say, a balance between risk and opportunity, if that makes sense.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah, totally. And so how do you ensure that the stuff that you\u0026rsquo;re working on is aligned with your organizational goals?\u003c/p\u003e\n\u003cp\u003eSarah: It\u0026rsquo;s really about aligning with your execs and aligning with your manager. And that\u0026rsquo;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\u0026rsquo;s something that I\u0026rsquo;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\u0026rsquo;s next. There\u0026rsquo;s a lot that goes into communication. I spent a lot of time with my manager debriefing about what\u0026rsquo;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\u0026rsquo;re aligned and if it makes sense, depending on what on his end with his manager, which is higher up in chain, is the biggest focus right now. So a lot of it is communication and making sure that you\u0026rsquo;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 something key. For example, our docs is huge. It\u0026rsquo;s really big, it\u0026rsquo;s a lot of content and it\u0026rsquo;s not going to go any like it\u0026rsquo;s not going to downsize any sooner. And it\u0026rsquo;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\u0026rsquo;s not about dropping quality. It\u0026rsquo;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\u0026rsquo;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\u0026rsquo;s definitely a turn that I\u0026rsquo;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 doesn\u0026rsquo;t matter, or 20% of it doesn\u0026rsquo;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 might not be well suited for everybody, which is okay. Not everybody has to. I think in many companies you can probably reach a level probably senior, and it\u0026rsquo;s fine if you never grow any higher than that. And it\u0026rsquo;s fine. We actually also need people who just care about technical stuff and quality, and that\u0026rsquo;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\u0026rsquo;s not just ic. There\u0026rsquo;s a little part of strategy, There\u0026rsquo;s a little part of even manager stuff that you will end up doing. I\u0026rsquo;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\u0026rsquo;s going in the right direction than them doing that. But again, that\u0026rsquo;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, people who get better. You don\u0026rsquo;t want to have a pyramid forever. You don\u0026rsquo;t want to have a lot of junior and just one staff engineer. That\u0026rsquo;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 grunt work like that makes no sense.\u003c/p\u003e\n\u003cp\u003eAlex: Yeah. A couple times you touched on the idea of helping people make like 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 sort of like difficult alignment conversations?\u003c/p\u003e\n\u003cp\u003eSarah: That\u0026rsquo;s hard definitely because you also bring your own like 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\u0026rsquo;re gonna be the one maintaining it or you\u0026rsquo;re gonna be on call or you\u0026rsquo;re gonna have to manage people who are on call. It is definitely difficult. But I would say it\u0026rsquo;s really about open mindedness and being aware of where you\u0026rsquo;re getting into, what you\u0026rsquo;re getting into. When you prepare for like becoming a staff engineer because that\u0026rsquo;s the promotion that you\u0026rsquo;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\u0026rsquo;s say, but you\u0026rsquo;re not passionate about people and you\u0026rsquo;re not passionate about making other people grow and you still want to be hands on on code, you\u0026rsquo;re going to be making miserable and it\u0026rsquo;s going to be hell for for everyone. I would say it\u0026rsquo;s the same when you\u0026rsquo;re targeting staff, staff level or staff senior staff, principal. You\u0026rsquo;re gonna have to make bigger compromises than deciding what the Linter rules are. And it\u0026rsquo;s not like it might be even challenging regarding your own values as a developer. Sometimes you\u0026rsquo;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. So 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\u0026rsquo;re getting into beforehand. If you don\u0026rsquo;t think that you\u0026rsquo;re going to be able to do that or if the company that you\u0026rsquo;re working on makes some strategic choices that you and most of them you don\u0026rsquo;t agree with but you like it there because you like working on the tech, maybe that\u0026rsquo;s not the best idea. So yeah, being able to work on compromise, to make compromises and, 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. So that\u0026rsquo;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. And it\u0026rsquo;s different from making technical arguments where it\u0026rsquo;s more about, okay, that\u0026rsquo;s obviously better or that\u0026rsquo;s better because xyz. Because sometimes it\u0026rsquo;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. So they are not inherently the core of what you know and the core of what you\u0026rsquo;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, where 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 on based on those.\u003c/p\u003e\n\u003cp\u003eDavid: One of the interesting things about the staff role that I found is that you\u0026rsquo;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 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, 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\u0026rsquo;re kind of trying to steer the ship, sometimes it can be hard to sort of bring everybody on board with the new vision. Have you seen that? And what kind of approaches do you take in those scenarios?\u003c/p\u003e\n\u003cp\u003eSarah: It\u0026rsquo;s always going to be, and that may sound very generic, but it\u0026rsquo;s always going to be through communication. 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\u0026rsquo;re afraid that people are going to overreact. That\u0026rsquo;s, I think, a bit patronizing that that\u0026rsquo;s actually very patronizing and people hate it. And then they become extremely defensive while, like thinking developers are going to freak out because you say that this is going to happen or that is going to happen, actually not true. People are able to, like, people know that they work in a company, they are not working on a pet project, so they\u0026rsquo;re able to hear stuff. What is usually also very helpful is to provide people with the ability to find solutions. It\u0026rsquo;s usually I found a really bad idea to come and say, okay, so this is the new direction and this is, this is how it\u0026rsquo;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\u0026rsquo;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\u0026rsquo;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 bounce the ball and make sure that they understand the entire process 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\u0026rsquo;s going to happen is that they\u0026rsquo;re going to. If they are not happy with it, but they feel like there\u0026rsquo;s nothing that they can do, frustration is going to start growing and they\u0026rsquo;re going to start talking about it with other people, never telling you about it directly. And then you\u0026rsquo;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\u0026rsquo;ve had conversations with people around stuff where I thought that might be difficult because that\u0026rsquo;s going to change, change a lot of things from the way we\u0026rsquo;re working right now. Usually when you have conversation around, okay, there\u0026rsquo;s this direction that\u0026rsquo;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\u0026rsquo;t think that works, instead of being like, well, that\u0026rsquo;s just the way it is and you\u0026rsquo;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\u0026rsquo;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\u0026rsquo;re never going to have collaboration coming from a relationship between two people who don\u0026rsquo;t trust each other. If you are a manager and you don\u0026rsquo;t have the trust of your team, they\u0026rsquo;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\u0026rsquo;re like minded, if they think that you\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eDavid: 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 two roles can best collaborate together?\u003c/p\u003e\n\u003cp\u003eSarah: So I would say like 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\u0026rsquo;s important for an engineering manager to know like to still no technical level stuff. Usually it\u0026rsquo;s someone who used to be an engineer because it\u0026rsquo;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\u0026rsquo;re working with people who are deep into code. You don\u0026rsquo;t want to be like, I don\u0026rsquo;t understand anything about what you\u0026rsquo;re doing, doing or saying, but it looks fine. But you\u0026rsquo;re still, you\u0026rsquo;re a manager, so you\u0026rsquo;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\u0026rsquo;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\u0026rsquo;t know what I should do next to grow because I feel like I\u0026rsquo;ve hit a plateau. That\u0026rsquo;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\u0026rsquo;s an IC because they are still in that IC position. And so that\u0026rsquo;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\u0026rsquo;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 are. Yeah, when you\u0026rsquo;re a Junior or you\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eAlex: Wow. And it sounds like you\u0026rsquo;ve got a really well thought out concept around this manager stuff. I\u0026rsquo;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?\u003c/p\u003e\n\u003cp\u003eSarah: 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 Jr. 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% 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\u0026rsquo;s a purely from an investment part aspect of things. That definitely makes sense. Now there\u0026rsquo;s the human aspect. I don\u0026rsquo;t think it makes sense for me to do all the code and work on all the features just because I enjoy that. That\u0026rsquo;s not how you create strong teams. And again, we\u0026rsquo;ve seen stories, we\u0026rsquo;ve read those stories where you have one person who\u0026rsquo;s 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 burnout or because 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\u0026rsquo;re going to be doing less of all the work is going to come around and steal them from you. It will happen. It\u0026rsquo;s not about if, it\u0026rsquo;s about when. If you don\u0026rsquo;t have your own back, if you did not prepare for when that person was going away, then you\u0026rsquo;re in a very, very difficult situation and it\u0026rsquo;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\u0026rsquo;s the culture that you\u0026rsquo;re creating, you absolutely need to understand that it not everything is about you in your career. It\u0026rsquo;s not all about you. And yes, that thing might make you shine and help you shine, but it\u0026rsquo;s also going to help another person shine. And it\u0026rsquo;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\u0026rsquo;m not going to create any relationships where someone will have my back later and I don\u0026rsquo;t know everything. There are things that many other people do much better than me. 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\u0026rsquo;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 to work in. It\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eDavid: Yeah, that makes sense. Changing gears a little bit, A question that I\u0026rsquo;ve sort of had from listening to you is sort of where you\u0026rsquo;ve learned all this stuff. I\u0026rsquo;m sure a lot of it has come from sort of with time and experience. But I\u0026rsquo;m curious if there are any resources, whether that\u0026rsquo;s books or blogs or people or anything else that you would refer folks to.\u003c/p\u003e\n\u003cp\u003eSarah: I probably won\u0026rsquo;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\u0026rsquo;s even outside of tech. It\u0026rsquo;s just trying to be a decent human being in general. And there\u0026rsquo;s a lot of things that you don\u0026rsquo;t have to read about necessarily to understand. It\u0026rsquo;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, okay, what\u0026rsquo;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\u0026rsquo;m making a difference? So yes, it\u0026rsquo;s usually conversations. I\u0026rsquo;m lucky enough to work with really awesome people who are. 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\u0026rsquo;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, there probably is one resource, one podcast that I\u0026rsquo;ve listened to for years, which is the Sean west 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, 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\u0026rsquo;s not about only what I\u0026rsquo;m going to work on this quarter. It\u0026rsquo;s about where I see us being in one year. It\u0026rsquo;s about what kind of connections and relationships I\u0026rsquo;m going to be able to foster in three years. It\u0026rsquo;s about the awesome relationship that I\u0026rsquo;ve preserved from that place I worked at 10 years ago. And now I\u0026rsquo;m. 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\u0026rsquo;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\u0026rsquo;s a balance to have. But on the other end, if you\u0026rsquo;re always going into okay, how can I make something impactful right now? Making blips on the radar like spikes. You\u0026rsquo;re never going to build a robust foundation. And I don\u0026rsquo;t want to make cheesy analogies, but I would say it\u0026rsquo;s kind of the same with a project you can rebuild every two years. Everybody loves that. But that\u0026rsquo;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\u0026rsquo;s stellar. Otherwise again, you\u0026rsquo;re gonna 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 at least has some good processes to make sure that they stay sane is how you\u0026rsquo;re going to build something that lasts and something that is not terrible to work on in 10 years. I\u0026rsquo;m not in the best industry for that. I do web so that\u0026rsquo;s easier to redo projects. But some people who work on very enterprise software, like I don\u0026rsquo;t know, 3D enterprise software for huge companies, then it\u0026rsquo;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\u0026rsquo;re building is building this for the long game. It\u0026rsquo;s not going to be perfect, but we have to think of the long run.\u003c/p\u003e\n\u003cp\u003eAlex: That makes a lot of sense. I really appreciate that idea of learning from outside of our industry. For instance, I\u0026rsquo;m learning a lot right now from 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\u0026rsquo;s just really a curiosity and hopefully it\u0026rsquo;s a fun question, is how much time do you still spend coding?\u003c/p\u003e\n\u003cp\u003eSarah: Oh, actually coding, I would say probably a bit less than 50% of the time. If you put reviewing as not coding, which sometimes a bit blended. But yeah, a lot of time is spent of reviewing. So yeah, I would say maybe 50% of the time on the best days.\u003c/p\u003e\n\u003cp\u003eAlex: Nice. Awesome.\u003c/p\u003e\n\u003cp\u003eDavid: Sarah, it was so nice to meet you. Thank you so much for taking the time today.\u003c/p\u003e\n\u003cp\u003eSarah: Thank you for having me. It was really fun.\u003c/p\u003e\n\u003cp\u003eDavid: That\u0026rsquo;s it. Thanks so much for listening to staffing. If you if you enjoyed today\u0026rsquo;s show, please consider adding a review on itunes, Spotify, or your podcaster 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.\u003c/p\u003e\n\u003cp\u003eAlex: You can find the notes from today\u0026rsquo;s episode at our website, podcast.staffenge.com the website also has our contact info. Please don\u0026rsquo;t be shy.\u003c/p\u003e\n","date_published":"2021-03-30T09:00:00-05:00","date_modified":"2021-03-30T09:00:00-05:00","authors":[{"name":"StaffEng Podcast"}]}]}