Screaming in the Cloud - 11 Job Titles in 8 Years at 1 Company with Sean Kilgore

Episode Date: July 27, 2021

About SeanSean Kilgore is an Architect at Twilio, where he draws boxes, lighthouses and soapboxes. In Sean’s spare time, he enjoys reading, walking, gaming, and a well-made drink.Links:Twilio: https://www.twilio.com/Silvia Botros's Twitter: https://twitter.com/dbsmasherSean's Twitter: https://twitter.com/log1kal

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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. Your company might be stuck in the middle of a DevOps evolution without even realizing it. Lucky you.

Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy-in on DevOps practices? Well, download the 2021 State of DevOps Report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping mid-evolution firms stuck in the middle of their DevOps evolution because they fail to evolve or die like dinosaurs. The significance of organizational buy-in,

and oh, it is significant indeed, and why team identities and interaction models matter. Not to mention whether the use of automation and cloud translate to DevOps success. All that and more awaits you. Visit www.puppet.com to download your copy of the report now. Up next, we've got the latest hit from Veeam. It's climbing charts everywhere, and soon it's going to climb right into your heart.

Here it is. Well, dang. Ransomware had my data all jacked up, only I had secure backup. Then I met you, me, my AWS backup dream team, yeah. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Sean Kilgore, who's an architect at a small company called Twilio. Sean, welcome to the show. Corey, it's a pleasure to be here. It really is. You're one of those fun people that I always mean to catch up with and really do a deep dive in, but we keep passing like ships in the night. And in fact, I want to go back to

more or less what is pretty damn close to your first real job in technology. You were a network administrator at Lutheran High School in Orange, California. I was. And at that same time, I was a network administrator down the street at Chapman University, also in Orange, California. And despite that, we have traveled in many of the same circles since, but we have never met in person despite copious opportunities to do so. That is amazing. Talking to you is like looking into a funhouse mirror of what would it have been like

if I could hold down a job and was actually good at things. It's really fun. Apparently I'd be able to grow a better beard. I don't know about that. My beard's pretty patchy. Yeah, I look like an angry 14-year-old trying to prove a point to mommy and daddy,

but that's not really the direction that we need to take this in today. And you've done a lot of stuff that aligns with things that are near and dear to my heart. For the last, what is it now, six years and change, seven years and change, you've been at SendGrid, then Twilio through acquisition. And you have done basically every operations-looking job at that company. You've had a bunch of titles. You ended up going from DevOps engineer to a team lead, then to a senior DevOps engineer again, and you voluntarily moved back to an individual contributor role.

Let's start there. What was management like? Management was interesting. My first go at that, I had no idea what I was doing. And so I didn't know how to ask for the help that I needed. And so my wife and I refer to that time as the time that I played a lot of video games. Just I wasn't prepared for the emotional outlay that managing humans costs. And so I would end up spending my nights just playing video games, trying to unwind and unpack from all that.

I've managed twice now. And the second time was it went much better. I knew more of what I all that. I've managed twice now. The second time was, it went much better. I knew more of what I was doing. I had more support. The manager of the team had left. I had worked with that team very closely in the past. I'd been part of it. And so my whole purpose there was to make sure

that we didn't lose anybody after that until we found a new manager. And that actually worked out pretty well. I had to have some really difficult conversations with some people along the way, but they all stayed. They all told me that they really enjoyed me managing them. And I've had people ask me to manage them again after that, which was super bonkers. It's always flattering when you have an impact as a manager and people seek you out to work with you again. I dabbled in management as well. No one ever asked me to do it twice. And I have effectively avoided managing people here at

the Duckbill Group, just because my belief of what a good manager is, and I think it aligns with what you've already said, requires a certain selflessness and ability to focus on others and grow them. Whereas my role here is very much as face of the company. And it's, it's about me. That's not a recipe for a successful outcome for managing people and not having them rage quit. Definitely. One thing that I find is interesting about management, the higher you rise in an organization, it's counterintuitive, but the more responsibility you get, but the less you can directly affect yourself. Your entire world becomes about effectively delegating work to others and about influence. In your case now, you are an architect, which means different things at different companies.

So I'm not entirely sure I know what it means at Twilio. So first, what is an architect at Twilio and where does responsibility start and stop, I guess, is where I want to go there. So architecture at Twilio and where does responsibility start and stop, I guess, is where I want to go there. So architecture at Twilio is kind of different. Some of the architects that I've worked with in the past is the, I design everything and then engineers go and build the thing that I designed. Ah, yes. The enterprise architect approach where I'm going to sit my ivory tower and dispatch effectively winged monkeys to implement things that I don't fully understand, but I have

the flashy title. You're saying that's not what it is. There's a fine distinction here because I think that some of the people I work with would definitely say that I am up in my ivory tower. It is more about if I'm looking five years out at what capabilities my teams need to be able to provide to execute against a business strategy, that landscape is going to change immensely along the way. And so my job isn't to say, we're going to use Kubernetes, because that's what we need to do five years out. It happens to be what I'm saying right now. And I'm sure we're going to go into that, Corey. But it's less about, this is how each of these things should be strung together to achieve that

goal, and more direction setting. So I worked on something that I call the lighthouse, right? And it's a vision of the future of where we want to go. But the caveat is that if you actually go to the lighthouse, it means you hit the rocks, right? It's describing what I call the bay of appropriate futures. And you want to land somewhere in that bay, but it's not going to be the thing I wrote down five years before we get there. And so it's much more of a technical leadership position, trying to help other technologists make good technology decisions. And so it's more about making sure that all of the right questions get asked, not having all the right answers. That's the difference between some architects that I've worked with in the past. And one of the challenges in that role is that you're not

managing people directly. So what that means is that you are, on some level, not doing a lot of the hands-on keyboard implementation work yourself. And unless I dramatically misunderstand your corporate culture, you're not empowered to unilaterally fire people, which means that you can only really lead via example and influence. Tell me about that. When people ask me if they want to be architects, I ask them if they can influence without authority or if that's even interesting to them. That is definitely the thing. And so when it comes down to, man, I really wish I could fire this person, A, that never happens. But B, it's definitely about modeling behaviors. And there's a bit of management here in that making expectations

clear of senior engineers is part of my job. And helping them also be examples for other engineers is definitely a thing I get graded on. Influence without authority is sort of the definitional characteristic of being a consultant. It turns out you can't enforce anything. It has to be the strength of your ideas combined in some shops. And I admit I have a bit of a somewhat cynical view on this, but also the ability for the client to commit to their sunk cost fallacy of, well, we paid a lot of money to hear this advice. We should probably do something with it. And there's always a story of making sure that you're serving the organization

with which you work well. But when you can only influence rather than direct, it becomes a much more nuanced thing. And I feel like the single differentiator between success and failure in that role is fundamentally empathy. Am I wrong on that? Not at all. When I'm working with a very in-the-code engineer who comes to me and is trying to convince their team that they should do something, one of the things that's a stumbling block for them is that they don't realize that other people need to be influenced in ways that might be different than the way that they're influenced. So as an example, I work with a team of very senior people. I know that some people will respond well if I cite Accelerate, for example. And some people

want to hear like, well, Google does this. So it's obvious that we should do that. And trying to thread that needle with everyone in a way that gets everyone on board in the best way for all of us. When you can do that, you can be an architect. Some weeks I feel like I'm closer to architect than I do others. It seems that the idea now, solutions architect being a job role that a lot of companies have, they hurl out into the universe, is in many ways vastly misunderstood. You want to talk about some kind of architecture story where I'm going to go ahead and design an architecture that solves some business problem on a whiteboard. That's not hard to do. The hard part is then controlling for

constraints such as, yeah, we already have a thing that doesn't look anything like that, and we want to get it to that point. Oh, by the way, 18 months of downtime while we do that is not acceptable. Nothing is ever truly Greenfield. And adapting to constraints and making compromises and being realistic seems to separate the folks who are good at that from the folks who are play acting. There's another thing in there where people who've worked on the same thing for a long time sometimes have a problem seeing where you could go. And so the constraints there can be really useful in designing things. A lot of people think that Greenfield is awesome,

but Greenfield just means the possible outcomes are the entire universe. I like working in constraints, essentially. So I want to talk to you a little bit about your tenure at Twilio, where you started off at SendGrid, and then there was an acquisition, and everyone I know got super quiet for a while, because it turns out when there's a pending acquisition, talking to people about it is frowned upon, and that goes doubly so in the

context of someone who basically shitposts for a living. And I get that. I respect confidentiality, but I also don't want people to jeopardize their own position. So it's one of those, yeah, whatever you're comfortable telling me or not is fine. So we didn't talk for a while. And then the acquisition happened and now you're there and you've been there at Twilio for a couple of years or so and haven't rage quit. So apparently it's worked. What was the transition like? The transition was really interesting. A lot of people were telling me that acquisitions were universally horrible and that's not how it worked. This is the first acquisition I've been through, so I have no context. People I trust told me that this one went well. So in my role as architect, this acquisition

was kind of interesting because SendGrid had a very robust, and we've done architecture for years, and Twilio's architecture was a little bit different. It was more like, there are some really, really senior people at Twilio who have seen some things, and you should probably ask them their opinion on stuff. But there wasn't really like an architecture review process. There was definitely a, you need to write down a bunch of stuff and get some people to look at it. But it wasn't a, you need to get approved by your local architect or a group of architects. Part of that is to provide visibility across the org so that we're not duplicating work and stuff. But Twilio basically adopted SendGrid's architecture process, but it grew 10x. So at SendGrid, we had, I think, six architects. At Twilio, we have like 40 now, so not quite 10x. But trying to copy and paste that

process was kind of rough. We're still kind of making that better. And then there were a couple things, you know, as the acquired company, you kind of expect, I don't know, maybe some house cleaning to happen. And that isn't what happened. We saw a lot of really senior leaders move into positions at Twilio of leadership. So on day one, I think, Sengred's sales leader became the sales leader for all of Twilio. And that sounded, I haven't done this before, but it sounded like that's not normal. And that's happened in a couple of different spots. It's been pretty neat. And when I think about the acquisition, not just of acquiring another channel for Twilio, but kind of doing an acqui-hire of a bunch of key positions, like that was a pretty valuable one.

Let's talk about one aspect of working at Twilio that I profoundly envy you for, which is working with one of the greatest people in the world, Sylvia. Let's talk about Sylvia. She interviewed me at Syngrid. She's been here almost a year longer than I have. And just, it's been such a joy to work with her, not just because everything gets Botros around her and so we have our own built-in chaos monkeys, but also there's no one that cares more about making sure that what teams are building

won't come back and bite the team later. She's worked with, I think, maybe a 10th of the company now. And at Twilio, that's like a lot of teams trying to just help them do better and make sure that the stuff that they're building is not going to page them all the time, is actually going to serve the customer in ways that isn't surprising to the customer. I can probably talk for half an hour about my appreciation for Sylvia. Well, she was a great guest in the early days of this podcast. Sylvia Botros is phenomenal.

She has the Twitter handle of DBSmasher. So she's my default go-to on misusing things as databases. And she also is just one of the most genuinely kind people I know. She also has an aura effect where she is basically a walking EMP, and every time someone tries to show her a piece of technology, it explodes in novel and interesting ways, which frankly, as a acceptance gate for technology, is a terrific skill set to have. Does it cause problems in the office? Not normally. It caused more problems in the office when we were actually in an office together, because Sylvia maybe predictably is also a giant klutz. And so the joke is that she also EMPs

herself. In the office, she does break things, but it's never in an intended way, or it's just like a fun, oh man, the Wi-Fi is down. It must be Sylvia. Exactly. It's always nice to have someone you can blame for these things. It's SOP. Yeah. Oh, absolutely. At some point, do you ever wind up missing things such as, oh, it's probably just Sylvia. No, it was actually a problem somewhere. So we actually determined that Sylvia's EMP works at a distance. She flew somewhere close to one of our hardware data centers. And at the time that she passed it, we had an outage, like the data center went dark kind of thing. And so it still happens, even if she's not around.

We're pretty sure it's not a local phenomenon. So the thing that I know is probably going to sound completely boring and ridiculous to half the audience, while the other half of the audience sits and listens rapidly. Before I started this place, I never stayed anywhere for longer than two years, because as previously disclosed in multiple directions, I am a terrible employee. First, why did you stay at the same place for as long as you have, and what's it like? And I'm really hoping you have an answer that isn't just, oh, I've had a complete lack of ambition, because I won't believe that for a second, but it is a cop-outs. Let me just shut that down now. No, it's more, I've been here for almost eight years now and I've never done the same thing.

The fun fact that I tell people when they're on board or I'm interviewing them is I think I've had more titles than anyone at Twilio. I'm up to 11, I think. And so 11 titles in eight years, it hasn't been the same company. When I started, I was employee number 150. There were 80 of us when I started at SendGrid. I work at a company with 4,500 people now. And going through that growth, the company that I work for today, and even pre-acquisition, you would not recognize from the day I started at SendGrid. And so if I had been doing the same thing all the time,

I wouldn't still be here. There was a point before we started architecture at SendGrid, I was definitely in a spot, kind of a rut, like, cool, I can continue to do the same thing over and over. But I felt like there wasn't a lot of growth to do. Like I needed to go see something else kind of thing.. I knew really well how to do our mail stuff. And I felt like I needed to broaden my horizons a bit, or I needed to level up. And at the time, the only place to go up was to management. And then we brought in a chief architect, J.R. Jasperson. And I remember very clearly,

it was like his third day or something. We had an all-company meeting, like a luncherson. And I remember very clearly, it was like his third day or something. We had an all-company meeting, like a lunch thing. And I walked up to him and said, you don't know this yet, but you're my new mentor. Because it seems like what you're talking about is really interesting to me. And he didn't know it, but the subtext there was like, and if you don't, I'm out. And since then, the work that I do day to day is completely different. Like, I work for a platform org. This platform org is 130 people right now. It spans everything from building EC2 instances to recently, it was like Twilio's API Edge. There's such a breadth in there that I'd never do the same thing every day. I really love installing, upgrading, and fixing security agents in my cloud

estate. Why do I say that? Because I sell things for a company that deploys an agent. There's no other reason. Because let's face it, agents can be a real headache. Well, Orca Security now gives you a single tool to detect basically every risk in your cloud environment that's as easy to install and maintain as a smartphone app. It is agentless, or my intro would have gotten me in trouble here, but it can still see deep into your AWS workloads while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets, no DevOps headaches. And believe me, you will hear from those people if you cause them headaches and no performance hits on live environment. Connect your first cloud account in minutes and see for yourself at orca.security.

That's orca as in whale dot security as in that thing your company claims to care about but doesn't until right after it really should have. That's functionally, I think, the problem that I had in working in environments as a DevOps type. Because for the first three months in a job where I'm the first ops person, great, everything's on fire. I'm an adrenaline junkie in that sense.

Cool. Oh, wow, all these problems that I know how to fix. And then it gets to a reasonable level of working. And now it's just care and feeding of same. Okay, now I'm getting slightly bored. So let me look for other problems in other parts of the org. And that doesn't go super well when you're not welcome in those parts of the org, which leads to a whole bunch of challenges I've had in my career. This is incidentally why being a consultant aligns so well with me and the way I approach things. It's cool. I'm going to come in, I'm going to fix things, and then I get to leave

on day one. We know this is a time-bound engagement and that's okay. Instead of going down the path of the lies everyone tells themselves, where average tenure in this space is 18 to 24 months, but magically we're all going to lie and pretend in the interview that this is their forever job. Suddenly you're going to stay here for 25 years and get a pension and a gold watch when you retire. And it's, oh, wow, that's amazing. It sounds like really having these conversations, wearing old timey stovepipe hats. There's just so much that isn't realistic in those conversations. So I talk to people who've been down those paths, who've been at the same company for a decade or two. And the common failure mode there is that they have a year or so of experience that they repeat 10 or 20 times. And that's sad. People get stuck. What you say

absolutely resonates with me in that every year is a different thing that you're working on. You're not doing the same thing twice. I get antsy when too many days look the same one to the next. I definitely hear that. If my every day was come in, join a stand-up, talk about the problem that I had last week and still have today, it wouldn't work for me. I feel lucky that I work for an organization where outside input is actually requested and honored. So if I go to a team and just happen to have noticed something and say, hey, like this right here, you might want to take a look at. And I have some opinions here if you'd like to hear them. Like I normally get asked for that opinion and it normally turns out pretty good. There's definitely times where it's been like, no, Sean, you don't know

what you're talking about. And normally they're right. It's definitely not the same. People say you should be at a company for 18 to 24 months. And that's true if your company is totally shortchanging you. When I ask my peers at other companies about, have I gotten stiffed by staying at the same place for this long? It's definitely not. And if that wasn't true, if Twilio was holding back my compensation, maybe this would have gone a different way, but, I could go somewhere else and triple my salary, which is not an exaggeration and an unpleasant discovery when people realize that they've been taken advantage of. And credit where due, I have had conversations with people at Twilio who have been there a long time, and I have never gotten the impression that that is what's going on there. Your compensation is fair.

I want to be very clear here. This is not one of those, oh, yeah, I'm just trying to be polite because someone's being taken advantage of and doesn't even know it. No, they're doing right by their employees. The fact that I have to call them out explicitly as an example of a rarity of a company doing right by its employees is monstrous. It is. We've hired a few people recently where I found out that I think their pay was close to doubled just by coming here. And I just wish that it was more okay to call out their prior employees

publicly and be like, cool, if you work for this company, we'll probably pay you a ton more. And then there's the other side of it too, which I did early on in my career. It's, oh, I'm leaving this company and screw you all. Why are you leaving? Oh, because I'm getting a 5% raise to change jobs. I'm not saying that money should not factor into it, but at some point, like when all is said and done at that scale, it works out to be a hundred bucks a paycheck or so. Is it really worth changing for that? Maybe. If there are things you don't like about the environment, please don't let me dissuade people from interviewing for jobs. You always should be doing that on some level just so you know what the market looks like.

But I'm also a big believer in you don't need to be as mercenary as I was early on in my career. A lot of it was shaped by environments, not Chapman, I want to be clear, that were not particularly kind to staff and that I felt taken advantage of because I was. And as a result, oh, screw me, screw you. And it became a very mercenary approach that didn't serve me well. That is now a baked-in aspect of how I view careers in some respects. And that is something of a problem that I wrestle with. The mercenary thing? Yeah, I wrestle with the mercenary thing just because when I talk to someone who's having a challenge at work or something, my default instinctive gut reaction that I've learned to suppress is, oh, screw them, quit and find another job. That's not the most constructive way to work in the context of a company where you're building a career trajectory

and a reputation. And you've been there for five years and maybe rage quitting because you didn't wind up getting to pick the title of that presentation isn't the best answer. I can be remarkably petty for the reasons I'll leave a company, but that's not constructive. And I try very hard to avoid giving that advice unnecessarily to people. It's definitely just like incidents, right? It's never a root cause. It's a contributing factor. And pay is just one contributing factor. I find that a lot of people, even if they're being taken advantage of compensation-wise, they won't leave unless there's something else wrong. Yeah, compensation is absolutely a symptom. And in most cases, that's not the real reason people are going to leave. I assure you, people who work at the Duckbill Group could make more money,

objectively, somewhere else. But there's a question of what people value. We pay people well, but we don't offer fang money with the equity upside and the rest. We're not trying to pull a Netflix and pay absolute top of market in all cases to all people. I would love to be able to do that. Our margins don't yet support that. Thanks to our sponsors. We're going to continue to ratchet those prices way up. I kid, I kid. But there are business reasons why things are the way they are. What we do offer instead is things that contribute to a workplace we want to work at. More of us are parents than aren't. We don't expect people to work outside of business hours in almost any scenario short of, you know, reinvent or something. There's a very human

approach to it. We're not VC-backed at all, so we don't ever have to worry about trying to sprint to hit milestones or we're dead as a company. We have this insane secret approach called revenue and profitability that mean we can continue to iterate month to month, and as long as the trend line continues, we're happy. That kind of sustainability is awesome and is a really good indicator that a company is going to be successful to me, especially smaller companies. The decision to not take VC money and to chase sustainable revenue growth, I know everyone wants to chase the hockey sticks, but at what cost? Yeah. And I think that people put this on job seekers way too much. I have been confronted at one point, and I will not name the company, when I was interviewing years ago. And I was asked by the hiring manager, well, it seems like, I don't know. Oh yeah, I guess it was. Oh, that was, huh, I guess so. So it was a failed

attempt to call bullshit on my job history. And because I don't take things like that well, I turned it around right back on him. And I said, no, no, I appreciate that. Thank you for clarifying. That's a warning sign is when I thank you for insulting me because what's coming next is always going to sting. But while we're on the topic of turnover, your team has lost 80% of its members in the last six months. What's going on with that? Is there a problem here that I should be aware of? And suddenly the backpedaling was phenomenal. I did get an offer from that company. I did not accept it. Good. You can tell a lot about a company by how they buy their people. And if you're actively being insulted or hazed in the job interview process, no.

I want people who I choose not to hire to come away from the experience feeling respected and that they enjoyed the experience to the point where they would say nice things about us if asked or even evangelize us without ever even having to be asked. And so far we've done that because we're very intentional in how we approach things. And man, am I tired of people doing this badly. When I interview someone,

