Episode #129: What To Do When the Servers Go Away with Tom McLaughlin
March 21, 2022 • 43 minutes
On this episode, Jeremy and Rebecca chat with Tom McLaughlin about the challenges of adopting serverless, what happens when devs become responsible for new areas, the engineering rigor required for serverless team enablement, and much more.
Tom is a cloud infrastructure and operations engineer with 13+ years of platform operations and IT experience, and over 8 years of AWS cloud infrastructure. He has worked in companies ranging from startups to the enterprise. His areas of focus around serverless started largely on the operational aspects of building and running reliable serverless systems. More recently his efforts involve mentoring teams new to AWS and serverless, and helping them successfully adopt these technologies through training and education.
Tom is also a leading serverless advocate in the DevOps community. He is a regular speaker at DevOpsDays conferences where he works to guide operations engineers in identifying and further the skills they need to be successful with serverless infrastructure.
What drew Tom early to serverless was the prospect of having no hosts or container management platform to build and manage which yielded the question: What would he do if the servers he was responsible for went away? As an early DevOps adopter he felt it was time to take a leap again into a new and emerging technology space. He’s found enjoyment in a community of people that are both pushing the future of technology and trying to understand its effects on the future of people and businesses.
When not working, Tom can be found racing his ‘87 Buick Grand National at the dragstrip, dabbling in photography, or playing with his cat Cinnamon.
Hi everyone. I'm Jeremy Daly. Rebecca:
And I'm Rebecca Marshburn and you are listening to Serverless Chats. Hey Jeremy, what's going on?Jeremy:
Oh, it's been a busy week. I just had a very busy Tuesday. I posted a tweet about this, but essentially we recorded a podcast, as you remember. Then I was on a round table with Jeff Barr and Alex DeBrie for the DynamoDB, a decade innovation with DynamoDB. Then I published my newsletter.
Then I gave a talk at that DynamoDB event on serverless and DynamoDB. And then when that was over with, I had to go and work in my basement for, I don't know, three hours or so, trying to get it finished up, cuz I had an electrician coming who actually came today and did some work. So yeah, it was busy.
So, I actually think I've duct taped myself to the chair so that I don't fall over. I'm so exhausted.Rebecca:
Well, I'm really glad that you stepped out to get some water, to stay hydrated. And honestly, so for listeners who don't know what day it is, when we recorded this, we're recording this on a Thursday. And at first I thought you were like, Jeremy, I thought you were like, man, it's been really busy. I've had a really busy Tuesday.
And I was like, no one tell this poor man, it's actually Thursday.Jeremy:
Wait, it's Thursday already.Rebecca:
It's already Thursday and here we are recording again, with a guest who is famous for asking: what do we do when the server goes away? And then beyond that really substantial question, this guest also wrote yesterday, which was a Wednesday, on Twitter: "Tomorrow I will record a podcast while wearing a blue velour track suit because business radical is how I roll." So Jeremy, will you please introduce who this mystery guest is and then confirm or deny whether or not he really is wearing a blue track suit velour?Jeremy:
I will. And I will tell you this, this is a hard guest to get. I mean, I actually invited this guest on as one of the first guests for Serverless Chats, way back in 2019. You know, we talked to all his people. We went through all the agencies, everybody we had to to finally get this guy, but we finally have him and we have him on the show.
He is an AWS Serverless Hero, a longtime cloud infrastructure engineer, and he's been working with new teams for, I don't know how many years now, helping them to adopt serverless. Tom McLaughlin. Hey Tom, thank you so much for being here.Tom:
Hi all. Thank you for having me. I can show up here because this is one of the nice benefits of being in between jobs. So there's nobody from PR to tell me, where I can appear or not appear. So , I start the new one next week. So we, that's why I was like, yeah, we have to get this recorded now. Rebecca:
Do you know in about three minutes, there's gonna be a knock on your door and it's just gonna be like, someone secret from PR in the future. Well, super glad you're here. Can you tell us a little bit about what you do in terms of what you mean by a longtime cloud infrastructure engineer who's helping teams adopt serverless? Tell us a little bit about that work and then we'll dive into, you know, deeper questions around such topics.Tom:
Sure. So, let's see. I got into the DevOps thing a little over 10 years ago, I was one of those early people. I said, I hate setting up servers. So why don't I just automate this? A few years later, I think it was like 2013, I first started working at Amazon, managing EC2 and then around 20, oh man, it would've been 2017, I started fiddling around with Lambda and I was like, this is pretty freaking awesome cuz I really hate servers. I really hate taking care of those, even though they like, you know, I made a career of doing that. I don't wanna do that anymore. So I got interested in that. And so yeah, since mid 2017, I've been in the serverless space.
And a lot of these teams that I've worked with are now people that have been saddled with, 'Hey, now you have to learn, an entirely new architecture, new tools, by the way, here's a new layer of the stack that you need to be responsible for the infrastructure. And, probably a few other things we forgot to tell you. And here you go. Off you go, this will be easier.'
so for a lot of these teams there's a very big knowledge gap that needs to be addressed and they need someone working with them that can sit there and fill in a lot of these gaps for them. So that's the role I play. You know, you could call me like a staff engineer or something like that.
That's usually the level role that I'm at now. And that's what I'm going to. So yeah, that's what I do these days. Jeremy:
So as part of that, you know, sort of working with new teams or really sort of watching these teams, I don't wanna say struggle, but maybe struggle with going from these, you know, sort of old practices, to these new practices using serverless. So maybe start with just like, what does that look like? What does your typical company look like that's going through that transition? Tom:
I don't, first. I don't think there is a typical company. but one of the things I have noticed is, and this is something I think we discussed a few years ago that serverless, back in like 2017/2018, we thought serverless was gonna be all the rage among the startups. And it really wasn't. It ended up becoming more so at the top, the big enterprises. And it's kind of working its way down. So that's, and so those are a lot of the people, and again, I've worked with small companies, startups and, and the enterprise. So I've seen both ends. So, yeah, there is no typical company, but particularly the enterprise, you have folks that are in a large company. They have been doing things a certain way for, for quite a while.
And they're now being tasked with change. So it might not just be, you know, an architecture change. It's part of, say, digital transformation or service modernization. So, you know it's all tied together with these larger initiatives. Rebecca:
I wanna follow up on that. I mean, I was also working at AWS on the serverless team, right? And we had definitely sort of like messaging for enterprise and messaging for startups and everything in between. And I'm so curious since you have been in the business for a long time, if you have a why behind, I mean, it was sort of surprising, right?
As you said, you thought maybe startups would adopt at first and it would work its way up, but really it started, or you saw the most adoption or desire for adoption through digital transformation at the enterprise level, and then maybe some startups end up using it as well. Do you have a hypothesis? Or maybe you have like, you know, cold, hard facts where you're like, this is actually why it was more adopted at the enterprise level and here's the reasons why we were surprised, but it didn't actually catch fire, let's say, in the startup land.Tom:
I think in the startup world, let's start there. I think Kubernetes was just so attractive just because there was the mind share and, you know, you could like, you know, throw a wrench somewhere and hit some infrastructure person that could set up Kubernetes for you. I don't, you know, a lot of it's funny cuz there's a meme where this person has a toy car and it's on like a giant flatbed truck and they're like 'deployed my WordPress instance to serverless', and, yeah, I, I think there's just this in the startup world, it's like, oh, we do Kubernetes, cuz we're gonna be that big and we're gonna need all of that.
And we don't know what we're gonna need tomorrow. So we can't tie ourselves into AWS. We need this agnostic platform. So that, and, and I see that appeal. I disagree with it, but I think that's why it's really taken, you know, that's why I think it's still very common in the startup world. You know, finding the people with the skills is really easy.
You can find somebody that knows how to put some software in a container. You can find an infrastructure person that can set up and run Kubernetes for you. So. All right. Cool. Let's just go with that. On the enterprise side, the enterprise is really fun. I would tell. anybody, take some time in the enterprise, if you just want to study like organizational culture, like pretend you're an anthropologist. It's really cool. so let...Jeremy:
I can't tell if you're being facetious or not.Tom:
I literally just read to Jeremy, I was like enterprise is really fun. I was like, this is likely the first time I've actually ever heard this.Tom:
No, it's very, it's so interesting because you start talking, when you look at the enterprise, you're just kind of like, 'Well, why is that giant 5,000 person organization, or 50,000 person organization making this sort of decision?' And then you have to start kind of going through the org chart.
And you can actually trace sometimes the logic of certain decisions by looking at the org chart. So my favorite is go try and sit there and sell, you know, a IT exec on, 'Hey, well, you know, if you go serverless great, you can transfer headcounts and resources over into development. You know, the people that make money, take stuff out of the stuff that costs money to run.'
And it sounds like a compelling argument, right? You know, who doesn't wanna make more money and spend less money, you know, running all that stuff.? That's great until you realize that, yeah. the people that like, you know, do the development and the people that do the operations are two completely separate , you know, like VPs or something like that. And for each of them, it's amazing that like, for each of them, actually, that argument doesn't only not resonate. It actually doesn't make sense for them. So you, so the person that's running infrastructure, they don't want to give up, you know, their budget and like the head count and stuff like that.
So they're incentivized to, you know, let's have this and you go to an enterprise, you know, a development VP. And they're like, 'Well, I can also use Kubernetes because somebody else is already providing this.' And I, now I'm just now talking about why people would use Kubernetes instead of serverless, in an enterprise.
But that's actually one of, that was actually something I saw once before, because it was just the org going through the org chart and trying, and seeing that, like people had different motivations And people looked at the arguments that we give in just different terms than we're accustomed to. Jeremy:
So, I think 'enterprise anthropology' sounds like a really bad suit shop or something like that. but, soTom:
I was just gonna say, yeah, it's I think, you know, it's the reason I say go into the org, go into the enterprise and it's just, once you start seeing like an org chart, you can understand how decisions get made. And it's fascinating, completely fascinating to understand all this stuff.
But why would certain, you know, why would a development team inside an enterprise go serverless? One of the reasons is you will have other IT executives who will disagree with that. You know, with that first executive's thinking that 'Sure, we can just have that other group run all our infrastructure.'
You'll have another team that says, no, we actually want to be more nimble. You know that infrastructure and IT group is serving a 5,000 person organization. And you're a small hundred to maybe 200 person development team. It's kind of like, 'well, wouldn't it be pretty cool if we could actually just have, you know, if we could respond more, more quickly to our own needs instead of having to filter everything through them.'
So that is again, so that's one reason why within an organization, yes, you can definitely, you will see, teams adopting, you know, serverless within the enterprise. Jeremy:
Right. Yeah. And I think there's a something in there too about sort of total cost of ownership, and how that plays in. I mean, I would think that as a startup you'd look at it and you'd say, 'Yeah, maybe I can get somebody to set up Kubernetes.' And I think the meme you're referring to was that, you know, something on the back of, like a tiny car on the back of a flatbed truck.
And it was like, you know, and I think it was deployed to Kubernetes, not deployed to serverless, right? Like you're basically over-provisioning what you need in order to run this tiny little workload. But I think you make some good points. I mean about, you know, enterprises or different organizational units, the politics that are involved with organizations or with enterprises where it's like, 'We don't wanna give up our budgets. We don't want to give up people, you know, we wanna keep these things here.' And if you can't keep those people busy, you know, because there's things to do. It's sort of interesting, but what do you think about from the sort of a TCO standpoint? I mean, operationally an enterprise has sometimes that different mindset where they say, 'Well, we already have this massive IT department that can run Kubernetes clusters and can do all these things for us. So we're not saving anything other than, you know, repurposing those people, which we maybe don't wanna do.' So instead, you know, if our developers can work a little bit faster, like that's really not, you know, why would we wanna have that control?
So, I don't know. How do you think that plays into it? Tom:
You know, I think something that, you know I've tried to kind of hammer into folks. You know, these teams they're newly adopting is ' You should be seeing faster delivery. You should be seeing things go to market much faster and understanding that that is helping to bring in, you know, more revenue, you know, faster.
And if you, you have to, I think, really get people to understand that because I think that's where the value really is. And you have to have your developers to understand that you have to have them understand that they should be able to, after they start learning these things, they should actually start seeing, you know, like quicker progress.
Like they should start seeing that they're oh, we're gonna talk about like sprint points and stuff like that. What are those like agile or scrum things that they...Jeremy:
Story points. Tom:
Yeah. Story points and Burn downJeremy:
Burn down charts.Tom:
And cycle times. All that stuff, like you should see all those things improving.
That's what you really want to see and start getting out of it. And I've totally skipped the TCO stuff only because in a giant enterprise, nobody shows you the bill. You're a team. And you're just kinda like, 'I really don't know how much this costs. I have an idea how much this costs kind of.' But like, the funny conversation's when somebody's like, 'But this is gonna cost like 500 bucks a month to run.' It's like, well, is that expensive? And they're just like, 'I don't know. It's like neither too high. I'm pretty sure that system over there, like takes like a million dollars a month, so.' Rebecca:
Yeah, I think that's also an interesting thing, cuz you could, you can have a good idea for how much something costs. But if you don't have that in context of the business, you actually don't know how much it costs. Cuz you're like 'I can know the true number', but without having it, in stark relief against the landscape of everything that everything costs or understanding.
And I'm not saying that all businesses and organizations should be like, here is our exact line by line item to every team. That's just like a lot of mental overhead. But it is hard to know how much something costs without understanding its relative cost in terms of what the business organization is spending its money on.Tom:
Or even the value of just how much that thing is bringing in. Rebecca:
Yeah, I think without, yeah, the cost and the value are certainly different things, but they're also extremely related to be like, okay, like if it, something is a million dollars, but the value is like, you know, $6 billion. I just made that number up. Then that's obviously like a big cost for a much bigger reward.
And then that could all go all the way down to like, well, you can spend $10 on something, but if you legitimately get zero value out of it and no impact at all, then like, well, why are we even doing that? Tom:
Yup. And I think with your more advanced engineering organizations, they're gonna be having these conversations. And they're gonna start focusing on these things. When you're just starting off, your problems are gonna be, I think very different. So in the enterprise, for instance, it's not enough to just be able to figure out you know, from Amazon documentation and blog posts, how to configure something.
There's how to configure it so it also complies with, you know, IT, you know, security and all the compliance needs that your organization has. I wanna deploy this thing correctly because if I don't, it's gonna get deleted on me after it gets deployed, which is not fun. And you know, so there's that, and there's also just the, you know, taking on the new responsibilities and having to understand things like, you know, you might have a developer before that never had to care.
You know, how does a customer's request make it to my service? It's like, you know, on a diagram, it'll just be, stick figure customer. And we just put a cloud for the internet and we just draw an arrow to our service. And it's like, yeah, no, like there's a lot [inaudible] Rebecca:
When of you put it like that...Tom:
Right. It went through a lot of stuff, you know, and Jeremy:
And you spent four years in college learning how to do that. I mean, that seems ridiculous.Tom:
Yeah. So, let's talk about that a little bit more. You talked about in maybe mature or engineering organizations that are well versed in this stuff, that's one thing. But that now we're talking about these early or these people that are just getting started with it. So what are some of those common pitfalls and traps that early adopters fall into? What are some more of those? Give us the lay of the land here.Tom:
Let's see. Let me think of some of the things I've experienced. Actually let's, start with this. The first thing I think most people do is, you know, we talked about lift and shift as, picking up software and just moving it to the cloud, but there's also this lift and shift of people just picking up their skills and moving it over to serverless, saying, 'yep, I'm gonna do things, the exact way I've been doing the exact way I know. And I'm just gonna change the technology.' And that is, that is one of the, I think. the first things to address. So, I'm always adamant about like, please, please, don't go down the route of like trying to recreate AWS on your laptop so that you can do all your testing there.
I'm with Ben Kehoe on that. Let's not do that.
Also, if you're, you know, I'm in the camp of 'Yeah, unit tests are nice, but the only reason I write unit tests is cuz I really want to get like the stupid errors caught really quickly.' I just want to know that, like, I'm not gonna get some stupid syntax failure, basic logic failure once it gets deployed.
And, you know, to me, it's, you know, if you've heard the testing pyramid where the bottom is, all these fat unit tests. Somebody told me the testing hexagon where it's smaller number unit tests wide on integration tests, smaller number for ETE. So that's, yeah, people picking up their skills and just dragging them over without rethinking things is definitely the first thing. Another is you put, actually my favorite, this is still my favorite. If you're working with a team that's completely new, to, you know, to serverless building their first application, if it has DynamoDB, don't tell them about setting the billing mode. Don't. Let them find that one on their own.
Let them find, you know, that if, 'Hey, if you didn't configure this, it's gonna be a pay per request.' By the way, there's only gonna be, what is it? What's the default like five?Jeremy:
Five, I think, yeah.Tom:
Five read and write capacity units. And that's a fun one. And, that's a reason. I also, that's a reason I'm very big on testing is because, 'Hey, I want you to figure out how to do load testing, because I want you to find this before it goes to production.' And I don't wanna also, I can interject myself and say, 'Hey, you did that wrong. You missed that.' But all I've done is covered one thing, you know? I've covered one issue that you'll hit with DynamoDB. I'd rather you learn how to do this, all this other testing. So when I'm not there or there's something I forgot or something I missed, you could catch that.
Right. Right. So, but what, how do they learn that? Like, what are the learning paths now? I mean, I think we, you know, AWS has certifications, things like that. you know, there's other trainings available, but I mean, how are companies, certainly the ones that you've been working with, how are they learning that? Are they going out and getting AWS certs?
Are they just organizing things internally? Are they just reading documentation on their own? Are they hitting up against this DynamoDB charging me for, things, even though I'm not using it or whatever. And figuring out these things on their own, like, what is that path for people?
All of the above. The path is yes . So I've helped people through getting certification, big shout out to A Cloud Guru. Very helpful. I will say though that the SAA cert, in retrospect, I would do the developer associate first. I think that's probably a better direction.
Let's see. So, there is that. There's another, I've also at one point developed a training. Like a training syllabus that was designed for . Group of people to be able to go through over the course of say like a quarter. It was sprint stories and it was, you know, here's how you gradually, you know, sprint by sprint, build your application.
And that was, it was broken down so that people could take their enrichment time. So that Friday, every one or two weeks, and they could work on this. So that's another path there. I see a lot of folks that want to put production, like they want to build production applications, with this new technology.
I've never been a fan of that. Like, I don't understand, like you're just learning a brand new technology. Do you really wanna put that in front of a customer? Especially if you, particularly, if you have a very large customer base. I'm very much a fan of, if you have a culture where people are building, you know, small service, small internal services, slack bots, things like that, or things you just make, you know, life around the company or department easier. Those are the first places to start. Like, do that. And, you know, get your feet wet before you decide, 'Hey, let's rearchitect that system over there with a completely new architecture and then put it in front of customers.'
I also have a new thing that I've recently discovered the glory of step functions. Oh my God. They are.amazing. Jeremy:
they are. Tom:
I love it. And I'm even starting to think now that particularly these things that don't have to go in front of a customer, skip Lambda, go write the step functions. Like don't even let people pick up and bring their development patterns over. Like give them something brand new. Like, 'Hey, here's a bunch of YAML now you're gonna build an application with YAML.' It's I think it again, it prevents people from just picking up and blindly transferring their skills over.
It forces people to get out of their comfort zone. So, if you, you know, you're working with Lambda and you've also, you've got these other infrastructure things to solve, you're probably gonna look at Lambda first and solving those development issues because that's, the code is the domain that you know. If you take that away now, it's like, okay, now we're gonna introduce you to things like, you know, configuring services, event driven architecture, this, that, the other thing. So I'm really keen to try that in my next place of just, yeah, skipping Lambda and just going straight for step functions and see how that works out. Rebecca:
Hot takes from Tom McLaughlin in the few weeks that we had to be able to get him before he's at this next role. So the path is yes. I wrote that in all caps on Jeremy and I's shared. That's you've like really dropped some memorable bumper stickers here today. So thank you for that. Rebecca:
Okay, so I wanna talk about roles and responsibilities and that I just tried to make that sound as dry as possible. BUt I work at Common Room and we're, if I do say so myself, a very rad startup. I love being here and something that we talk about a Tom:
let people wear business radical? Oh wait. You're not even in an office, so Rebecca:
Oh, I actually am right now, if you can't tell. Aha! But, Tom:
Yeah, that's why cool black background.Tom:
Is business radical an accepted, form of dress?Rebecca:
Cuz really good in a medium that doesn't have video. Rebecca:
Right? No, it looks great. Let me tell the listeners, you look great in that blue velour track suit. It becomes you. So we talk a lot about in a startup situation at least, right? And I think this happens a lot, but, we talk a lot about that line between player/coach and everyone, you know, maybe you're a manager, but you're also, you're not just coaching because you're also needed to play because you definitely need to be like. Be in there, like doing what all the other players are doing, cuz there's not enough people to just necessarily be like, cool, go do this thing. And like, I will simply look from here.
But there's these ideas around, like, what is the right balance between being a player and a coach? And I think this can be, you know, said in a lot of different ways or thought about a lot of different ways where it's like, it's just the idea of trade offs, right? And what happens. Like how clear is the line between two separate entities trying to do two separate things? So if start up developers are, you know, the Jack and Jill, the player/coach, the everything of all trades when it comes to being responsible for new areas of an application, like, what happens when there are clear lines between developers and operations and where is that line?
Is it dev line ops? Is it DevOps, there is no line? Is it, what line should people be aiming for in terms of even thinking through at that high level? Like, what it means to be a developer in this new space, as an early adopter or someone stepping into serverless. Tom:
You know, I really don't know what it is. I don't know where the lines really are. The one, I think the one thing I would say is if I were still primarily on the op side, which I'm not anymore. I tend, you know, I'm an infrastructure engineer, I'm an operations person, but I work more with development teams.
If I was an operations person, if the thing I would want to do is probably move towards something like an enablement team. And I want to get out of fixing things and I want to move more towards building the tools that can 10 X myself. I want you to be able to download my know-how and be able to use that without me being there.
So, that could be that there's, I mean, a lot of places have this, you know, it's developer experience, developer enablement. They're building tools. They're maybe building CDK constructs that have best practices in them. So as an operations person, that's probably the direction I want to go.
Because once you got a team that's, you know, it's Lambda, it's API gate where GraphQL there's CloudFront, DynamoDB. They're responsible for keeping that up and running and you, as an operations person, there really isn't much for you to do. So, yeah, that's why, you know, the line is just so far over for these development teams that they've just usurped what my old job would've been.
You know, you were actually giving me, I actually thought you were gonna go a different direction with this question. I really did. I was actually just off to the side Googling it. Rebecca:
You were talking the player/coach and roles and responsibilities. I thought you were gonna just start talking about, so yeah what I do. Cuz I'm usually not tied directly to a team.
And so I thought you were gonna go there. And the book I was bringing up is The Staff Engineer by Will Larson. That is an awesome book. Anybody that is, you know, senior and wants to go post-senior, or even if you're just somebody that wants to go to a post-senior/ IC leadership role, that is such a great book.
It is a tremendous help for understanding your role now. You know, once you leave the confines of a single team and you're responsible for broader things, your job just changes so much and It becomes so different and you have to just figure out how to navigate that stuff. Jeremy:
Yeah. I mean, that's certainly one of those things as you graduate beyond, you know, just working on an individual team, supervising multiple teams, or even getting into strategy and things at higher levels and trying to coordinate that stuff, it gets pretty complex, but I wanna go back sort of to, I think to Rebecca's question a little bit here.
And it's something that you said where the developers have come so far into the ops world, that basically there wasn't a lot for you to do. But then on the other side of this thing, cuz I know the stuff that you've done in the past, you've written a lot of code. So you go from managing infrastructure to then going and writing a whole bunch of code.
And so there's this crossover where it's like devs to ops and ops to devs, and somewhere in between, maybe there's a thing called DevOps. I don't know, but like. I'm just curious. you know, that is an interesting shift in responsibility, right? And I think that, you know, we've talked to Charity Majors about this as well, where it's like, it's not about less ops it's about better ops, maybe. Where your ops people are freed up to do more interesting things, including the things you mentioned, like wrIting automation scripts and all kinds of things that they can do. But I'm just curious, like when that happens, you know, where is the, or what's the, or I should say maybe is there, a contention there? Is it something where as devs become more responsible for the infrastructure they control, that ops teams have to look at their roles differently?
Is there a contention there? Is there a way to make that smoother or is that just, you know, is that just growing pains?Tom:
So there are growing pains. I think, something to, I think something for these ops people to be aware of, if you find yourself writing, building more tools, writing more code, all that sort of stuff. At the end of the day, you're building a product. It doesn't matter if your product is, you know, just internal developers. You're still building a product, which means I don't have to use your product. So you, as the operations person doing software development, you need to also figure out how do I get people to use these tools that I'm using. So that's another, I think, bigger shift for ops people. There's no more, 'Well, we said, that's how you have to do it. So that's how you have to do it.'
So, it's now, you know, it's, you don't wanna, if somebody doesn't want to use your tools and do it your way, they're gonna ignore you. So. I completely lost my train of thought there, but Rebecca:
No, no, we were a little slow on the uptake to like, we could have cut you off with a question, you know? And then it would've seemed like you didn't lose your train of thought. So, we'll just cut this out and no one will ever know. So where do you see that separation today with teams embracing serverless?
Right? Like how specialized should someone be when you walk into a place? And there's sort of that, you know, they're the early adopters or they're trying to be early adopters within an organization. Do you set up guidelines or guardrails around like, Hey, this is how the new world order works. This is how you can, here's a frameworked way for you to think about responsibility. Tom:
So first off, I'm very interested in where I'm going next, because it sounds like it's gonna be a bit different from where I came from in terms of attitude, towards adopting new things. And it's not, you know, it's not like bad, you know, new things, bad versus new things good. It's just the, how you go about it.
First thing I would say is, if you're gonna adopt some new sort of technology. Get some people in the door that actually know the technology, like get a few specialists in there that really know it. You know there is a real good use for specialists.
They will save you so much time because they know the technology well. And they will show people how to do things well, instead of forcing everyone to kind of learn as they go and, hopefully, you know, pick up all the best practices, but sometimes not. The next thing is that, you know, and organizations vary with this There are organizations that emphasize everything is, you know, everything is best done when it comes up from the team, when it bubbles up from a single team. And so in those organizations, everybody kind of, you can try and herd the cats, but a lot of people are just going off in their own direction, doing their own thing.
If you have an organization where, you know, you can easily share learnings and people adopt, like pick up learnings from other teams maybe that can work. Hopefully it's with people that, you know, also have some sort of specialist that's guiding them. The other direction, or the other approach is something that, my preference is, we wanna limit. We wanna put limits and constraints in what developers are doing.
And we want, you know, we want to pick the tool. We don't wanna say, 'Hey, there's a, there's a plethora of serverless tools, Serverless Framework, SAM, CDK' instead of saying, 'Hey, each team pick whatever you want and just do it.' Instead you say it at like a department level, 'No, we're picking one and that's what everyone is going to use.'
And we're picking, you know, we're picking certain languages and those are the ones we're going to use. Because if you do, when you do that, now you can start actually building, you know, cohesive, you can start building training much easier for people. Because every, if you've got like all your teams on the same page, it's a lot easier to train that department than having every single team operating as their own like little mini republic. Jeremy:
So, you mentioned that book The Staff Engineer. But who else, who else would you say that you sort of admire? Like, which, I mean maybe which companies are doing this, right? Or like what people are writing about this, I'm sure you probably read Accelerate, things like that.
But I mean, where are the examples to look at? Like who are the role models that new companies that are adopting or companies that are adopting serverless should be following?Tom:
So I got an interesting take on this. Everybody's lying. Everybody is lying. Everyone's telling you that everything's going great. When, when actually in the organization, it's a, you know, it's like fireworks going off in all sorts of different directions. That's just the, that is really just the way it is. It's very hard for me to sit there and say, 'Oh, you wanna look at that organization.' Or, 'You wanna look at that person? I mean, I definitely say look at all the AWS Heroes. MY buddy, Matt Coulter, who I know well. We won't say why. But he, I mean, he knows his stuff quite well.
Jeremy, you know your stuff quite well. You're one of the people I go to. Ben Kehoe is another person that I look for anything he says. But really, I think what you, you kind of have to do is take everything that we say and then, you know, try ideas out and see what works for you within your organization.
If you have a, you know, start with, have an idea of where you want to get. And take the ideas that you see, you know, being floated around. And take, you know, take everything that we say and experiment and try it out and say, does this work in my organization?
Because there are things that will work in your organization that don't work in another organization or vice versa. So as you know, so you're just gonna have to experiment and figure out what, you know, what fits for you folks? Rebecca:
thank you for that. I love hearing from, from people who they admire, whether or not it's like the way an organization or a company is running or the individuals that they follow and learn from. I think it's like, that's also how we begin to follow and learn from new individuals by, you know, word of mouth, like, 'Hey, who have you learned from that I can learn from too?' I did notice that you mentioned. Ben Kehoe and Matt Coulter and Jeremy, I didn't hear my name. So we're just, it's fine. We're gonna move right through that. But I have the power here to end this conversation.Tom:
We first met because of SAR and I thank you for that very much. Jeremy:
Not the disease by the way. He is talking about Serverless Application Repository.Rebecca:
Yeah. Yeah. Tom:
I still love the idea of Serverless Application Repo. Rebecca:
The idea is right. The idea is right, Tom:
Yes. I really do. And I was, I have to thank you because again, like you, you were one of the first, you were one of the first Amazon people that ever reached out to me, I think.Rebecca:
Good. I'm so glad. Yes. Well, part of my role there, right, was like finding neat people, doing neat stuff. And then just persistently DMing and saying like, 'Hey, do you wanna talk now? Hey!' And you know, maybe that just suits my personality. So Tom, thank you so much for joining us, sharing your knowledge, joining us at this moment in your life, Tom:
Where you're able to be open and have this conversation, especially like reflective as you move into your next role. I think we're super excited to see what you do there.Jeremy:
Although, it sounds his cat might be a corporate agent trying to sabotage things.Rebecca:
His cat is a PR agent from the future. Absolutely. That's why the cat bit you at a specific moment, it was like far too 'far.'Tom:
time I've done a recording, my cat bites me. Rebecca:
That cat needs that attention, man. Tom:
had the morning show way back, she would bite me at least once an episode on camera. Rebecca:
Well, how can listeners find out more about you? Where should they find out more about you?Where should they follow you? And we'll put it all in the show notes. Tom:
Yeah, find me onTwitter. T M C L AU G H B O S. I don't have a pronounceable nick because TMCLAUGH goes back to the days when, you had, eight character usernames. So, I've had that for a very long time. And I think it's, Tara McLaughlin, also in Boston, has that on Twitter.
So I tacked on the BOS. I am gonna get that handle one of these days, you know, Jeremy:
TMC laugh. BOS.Rebecca:
So I always said 'T MCLAUGH boss' And, I know that it's you're Boston, but I always thought of it as like, like he's a boss, you know? Tom:
I'm pretty boss. Jeremy:
T McLaugh Boss.Jeremy:
Well, Tom, we've got your LinkedIn, and a few other things here that we will make sure that we put in the show notes. Thanks again. This was awesome. Tom: