Speaker 1: Hello and welcome to Screaming in the Cloud with your host cloud economist's, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey Quinn: This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. From where I sit, every cloud platform out there, biases for something, some bias for offering a managed service around every possible need. A customer could have, others bias for, "Hey, we hear there's money to be made in the cloud. Maybe give some of that to us." DigitalOcean from, where I sit, biases for simplicity. I've spoken to a number of DigitalOcean customers and they all say the same thing, which distills down to they can get up and running in less than a minute and not have to spend weeks going to cloud school first. Making things simple and accessible has tremendous value in speeding up your time to market. There's also value in DigitalOcean offering things for a fixed price. You know what this month's bill is going to be, you're not going to have a minor heart issue when the bill comes due, and that winds up carrying forward in a number of different ways.

Corey Quinn: Their services are understandable without spending three months of study first, you don't really have to go stupendously deep just to understand what you're getting into. It's click a button or make an API call and receive the cloud resource. They also offer very understandable monitoring and alerting. They have a managed database offering. They have an object store, and as of late last year, they offer a managed Kubernetes offering that doesn't require a deep understanding of Greek mythology for you to wrap your head around it. For those wondering what I'm talking about, Kubernetes is, of course, named after the Greek god of spending money on cloud services. Lastly, DigitalOcean isn't what I would call small time. There are over 150,000 businesses using them today. Go ahead and give him a try or visit DO.co/Screaming and they'll give you a free hundred dollar credit to try it out. That's DO.co/Screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud.

Corey Quinn: Hello and welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Silvia Botros, principal engineer at SendGrid. Welcome to the show, Silvia.

Silvia Botros: Thank you, Corey. Thank you for having me.

Corey Quinn: You might be better known on the Internet as dbsmasher, which is first an awesome name and secondly, deeply evocative of my entire relationship with databases dating back to my first experiences with technology 20 years ago.

Silvia Botros: Me too. I've been breaking them for a while. My current nickname internally to the team is RemoteEMP, 'cause a lot of times I'll just like touch something and it'll ... I seem to have this secret knack of a QA engineer. Like I'll touch a tool and I'm the first one to find like a bug or just make it completely kernel panic and things like that, and it's been challenging sometimes.

Corey Quinn: It's hard to realize at the time because when you, when you had everything you touch breaks, one of the, I think easiest things to do is fall into this pattern of assuming it's, oh, obviously it's because I'm cursed. And well, yes, you are, that does wind up having a tremendously valuable aspect to it of finding the ways that things break in failure modes that you hadn't predicted or experienced before. I've learned that one when I wind up talking to product teams at various cloud companies and they want me to look at things and the answer is not that the product is generally terrible, it's that I have really weird use cases and I find ways that things fail that hadn't been predicted before. That alone winds up being tremendously valuable if you could only bottle it.

Corey Quinn: It's super annoying when you're on deadline and trying to get something like guarding and, oh, you found a new interpreter bug, no one's done that recently. That's awesome, it's great, thanks. But I'd kind of like to get this thing to ship this week. That would be awesome. So I feel your pain there. I really do.

Silvia Botros: Yeah. I'm currently having this whole saga. We're doing this large project with SendGrid that we announced maybe like less than a year ago, just under a year ago, where we are moving our infrastructure from in pieces. It's a long journey. We're currently self-hosted in our old colo centers and we're moving to Amazon. And so one of the very first thing you are told when you're going to go to Amazon is if you do infrastructure as code, which you really should, Terraform is the thing, learn Terraform. I had been for years now managing the databases at SendGrid using Chef which has its own obviously wars, like nothing is perfect, but I had come to terms with learning all the things. Like the tricks like don't get too crazy with attributes, precedents, things like that. But now it's an entire mind shift with the declarative language that it doesn't even have loops yet.

Silvia Botros: It's been a thing for a month now. My team has watched me rail, like keep trying things with Terraform, trying to use it to deploy aurora clusters with regional replicas and it's been that kind of thing. I've already filed two bugs with Terraform, found a third one that totally applies to what I'm trying to do, and I am pretty close to just, you know, wrapping it in bash to try to work around the bugs while things are being figured out. So being being on that edge of like, yeah, this is awesome that I'm finding bugs but I really, I've been working at this for a month and I would like to never look at it again for awhile. That's definitely a thing.

Corey Quinn: That's the interesting part I've always found about managing infrastructure as code. Once you get it up and running it works and you do it in CloudFormation, Terraform, Shaft, Bash script, et cetera. And then you invariably don't touch it for six months, a year or whatnot, until you have to make changes. And then you go back to it and it's almost like relearning whatever it is that you wound up building the first time. And you look at this and it's, "What moron wound up writing this?" And you pull up git blame which we may as well called git shame because that's how everyone uses it, and you realize that the moron was you. And "Oh, we're just going to fix that now and we need never speak of this again." But it's one of the most demoralizing things in the world. It's like on the one hand it's, yeah, I'm good at this and I'm considered an industry leader. And on the other it's, ha, what is Terraform and how might one use a thing like that? It's a constant humbling of wherever we think we are in this space.

Silvia Botros: Oh yeah. Um so, about the git shame part, I used to do that way back when I started at SendGrid and it is incidentally my seven year anniversary today as we record this.

Corey Quinn: Oh, congratulations.

Silvia Botros: Thank you.

Corey Quinn: Seven years at a company in tech that's like 25 years on a watch in most-

Silvia Botros: I know ... It's it's I can't believe it either. I still vividly remember my first day actually. But I mean at the time I was still like a bit, like had a hard time with the empathy bit of working as an engineer. And like I would do this thing where I'd go git blame and be like, "What was that person's thing thinking?" But seven years in and at the same company, most likely they git blame will be me. So all the time I go back, I'm like, "Oh, man, that Silvia was really an idiot when she did this."

Corey Quinn: One of my favorite git extensions, it made the rounds a while back on GitHub, is git blames someone else, where it goes back and rewrites history and attributes commits to other people, which is just spectacular.

Silvia Botros: Oh, one of the people still on the ops team with us, and he's been at SendGrid longer than me, it's going to be nine years for him in a couple of months, he was the first DBA, although he never held a title, but he and I have this like friendship where we troll each other a lot. And I distinctly remember only a few months ago when someone who is much newer on the team finding a script that was causing issues and they were like debugging this thing that is very arcane and there they go to git ... No, they go into the script and it was, it's a Bash script and title at the top, whoever wrote it put in the author as dbsmasher. But then when I was like, I don't even recognize this, and I git blame it and it was my coworker. And that was definitely one of those, what we like to show each other in our team. We love each other so much. It's a good relationship where we just like throw jabs at each other like that all the time.

Corey Quinn: It's fun and it's easier to do in some cases with things like git just because you wind up in this world of this incredibly complex tool that's primary job is to make everyone feel stupid, no matter who you are, what you do, you will go past your comfort zone with git full stop. But then you wind up … find that other people seem to know certain things that you don't. It becomes a constant, first, excuse to share knowledge with people. And secondly, in that uncomfortable world of this complex critical thing that no one fully understands, comedy arises. And it's always a reliable direction to go in as far as easy jokes. At least, well, easy should be in quotes because it's git, nothing's easy.

Silvia Botros: Yeah. That's definitely one of the lessons learned after this many years. Seven years at SendGrid, like not everything has been smooth sailing at all times. But uh it's much healthier to come out of it with a laugh than get angry.

Corey Quinn: So, in the interest of full disclosure, I write a newsletter every week that goes out to give or take 10,000 people. And that is powered these days through SendGrid. I am a paying customer.

Silvia Botros: Excellent.

Corey Quinn: This is a podcast. This is, yeah, this is me using a service that works. So when I find a vendor I'm using, like SendGrid, is doing something publicly that is entertaining, in this case, as you just mentioned, moving to AWS, hey, that also is relevant to my interests, I immediately get simultaneously intrigued and a little worried. It's, "Huh, well, the service I've been using is super reliable, but now they're publicly changing a lot, a fundamental piece of the architecture. Well, that's going to be interesting. How is that going to play out potentially?" So I'm curious to hear, I guess first, how you folks think about the migration to AWS? Starting at the beginning, what drives that? Yeah, we're going to pick up this thing that we've built and move it to a completely different environment is generally not something a company does for funsies.

Silvia Botros: Exactly. So, the conversation around making this move started maybe a year and a half ago. We've been an AWS partner for a while. We are in their marketplace as one of the email providers right next to SES and you know getting traction there. But one of the other things that were also happening June at that time was we were talking as both as the ops org and generally as engineering of how much work was really going into hardware procurement, getting the racks in place, making sure they are actually usable, um getting them provisioned, getting them out to networking them in our internal system that we use to provision the host and then turning them into like KBM host. Like the amount of work that goes from, "Hey, we need racks in DCX," to the engineers have assets at hand that they can deploy things to, it's a very long road and it was a serious concern at our velocity.

Silvia Botros: There's also the other concern where as a business we send mail and we have known peaks of traffic. There are certain times where customers want to send more mail. For example, Black Friday and Cyber Monday is a known thing for us. Um so we just tweeted after last Cyber Monday, like we sent three billion emails just in the 24 hour span alone, with a lot of like impressive peaks within like one hour span or 15 minutes span internally. So if you're self-hosted, you find yourself having to procure hardware that accommodates the peaks, but then there's a lot of idle in other times. Weekends you know are pretty quiet. Not a lot of people send email over the weekends. So that became another concern is like how much money is sitting idle while just to be ready to use when we have high peak days, like Black Friday, Cyber Monday or other days. GDPR was another day as well that was very high peak. So those two things changed.

Corey Quinn: Oh, geez, yes. We call the GDPR day alone was one of those absolutely horrible days for anyone who depends on getting important things in their email inbox.

Silvia Botros: Here's the funny part. Our big data team was waiting to see what happens with that day because it was going to be an interesting one time event for them to see how we handle it. But from an operational perspective, we didn't feel it, as in we felt it way more in our own impersonal inboxes than, oh my God, look, the traffic is high and things are, knock on wood. Nothing went wrong that day, it just sort of flew by and the next day we went, "Oh, we sent like," I don't remember the number it was, but it was definitely north of two billion. "We sent that much? Oh, that's cool." So it was clear example that we had a pretty solid infrastructure that handled the scale like very comfortably.

Silvia Botros: But then at the other hand you should, like it was enough for us to go, "This is a good reason for us to move to the cloud because it would have probably cost us less in hardware or in like infrastructure costs to not have all that hardware sit there waiting for GDPR to happen and for us to use it." So, between the idle infrastructure concerns and the developer velocity concerns, it became clear that we were like, we needed something that could just elastically scale with us for delivering all these billions of emails. But also like you said, it's like we are a large company, we've been around for awhile, we have many, many customers. You can't just change tires on a bus that's flying at a hundred miles an hour and just be like, let's just stop in and get the tires off. It has to happen while you're running. So, that's why we decided it's not going to be like a quick thing. We set an ambitious goal still for a couple years, but we're doing it in small portions. There's a lot of education internally for all of our engineers as to how to actually build stuff in Amazon. It changes your architectural of mindset when you're designing things.

Corey Quinn: Well, hopefully. If it doesn't, you've created a heck of a problem.

Silvia Botros: Exactly. It's you never want to. There's a lot of things that you can take for granted when you are owning everything down to the network year versus when you go into Amazon and things are far less under your control. But I think ultimately it's better for us as engineers to do that way because then you'll learn to make what you build actually resilient and not just happens to work because you know if the network goes down I know who to poke.

Corey Quinn: It's interesting dealing with a company like SendGrid. In the interest of further disclosure, I started my career as a Unix administrator focusing on large scale email systems. Not SendGrid large scale, but large scale enough measured in the millions of users. As I was building out the newsletter, we talked earlier about the idea of finding weird edge case, strange bugs, it was very clear that I am as every other aspect of my life, not the typical case for anything. So I'm talking to an account rep as I'm getting my SendGrid accounts set up and they said, "Okay, how many emails do you wind up sending a week?" I'm like, "Oh, cool." I have at that point 3,000 subscribers. They said, "Great, cool. We can absolutely send email to your three million subscribers." And it's, "Whoa, whoa, whoa. You're off there a little bit." Okay. No matter how big this thing gets, we got you.

Corey Quinn: But the other side is cool and I want to build this newsletter management thing into it too. And the response was, "Oh, here's our API." So the things that seemed very complex to me of sending high degree high volumes of email with a great deliverability story, your entire corporate approaches, "Yeah, no problem. We got that." But the stuff that involves some of the higher level moving up the stack aspects is on the other side of a "Oh, yeah. That's not really what we do." And credit where due, I appreciated being told that explicitly, as opposed to the song and dance so many vendors like to do of, "Oh yeah, it'll also make fries," but that doesn't lead to a good experience. So, this is where we start and this is where we stop is fantastic.

Corey Quinn: A question that I have though, as you've since then started to broaden out a bit into a marketing campaign story and going down towards, I guess the, I don't want to say lower end of the market, but that's absolutely where I am. It's becoming an increasingly capable platform as time goes on. It's nice to see that enhancements, those enhancement start to come out. And I guess what I'm curious about and feel free to tell me you can't answer it, but is some of that flexibility and capability improvement being driven by, even in a tertiary sense, by the migration into the cloud?

Silvia Botros: It hasn't been driven by it, it's actually helped accelerate it though because our customers kept asking for it. They're like, "We love your API, but we also want to use it for handling marketing, and our marketers are not developers. They can't write API code. They can't write code that talks to APIs, they need to be able to do some things in the GUI." 

Silvia Botros: So, that was one of the drivers actually because a couple of years ago we were embarking on uh the marketing campaigns application getting its new rewrites. We were wanting to add some features around automation, which is now in ... I think it's open beta, maybe closed beta, but I'm fairly certain it's on the website right now. Um that is marketing campaigns was one of the first parts of our product lineup that we wanted to move and to make all the new things that we add to it AWS Native. So, that was one of those things that, yeah, like once we do this, that's definitely the first one to start doing this with. A, because it's a smaller volume compared to our bread and butter infrastructure, email business line. And two, because once they do that, it has a lot more potential to be able to leverage all of the cool things that are in Amazon that we don't want to have to build internally.

Silvia Botros: 'Cause one of the biggest drivers for this move was also we need to focus our engineers on the things that are our business advantage. We no longer want to spend any engineering time building an internal provisioning system for hardware um or building a DIY metric stack or any of those things that don't actually, that we don't actually bill our customers for. So, when we start going into complex systems like handling a marketing contact and all of the things that go along with it, having the ability to use something like AWS where it's like there's a lot of managed things can help us build the higher up pieces faster.

Corey Quinn: Sorry, I was on mute. Please take that silence out.

Corey Quinn: There's always a capability story that starts to enhance itself as you start moving towards more dynamic infrastructures where, okay, we need to wind up being able to serve very bursty loads so when we wind up on GDPR Day or what not, suddenly we're at 18 times normal capacity and then that drops down to effectively nothing and we don't pay for it except when we're using it. There's something that winds up shifting from a perspective context around the idea of being able to take whatever it is you're doing and spin something up to see how it works and spin it down when you don't need it. That for whatever reason you don't have that level of dynamic ability to innovate when you're paying for hardware, having to get it racked and, "Oh, you want to try this new experiment? Cool. We're going to expedite that and get the infrastructure spun up in only two short months." It tends to react to

Silvia Botros: That's if you're lucky.

Corey Quinn: Yeah, oh, yeah. I'm speaking aspirationally here for startup territory, not big enterprises. It's, "Cool, we'll get that for you by third quarter," and they very conspicuously don't mention a third quarter of what year. So, historically as well, you were focused primarily on databases, and now as you mentioned to me earlier, you don't have the word database appearing anywhere in your title either because they've you've scared them all into submission, or it's the future we don't need databases anymore, or perhaps least interestingly but most likely your capability is now expanded beyond pure databases into other arenas. Can you give me a little context into that?

Silvia Botros: Yeah. So, way back when I started at SendGrid we didn't even have like written down like job titles, like the job title comes with your offer and sort of you kind of guessed what it means. I had the luxury when I started at SendGrid, I was one of the first actually who wasn't hired with a vague software engineer, quote unquote, title. It was more specific to DBA. So, I at least had an idea of where my scope was, but we didn't have enough effort at the time into explaining what those titles meant, what the levels attached to them meant, what competencies we expect. And after that to the next step as most companies do, people started needing that, so that was defined. But one of the biggest concerns that I had raised at the time was that the track seemed to, for individual contributors, would go all the way up to like senior engineer, or senior DBA in my case, and then it would stop. And other than that you started going into the management level where you start seeing like senior management director, senior director of VP, and so on.

Silvia Botros: This was around, I don't know, year four or so or five at SendGrid. And uh I started facing the usual question that all engineers around this time for like me face, do you want to go into management? I genuinely was not super interested in it. I knew that we still had a lot of technical things to solve and I wanted to be involved in solving them. But I still pointed out that, hey, this difference in the tracks is sticking out to me. So, to their credit at SendGrid, we started talking about, hey, do we need to redo our our tracks? And that's when SendGrid introduced a new rewrite of our leveling and our titles infrastructure.

Silvia Botros: We started having a fully fledged individual contributor track. We started having what we call principal engineer, principal engineer II, and architect. That role starts becoming more of a leadership without direct reports kind of role. There's definitely an emphasis in it on helps the other people in the org do stuff, be a force multiplier for other engineers, helps teach, helps mentor far more than, you know, goes in a black hole and comes out with a shiny fully done production product. So that's been really great, at least for me, I felt it was very empowering to be able to say, "Hey, I've learned a bunch of things over the last few years. I would like to continue solving problems here. But I would like that also acknowledged as part of the career track that we have."

Corey Quinn: One of the things I think that I admire the most about you has always been your willingness to help mentor people, help people understand something they didn't before. It's something that I would love to see more of across the industry. It was even in early days when I first was getting a vague awareness of who you are, your willingness to help people understand complex things in reasonable ways was one of your defining characteristics. It's one of those things where people never quite know what their own reputation is, but that's one that you've been carrying for an awful long time. I figured you're probably, I've been told this before, but in the off chance you haven't, that is how people tend to view what you do.

Silvia Botros: Thank you. That's really nice of you. I really appreciate that. Yeah. Um I didn't have that much of ... My time at SendGrid, for a really long time I was the only DBA. I've had a consultant outfit helping me out of for most of that time when I was solo, but as much as one tries to incorporate a consultant outfit as part of the org, there's always going to be that level of that you still have to be able to give them more specific things to do and you know contain the work so that the output is still usable when they are gone. So, for a long time back then, I was starting to get very aware of the fact that a lot of the engineers that we had at SendGrid at the time were still not super comfortable with you know databases and their quickest instinct was to ask the DBA to look at it. It would like, "Please go fix this, like whatever magic you do."

Silvia Botros: And I started having issues with burnouts for awhile and it was like I was feeling that I was doing the same thing over and over again. It was not really, I wasn't growing. I wasn't being challenged. I wasn't learning new things. So, that's when I decided that, no, I need to stop you know guarding things that way, I need to be able to teach the engineers how to figure out what's wrong, try to document how the code that's running the databases looks like, things like that. Because ultimately I was like, if nobody else knows how to do what I do right now, I will always be doing what I'm doing right now. So, that's where that motivation came from. Like a slightly selfish motivation still, but I'm glad it helps everybody else out.

Silvia Botros: Since then we've started hiring more DBAs. We are now a team of four, soon to be five, which is still mind boggling to me. But now that we're at this stage, since I've gotten principal engineer the database portion has been taken out of the title I've recently joined our architecture team. I'm working closely with our architect team and PE IIs who report directly to the CTO, which means I get to you know help with more strategic things. So, it's less about databases specifically and more about how to build the things that bring the value to the business. And I've been definitely enjoying that a lot recently.

Corey Quinn: Something fascinating is that you've been at SendGrid for, as you mentioned, seven years as of today. Congratulations again, but you haven't, I guess, crossed over, for lack of a better term, into the management track. You are very publicly an individual contributor. What drives that?

Silvia Botros: Uh it's funny you mentioned that because my boss and a former VP of ops would both say that, "Yeah, she didn't want to do management. We're still having her do all sorts of manage-y things." They're sort of sneaky that way. But what I'm doing is basically it's I help out with a lot of like the helping grow the younger engineers in the org without actually having to just write performance reviews and handle calibration meetings, which is really a nice thing to do. The reason I've tried to avoid doing management was it was two-fold. One of them was more personal is that ... Let me start with the other one first. The general one is because I felt that there was a lot more technical changes coming up that I would love to be involved in.

Silvia Botros: I'm very aware of the fact that if I do the move to management, I need to not be in the way for the code, like for how to build the things and it stops being about that. I'm not a huge fan of the interim stage of being asked to do both where you're in charge of people's performance reviews and you have to help grow people's careers at the same time. You're responsible for building large parts of the product yourself. Charity Majors talked about that recently. There's also that amazing book by Camille Fournier about The Manager's Path. They both acknowledge that stage, but they always say it's a difficult one that needs to be short lived and has you know a time box around it. But I knew that it would still mean like the next step would be step away from the technical and actually help with the people. And I'm fine with that, but I was like, I know myself I'm going to want to do the technical stuff and I know that we specifically at SendGrid have a lot of very interesting technical challenges coming up and I wanted to be part of them. So that was, that was the one side of it.

Silvia Botros: The other side was far more selfish just because of the fact that at the time when this fork in the road appeared for the first time for me, there was not yet any principal engineers at SendGrid who are women. I was like, "Nah, I kind of want to do that. I want to start, like I want to make the case that, yes, you can have, you can hire women engineers. They don't have to go into the human side or like the quote unquote 'soft skills' side of things to continue working and to advance their career." That's like, yeah, I can totally like go in and be part of the technical decisions and do that. I've recently given the architecture team flak because until I joined they were literally all like white dudes and they all loved plaid shirts. In fact, a specific shirt. So, when I joined the teams we sort of like decided to compromise where they decided to buy me the plaid shirt. But it's like now, yeah, like the team is not just dudes. So, I've been especially proud of that one.

Corey Quinn: It's neat to see people who have grown in their careers to incredibly lofty professional heights, remaining individual contributors. And SendGrid has a bit of a knack for this. One of the folks you have working over there used to be the CTO at a company I worked, now individual contributor. One of the most distinguished engineers I've ever had the privilege of working with. And the list goes on where there's very clearly a separate technical track at SendGrid that is not perceived as being lesser than management. And I really like that pattern and I wish that more companies would embrace that. In too many environments if you want to advance professionally, you're walking down a path of management, which is often terrible. It's you're a terrific engineer, so we're now going to focus on an orthogonal skillset that winds up having very little relevance to what made you good at this. So, we're going to lose a terrific engineer and gain a crappy manager. That sounds best for everyone, but it's the only way for you to develop. I really like it when companies go in a different direction.

Silvia Botros: And it wasn't from day one, like I said. We've had our own hurdles. Learning that lesson the hard way sometimes. We've promoted engineers into management roles and watched them not do so well. One of the people with me on the architecture team, he was sort of dragged into management for a bit and then he realizes like, it's not for me. The good thing about SendGrid and it's innate to our culture is that we have the humility, whether it's the executive team or the management team or the senior ICs to say, "Okay, that's not working. If I want to continue being here and providing value, we need to fix this part and it's fine to admit that management is not for me. I'm not going to do that." And that friend of mine, Shawn Kilgore, he ended up stepping away from management after, I think it was like a year, maybe less, and went back to, no, I want to be senior IC, I want to help this company build scalable you know long-term infrastructure that provides value, but I don't want to be, I don't want to manage people. I prefer to help the people without being directly responsible for the problems, reviews and all the other things that come along with it. And that was fine.

Silvia Botros: Unfortunately a lot of companies don't ... They consider that a failure and that you're just not good at either anymore, which is mind boggling to me. It's like, no, like I give you this entirely other job and didn't give you any help understanding how it's supposed to go, and then you failed and now I'm surprised and I'm going to let you go. It just doesn't make sense.

Corey Quinn: I think that there's a terrific story around the idea of being able to, I guess, continue to develop, nurture, and of course attract talent. It seems very strange to me that in many cases when someone is management at a company and they're not succeeding or thriving in that role, or they want to go back to working on as an IC for a variety of different topics, there's no way to do that without changing companies or losing face. People in the industry tend to view that as a perceived demotion and that's not great.

Silvia Botros: I think part of it is because there's this implied presumption that IC doesn't actually help lead that if. I've seen this before and I've argued with people on Twitter about it before. Where they'll say like senior engineer, like does she know algorithms and this many times or has like the focus with a senior individual computer, a senior software engineer is that they write code really, really well. And I've taken issue with that because ultimately I don't think that being IC means you're precluded from talking to people or precluded from helping mentor the younger engineers and the work. And once that dawn on people, it becomes clear that even as a principal engineer with no direct reports, I still have a responsibility towards everybody else in the organization to not just do things but to teach things. So, once that gets clear, you no longer have the delineation of like, yeah, the managers are higher caste than the individual contributors, and if I prefer to do IC work, then I'm going to forever have a ceiling on my career.

Corey Quinn: It's nice to see companies embrace that. I think that's something that I think the entire industry could learn from in more depth. I want to thank you for taking the time out of your day to speak with me, especially given this is your seventh anniversary at SendGrid. There are probably things you could be doing that are a lot more entertaining than listening to me prattle on. So, thank you for that.

Silvia Botros: Not at all. Thank you, Corey.

Corey Quinn: If people want to hear more from you, where can they go?

Silvia Botros: Well, I do have a blog. It's blog.dbsmasher.com and I'll make sure that you have the link for the show notes. If you would like a more stream of consciousness, there's my Twitter feed. Sometimes it is literally just screaming in the void against some sort of bug. I will occasionally OH my team, which they seem to apparently enjoy. I don't know. But whenever they say something witty, I'll tend to sometimes just OH it with no context and people seem to think that's funny. I certainly get some joy out of it. But yeah you can definitely catch me on Twitter and catch all sorts of things about what I'm doing right now that might be frustrating or even fun.

Corey Quinn: Well, thank you very much. I'll definitely put those links into the show notes. Thanks so much again for taking the time to speak with me and my ridiculous nonsense.

Silvia Botros: No worries. Thank you, Corey, for having me. It's been fun.

Corey Quinn: Silvia Botros, Principal Engineer at SendGrid. I'm Corey Quinn. This is Screaming in the Cloud.

Speaker 1: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever fine snark is sold.