I want them to leave. And if they don't take the job, I want it to be because it wasn't the right job for them or like the team wasn't the right fit. Not because anything happened in the interview process that was like a red flag. That's the worst. I want Twilio to be a spot where there are no red flags. That would be ideal. Absolutely. I think that so many folks get it wrong, where there's this idea of, oh, I'm going to interview you, and oh, you're an ops person. Great. I want you to implement Quicksort on the whiteboard. And it's question one, do you do that a lot here? And two, no, of course you don't because I've seen your services list. There's no rhyme or reason to the order it appears in.

Maybe someone should implement Quicksort in production. And then there's the other side too of, oh great, there's this broad skillset across the entire space. I'm going to figure out where you're weak and then needle you on those. I don't like hiring for absence of weakness. I like hiring for you're really good

at things we need here and you're acceptable at the things that are non-negotiable and able to improve in areas where it becomes helpful. Yeah. The best interview process I ever had, they flew me up to San Francisco. I worked with them for a day on a real problem that they had, like pair programming. They offered me the job. It didn't work out because I didn't want to move to San Francisco, it turned out. But that interview process was super valuable to me as the candidate because I found out exactly how a day at that job would work, what it would look like. I had a very similar experience once, and the cherry on the top was they paid me a nominal

contracting rate for the day. Same. Because it was touching things that they were doing. And I think that that's another anti-pattern of, but it's a thing that also just happens to be a thing we're going to use in production, but we're not going to tell you that and we're not going to compensate you for it. I'll work on toy problems, not production in an interview context. I wanted to circle back to one thing about leaving a company like rage quitting. It's essentially, if you rage quit because of a problem, like a small thing, you're missing an opportunity to grow. And especially if I had one superpower, I would say that it's probably managing up. Part of this is just, I have a lot of privilege that lets me do that. But it is definitely a skill that I wish more people had for their own careers.

I really do too. We spend all this time practicing how to be a candidate in a job interview and almost no time training people how to be a good interviewer and what you're looking for. And you wind up with terrible things. Like I had this problem once in production that I thought was super clever. So I'm going to set it up for you and see how you would solve that problem. And if you don't follow the exact same path that I did, then we're going to go ahead and just keep shooting down anything else you suggest. No, stop it.

I do a lot of interviewing. And so I love when I learn something from a candidate because I can ask them questions that are like, how did you figure this out? Like, how did you even notice that this was a problem? And you get to go really deep in something they know the way they know it. We used to do the like, build this in LRU cache in the best big O notation time.

And if you didn't get it, you didn't get the job. Like if you did it in slower than optimum time. And I remember leaving one of the interviews and doing the recap. And it was like, if anyone came to work and did this, I would be upset at them for wasting time. This is part of the standard library of all the things that we do. Why are we asking this question? I know for a while we stopped asking the question, which is great. I don't do a lot of code interviews at Twilio, so I don't know if we do something similar yet. I should go find out. I do not know either way, to be clear. None of the stories I'm talking about involve Twilio,

though I will say I went on an interview years ago at SendGrid in Anaheim, and I don't know if I ever got a formal rejection or not afterwards, but regardless, they did not opt to hire me. In hindsight, good decision. I wonder if we were in the office at the same time. It would have been 2006, so I think it might have been a bit before your time. That was before my time. And very much credit where due. I

started my career in large-scale email systems, so SendGrid was one of those, oh, I could probably apply this skill set there. The problem, of course, was that it became pretty apparent even in those days that eventually there weren't going to be that many companies that needed that skill set. The days of an email admin in every company were drawing to a close and it was time to evolve or die. You're welcome. Of course. And again, SendGrid today under the hood, deep under the hood, does still power last week in AWS. You folks send emails and get them where they need to go, for which I thank you and the rest of the world probably does not most weeks.

Yeah. So we've covered a lot of wide ranging topics. If people want to hear more about who you are and what you have to say, where can they find you? I'm on Twitter at logical with a one and a K because I hate people who want to find me apparently, but that's L O G one KL. Twitter's probably the only thing. Excellent. We'll, of course, put a link to that in the

show notes. Sean, thank you so much for speaking with me today. I really appreciate it. Thank you so much, Corey. I love having these kind of conversations. I love that there is no plan. We're just going to have a conversation and record it. I love listening to these kinds of podcasts. Well, I like creating these kinds of

podcasts because the other ones take way too much work. Sean Kilgore, architect at Twilio. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast,

please leave a five-star review on your podcast platform of choice, along with a comment explaining how it is almost certainly the fault of Sylvia Boutris' aura. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point.

Visit duckbillgroup.com to get started. this has been a humble pod production stay humble